Re: Meanness

[Eli Zaretskii <eliz@gnu.org>]

> From: David Kastrup <dak@gnu.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 26 Jul 2008 19:21:31 +0200
> 
> > 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.

Wrong.  The gain is to have abstractions like IS_DIRECTORY_SEP and
IS_ABSOLUTE_FILE_NAME, instead of testing for literal characters.  The
gain is to realize that file names are not simple strings and cannot
be compared for equality with strcmp and its ilk.  Such abstractions
will serve us well when we get to supporting Unicode file names where
normalization prevents simple string comparison.

> Such things require creating artificial splicings of code and
> pseudo-abstractions and APIs which make code less straightforward to
> read and write.

Yeah, and C++ abstractions make code less straightforward to read and
write that C or assembly.  Get real!

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

Wrong again: Emacs has text terminal color support that was lifted
almost verbatim from the code written for the DOS port.  The DOS code
was written by implementing the abstract interface of Xlib.

> Gtk/Pango provides right-to-left typesetting and
> internationalization.  Emacs doesn't.

Irrelevant: Emacs cannot use Pango because it doesn't fit well the
Emacs display engine, which walks the buffer one character at a time.

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

That is your experience.  Mine is different.

> Can we please _stop_ this silliness?

Stop responding, if you want this to stop.