Emacs for Windows

Emacs for Windows

[Alexander Shukaev]

Hello everyone,

I've been providing high-quality native builds of Vim for Windows for quite
some time now. The biggest point is that both x86 (32-bit) and x64 (64-bit)
architectures are supported. They have become extremely popular ever since.

Now I would like to spread out news that I've started Emacs for Windows
<https://bitbucket.org/Haroogan/emacs-for-windows>. It aims to provide
high-quality native builds of Emacs for Windows, and once again, x86
(32-bit) and x64 (64-bit) architectures are supported (unlike official
binaries). Many external features and their corresponding runtime (shared)
libraries (DLLs) are already included, so there is no need to search
through different binary repositories to get up-to-date GnuTLS, for
example, or DBUS, and many others. These features have lots of runtime
dependencies, building which is quite cumbersome (if possible at all) for
inexperienced users. From now on, all of that is included in my
distributions.

I'm looking forward to some feedback, if anybody finds that useful and
wants me to continue to support that project actively. It does not mean
that I'm going to drop that at all otherwise (since I'm using it as well
for myself), but if there is lack of public interest, then I would probably
update it much rarer than I could otherwise.

Kind regards,
Alexander Shukaev

Re: Emacs for Windows

[H. Dieter Wilhelm]

Alexander Shukaev <haroogan@gmail.com> writes:

> Hello everyone,
>
> I've been providing high-quality native builds of Vim for Windows for quite
> some time now. The biggest point is that both x86 (32-bit) and x64 (64-bit)
> architectures are supported. They have become extremely popular ever since.
>
> Now I would like to spread out news that I've started Emacs for Windows
> <https://bitbucket.org/Haroogan/emacs-for-windows>. It aims to provide
> high-quality native builds of Emacs for Windows, and once again, x86
> (32-bit) and x64 (64-bit) architectures are supported (unlike official
> binaries). Many external features and their corresponding runtime (shared)
> libraries (DLLs) are already included, so there is no need to search
> through different binary repositories to get up-to-date GnuTLS, for
> example, or DBUS, and many others. These features have lots of runtime
> dependencies, building which is quite cumbersome (if possible at all) for
> inexperienced users. From now on, all of that is included in my
> distributions.
>
> I'm looking forward to some feedback, if anybody finds that useful and
> wants me to continue to support that project actively. It does not mean
> that I'm going to drop that at all otherwise (since I'm using it as well
> for myself), but if there is lack of public interest, then I would probably
> update it much rarer than I could otherwise.

I'm using Emacs mainly under Linux, but at work I'm forced to use
Windows as well. Sure enough, I'm installing Emacs under Windows as well
but there I'm not able (not knowledgeable enough) to compile the latest
and greatest, so I'm glad to hear from your initiative, thank you for
your effort and please keep it up.

   Dieter
-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: Emacs for Windows

[E Sabof]

Last time I've tried using Emacs on Windows, finding adequate replacements for Unix utilities and libraries was a problem. There should be demand for a well-researched, batteries-included distribution.

Evgeni

Alexander Shukaev <haroogan@gmail.com> writes:

> Hello everyone,
>
> I've been providing high-quality native builds of Vim for Windows for quite
> some time now. The biggest point is that both x86 (32-bit) and x64 (64-bit)
> architectures are supported. They have become extremely popular ever since.
>
> Now I would like to spread out news that I've started Emacs for Windows
> <https://bitbucket.org/Haroogan/emacs-for-windows>. It aims to provide
> high-quality native builds of Emacs for Windows, and once again, x86
> (32-bit) and x64 (64-bit) architectures are supported (unlike official
> binaries). Many external features and their corresponding runtime (shared)
> libraries (DLLs) are already included, so there is no need to search
> through different binary repositories to get up-to-date GnuTLS, for
> example, or DBUS, and many others. These features have lots of runtime
> dependencies, building which is quite cumbersome (if possible at all) for
> inexperienced users. From now on, all of that is included in my
> distributions.
>
> I'm looking forward to some feedback, if anybody finds that useful and
> wants me to continue to support that project actively. It does not mean
> that I'm going to drop that at all otherwise (since I'm using it as well
> for myself), but if there is lack of public interest, then I would probably
> update it much rarer than I could otherwise.
>
> Kind regards,
> Alexander Shukaev

Re: Emacs for Windows

[Pascal J. Bourguignon]

E Sabof <esabof@gmail.com> writes:

> Last time I've tried using Emacs on Windows, finding adequate
> replacements for Unix utilities and libraries was a problem. There
> should be demand for a well-researched, batteries-included
> distribution.

There is.  It is called cygwin.

http://cygwin.com/setup.exe


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Emacs for Windows

[E Sabof]

Last time I checked (+1 year ago),it came with an outdated Emacs
version, and it's utilities had interoperability issues with GNU
binaries. Too much time has passed for me to remember the specifics.

Evgeni

Pascal J. Bourguignon <pjb@informatimago.com> writes:

> E Sabof <esabof@gmail.com> writes:
>
>> Last time I've tried using Emacs on Windows, finding adequate
>> replacements for Unix utilities and libraries was a problem. There
>> should be demand for a well-researched, batteries-included
>> distribution.
>
> There is. It is called cygwin.
>
> http://cygwin.com/setup.exe

Re: Emacs for Windows

[John Mastro]

Hi all,

E Sabof <esabof@gmail.com> wrote:
> Last time I checked (+1 year ago),it came with an outdated Emacs
> version, and it's utilities had interoperability issues with GNU
> binaries. Too much time has passed for me to remember the specifics.

When I have to use Windows (at work), I use the "normal" (i.e.
non-Cygwin) build of Emacs, but I make heavy use of Cygwin for the shell
and all the standard command line tools.

The main elements of my configuration are:
- Make c:\ Cygwin's root (I think I got this from a Steve Yegge article)
- In init.el, add /bin to "PATH" and `exec-path'
- Set each of these to Cygwin's ZSH/Bash/whatever:
  - "SHELL"
  - `shell-file-name'
  - `explicit-shell-file-name'
  - `ediff-shell'

I also set `null-device' to "/dev/null", though I don't remember why.

I've been very happy with the result. I haven't run into any real
interoperability issues, though of course YMMV.

-- 
john

Re: Emacs for Windows

[Glenn Morris]

E Sabof wrote:

> Last time I checked (+1 year ago),it came with an outdated Emacs
> version,

Cygwin packaged the last two Emacs releases within days of them being made:

https://cygwin.com/ml/cygwin-announce/2013-03/msg00019.html
https://cygwin.com/ml/cygwin-announce/2012-08/msg00022.html

> Too much time has passed for me to remember the specifics.

Sounds like your recollection is faulty.

Re: Emacs for Windows

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Fri, 10 Oct 2014 03:07:52 +0200
> 
> E Sabof <esabof@gmail.com> writes:
> 
> > Last time I've tried using Emacs on Windows, finding adequate
> > replacements for Unix utilities and libraries was a problem. There
> > should be demand for a well-researched, batteries-included
> > distribution.
> 
> There is.  It is called cygwin.

Not something to be suggested as the first choice, since Cygwin lives
in its own Posix world, subtly incompatible with the native Windows
world.  E.g., you will be unable to pass Windows d:\foo\bar file names
to Cygwin utilities, unless you install support packages to do that.
And there subtle issues with subprocess I/O.

I recommend native MinGW-compiled utilities, unless the OP wants those
for which native ports simply don't exist (e.g., those that require
the Posix 'fork' semantics).

Re: Emacs for Windows

[Eli Zaretskii]

> From: E Sabof <esabof@gmail.com>
> Date: Thu, 09 Oct 2014 23:37:38 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> Last time I've tried using Emacs on Windows

When was that?

> finding adequate replacements for Unix utilities and libraries was a
> problem.

Which utilities did you not find easily, and where did you look?  I
can show 3 URLs where you will find MinGW binaries of everything
(well, everything I have on my systems ;-).

> There should be demand for a well-researched, batteries-included distribution.

I don't think everything should be in the same zip, though.  Doing so
causes trouble in the long run, because different packages have
different schedules, and you want to upgrade to the newer versions
from time to time.

Re: Emacs for Windows

[Stefan Monnier]

>> There should be demand for a well-researched,
>> batteries-included distribution.
> I don't think everything should be in the same zip, though.  Doing so
> causes trouble in the long run, because different packages have
> different schedules, and you want to upgrade to the newer versions
> from time to time.

Isn't there some kind of package distribution system for Windows (à la
Debian's APT, Redhat's RPM, or MacPorts, Fink, younameit)?


        Stefan

Re: Emacs for Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 Oct 2014 08:36:41 -0400
> 
> Isn't there some kind of package distribution system for Windows (à la
> Debian's APT, Redhat's RPM, or MacPorts, Fink, younameit)?

Not one that is widely used, and not present out of the box on every
Windows machine.

There's "Windows Update", but that only updates OS components.

Re: Emacs for Windows

[Stefan Monnier]

>> Isn't there some kind of package distribution system for Windows (à la
>> Debian's APT, Redhat's RPM, or MacPorts, Fink, younameit)?
> Not one that is widely used, and not present out of the box on every
> Windows machine.

I definitely don't mean one that's present out of the box.  But one that
people can easily install once and then use it to
install/uninstall/update Emacs and whatever other Free Software
she wants.

I think such a package manager would really help spread the use of Free
Software under Windows.


        Stefan

Re: Emacs for Windows

[David Engster]

Stefan Monnier writes:
>>> Isn't there some kind of package distribution system for Windows (à la
>>> Debian's APT, Redhat's RPM, or MacPorts, Fink, younameit)?
>> Not one that is widely used, and not present out of the box on every
>> Windows machine.
>
> I definitely don't mean one that's present out of the box.  But one that
> people can easily install once and then use it to
> install/uninstall/update Emacs and whatever other Free Software
> she wants.
>
> I think such a package manager would really help spread the use of Free
> Software under Windows.

There's wpkg and Chocolatey, and from my impression the latter is
getting more and more popular:

https://chocolatey.org/

It already has an Emacs package.

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Fri, 10 Oct 2014 16:16:03 +0200
> 
> There's wpkg and Chocolatey, and from my impression the latter is
> getting more and more popular:
> 
> https://chocolatey.org/
> 
> It already has an Emacs package.

But almost nothing of interest to Emacs users except Emacs itself,
AFAICS (apologies if I missed something).  It has a long way to go,
and it must convince the few people who produce high-quality ports to
distribute those ports via those package managers.  It is much easier
to create a zip file of a binary distribution that use one of those.

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Fri, 10 Oct 2014 16:16:03 +0200
>> 
>> There's wpkg and Chocolatey, and from my impression the latter is
>> getting more and more popular:
>> 
>> https://chocolatey.org/
>> 
>> It already has an Emacs package.
>
> But almost nothing of interest to Emacs users except Emacs itself,
> AFAICS (apologies if I missed something).

It seems that most of the packages are non-free, indeed, and the
Chocolatey maintainers do not seem to care much about free software (it
seems you cannot search by license, for instance).

But there are things like GNU make, cmake, git, mercurial, wget,
tightvnc, clink, CLISP, Racket, gcc-arm, Python, Ruby, TCL, which is all
stuff which I currently have to install manually, so it at least gets me
thinking into trying it out.

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 10 Oct 2014 18:04:48 +0200
> 
> Eli Zaretskii writes:
> >> From: David Engster <deng@randomsample.de>
> >> Date: Fri, 10 Oct 2014 16:16:03 +0200
> >> 
> >> There's wpkg and Chocolatey, and from my impression the latter is
> >> getting more and more popular:
> >> 
> >> https://chocolatey.org/
> >> 
> >> It already has an Emacs package.
> >
> > But almost nothing of interest to Emacs users except Emacs itself,
> > AFAICS (apologies if I missed something).
> 
> It seems that most of the packages are non-free, indeed, and the
> Chocolatey maintainers do not seem to care much about free software (it
> seems you cannot search by license, for instance).

Indeed, that's discouraging.

> But there are things like GNU make, cmake, git, mercurial, wget,
> tightvnc, clink, CLISP, Racket, gcc-arm, Python, Ruby, TCL, which is all
> stuff which I currently have to install manually, so it at least gets me
> thinking into trying it out.

But some of them seem to be sporadically supported.  E.g., they offer
Make 3.81, whereas GNU Make 4.1 was released a few days ago (so at
least 3.82 and 4.0 are missing).

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
> But some of them seem to be sporadically supported.  E.g., they offer
> Make 3.81, whereas GNU Make 4.1 was released a few days ago (so at
> least 3.82 and 4.0 are missing).

Yes, I guess that package needs a maintainer. But at least there is
already one to build upon.

I think that wpkg, being based on dpkg/apt, might be better technically
and from a license point of view, but I can't even browse the "Package
Explorer" on the site, so that's even more discouraging...

-David

Re: Emacs for Windows

[David Engster]

David Engster writes:
> Eli Zaretskii writes:
>> But some of them seem to be sporadically supported.  E.g., they offer
>> Make 3.81, whereas GNU Make 4.1 was released a few days ago (so at
>> least 3.82 and 4.0 are missing).
>
> Yes, I guess that package needs a maintainer.

Actually, I think that package is simply taken from the gnuwin32
project, and there it wasn't updated since 2006... Unfortunately, it's
the first hit I get when I search for "gnu make windows". I usually
compile GNU Make myself on Windows, which is easy enough.

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 10 Oct 2014 18:23:28 +0200
> 
> I usually compile GNU Make myself on Windows, which is easy enough.

With Guile support?

Re: Emacs for Windows

[David Engster]

Eli Zaretskii schreibt:
>> From: David Engster <deng@randomsample.de>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Fri, 10 Oct 2014 18:23:28 +0200
>> 
>> I usually compile GNU Make myself on Windows, which is easy enough.
>
> With Guile support?

No. That obviously brings a bunch of dependencies in, and I don't need
it.

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Fri, 10 Oct 2014 21:13:00 +0200
> 
> Eli Zaretskii schreibt:
> >> From: David Engster <deng@randomsample.de>
> >> Cc: help-gnu-emacs@gnu.org
> >> Date: Fri, 10 Oct 2014 18:23:28 +0200
> >> 
> >> I usually compile GNU Make myself on Windows, which is easy enough.
> >
> > With Guile support?
> 
> No. That obviously brings a bunch of dependencies in, and I don't need
> it.

The point is building Make with Guile support is not really easy
enough.

As for "don't need" part: Guile support in Make is still very young,
but a day might come when some project you'd like to build will use
Guile extensions, and it would be nice to have that supported when it
happens.

(I'm going to upload such a binary in  week or two.)

Re: Emacs for Windows

[Noam Postavsky]

David Engster <deng <at> randomsample.de> writes:
> 
> It seems that most of the packages are non-free, indeed, and the
> Chocolatey maintainers do not seem to care much about free software (it
> seems you cannot search by license, for instance).

Last time I looked for this, I settled on Npackd. I didn't end up using the
machine I installed in on very much, but I can at least say it does show
licenses and allow sorting search results by license. What I remember of
Chocolatey is that it's rather focused on .NET developers.

Re: Emacs for Windows

[Robert Thorpe]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Engster <deng@randomsample.de>
>> Date: Fri, 10 Oct 2014 16:16:03 +0200
>> 
>> There's wpkg and Chocolatey, and from my impression the latter is
>> getting more and more popular:
>> 
>> https://chocolatey.org/
>> 
>> It already has an Emacs package.
>
> But almost nothing of interest to Emacs users except Emacs itself,
> AFAICS (apologies if I missed something).  It has a long way to go,
> and it must convince the few people who produce high-quality ports to
> distribute those ports via those package managers.  It is much easier
> to create a zip file of a binary distribution that use one of those.

On MS Windows I generally use mingw because I use a lot of native Windows
programs.

The problem I've found is knowing which port to pick since there are
several systems (mingw, mingw2, gnuwin32 & ezwinports).  There's a lot of overlap in the programs they provide

Eli, what's the advantage of your ezwinports over the ports provided by
others?

BR,
Robert Thorpe

Re: Emacs for Windows

[Eli Zaretskii]

> From: Robert Thorpe <rt@robertthorpeconsulting.com>
> Cc: 
> Date: Sat, 11 Oct 2014 16:46:22 +0100
> 
> Eli, what's the advantage of your ezwinports over the ports provided by
> others?

What others?  I only build a package if either there are no Windows
ports at all for it, or the existing ports are very old, or buggy, or
broken.  I'm like you: if a reasonably good port of a package already
exists, I prefer to install it, rather than build it myself.  So
there's nothing you can compare with what I put on the ezwinports
site.

Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli, what's the advantage of your ezwinports over the ports provided by
>> others?
>
> What others?  I only build a package if either there are no Windows
> ports at all for it, or the existing ports are very old, or buggy, or
> broken.  I'm like you: if a reasonably good port of a package already
> exists, I prefer to install it, rather than build it myself.  So
> there's nothing you can compare with what I put on the ezwinports
> site.

I think that this directly addresses the OP question: ezwinports's
packages contain changes that enhances the performance and robustness
(sometimes by a large amount) over those built from the pristine
sources, if there are alternatives at all.

Re: Emacs for Windows

[Robert Thorpe]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Eli, what's the advantage of your ezwinports over the ports provided by
>>> others?
>>
>> What others?  I only build a package if either there are no Windows
>> ports at all for it, or the existing ports are very old, or buggy, or
>> broken.  I'm like you: if a reasonably good port of a package already
>> exists, I prefer to install it, rather than build it myself.  So
>> there's nothing you can compare with what I put on the ezwinports
>> site.
>
> I think that this directly addresses the OP question: ezwinports's
> packages contain changes that enhances the performance and robustness
> (sometimes by a large amount) over those built from the pristine
> sources, if there are alternatives at all.

Yes, that answers my question.  I'm only a casual user of most of these
programs, so I wouldn't know what versions are very old or buggy.  I'll
try it out.

BR,
Robert Thorpe

Re: Emacs for Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 Oct 2014 09:48:45 -0400
> 
> I definitely don't mean one that's present out of the box.  But one that
> people can easily install once and then use it to
> install/uninstall/update Emacs and whatever other Free Software
> she wants.
> 
> I think such a package manager would really help spread the use of Free
> Software under Windows.

Like I said, I'm not aware of such a beast.  Some projects have their
own facilities, specific to the project (Cygwin and MinGW each have
such thing), but they are incompatible and cannot read each other's
metadata.  To say nothing of the fact that they are only good for
ports that are offered by the respective projects, and so are useless
for 3rd-party ports.

Re: Emacs for Windows

[Stefan Monnier]

> Like I said, I'm not aware of such a beast.  Some projects have their
> own facilities, specific to the project (Cygwin and MinGW each have
> such thing), but they are incompatible and cannot read each other's
> metadata.  To say nothing of the fact that they are only good for
> ports that are offered by the respective projects, and so are useless
> for 3rd-party ports.

Incompatibility between systems is mostly unavoidable.
And "they only support the package they offer" is also
largely unavoidable.

I'm surprised nobody has tried to solve this problem: contact all the
people who work(ed) on related projects (mingw, gnuwin32, chocolatey,
wpkg, you name it; cygwin is probably out because it works within
a slightly different domain and is already "the name of the game" within
its own domain) and try to come up with a plan to consolidate them into
a single system.

I mean, distribution via zip files is so painful for the user who has to
figure out on his own how to upgrade from one version to another, plus
all the dependencies, etc...  How do people live with that?

Oh well, I guess it's good: it motivates users to try another OS,


        Stefan

Re: Emacs for Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 Oct 2014 13:33:13 -0400
> 
> I'm surprised nobody has tried to solve this problem

I think that's because there is no problem.

> I mean, distribution via zip files is so painful for the user who has to
> figure out on his own how to upgrade from one version to another, plus
> all the dependencies, etc...

If the package is done well, then all the dependencies are already
bundled.  And then all you need is unzip the file.  How hard can that
be?

> How do people live with that?

I can tell you that no one ever asked me to provide the binary zips I
upload in any other form.  Which makes me think there is no problem.

Re: Emacs for Windows

[Stefan Monnier]

>> I mean, distribution via zip files is so painful for the user who has to
>> figure out on his own how to upgrade from one version to another, plus
>> all the dependencies, etc...
> If the package is done well, then all the dependencies are already
> bundled.  And then all you need is unzip the file.  How hard can that
> be?

How is that going to tell you when a bugfix release has been released?
How is that going to choose where to unzip?
How is that going to uninstall the old version?
And of course, you end up with umpteen copies of the dependencies, but
I guess only anal-retentive nit pickers will care about the wasted disk
and RAM space.

>> How do people live with that?
> I can tell you that no one ever asked me to provide the binary zips I
> upload in any other form.  Which makes me think there is no problem.

In the absence of a package manager, there's of course no other form
that could be requested, indeed.


        Stefan

Re: Emacs for Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 Oct 2014 14:34:11 -0400
> 
> >> I mean, distribution via zip files is so painful for the user who has to
> >> figure out on his own how to upgrade from one version to another, plus
> >> all the dependencies, etc...
> > If the package is done well, then all the dependencies are already
> > bundled.  And then all you need is unzip the file.  How hard can that
> > be?
> 
> How is that going to tell you when a bugfix release has been released?

You watch the site where you downloaded the previous one from.

> How is that going to choose where to unzip?

It doesn't.  _You_ decide.  Some see that as an advantage.

> How is that going to uninstall the old version?

No need, the new files will overwrite the old ones.

> And of course, you end up with umpteen copies of the dependencies, but
> I guess only anal-retentive nit pickers will care about the wasted disk
> and RAM space.

Exactly.  Besides, other packages, not yet updated, could still need
the old dependencies anyway.  Even the omniscient installers always
ask you whether to remove shared libraries they _think_ are no longer
needed (and I personally always say NO).

> >> How do people live with that?
> > I can tell you that no one ever asked me to provide the binary zips I
> > upload in any other form.  Which makes me think there is no problem.
> 
> In the absence of a package manager, there's of course no other form
> that could be requested, indeed.

The other form is some kind of installer.

Re: Emacs for Windows

[Stefan Monnier]

>> How is that going to tell you when a bugfix release has been released?
> You watch the site where you downloaded the previous one from.

Right, and of course that's a different site for each package.  To me
that reads "nightmare" ;-)

>> How is that going to choose where to unzip?
> It doesn't.  _You_ decide.  Some see that as an advantage.

I can definitely see the advantage of doing things manually, but in my
experience, the majority of users is not very disciplined, so this one
reads like "big mess".

>> How is that going to uninstall the old version?

> No need, the new files will overwrite the old ones.

>> And of course, you end up with umpteen copies of the dependencies, but
>> I guess only anal-retentive nit pickers will care about the wasted disk
>> and RAM space.
> Exactly.  Besides, other packages, not yet updated, could still need
> the old dependencies anyway.

So as long as there's no new release of Emacs (say), you'll keep on
using whichever version of the libraries was current at the time, with
their security bugs and all.  Yay!

> The other form is some kind of installer.

Which wouldn't make any difference, except maybe in choosing the place
where you install the files, which is the more minor of the problems.


        Stefan

Re: Emacs for Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 11 Oct 2014 09:26:15 -0400
> 
> >> How is that going to tell you when a bugfix release has been released?
> > You watch the site where you downloaded the previous one from.
> 
> Right, and of course that's a different site for each package.  To me
> that reads "nightmare" ;-)

That's an exaggeration: there are maybe 2 or sites to watch.

> >> How is that going to choose where to unzip?
> > It doesn't.  _You_ decide.  Some see that as an advantage.
> 
> I can definitely see the advantage of doing things manually, but in my
> experience, the majority of users is not very disciplined, so this one
> reads like "big mess".

Complaints (or rather lack thereof) on my site is evidence to the
contrary.

> >> How is that going to uninstall the old version?
> 
> > No need, the new files will overwrite the old ones.
> 
> >> And of course, you end up with umpteen copies of the dependencies, but
> >> I guess only anal-retentive nit pickers will care about the wasted disk
> >> and RAM space.
> > Exactly.  Besides, other packages, not yet updated, could still need
> > the old dependencies anyway.
> 
> So as long as there's no new release of Emacs (say), you'll keep on
> using whichever version of the libraries was current at the time, with
> their security bugs and all.  Yay!

In that hypothetical situation, I have no choice: the updated library
will most probably be incompatible with the Emacs binary built against
the older one.  I must wait till The Powers That Be produce a new
Emacs binary for me (or build it myself -- which is how the ezwinports
site started).

> > The other form is some kind of installer.
> 
> Which wouldn't make any difference, except maybe in choosing the place
> where you install the files, which is the more minor of the problems.

That's not the point.  The point is, there are no requests to use an
installer.

Give up, Stefan!  You see grave problems where there are at most minor
ones, or none at all.

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sat, 11 Oct 2014 09:26:15 -0400
>> 
>> >> How is that going to tell you when a bugfix release has been released?
>> > You watch the site where you downloaded the previous one from.
>> 
>> Right, and of course that's a different site for each package.  To me
>> that reads "nightmare" ;-)
>
> That's an exaggeration: there are maybe 2 or sites to watch.

Depends on what you have installed. I'd have to watch:

- ezwinports, obviously. :-)

- Emacs - depends on who is currently providing a binary, switches
  pretty much every year.

- MinGW/MSys

- GNUWin32

- MSYSGit

- GnuPG

- Mercurial

- Python, Ruby: respective homepages

- GNU Global

- Exuberant Ctags

- Windows-only-but-free stuff like Clink, ConEmu, Putty/Plink

That's just off the top of my head, I'm sure there's more. Obviously, I
don't check all those regularly, only when I see the need, but that's
not a good solution.

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 11 Oct 2014 16:44:58 +0200
> 
> Eli Zaretskii writes:
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date: Sat, 11 Oct 2014 09:26:15 -0400
> >> 
> >> >> How is that going to tell you when a bugfix release has been released?
> >> > You watch the site where you downloaded the previous one from.
> >> 
> >> Right, and of course that's a different site for each package.  To me
> >> that reads "nightmare" ;-)
> >
> > That's an exaggeration: there are maybe 2 or sites to watch.
> 
> Depends on what you have installed. I'd have to watch:
> 
> - ezwinports, obviously. :-)
> 
> - Emacs - depends on who is currently providing a binary, switches
>   pretty much every year.
> 
> - MinGW/MSys
> 
> - GNUWin32
> 
> - MSYSGit
> 
> - GnuPG
> 
> - Mercurial
> 
> - Python, Ruby: respective homepages
> 
> - GNU Global
> 
> - Exuberant Ctags
> 
> - Windows-only-but-free stuff like Clink, ConEmu, Putty/Plink
> 
> That's just off the top of my head, I'm sure there's more. Obviously, I
> don't check all those regularly, only when I see the need, but that's
> not a good solution.

First, even the above is not a large list.  Second, I think you
exaggerate a little bit (e.g., GnuWin32 didn't see any new versions
since 2010, so no need to watch them anymore.  MinGW/MSYS and PuTTY
are likewise very seldomly updated.

So the problem is not as hard as Stefan might think.

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
> First, even the above is not a large list.  Second, I think you
> exaggerate a little bit (e.g., GnuWin32 didn't see any new versions
> since 2010, so no need to watch them anymore.  MinGW/MSYS and PuTTY
> are likewise very seldomly updated.

Yes, that's why I practically never check them. If there's a security
update, or a nice new feature, I probably won't notice. Or what about
the latest bash security problem? I actually don't know how many
bash.exe I have on my Windows system in need of an update.

Oh, and don't get me started on MsysGit shipping its own MSYS
environment, which is oh-so-slightly incompatible to the one from MSYS
itself, leading to weird errors when you accidentally mix them, which
can easily happen since you usually have both in PATH. I'd love to have
*one* central MSYS which other packages could depend on.

-David

Re: Emacs for Windows

[Óscar Fuentes]

David Engster <deng@randomsample.de> writes:

> Eli Zaretskii writes:
>> First, even the above is not a large list.  Second, I think you
>> exaggerate a little bit (e.g., GnuWin32 didn't see any new versions
>> since 2010, so no need to watch them anymore.  MinGW/MSYS and PuTTY
>> are likewise very seldomly updated.
>
> Yes, that's why I practically never check them. If there's a security
> update, or a nice new feature, I probably won't notice. Or what about
> the latest bash security problem? I actually don't know how many
> bash.exe I have on my Windows system in need of an update.

MSYS2: pacman -Syu

> Oh, and don't get me started on MsysGit shipping its own MSYS
> environment, which is oh-so-slightly incompatible to the one from MSYS
> itself, leading to weird errors when you accidentally mix them, which
> can easily happen since you usually have both in PATH.

MSYS2 has not this problem. Just put Git at the end of PATH and it will
work fine from MSYS2 shell (or Emacs).

> I'd love to have *one* central MSYS which other packages could depend
> on.

MSYS2 provides a Posix-y buid of Git and a native one is on the works.

As the ice on the cake, the time required for setting up an enviromnent
for building a Windows native Emacs on MSYS2 is determined by your
Internet connection. Everything is there, up to date, one command away.

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 11 Oct 2014 18:25:54 +0200
> 
> Oh, and don't get me started on MsysGit shipping its own MSYS
> environment, which is oh-so-slightly incompatible to the one from MSYS
> itself, leading to weird errors when you accidentally mix them, which
> can easily happen since you usually have both in PATH. I'd love to have
> *one* central MSYS which other packages could depend on.

Yep.  I keep them separate, for that very reason.  Which is a bit of
a pain when you need to configure and build a package that requires
Git as part of its configure/build process...

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Sat, 11 Oct 2014 18:25:54 +0200
>> 
>> Oh, and don't get me started on MsysGit shipping its own MSYS
>> environment, which is oh-so-slightly incompatible to the one from MSYS
>> itself, leading to weird errors when you accidentally mix them, which
>> can easily happen since you usually have both in PATH. I'd love to have
>> *one* central MSYS which other packages could depend on.
>
> Yep.  I keep them separate, for that very reason.  Which is a bit of
> a pain when you need to configure and build a package that requires
> Git as part of its configure/build process...

Yes, and good dependency management through a package manager could
avoid such problems. I lately learned that the new MSYS will even
deliberately break binary compatibility, and I expect a whole new bunch
of problems (not so much for me, because I know where to look by now,
but for my colleagues at work which depend more and more on free
software on Windows).

-David

Re: Emacs for Windows

[David Engster]

David Engster writes:
> avoid such problems. I lately learned that the new MSYS will even
> deliberately break binary compatibility

Erm, I meant MinGW. It's all so confusing. ;-)

-David

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 11 Oct 2014 19:38:20 +0200
> 
> David Engster writes:
> > avoid such problems. I lately learned that the new MSYS will even
> > deliberately break binary compatibility
> 
> Erm, I meant MinGW.

Ah, that...  Yes, MinGW runtime 4.x breaks binary compatibility,
although I practically begged them not to do that.  It is also buggy,
which is why I won't upgrade.

Re: Emacs for Windows

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 11 Oct 2014 19:19:49 +0200
> 
> Yes, and good dependency management through a package manager could
> avoid such problems.

Only if the two teams (MSYS and Msysgit) cooperate with one another, I
think.  Otherwise, it would be very hard to solve this problem.

Re: Emacs for Windows

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Sat, 11 Oct 2014 19:19:49 +0200
>> 
>> Yes, and good dependency management through a package manager could
>> avoid such problems.
>
> Only if the two teams (MSYS and Msysgit) cooperate with one another, I
> think.  Otherwise, it would be very hard to solve this problem.

I'd be surprised if the MsysGit guys wouldn't be happy to concentrate on
Git instead of the environment it needs. Just look at issues like

https://github.com/msysgit/msysgit/issues/31

regarding the ancient OpenSSH version that ships with MsysGit. There
simply is no one who actually likes to deal with building this stuff.

-David

Re: Emacs for Windows

[Glenn Morris]

Stefan Monnier wrote:

> I definitely don't mean one that's present out of the box.  But one that
> people can easily install once and then use it to
> install/uninstall/update Emacs and whatever other Free Software
> she wants.

The standard answer is Cygwin; but some people are apparently against it.

Re: Emacs for Windows

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 10 Oct 2014 11:44:56 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> Stefan Monnier wrote:
> 
> > I definitely don't mean one that's present out of the box.  But one that
> > people can easily install once and then use it to
> > install/uninstall/update Emacs and whatever other Free Software
> > she wants.
> 
> The standard answer is Cygwin

Cygwin is not a package manager, it is a project that includes a
package manager.

> but some people are apparently against it.

It has its disadvantages if you must heavily use non-Cygwin programs.

Re: Emacs for Windows

[Grant Rettke]

Some may be quite shocked to know that there are Emacs users on
Windows who do not come from a UNI* or OSS background.

On Fri, Oct 10, 2014 at 10:44 AM, Glenn Morris <rgm@gnu.org> wrote:
> Stefan Monnier wrote:
>
>> I definitely don't mean one that's present out of the box.  But one that
>> people can easily install once and then use it to
>> install/uninstall/update Emacs and whatever other Free Software
>> she wants.
>
> The standard answer is Cygwin; but some people are apparently against it.
>



-- 
Grant Rettke
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: Emacs for Windows

[H. Dieter Wilhelm]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote:
>
>> I definitely don't mean one that's present out of the box.  But one that
>> people can easily install once and then use it to
>> install/uninstall/update Emacs and whatever other Free Software
>> she wants.
>
> The standard answer is Cygwin; but some people are apparently against it.

Nothing against Cygwin, tried it once and prefer installing some real
Gnu/Linux system under a Windows VM.


-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: Emacs for Windows

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I definitely don't mean one that's present out of the box.  But one that
> people can easily install once and then use it to
> install/uninstall/update Emacs and whatever other Free Software
> she wants.
>
> I think such a package manager would really help spread the use of Free
> Software under Windows.

http://msys2.github.io

It brings Arch's pacman package manager to Windows. Has lots of packages
and growing fast. Supports both x86 and x86_64. No Emacs yet, but that's
not hard to fix.

Re: Emacs for Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 11 Oct 2014 17:38:26 +0200
> 
> > I think such a package manager would really help spread the use of Free
> > Software under Windows.
> 
> http://msys2.github.io

Ask them to provide up-to-date sources first.

Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> http://msys2.github.io
>
> Ask them to provide up-to-date sources first.

Uh?

Re: Emacs for Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 11 Oct 2014 18:00:36 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> http://msys2.github.io
> >
> > Ask them to provide up-to-date sources first.
> 
> Uh?

Not every binary distribution they have has the corresponding source
distribution.  (Apologies if I missed something, but I really did look
and didn't find.)

Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> http://msys2.github.io
>> >
>> > Ask them to provide up-to-date sources first.
>> 
>> Uh?
>
> Not every binary distribution they have has the corresponding source
> distribution.  (Apologies if I missed something, but I really did look
> and didn't find.)

Yes, that's something that catched my attention too.

AFAIK, they provide sources for those packages that belong to them (i.e.
MSYS2 proper). For the rest, the sources are retrieved from their
official sites (i.e. gcc) and then local pactches are applied, if any
exists. This is automated by the Arch Build System (abs for short, that
was ported to MSYS2.) Any user can retrieve a package's source code by
using certain abs commands. The local patches are readily available from
GitHub. If you wish to build the package instead of intalling the
binaries, then retrieving the sources, applying the local paches,
building and installing is nicely automated by abs.

AFAIU this violates the requirement of obtaining the source code from
the binary code distributor.

Re: Emacs for Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 11 Oct 2014 18:18:50 +0200
> 
> > Not every binary distribution they have has the corresponding source
> > distribution.  (Apologies if I missed something, but I really did look
> > and didn't find.)
> 
> Yes, that's something that catched my attention too.
> 
> AFAIK, they provide sources for those packages that belong to them (i.e.
> MSYS2 proper). For the rest, the sources are retrieved from their
> official sites (i.e. gcc) and then local pactches are applied, if any
> exists. This is automated by the Arch Build System (abs for short, that
> was ported to MSYS2.) Any user can retrieve a package's source code by
> using certain abs commands. The local patches are readily available from
> GitHub. If you wish to build the package instead of intalling the
> binaries, then retrieving the sources, applying the local paches,
> building and installing is nicely automated by abs.

Fhew!  And where does one learn about this procedure?

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

I really wonder whether they run the test suite for each package
before they release it.  Guile, for example, fails the tests miserably
on Windows if not patched.

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.

> AFAIU this violates the requirement of obtaining the source code from
> the binary code distributor.

Indeed.

Btw, strangely enough, they don't have some very important packages,
like Gawk, Flex, and m4, to name just a few.  Strange collection.

Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> AFAIK, they provide sources for those packages that belong to them (i.e.
>> MSYS2 proper). For the rest, the sources are retrieved from their
>> official sites (i.e. gcc) and then local pactches are applied, if any
>> exists. This is automated by the Arch Build System (abs for short, that
>> was ported to MSYS2.) Any user can retrieve a package's source code by
>> using certain abs commands. The local patches are readily available from
>> GitHub. If you wish to build the package instead of intalling the
>> binaries, then retrieving the sources, applying the local paches,
>> building and installing is nicely automated by abs.
>
> Fhew!  And where does one learn about this procedure?

Somewhere on the Arch documentation about abs/pacman/etc. I don't know
how good it is, but I'll investigate it because I'll like to contribute
some packages. Seeing how many people is contributing, it must not be
that hard to learn. You can use the PKGBUILD (the build recipe used by
abs) of a similar package as a template too.

> 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. It depends on the MSYS2
Posix layer. The PKGBUILD and patches are here:

https://github.com/Alexpux/MSYS2-packages/tree/master/guile

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.

> I really wonder whether they run the test suite for each package
> before they release it.  Guile, for example, fails the tests miserably
> on Windows if not patched.
>
> 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

>> AFAIU this violates the requirement of obtaining the source code from
>> the binary code distributor.
>
> Indeed.
>
> Btw, strangely enough, they don't have some very important packages,
> like Gawk, Flex, and m4, to name just a few.  Strange collection.

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

Gawk as a MSYS2 package:

$ pacman -Ss gawk
msys/gawk 4.1.1-1 (base base-devel) [instalado]
    GNU version of awk

Same for flex.

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.

Re: Emacs for Windows

[Eli Zaretskii]

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

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.

Re: Emacs for Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 11 Oct 2014 21:40:23 +0200
> 
> Guile is not available as a native package. It depends on the MSYS2
> Posix layer. The PKGBUILD and patches are here:
> 
> https://github.com/Alexpux/MSYS2-packages/tree/master/guile

Btw, if there's no native MinGW port of Guile, then the MSYS2 port is
of little use.  Guile is being used as an extension language in an
increasing number of GNU packages (Lilypond, GDB, and Make, to name
just a few).  Since you cannot link MinGW programs against MSYS2
libraries, users will be unable to have Guile-enhanced MinGW ports
unless a native MinGW port of Guile is available.

Re: Emacs for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Sat, 11 Oct 2014 21:40:23 +0200
>> 
>> Guile is not available as a native package. It depends on the MSYS2
>> Posix layer. The PKGBUILD and patches are here:
>> 
>> https://github.com/Alexpux/MSYS2-packages/tree/master/guile
>
> Btw, if there's no native MinGW port of Guile, then the MSYS2 port is
> of little use.  Guile is being used as an extension language in an
> increasing number of GNU packages (Lilypond, GDB, and Make, to name
> just a few).  Since you cannot link MinGW programs against MSYS2
> libraries, users will be unable to have Guile-enhanced MinGW ports
> unless a native MinGW port of Guile is available.

I have native and up-to-date gdb and GNU Make on my MinGW environment
and they work fine. You forgot to mention that Guile is an optional
requirement for those packages (not for Lilypond, but that's a very
different kind of software).

But let's pretend that you have a strong point here and that some
significant package requires Guile on its Makefiles. Just build it with
the MSYS2 Make, as you probably must do anyways if the package build
system depends on the Autotools or any other GNUism/Poxisism.

IIRC MSYS2 gdb works with MinGW binaries.

Your blatant hyperbole would imply that the Windows native ports of GNU
software that existed to this day are of little use, because MSYS2 just
aggregates and distributes it.

Finally, if there is no native port of Guile to Windows, maybe it is
because nobody cared enough to fight that battle. Many years ago I
looked at the Guile community and noticed an open hostility towards
Windows. Some file names on the source tarball, for instance, contained
invalid chars for the Windows' filesystems (`*') and they flat out
rejected to modify that little detail, including the funny individual
that chimed in to say that it was a "feature".

Re: Emacs for Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 12 Oct 2014 14:13:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Sat, 11 Oct 2014 21:40:23 +0200
> >> 
> >> Guile is not available as a native package. It depends on the MSYS2
> >> Posix layer. The PKGBUILD and patches are here:
> >> 
> >> https://github.com/Alexpux/MSYS2-packages/tree/master/guile
> >
> > Btw, if there's no native MinGW port of Guile, then the MSYS2 port is
> > of little use.  Guile is being used as an extension language in an
> > increasing number of GNU packages (Lilypond, GDB, and Make, to name
> > just a few).  Since you cannot link MinGW programs against MSYS2
> > libraries, users will be unable to have Guile-enhanced MinGW ports
> > unless a native MinGW port of Guile is available.
> 
> I have native and up-to-date gdb and GNU Make on my MinGW environment
> and they work fine.  You forgot to mention that Guile is an optional
> requirement for those packages (not for Lilypond, but that's a very
> different kind of software).

I didn't forget.  Python is also optional in GDB, and yet the port
distributed by the MSYS2 site does include it.  So evidently someone
thought it would be useful, and I agree.  Likewise for Guile: a GDB or
Make that can use Guile extensions are more useful than those which
cannot.

> But let's pretend that you have a strong point here and that some
> significant package requires Guile on its Makefiles. Just build it with
> the MSYS2 Make, as you probably must do anyways if the package build
> system depends on the Autotools or any other GNUism/Poxisism.
> 
> IIRC MSYS2 gdb works with MinGW binaries.

This thread was about native MinGW ports, and where and how to get
them.  Not about MSYS2 ports.  Using MSYS ports for anything but
building MinGW has its own issues, as you well know.

> Your blatant hyperbole would imply that the Windows native ports of GNU
> software that existed to this day are of little use, because MSYS2 just
> aggregates and distributes it.

My point is that people should know what they get when they download a
port.  If the ports distributed by MSYS2 are of questionable quality,
or didn't all pass their test suites, it would be prudent to say so.

And I don't think I deserve the "blatant hyperbole" part.

> Finally, if there is no native port of Guile to Windows

There is:

   http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download

(Btw, you will also find Hunspell there, so perhaps you don't need to
resist that temptation of yours.)

Re: Emacs for Windows

[E Sabof]

I recall trying to get GIT (which comes with it's own mini posix environment), ack-grep (not part of cygwin, and requiring a windows version of perl), SSH (I think from cygwin) to get along, while trying to keep thing like find-dired and find-grep working.

Admittedly it's more of a general unix-on-windows problem.

Evgeni

Eli Zaretskii <eliz@gnu.org> writes:

>> From: E Sabof <esabof@gmail.com>
>> Date: Thu, 09 Oct 2014 23:37:38 +0100
>> Cc: help-gnu-emacs@gnu.org
>>
>> Last time I've tried using Emacs on Windows
>
> When was that?
>
>> finding adequate replacements for Unix utilities and libraries was a
>> problem.
>
> Which utilities did you not find easily, and where did you look?  I
> can show 3 URLs where you will find MinGW binaries of everything
> (well, everything I have on my systems ;-).
>
>> There should be demand for a well-researched, batteries-included distribution.
>
> I don't think everything should be in the same zip, though.  Doing so
> causes trouble in the long run, because different packages have
> different schedules, and you want to upgrade to the newer versions
> from time to time.

Re: Emacs for Windows

[John Mastro]

E Sabof <esabof@gmail.com> wrote:
> I recall trying to get GIT (which comes with it's own mini posix
> environment), ack-grep (not part of cygwin, and requiring a windows
> version of perl), SSH (I think from cygwin) to get along, while trying
> to keep thing like find-dired and find-grep working.

In case it's off interest, here's how I deal with those things:
    - Use Cygwin's git
    - Use CPAN with Cygwin's Perl to install Ack
    - Use Cygwin's SSH

So far `find-dired', `find-grep', and so on have worked fine. Much
better than the results I've gotten from solutions other than Cygwin.

--
john

Re: Emacs for Windows

[E Sabof]

Thanks, I'll give Cygwin another try when I happened to use Windows.

Evgeni

John Mastro <john.b.mastro@gmail.com> writes:

> E Sabof <esabof@gmail.com> wrote:
>> I recall trying to get GIT (which comes with it's own mini posix
>> environment), ack-grep (not part of cygwin, and requiring a windows
>> version of perl), SSH (I think from cygwin) to get along, while trying
>> to keep thing like find-dired and find-grep working.
>
> In case it's off interest, here's how I deal with those things:
>     - Use Cygwin's git
>     - Use CPAN with Cygwin's Perl to install Ack
>     - Use Cygwin's SSH
>
> So far `find-dired', `find-grep', and so on have worked fine. Much
> better than the results I've gotten from solutions other than Cygwin.

Re: Emacs for Windows

[Eli Zaretskii]

> From: E Sabof <esabof@gmail.com>
> Cc: haroogan@gmail.com, help-gnu-emacs@gnu.org
> Date: Fri, 10 Oct 2014 21:38:57 +0100
> 
> I recall trying to get GIT (which comes with it's own mini posix environment), ack-grep (not part of cygwin, and requiring a windows version of perl), SSH (I think from cygwin) to get along, while trying to keep thing like find-dired and find-grep working.

None of that is a problem for me.  Instead of SSH, I suggest plink
from PuTTY (which Tramp supports out of the box), and the "mini posix
environment" that comes with GIT, which are MSYS programs, is
available in native MinGW ports from GnuWin32.

So, while the initial setup does takes some effort, it is not too hard
and doesn't require anything except unzipping a bunch of archives and
setting up PATH.

Re: Emacs for Windows

[E Sabof]

Thanks, I'll keep these in mind

Evgeni

Eli Zaretskii <eliz@gnu.org> writes:

>> From: E Sabof <esabof@gmail.com>
>> Cc: haroogan@gmail.com, help-gnu-emacs@gnu.org
>> Date: Fri, 10 Oct 2014 21:38:57 +0100
>>
>> I recall trying to get GIT (which comes with it's own mini posix environment), ack-grep (not part of cygwin, and requiring a windows version of perl), SSH (I think from cygwin) to get along, while trying to keep thing like find-dired and find-grep working.
>
> None of that is a problem for me.  Instead of SSH, I suggest plink
> from PuTTY (which Tramp supports out of the box), and the "mini posix
> environment" that comes with GIT, which are MSYS programs, is
> available in native MinGW ports from GnuWin32.
>
> So, while the initial setup does takes some effort, it is not too hard
> and doesn't require anything except unzipping a bunch of archives and
> setting up PATH.

Re: Emacs for Windows

[Mirko]

On Friday, October 10, 2014 8:36:41 AM UTC-4, Stefan Monnier wrote:
> >> There should be demand for a well-researched,
> >> batteries-included distribution.
> > I don't think everything should be in the same zip, though.  Doing so
> > causes trouble in the long run, because different packages have
> > different schedules, and you want to upgrade to the newer versions
> > from time to time.
> 
> Isn't there some kind of package distribution system for Windows (à la
> Debian's APT, Redhat's RPM, or MacPorts, Fink, younameit)?
> 
> 
>         Stefan

I wish for such a system too.  I currently have several almost identical 
installations of Python or TCL, on my Windows machines.  They came bundled with 
several commercial or free software simulation packages that use Python or TCL 
in the background.

The same need that drives Linux and Cygwin have package maintenance frameworks 
exists on Windows.  The lack of clamor for one (as Eli noted in his posts) may 
stem from the "if you build it they will come" behavior.

If such a system existed, and was well maintained, it would allow the user base 
for that software to grow much faster than now.  That requires a young king 
that is willing to raise the sword, lay down the vision, and several knights to 
join him in the quest.  Afterwards, more may follow.  Glory and eternal fame to 
them.

Mirko

Re: Emacs for Windows

[Grant Rettke]

Thanks great to know and I will pass on that detail my Emacs on
Windows using friends.

On Thu, Oct 9, 2014 at 4:43 AM, Alexander Shukaev <haroogan@gmail.com> wrote:
> Hello everyone,
>
> I've been providing high-quality native builds of Vim for Windows for quite
> some time now. The biggest point is that both x86 (32-bit) and x64 (64-bit)
> architectures are supported. They have become extremely popular ever since.
>
> Now I would like to spread out news that I've started Emacs for Windows
> <https://bitbucket.org/Haroogan/emacs-for-windows>. It aims to provide
> high-quality native builds of Emacs for Windows, and once again, x86
> (32-bit) and x64 (64-bit) architectures are supported (unlike official
> binaries). Many external features and their corresponding runtime (shared)
> libraries (DLLs) are already included, so there is no need to search
> through different binary repositories to get up-to-date GnuTLS, for
> example, or DBUS, and many others. These features have lots of runtime
> dependencies, building which is quite cumbersome (if possible at all) for
> inexperienced users. From now on, all of that is included in my
> distributions.
>
> I'm looking forward to some feedback, if anybody finds that useful and
> wants me to continue to support that project actively. It does not mean
> that I'm going to drop that at all otherwise (since I'm using it as well
> for myself), but if there is lack of public interest, then I would probably
> update it much rarer than I could otherwise.
>
> Kind regards,
> Alexander Shukaev



-- 
Grant Rettke
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: Emacs for Windows

[H. Dieter Wilhelm]

Hello Alexander,

when do you plan to have a version of Emacs 24.4?

Thanks for your help

       Dieter

Alexander Shukaev <haroogan@gmail.com> writes:

> Hello everyone,
>
> I've been providing high-quality native builds of Vim for Windows for quite
> some time now. The biggest point is that both x86 (32-bit) and x64 (64-bit)
> architectures are supported. They have become extremely popular ever since.
>
> Now I would like to spread out news that I've started Emacs for Windows
> <https://bitbucket.org/Haroogan/emacs-for-windows>. It aims to provide
> high-quality native builds of Emacs for Windows, and once again, x86
> (32-bit) and x64 (64-bit) architectures are supported (unlike official
> binaries). Many external features and their corresponding runtime (shared)
> libraries (DLLs) are already included, so there is no need to search
> through different binary repositories to get up-to-date GnuTLS, for
> example, or DBUS, and many others. These features have lots of runtime
> dependencies, building which is quite cumbersome (if possible at all) for
> inexperienced users. From now on, all of that is included in my
> distributions.
>
> I'm looking forward to some feedback, if anybody finds that useful and
> wants me to continue to support that project actively. It does not mean
> that I'm going to drop that at all otherwise (since I'm using it as well
> for myself), but if there is lack of public interest, then I would probably
> update it much rarer than I could otherwise.
>
> Kind regards,
> Alexander Shukaev
>

-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: Emacs for Windows

[Bug Dout]

Sounds great. The place I work for abandoned *nix (Solaris) long ago for
Windows, and I use GNU Emacs at work and home.
-- 
Be kind; everyone you meet is fighting a hard battle.
 ~ Plato

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: Emacs for Windows

[tux-]

FYI, Win64 builds of Emacs "trunk" have been around for quite some time
now:

http://emacsbinw64.sourceforge.net/

Maybe you'd save some time by not doing the same thing again.

Regards.

Re: Emacs for Windows

[Alexander Shukaev]

Unfortunately these builds are of low quality. Want me to go into details?

Re: Emacs for Windows

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

() Alexander Shukaev <haroogan@gmail.com>
() Wed, 15 Oct 2014 17:23:25 +0200

   low quality. Want me to go into details?

Are there any details that are not windows-specific?
If so, i'm interested in those.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs for Windows

[Alexander Shukaev]

>
> Are there any details that are not windows-specific?
> If so, i'm interested in those.
>

They are Windows-specific. However, I stopped looking for issues after
finding several of them, so I can't guarantee there are no others...

Re: Emacs for Windows

[John Mastro]

Alexander Shukaev <haroogan@gmail.com> wrote:
> Unfortunately these builds are of low quality. Want me to go into details?

Yes, I'd appreciate details.

I've been using them happily for a month or so, though I don't use
many Windows-specific features (whatever those may be).

-- 
john

Re: Emacs for Windows

[Jason Rumney]

On Wednesday, 15 October 2014 23:23:25 UTC+8, Alexander Shukaev  wrote:
> Unfortunately these builds are of low quality. Want me to go into details?

They are however superior to what you have provided in at least one *very* important way.

Re: Emacs for Windows

[John Mastro]

Jason Rumney <jasonrumney@gmail.com> wrote:
> On Wednesday, 15 October 2014 23:23:25 UTC+8, Alexander Shukaev  wrote:
> > Unfortunately these builds are of low quality. Want me to go into details?
>
> They are however superior to what you have provided in at least one *very* important way.

As someone who'll likely use at least one of these two builds, the lack
of details are killing me :-)

I'd love to hear more from both Alexander and Jason.

-- 
john

Re: Emacs for Windows

[Nikolay Kudryavtsev]

Hello. I've just tried both builds, and one thing I immediately noticed 
about emacsbinw64 is that it eats over 600 mb's of memory just after 
load. Shukaev's version does not do this.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Emacs for Windows

[John Mastro]

Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> wrote:
> Hello. I've just tried both builds, and one thing I immediately noticed
> about emacsbinw64 is that it eats over 600 mb's of memory just after load.
> Shukaev's version does not do this.

Interesting. On my Windows 7 machine at work, the emacsbinw64 build of
24.4 uses 29MB and change immediately after startup. Not sure what would
cause such a large difference.

-- 
john

Re: Emacs for Windows

[John Mastro]

John Mastro <john.b.mastro@gmail.com> wrote:
> Interesting. On my Windows 7 machine at work, the emacsbinw64 build of
> 24.4 uses 29MB and change immediately after startup. Not sure what would
> cause such a large difference.

Oops, that's with all my packages and configuration. From `emacs -Q' it
uses only 10MB.

-- 
john

Re: Emacs for Windows

[Nikolay Kudryavtsev]

Just tested 24.4.51 x 64 from BitBucket and it is as much a memory hog 
as the same version of emacs-w64. So this bug is not compiler specific.

25.0.50 from the same source is fine.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Emacs for Windows

[Bug Dout]

I noticed the same thing. The version I was using before, 24.3, was a
real memory hog...I just thought it was normal. By accident, in trying
to find a Windows version of 24.4, I downloaded 25.0.50.1
(x86_64-w64-mingw32) and it uses a small fraction of the other version's
footprint.

Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> writes:

> Just tested 24.4.51 x 64 from BitBucket and it is as much a memory hog
> as the same version of emacs-w64. So this bug is not compiler
> specific.
>
> 25.0.50 from the same source is fine.

-- 
One death is a tragedy. A million deaths is a statistic.
 ~ Josef Stalin

Re: Emacs for Windows

[Eli Zaretskii]

> From: Bug Dout <buggsy2@mailinator.com>
> Date: Sun, 30 Nov 2014 09:27:36 -0800
> 
> I noticed the same thing. The version I was using before, 24.3, was a
> real memory hog...I just thought it was normal. By accident, in trying
> to find a Windows version of 24.4, I downloaded 25.0.50.1
> (x86_64-w64-mingw32) and it uses a small fraction of the other version's
> footprint.
> 
> Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> writes:
> 
> > Just tested 24.4.51 x 64 from BitBucket and it is as much a memory hog
> > as the same version of emacs-w64. So this bug is not compiler
> > specific.
> >
> > 25.0.50 from the same source is fine.

My crystal ball says you are both looking at the wrong measure of
memory.  Emacs 24 and before _reserved_ 1.6GB of memory, but didn't
commit more than it actually needed.  So it was never a memory hog.

Emacs 25 changed the way it allocates memory on Windows, so it no
longer needs to reserve anything.

Re: Emacs for Windows

[Sampath Weerasinghe]

i also had similar troubles, i downloaded emacs by googling emacs windows

 im using windows 8 with gui mode emacs

emacs will cause so much cpu usage the entire system becomes unresposive
and it would use a lot of memeory while working with very small files.

often these troubles start when quickly saving/closing multiple
emacs  windows.


so nowadays i use console mode emacs through ssh, tmux on my remote ubuntu
ec2 instance.  scrolling is a pain, but id rather not have a hung OS.


-Sam

On Wednesday, November 5, 2014, John Mastro <john.b.mastro@gmail.com
<javascript:_e(%7B%7D,'cvml','john.b.mastro@gmail.com');>> wrote:

> Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> wrote:
> > Hello. I've just tried both builds, and one thing I immediately noticed
> > about emacsbinw64 is that it eats over 600 mb's of memory just after
> load.
> > Shukaev's version does not do this.
>
> Interesting. On my Windows 7 machine at work, the emacsbinw64 build of
> 24.4 uses 29MB and change immediately after startup. Not sure what would
> cause such a large difference.
>
> --
> john
>
>