GNU bug report logs - #75170
add-to-alist: new function

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75170 <at> debbugs.gnu.org, rpluim <at> gmail.com, acorallo <at> gnu.org, winkler <at> gnu.org, monnier <at> gnu.org
Subject: bug#75170: add-to-alist: new function
Date: Wed, 22 Jan 2025 16:05:48 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 21 Jan 2025 14:34:48 -0600
> Cc: winkler <at> gnu.org, rpluim <at> gmail.com, acorallo <at> gnu.org, 75170 <at> debbugs.gnu.org, 
> 	monnier <at> gnu.org
> 
> Stefan Kangas <stefankangas <at> gmail.com> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> From: Stefan Kangas <stefankangas <at> gmail.com>
> >>> Date: Tue, 21 Jan 2025 13:41:17 -0600
> >>> Cc: rpluim <at> gmail.com, acorallo <at> gnu.org, 75170 <at> debbugs.gnu.org, monnier <at> gnu.org
> >>>
> >>> I believe that the "contains both associations" part is what will risk
> >>> confusing some users.  It's not a given that they know that the first
> >>> one is the one that will be used.  It could just as easily have been the
> >>> last one, for example.
> >>
> >> And yet add-to-list is exactly what we tell users to use, see the node
> >> (emacs) Frame Parameters.
> >
> > I'm personally on the fence about this addition.  I see good arguments
> > both for and against.
> >
> > Given your doubts, maybe we should close this as a wontfix.
> 
> I sent that too soon.  It should have read:
> 
>     Given your doubts, and the controversy around this, maybe we should
>     close this as a wontfix.

I don't have strong feelings or opinions, actually.  Adding another
API whose name is similar to an existing one, but which works
differently (and what's worse, has different syntactic requirements),
will add to confusion and to the documentation efforts (need to go
through all the places where we currently recommend add-to-list and
change them).  But if enough people insist on that...

I do still wonder why people who most certainly know about Emacs Lisp
enough to use setf/alist-git insist on adding this function to Emacs,
even though they've already solved their problem by having a private
definition for it.  Why insist on adding this to Emacs?  But I don't
necessarily expect an answer to that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.