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

Previous Next

Package: emacs;

Reported by: Roland Winkler <winkler <at> gnu.org>

Date: Sun, 29 Dec 2024 05:35:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 75170 <at> debbugs.gnu.org, rpluim <at> gmail.com, acorallo <at> gnu.org, stefankangas <at> gmail.com, monnier <at> gnu.org
Subject: bug#75170: add-to-alist: new function
Date: Tue, 21 Jan 2025 21:35:05 +0200
> From: Roland Winkler <winkler <at> gnu.org>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  rpluim <at> gmail.com,
>   acorallo <at> gnu.org,  75170 <at> debbugs.gnu.org,  monnier <at> gnu.org
> Date: Tue, 21 Jan 2025 13:21:01 -0600
> 
> On Tue, Jan 21 2025, Eli Zaretskii wrote:
> > Can someone tell me again why add-to-list doesn't fit the bill of
> > being a tool easy for end-users?  I've been using it in my init files
> > to customize stuff like default-frame-alist since about forever.
> 
> The following was my answer from end of last year:
> 
> On Sun, Dec 29 2024, Roland Winkler wrote:
> > The advantage I see for also having the function add-to-alist is the
> > following:
> >
> > add-to-list checks for the presence of an element in a list.  In the
> > case of alists, this means it checks for the presence of associations.
> > You cannot easily modify an existing association with add-to-list.  If
> > you have an alist with association (foo . bar) and you call add-to-list
> > with an element (foo . baz), add-to-list will not remove the association
> > (foo . bar), but the alist will then contain both associations.
> >
> > add-to-alist checks for the presence of keys and it makes sure that each
> > key appears only once in an alist.  By default, it replaces the value of
> > an existing key.  This makes it easy to modify an existing association.
> > Only with the optional arg NO-REPLACE non-nil, it will preserve an
> > existing association.

I know all this, but why do we think end-users who aren't comfortable
with alist-get and setf will need to "check for the presence of keys
and make sure that each key appears only once in an alist"?  Since by
default add-to-list prepends the new association, those which come
after it don't matter, right?

So if we want to cater to people for whom Lisp is not a first
language, why do we think they need anything beyond add-to-list?  Does
the fact that I still use add-to-list, so many years after I started
using Emacs, tell something?




This bug report was last modified 196 days ago.

Previous Next


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