Re: Development Speed

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 16:51:41 +0100
> 
> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

That's a lopsided view of what happened, with denigrating epithets
("painful", "inadequate") to season it.  The switch to bzr was no more
painful than any switch from a centralized VCS to a dVCS could be
expected to be.  At the time we switched, bzr was a viable
alternative, used by several other projects (some of which kept using
it long after we switched to Git).  And how the problem with
contributors' mindsets is any evidence in favor of your argument is a
mystery to me.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

Another lopsided view: we are looking for a better system for quite
some time, and until now none was found to satisfy our basic
requirements.  Hopefully, sourcehut will.

For a more balanced view, try to find a project that is happy with its
bug tracker.  I'm still looking.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

Really?  Like what?

And how is this a "technology" problem?  Or would you like us to
rewrite Emacs in Rust?

Come on, get real!  This is supposed to be a serious discussion, not a
mud-throwing match.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

And how is this any evidence that we procrastinate in our acceptance
of new technology?  Does Motif support disallow any such advances?

> 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.  Or maybe you have
some different suggestion in mind, because what he was suggesting
makes no sense to me.  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?

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

No, we maintain old code because it works and because we decide not to
break it.  It's a decision which has reasons, you just choose to
ignore them because you want to make a point in an argument.

And how is this any evidence of (not) accepting new technologies,
anyway?  Or are we changing the subject now to something like "all I
hated in Emacs development but was afraid to say out loud"?

> 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.
  . 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).
  . Reasons why "plenty of C hackers", if they indeed exist (and IME
    the jury is still out on that one), need serious investigation.
    I have my guesses about that, but they will remain unsaid at this
    point.

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.