Re: What's missing in ELisp that makes people want to use cl-lib?

["João Távora" <joaotavora@gmail.com>]

On Thu, Nov 9, 2023 at 11:38 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Thu, 9 Nov 2023 11:06:02 +0000
> > Cc: Dmitry Gutov <dmitry@gutov.dev>,
> >  Björn Bidar <bjorn.bidar@thaodan.de>,
> >  emacs-devel <emacs-devel@gnu.org>
> >
> > So I propose we let programmers use their judgement.
>
> That's fair enough, provided that those same programmers step up to
> become the Emacs maintainers, and thus share the burden to at least
> some extent.  Especially those of them who consider witty sarcasm a
> useful style in a discussion like this one.

Did you read the rest of the paragraph from which you extracted that
one line?  I'm advocating for being discriminate and

Also, I would hope this is not a suggestion that I don't step to share the
burden of maintaining things?  I do, certainly for all the features that I
have I added to core in the past 10 years and frequently also to parts
of the code those features interact with.  Do you often have to fix bugs in
flymake.el, elec-pair.el, icomplete.el, eldoc.el, jsonrpc.el, etc...
that I didn't care to take a look at in a reasonable time frame?  More
importantly, to what extent are you and others significantly or often
hindered by the style I use there?

I can't address what I don't know about.  I can't track the bug tracker
as closely as you do.  If I'm missing or late about bug reports about
such things, just ping me like you usually do.

Or are you suggesting I should dumb down my style for when I'm dead and
my code survives me?  Just so you know, I think that's not entirely
unreasonable.  In fact if you read the pdf I linked to, it's a valid
criteria for making decisions.   But it's definitely not the only one.
Who knows if Emacs 40's maintainer wouldn't have appreciated it if I
had smartened it up even more and use _only_ cl-lib.

Anyway, if there's some code of mine that's bothering you and you
find inescrutable, point me to it and we can discuss it, of course.

> The following is left as an exercise for the interested readers: take
> a non-trivial piece of code that you never in your life have laid your
> eyes upon, and decide what to do with a serious bug report about that
> code, with or without a patch proposed by someone.  A recent case in
> point: bug#66970.  Bonus points for doing this with code in a
> programming language you don't command 110%, like C if you are mainly
> a Lisp programmer or vice versa.

Do you need help reading some Elisp construct or debugging?
Is this meaningfully related to style in Lisp code?  You want help
reading hangul.el?  (which doesn't seem to use cl-lib.el btw)

Would you like help rewriting hangul-insert-character to support
overwrite-mode, perhaps by leveraging post-self-insert-hook?  I can
help with that.  If there is some deep required specific domain
knowledge about input methods or how the Korean language works, you
or someone else may have to help out with that.  If C code is involved,
it's not a problem.  I'll have a better look later.

The problem of maintaining other people's code (which btw is 95%
of all my professional experience) is not about programming techniques
or even languages at all, it's about domain knowledge.

João