bug#43439: [PATCH] doprnt improvements

[Eli Zaretskii]

> Cc: 43439@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 15 Oct 2020 11:50:48 -0700
> 
> On 10/15/20 11:12 AM, Eli Zaretskii wrote:
> > I didn't agree to modifying doprnt in
> > significant ways, so you are now suggesting to do an even more radical
> > modification, just under another name?
> 
> If you'd rather have the patch keep doprnt entirely as-is (i.e., not change 
> doprnt's implementation at all), I can easily modify the patch to do that.

No, I want to continue calling doprnt directly, not replace all its
calls with a call to another function.  doprnt by itself is useless
unless it is used by the relevant primitives.  I see no need to
replace it with another function, because doprnt works and works well.

> All current Emacs code that calls doprnt would benefit from switching to the 
> proposed evsnprintf function, an API that is simpler and faster and that has 
> better static checking with GCC.

Yes, that's exactly where we disagree.  I made my proposal to find
some kind of middle ground, and was disappointed to see you suggesting
to move even farther from a potential agreement.

In general, I'm against messing with code that has been stable for
ages, for ephemeral benefits or minor stylistic reasons.  If nothing
else, it gets in the way of maintaining Emacs because code I've known
for years and could find with my eyes closed constantly shifts and
changes under my feet.  Another example of this is that src/lisp.h
macros look nowadays completely different from what they were several
years ago.  This need to constantly unlearn that which was burned into
my muscle memory is not pleasant at all.  Changes that take us forward
because they are needed for new and improved features are welcome and
justified, but there are no new features in all those changes,
including in the doprnt patch.  I wish this fever would stop.