Re: Meanness

[Thomas Lord]

David Kastrup wrote:
>  Improving "Emacs on Windows" is not
> the same as improving Emacs because Emacs is targeted as a component of
> the GNU system.  Supporting Emacs on Windows is at best orthogonal to
> that goal.
>   

I dunno about that (about "at best orthogonal to that goal").

Emacs is supposed to be a *component*, I agree.

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.

The best way to force improvements to cohesion is by "porting" and using
the component in comparable but substantially different environments.
Windows is such.    There aren't a lot of others to pick from.   That so
many, including many who certainly do support free software can benefit
from Emacs on Windows is just icing on the cake.

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.   That, in turn, makes it easier in the future (if need or 
desire
be) to try some other window system besides X11 on GNU.   It's easier
because programs like Emacs are already very clean *components*.

Don't get me wrong.   Maintaining the Windows port *poorly* can do
at least as much harm as good -- turning Emacs into a tangle of
new #ifdefs, turning Emacs lisp into a language that works differently
on different platforms, leading to *two* build systems instead of one, etc.

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

-t




>