Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <address@hidden> writes:

> David Kastrup wrote:
>> Eli Zaretskii <address@hidden> writes:
>>
>>>> From: Richard M Stallman <address@hidden>
>>>> Date: Thu, 24 Jul 2008 18:05:28 -0400
>>>> Cc: address@hidden, address@hidden, address@hidden,
>>>>    address@hidden, address@hidden, address@hidden, address@hidden
>>>>
>>>>     > When I ask myself, is the world better for having Emacs and Firefox
>>>>     > running on Microsoft Windows, the answer is an unequivocal yes -
>>>>     > people who hack on MS-Windows can thus do a better job.
>>>>
>>>>     But their job does not in general benefit others.  So we are creating
>>>>     better opportunities for work that does not help the community.
>>>>
>>>> I agree.
>>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>>> others, including Emacs on other platforms?
>>
>> You don't have time left for getting Emacs-Bidi to run on any platform,
>> right?  Now it is, of course, your choice what to spend your developer
>> time on, like it is everybody other's choice, too.
>
> Maybe the easiest way to give Eli more time for that is give good
> support for needed tools on w32?

That sounds suspiciously like "throwing good time after bad time", to
borrow a management term.  It really sounds like a bottomless pit: you
can throw more and more time that way, and the results will be more and
more tasks.

> At least a lot of my time has been spent working around different
> deficiencys in GNU tools and other things needed on w32.

You are not exactly making a shining case for w32 support being not a
major side track for GNU project contributors.

> I do not know the reasons for these deficiences, but the deficiences
> are there.

In the company I am earning my money in, we have been cutting our losses
on Windows recently and now offer only a solution based on Ubuntu
packages.  If you need to run it on Windows, you use a virtual machine.

And that is a proprietary product with industrial customers, and
basically a batch processing product.

So the difficulties were mostly related to setup and installation and
configuration and file paths, nowhere near as complicated as for
something like Emacs.

Go figure.

> I can guess two main reasons for the deficiencies:
>
> 1) Lack of knowledge. It is not very common that someone knows both
> the GNU/Linux API and the w32 API in depth. A problem of this kind was
> the network problem with Emacs client on w32 (which took Juanma quite
> a while to solve).
>
> Like most other people I would assume that this kind of problems
> should be worked around with libraries when possible. Something ios
> maybe wrong when this does not work?
>
> 2) The other reason I guess is important is attitude. If a lot of
> people with good reputation says that working on w32 is not that
> important then those with a more admiring mind might agree without
> really diving into the subject. That shows up in code quality later.

I don't see a problem.  If people spend the time on other things than
w32 support, then it is likely better invested.

I know that I have spent an inordinary amount of time on support Emacs,
XEmacs, various Unices and Windows for AUCTeX.  In particular making the
AUCTeX installation work with MSYS has been a major pain in the ***.
And keeping XEmacs compatibility means tying oneself to abstractions,
APIs and core functionality of Emacs 20.4 or something.

Keeping this compatibility in mind means aiming for abstractions and
modularization and APIs which generate whole new subsystems and lots of
independent fragilities.  At each particular point of coding, the
compatibility costs may be tolerable.  But they add up.

If Emacs image and font and display code just took Gdk, Gtk, Pango, Xft
and other subsystems for granted and used _their_ interfaces
indiscriminately, the code would be likely more transparent,
maintainable and obvious.  Having to abstract to a level that makes it
possible to use w32 rendering, MacOSX rendering, legacy X11 rendering
and so on comes at a cost.

A high cost.  We have slow image rendering, complex loaders, weird code
paths and hard to understand data flow.  And we are getting there with
text rendering, too.

So in addition to the time sink for the proprietary system developers
themselves, our compatibility layers add cruft complicating things for
everyone.  I am not convinced that this offsets the advantages.

Again: I am mostly talk and little work, and so I am hardly in a
position to admonish anybody.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum