Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed multibyte strings with text properties

From: Eli Zaretskii <[email-masked]>
Date: Sun, 19 Jan 2025 08:35:30 +0200

> From: Stefan Kangas <[email-masked]>
> Date: Sat, 18 Jan 2025 19:14:39 -0600
> Cc: Pip Cet <[email-masked]>, Richard Stallman <[email-masked]>, [email-masked], 
> 	[email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > If we were developing Emacs from scratch today, we would probably use
> > something simpler.  But we've had those macros for so long, and for
> > each kind of Lisp object in Emacs, that removing them now would need
> > to have a very good reason.
> 
> FTR, I agree that most of these macros should be removed.  It would be a
> useful simplification of our code.
> 
> This is not a new idea:
> https://lists.gnu.org/r/emacs-devel/2024-02/msg00806.html
> https://lists.gnu.org/r/emacs-devel/2024-03/msg00064.html
> 
> The counter-argument is "muscle memory" for old-time Emacs hackers.
> This disregards the complexity and confusion these macros mean for
> everyone that do not share said muscle memory.

This is a known tension for which there's no good solution except
asking the newcomers to get used to those macros.  The advantage of
remembering them is that one can instantly know where to look for some
problem or aspect of how Emacs internals work.  Removing them is a
terrible blow; I'm still recovering from the massive overhaul of
macros in lisp.h done years ago, and have to follow the chain of
macros and inline functions there too frequently, where previously I
just _knew_ how a macro works.  By contrast, newcomers will need to
learn the internals anyway, even if these macros weer removed, it's
just that their learning curve could perhaps be somewhat less steep,
because these macros are not hard to understand and the mental model
of their workings is quite simple.