21.4 better than 21.5?

[David Kastrup]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Aidan Kehoe writes:
>
>  > We'd also need to do the sort of energetic Mac integration that
>  > Aquamacs did, something almost impossible without a fork. ("What do
>  > you mean you want to turn on CUA-mode by default?")
>
> I don't see a need for a fork.  That's a much bigger problem in the
> GNU Church of Emacs than it is in relatively pragmatic XEmacs.
> (shifted-motion-selects-region, anyone?)

The "GNU Church of Emacs" doctrine that you are probably referring to is
the doctrine of keeping features out or disabled by default until their
proponents have brought the implementation to a state where enabling it
does not cause a major regression for other users (as well as
themselves).

This doctrine has lead to syntax highlighting which does not render the
editor unusable for large files.  It has led to, well
shifted-motion-selects-region in a sensible way, after all.  It has made
porting to different graphical platforms a challenge and obstacle.
Emacs has by now Windows, GTK+, MacOSX ports that look in style on the
respective platforms.  Porting XEmacs has been simpler, but it looks
like XEmacs everywhere.

I remember one particular occasion where this doctrine was violated:
MULE.  This probably caused the last major migration to XEmacs.  And is
now more or less cause for backward migration.

Emacs development is currently active again on right-to-left
typesetting.  That's exciting.  XEmacs is still playing catch-up with
left-to-right.

So there was some payoff for violating the doctrine, after all.  Because
it was not about being the first to be somewhere, but about getting a
headstart on a road that will go on for years, and where it is important
to keep up with where the rest of world is going, because an editor that
can't be used to edit the files in the native encoding of its operating
systems comfortably is going nowhere.

Sadly, I have seen XEmacs seen make little use of the headstarts its
developers gave it with raw features.

> If that's what Mac users want, I don't have a problem with it.  We[1]
> should put some effort into documenting behaviors (especially for
> developers) and into turning that steaming pile of donkey-do-do known
> as "custom themes" into a useful feature.  If we had those, then we
> really could skin "classic Emacs" vs. "classy Mac".

Yup.  That does not work on Emacs either.  And certainly custom themes
are much saner than UI forks like Aquamacs.

Because then a Mac lover can also tell his Emacs on Windows "please
behave like on Mac" and vice versa.

-- 
David Kastrup