Re: Meanness

[David Kastrup <dak@gnu.org>]

Thomas Lord <lord@emf.net> writes:

> As a component, one requirement is that it have excellent "fit"
> (aka "coupling") with other parts of a GNU system.   Making
> Emacs work really well on today's GNU/Linux systems is
> probably the best way to force improvements to its coupling.
>
> However:
>
> As a *component*, especially one of such central, low-level
> importance, Emacs should also have excellent "orthogonality and
> self-containment" (aka "cohesion").  It should fit well with a larger
> GNU system but it should, internally, be flexible, self-contained,
> based on good abstractions, etc.  It should fit GNU but it shouldn't
> be overly "intertwingled" with GNU.

Why?

> The best way to force improvements to cohesion is by "porting" and
> using the component in comparable but substantially different
> environments.  Windows is such.

No.  Windows is not comparable.  Various Unix variants are.  There is
nothing to be gained for Emacs on GNU/Linux by having to support file
systems which use backslashes instead of slashes and have drive letters.
Such things require creating artificial splicings of code and
pseudo-abstractions and APIs which make code less straightforward to
read and write.

That is a cost, not a benefit.

> Two simple examples: fonts and colors.  If the abstractions at the
> Emacs lisp level for fonts and colors are agnostic with respect to GNU
> vs. Windows and are effective on both, *that improves the quality of
> the Emacs component on GNU systems* by shaking out any needless
> intertwingling with X11 abstractions.

Uh no, it doesn't.  Gdk (and Gtk) provide efficient color map and image
handling.  Emacs doesn't.  It is quite worse, and that's exactly because
of being reduced to lowest denominator handling and corresponding
interfaces.  Gtk/Pango provides right-to-left typesetting and
internationalization.  Emacs doesn't.  The list goes on and on.

I am well aware that there are cost/benefit weighings involved.  That's
fine.  But declaring the costs to be benefits is not a basis for
planning.

> Doing it well, though, should improve emacs *on GNU* in ways that
> almost no other plausible activity can do.

My experience with Windows-too projects runs quite contrary.  The costs
are in _no_ relation whatsoever to the benefits for the non-Windows
parts (actually, their tend to be only costs for them, without
benefits).  And I don't see Emacs as an exception.  The benefit for a
Windows port lies in having a Windows port.  If there were tangible
other benefits, we could invent imaginary operating systems en gros and
spend our time porting to them.

Can we please _stop_ this silliness?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum