emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is intellisense features integration in Emacs technically possible?


From: David Kastrup
Subject: Re: Is intellisense features integration in Emacs technically possible?
Date: Wed, 22 Jan 2014 09:13:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

> I apologize for responding to DAK's post but I lost Óscar's.
>
>  > Óscar Fuentes <address@hidden> writes:
>  > 
>  > > Eli Zaretskii <address@hidden> writes:
>  > >
>  > >> The Emacs display engine is many tens of thousands of C code plus many
>  > >> thousands of Lisp.
>  > >
>  > > AFAIU this is largely a consequence of the development baggage of Emacs.
>  > > That is, the complexity of the current code base is far greater than the
>  > > complexity of its purpose.
>
> It could surely be a lot smaller if it were restricted to a single
> multiplatform toolkit such as wxWindows.  However, users seem to
> prefer platform-specific code, leading to a lot of duplication.  It's
> not clear to me that's bad, given that both user preference and
> developer skills are often very platform-specific.
>
> By comparison, it's hard to say exactly (depends on what you mean by
> "display"), but XEmacs's display engine is about 3.5KLOC of C code, of
> which less than 1.5KLOC are in the platform-independent parts.

IIUC correctly, XEmacs' display engine factors quite more code and
behavior into a platform independent part of the code base.  From an
engineering and maintenance perspective that seems like a sane thing to
do and certainly factored in significantly in the headstart XEmacs had
over Emacs regarding the support of graphical interfaces.

In the long run, it may have made it harder for XEmacs to keep up with
the changing evolution of desktop environment looks, never mind how
little this may have actually to do with engineering or usability.
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.
And that look makes it quite more apparent that XEmacs was competing
with the likes of the Athena widget set and Motif than one can see with
Emacs.

I am actually grateful that I can compile my Emacs with
--without-toolkit-scroll-bars (why is that only a compile-time option?)
and get the Lucid scrollbars for my otherwise GTK+ Emacs since, ugly
looks aside, the semantics of the old Athena scrollbar design are vastly
superior over that of the prettier GTK+ scrollbars, and the GTK+
maintainers are usually quite opposed to provide configurability.

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.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]