Subject: bug#55930: 29.0.50; Removing some items from Emacs FAQ for MS Windows

From: Eli Zaretskii <[email-masked]>
Date: Tue, 14 Jun 2022 14:59:52 +0300

> From: Arash Esbati <[email-masked]>
> Cc: [email-masked]
> Date: Tue, 14 Jun 2022 11:23:28 +0200
> 
> Thanks.  Next iteration is attached.  Any comments welcome.

Below.

> -To compile Emacs on Windows, you will need the MinGW port of GCC and
> -Binutils, the MinGW runtime and development environment, and the MSYS
> -suite of tools.  For the details, see the file @file{nt/INSTALL} in
> -the Emacs source distribution.
> +To compile Emacs on Windows, you will need either the MinGW-w64 port
> +of GCC and Binutils, the MinGW-w64 runtime and development
> +environment, and the MSYS2 suite of tools, or the MinGW port of GCC
> +and the MSYS suite of tools.  For the details, see the files
> +@file{nt/INSTALL.W64} or @file{nt/INSTALL} in the Emacs source
> +distribution.

Instead of saying everything twice, once for MinGW64 and then for
MinGW, I'd prefer to say it once for MinGW64, and mention MinGW only
in one or two places, where the we explain the difference.  That would
be consistent with our recommendation to use MinGW64 except in rare
exceptions, and will also avoid annoying repetition.

> +Choosing the right environment from the ones mentioned above depends
> +on your requirements and the Windows version you're using.  The list
> +below should give some guidance:
> +
> +@itemize @w{}
> +@item
> +MinGW-w64 and MSYS2 (requires 64-bit Windows 7 or newer)
> +
> +@itemize
> +@item
> +You want to build a 64-bit Emacs executable.
> +@item
> +You want to build a 32-bit Emacs executable and want to use a newer
> +version of GCC than 9.x.
> +@item
> +You want to have access to recent versions of other libraries for
> +displaying images, TLS etc@. out of the box.
> +@end itemize
> +
> +@item
> +MinGW and MSYS
> +@itemize
> +@item
> +You're using a 32-bit version of Windows.
> +@item
> +You're using a Windows version prior to Windows 7.
> +@end itemize
> +@end itemize

This again treats the two flavors of MinGW as equal, which I think is
not what we want.  My suggestion is to make it shorter and more to the
point by saying something like

  We recommend that you use MinGW64, unless you need to build Emacs
  for running on versions of MS-Windows before Windows 7.

I see no reason to say more or give more detailed list of
considerations.

>  Latest versions of GDB might refuse to load the init file for security
>  reasons, unless you customize GDB; alternatively, use an explicit
> -@kbd{source ./gdbinit} command after entering GDB.
> -} in that directory, to define some extra commands for working with
> -lisp while debugging, and set up breakpoints to catch abnormal
> -aborts.
> +@kbd{source ./gdbinit} command after entering GDB.  } in that
> +directory, to define some extra commands for working with lisp while
> +debugging, and set up breakpoints to catch abnormal aborts.

This looks like unnecessary whitespace change, perhaps caused by
refilling the text?  The newline before the closing "}" of @footnote
is deliberate and shouldn't be removed, as it makes it easier to
realize where the footnote ends.

> @@ -1645,8 +1679,8 @@ Attachments with Gnus
>  In your @env{HOME} directory create a file called @file{.mailcap},
>  with contents like the following:
>  @example
> -application/zip "C:/Program Files/7-Zip/7zFM.exe"
> -video/* "C:/Program Files/VideoLAN/VLC/vlc.exe"
> +application/zip; "C:/Program Files/7-Zip/7zFM.exe"
> +video/*; "C:/Program Files/VideoLAN/VLC/vlc.exe"
>  @end example

Is that semi-colon really necessary?  Did the Gnus syntax change?

>  Another possibility is Hunspell, which is available from
>  @uref{https://sourceforge.net/projects/ezwinports/files/?source=navbar,
> -the ezwinports site}.
> +the ezwinports site}.  If you're using the MSYS2 distribution, you can
> +install a recent version of either GNU Aspell or Hunspell through the
> +package manager Pacman.  @xref{Other useful ports}.

Is Hunspell offered by MSYS2 a MinGW64 program or an MSYS program?  If
the latter, we should at least warn people about potential issues with
I/O incompatibilities.

Thanks.