Re: master 78fc49407b8 1/3: Improve filling of ChangeLog entries

[Dmitry Gutov]

On 31/01/2024 20:45, Alan Mackenzie wrote:
> Hello, Dmitry.
>
> On Wed, Jan 31, 2024 at 19:05:57 +0200, Dmitry Gutov wrote:
> > On 31/01/2024 17:32, Alan Mackenzie wrote:
> > > On Wed, Jan 31, 2024 at 17:15:41 +0200, Dmitry Gutov wrote:
> > > > On 31/01/2024 16:01, Po Lu wrote:
> > > > > See any file in CC Mode,
> > > > No shortage of maintainers, you say?
> > > None.
> > One cannot name a package with bus factor of 1 and say it has plenty of
> > people willing to maintain it.
> What's a "bus factor" in this context?
The smallest number of developers who would need to mysteriously 
disappear, for it to become a problem for the project.
> It would appear that one person,
> me, is indeed enough to maintain it.  The rate of bugs reported for it
> has sunk to near zero, possibly because of the release of the tree sitter
> C Mode in Emacs 29.1.
That's good.

> > I don't mean to criticize your work (not knowing the exact tradeoffs),
> > but it's plainly a bad example.
> Bad example of what?
Of a body of Lisp code maintained by different developers, who all 
accepted (and possibly chosen) its current style, thereby justifying it 
as something usable as a standard, rather than only a personal preference.
> [ .... ]
>
> > > After several days of struggling with named-let, cl-labels, and friends,
> > > I vote for the plain Lisp, even if it does need more lines to express.
> > > It is simply less work.
> > I've never used named-let, and very rarely cl-labels.
> I've never used either, but still need to debug them.  :-(
edebug usually helps, no?

> > The latter is a very simple idea, though: create a bunch of local
> > function definitions. Like nested functions in Python, for example.
> It's a complicated macro.  Why is it needed at all?  Is there anything
> using it that couldn't be conveniently written in plain Lisp?
Having local variable bindings with lambda values is a little messier in 
comparison. For example, the use of cl-labels in 
'comp-collect-rev-post-order' seems easy to read and thus justified. 
Also, it allows having mutually recursive functions, which won't be an 
option in sequential bindings (but I don't see this property taken 
advantage of much).