Re: Emacs for Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 11 Oct 2014 21:40:23 +0200
> 
> > Btw, I reviewed a few patches they have in github for a couple of
> > packages with which I'm familiar, and either the patches available
> > through github are not all the story (e.g., perhaps they use some
> > additional non-default replacements for standard library functions),
> > or their ports are crippled.  Examples include Guile (which needs to
> > be heavily patched to work on Windows) and Hunspell (likewise, and one
> > of the bugs affects Unix as well).
> 
> Guile is not available as a native package.

Then what is

  https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-guile

?

> 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?  If so, why is it in
the MinGW tree?

> The PKGBUILD and patches are here:
> 
> https://github.com/Alexpux/MSYS2-packages/tree/master/guile

This is for MSYS2 Guile.  I'm talking about this:

  https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-guile

which has its own PKGBUILD and a patch.

> Hunspell es available as a native package:
> 
> $ pacman -Ss hunspe
> mingw32/mingw-w64-i686-hunspell 1.3.3-2
>     Spell checker and morphological analyzer library and program (mingw-w64)
> mingw64/mingw-w64-x86_64-hunspell 1.3.3-2
>     Spell checker and morphological analyzer library and program (mingw-w64)
> 
> but there are some reports about crashes on the bug tracker. Maybe they
> are just discovering the issues you mention.

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.

> > In addition, at least one package -- Bison 3.0.2 -- has no patches at
> > all, and no source distro under "Sources", so either it is buggy, or
> > the patches used to build the binaries were not posted.
> 
> 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.  Anyway, this still leaves us with 4 bugs
out of what I discovered just by running the Bison test suite.  So
again, it doesn't sound like they are running the test suite, or care
about the failures it shows, because the bugs that are left cause
several dozen of tests fail.

> m4 is available as MSYS2 and MinGW-w64 packages:
> 
> $ pacman -Ss m4
> mingw32/mingw-w64-i686-m4 1.4.17-1
>     The GNU macro processor (mingw-w64)
> mingw64/mingw-w64-x86_64-m4 1.4.17-1
>     The GNU macro processor (mingw-w64)
> msys/m4 1.4.17-2 (base-devel) [instalado]
>     The GNU macro processor

Somehow missed that, sorry.

> 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.

> 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.