Re: Motif support

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I worked on some code bases much larger than Emacs' C part,
>> with an application domain much more technical and specialized, and
>> achieved productivity on non-trivial tasks after a few hours of study.
>> Those are projects that put a lot of thought on code architecture, both
>> macro and micro, with no tolerance for long-lived hacks or "somehow this
>> seems to work" changes.
>
> Either those projects were redesigned and rewritten every few years,

Yes.

Well, sort of. Not really rewritten as in "let's scrap everything an
begin anew", but there were no misgivings about rethinking, changing and
scraping things when they seemed to start going out of hands.

> or they stopped getting significant changes after several years.
>
> Emacs has its major part rewritten only very rarely (the display
> engine in Emacs 21 and the handling of non-ASCII in Emacs 20 and then
> again in Emacs 23 are basically the only examples that come to mind).
> Emacs is also a highly interactive program with many extensions "in
> the wild", so it must stay compatible throughout the changes.  And
> finally, I very much doubt that any other project supports so many
> different UI frameworks.

AFAIK a lot of the complexity on the display engine comes from
shoehorning a GUI on top of a TUI design.

> These differences explain why you don't frequently see the complexity
> we have in Emacs.
>
> And please don't take this as a defense of what we have, it's just a
> statement of some facts we should keep in mind.

Agreed. If the technical exigence on Emacs were as high as in those
other projects, probably Emacs would be dead by now for lack of
contributors. Different environments, different applications, different
state of mind of contributors (vocational payjob vs scratch-an-itch on
free time), etc.

That said, the combination of micro-changes (features plus bug fixes)
combined with the principle of "if it works, don't fix it" is too easily
perceptible on Emacs :-)