Re: Development Speed

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

I'm skipping over several things to keep this short and to the point.

>> A the same time someone suggested experimenting with a new approach to
>> display and he was shunned ("We tried with such a library, many eons
>> ago. It was named lwlib, and you can judge for yourself how successful
>> it is.") Right, because if it failed many eons ago, trying again is
>> doomed to fail for sure, as technologies in software change as often as
>> in medieval masonry; and what the OP was suggesting is not what lwlib
>> does, IIUC.
>
> Maybe you misunderstood what the OP was suggesting.

I don't think so, the few doubts I had vanished after reading his recent
messages.

> Or maybe you have
> some different suggestion in mind, because what he was suggesting
> makes no sense to me.

Maybe asking for clarification? I can expand on the proposal, but
somebody else already did. I can answer specifics about that topic if
necessary.

> Do we have to accept any suggestion whatsoever,
> no matter if it does or doesn't make sense, lest Óscar will accuse us
> of being backward?

Well, that's a glaring example of what I said about not internalizing
the social implications of our "new" tools :-) If you have doubts about
his suggestion, you could just say "I don't get what you are proposing
but if you think it is good for Emacs then sure, go ahead and I'll
examine your work when you have something to show." Then the OP goes to
work on his personal repo. That has almost zero cost to you, both on
effort and risk. It's not like the old times when you had to give write
permissions to the project's repo and destabilizing WIP usually happened
on the main branch because merges on CVS are a pain.

>> Emacs' architecture favors plug-in components, in the form of Elisp
>> packages, external processes and C libraries exposed to Elisp. That's
>> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
>> But working on certain key parts of the core is very hard, both
>> technically and socially. You are concerned about the lack of C
>> contributors, but I think your worries are not well focused: there are
>> still plenty of C hackers around, but do they see our C core as
>> something they would enjoy contributing to?
>
> That is against any reasonable experience and facts on so many levels
> that I don't know where to start.  Here's several items, as food for
> thought:
>
>   . Emacs extensibility via Lisp can only go so far, sooner or later
>     it hits a wall.  Some extensions and major developments need
>     changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in
>     with Lisp is bound to fail.  Evidence: linum vs native line
>     numbers.  Evidence: bidirectional editing (which originally had a
>     Lisp implementation which went nowhere).  Evidence: HarfBuzz vs
>     "ligatures" via prettify-symbols-mode.

Very true, but I don't see how this contradicts what I wrote. The
occasional new feature on core base happens, but extensions (Elisp,
interfaces to external processes and, more recently, modules) makes the
bulk of Emacs' user-perceptible improvements, much more so if we count
external packages.

>   . Working on the C level requires certain efforts, but is far from
>     being impossible for novices.  Evidence: face-extension feature
>     and display-fill-column-indicator-mode feature that was coded by
>     someone who started from almost zero knowledge of the display
>     code.  Evidence: several people who started working on the C code
>     just recently (see Git logs).

I'm convinced that there is a strong survival bias at play here.

> Bottom line: I find that Emacs recently picks up quite a few new
> technologies, and for an old and stable program such as Emacs we
> should be proud of what we accomplished.

This definitely agree with.