Re: Is intellisense features integration in Emacs technically possible?

[Stephen J. Turnbull]

David Kastrup writes:

 > In the long run, [XEmacs-style factoring of (re-)display
 > functionality] may have made it harder for XEmacs to keep up with
 > the changing evolution of desktop environment looks,

Unlikely.  XEmacs developers just emphasized application functionality
over desktop integration (except with X, where ICCCM conformance was
an early goal -- of course platforms like Windows and Mac OS X make it
easy to conform at that level, whereas in practice ICCCM conformance
is impossible).

True, the native widget support was poorly done, which made everything
except Xt/Athena look like crap when compared with implementing
directly as done in Emacs.  The widgets look like a 14-year-old boy at
a sock hop, never quite able to fit in with the cool kids.  But that's
because they guy who implemented native widget support thought like a
Windows programmer, and didn't really like the idea of delegating to
widgets.  So his code tries to control everything from the Emacs
window level down, in C.  Yuck.  Not to mention hard to modify at all,
let alone beautify.

OTOH, Bill Perry's original work on GTK+ support had all the cool stuff
-- tear off menus, Glade and GNOME integration, and an FFI for anything
that came along later.  That all bitrotted because BeOpen went under
so financial support for GTK+ did too, and the people who ported to GTK+
v2 again just wanted the toplevel effect of the GTK look, and so
didn't do a great job of bringing the cool stuff along with them.

N.B. While obviously I have strong opinions on how these things
*should* have been done in retrospect, it's not clear to me what was
the right thing to do at the time.

The main point here is that I think what we would need to improve
platform integration is *more* refactoring, not less.

 > XEmacs looks a lot like XEmacs on every platform, or at least it
 > did so when I looked at it the last time, admittedly considerable
 > time ago.

So does Emacs.  On the Mac as supplied by MacPorts it looks a lot like
a late '90s X application. :-)  And spews ugly GTK QA warnings like
crazy -- uh, excuse me, like all the other GTK apps.

 > I am actually grateful that I can compile my Emacs with
 > --without-toolkit-scroll-bars (why is that only a compile-time
 > option?)

Because nobody really took the Lucid Widget promise of true toolkit
independence seriously, and that's probably because they never really
delivered on it.  It's not really possible to plug and play different
toolkits at runtime, although it *is* possible to mix and match at
compile time.  So you'd have to rewrite lwlib for that kind of feature.

 > But as the user interface wars we had in Emacs alone over the issue
 > of whether the scrollbar should be to the left or the right side of
 > the window show, for a lot of people blending into the respective
 > environment feels very important.

Apparently so.  But few of them were XEmacs developers, so that has
never been emphasized in XEmacs.