Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Guile is not available as a native package.
>
> Then what is
>
>   https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-guile
>
> ?

The fact that a PKGBUILD exists for MinGW-w64 (or MSYS2) does not mean
that it is considered ready for consumption. Until it does appear on the
pacman database at the user's end, the binary package is not available.

>> It depends on the MSYS2 Posix layer.
>
> Sorry, I don't understand what that means.  Are you saying it's an
> MSYS2 build, rather than a native MinGW build?

Yes.

[snip]

>> Hunspell es available as a native package:
>
> The main problem with the upstream sources, which affects Unix as
> well, is that Hunspell reports offsets in bytes, not in characters, so
> the Emacs ispell.el interface barfs unless you use a single-byte
> encoding (whereas the default is to use UTF-8 with Aspell and
> Hunspell).  So this means this port is not useful for Emacs users.

Thanks for the info. From now on I'll resist the temptation of switching
to hunspell.

>> bison is available as a MSYS2 package and as a MinGW-w64 package (the
>> "native" counterpart.) For the later, the recipe and patches are here:
>> 
>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-bison
>
> In a hidden place, I see.

Why hidden? It is stored along the rest of the MinGW-w64 packages and it
is listed on `pacman -Ss bison' as well.

[snip]

>> Gawk as a MSYS2 package:
>
> Since Gawk builds with MinGW out of the box, even without the need to
> run the configure script, not having a MinGW64 port for it is strange,
> to say the least.
>
>> Same for flex.
>
> Without Flex, you don't have a complete development environment, so
> again, not offering a MinGW Flex sounds like an omission that should
> be fixed.

Except for building a few third party packages (i.e. GCC which doesn't
require them anymore for building the released tarballs) I never use
flex/bison myself nor perceived that its usage is ubiquitous. YMMV.

>> Please note that the project is a just months old and there is no
>> central authority for ensuring that the submitted build recipes are
>> sound. If it builds, it is accepted and then they wait for bug reports.
>> If the package is too broken, it is retracted until someone fixes it.
>
> My point is that the amount of hype this project generates among its
> fans is not entirely justified by the evident omissions and (IMO)
> insufficient QA.

If there are omissions is because so far nobody cared enough about the
omitted packages and the insufficient QA is the consequence of an
heterogeneous community and the impossibility for the maintainers to
check that every package works as it should. These are ailments that
improve with age as the community grows and matures.

I remember the experience of setting up the environment for building
Emacs on Windows. It was so painful that I used the same setup and
libraries for many years, frozen on a virtual machine. Now, starting
from scratch, I can obtain all the necessary and optional (*)
requirements for building Emacs on a few minutes. Everything up to date
and on a working condition, as far as my experience goes. Same for my
C++ development enviroment (**). So the hype is justified, IMO.

* IIRC there is a problem witn the xpm package. It is installed but
  Emacs' configure script doesn't detect it. Maybe the package is
  incomplete or installed on the wrong place.

** Except Emacs itself, which I wouldn't use anyways because I have
   local patches.