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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Roland Winkler <winkler <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: 75170 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, acorallo <at> gnu.org
Subject: bug#75170: add-to-alist: new function
Date: Mon, 20 Jan 2025 14:41:28 -0600

Roland Winkler <winkler <at> gnu.org> writes:

> On Mon, Jan 20 2025, Robert Pluim wrote:
>> Iʼm not sure what this would offer over
>>
>>     (setf (alist-get key alist) value)
>>
>> which will add a key->value mapping if it doesnʼt exist, and replace
>> it if it does. I also donʼt see a real use for retaining the existing
>> mapping: `alist-get' will return the first one anyway.
>
> By now, this approach has been proposed in this thread a few times.
> The question is: this uses the concept of generalized variables.
> Is this a concept we recommend to users for their init files?
> To the best of my knowledge, previously this has not been the case.
> I am tempted to argue that in our recommendations what users should
> do in their init files, we should stick to strategies that are as
> simple and transparent as possible, and the above does not match
> that criterion.  A collection of functions we recommend to users for
> their init files might be a good thing.  add-to-list already serves
> that specific purpose, and add-to-alist could be another one.

I certainly appreciate the arguments against adding more redundancy to
ELisp, but I think the point still stands that Emacs should be easy to
customize.  Generalized variables don't do that job in my book.

Michael Heerdegen pointed out that `map-put!` could though, given:

    (setq foo '((clown . foot) (thunder . clap)))

We get:

    (map-put! foo 'clown 'hand)

Which I compare to:

    (add-to-alist foo '((clown . hand)))

Is that a workable alternative?  We lose the symmetry with `add-to-list`
of course, but there are fewer parentheses and dots to get wrong, and
all we need do is promote it.  Which may or may not be easy.

Previous Next

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