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

Previous Next

Full log

Message #46 received at 75170 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thievol <at> posteo.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75170 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <acorallo <at> gnu.org>, Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#75170: add-to-alist: new function
Date: Sun, 19 Jan 2025 15:14:10 +0000

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Roland Winkler <winkler <at> gnu.org>
>>> Cc: 75170 <at> debbugs.gnu.org
>>> Date: Sun, 29 Dec 2024 08:50:18 -0600
>>>
>>> On Sun, Dec 29 2024, Eli Zaretskii wrote:
>>> > What is the advantage of adding this function, given that add-to-list
>>> > can be used with alists, and given that alist-get can nowadays be used
>>> > as a generalize variable?
>>>
>>> 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.
>>>
>>> Say, I want in my .emacs file a more complicated association for a key,
>>> and I do not get initially what I want.  I can call add-to-alist
>>> multiple times, till I get what I want.
>>>
>>> Is there a simple way to accomplish this in other ways (a way that we
>>> recommend for users in their init file if they do not want to use
>>> customize like me)?
>>>
>>> Would it make sense to give this functions a different name if more
>>> often it may be used to modify existing associations in an alist instead
>>> of adding new ones?
>>
>> Let's hear the other co-maintainers.
>>
>> Stefan and Andrea, WDYT about this?  Should we add this function?
>
> The benefit here is that users could more easily replace associations in
> alists.  Superfluous associations are not the end of the world, as
> `alist-get' will anyways only get the first one, but users might not
> know that, and it's less aesthetically pleasing.
>
> If Emacs Lisp was just a programming system, then I would be against
> this addition as redundant.  Since a small subset of ELisp is also used
> as a kind of "customization language", I think it occasionally makes
> sense to introduce even redundant constructs, provided that it makes
> said customization easier.  I think this might be one such example.
>
> On balance, I think we could add it.

While you are at it why not implementing a add-to-(a)list function that
add/remove an elemnt at INDEX in list?
It is what I am providing for my users in Helm.

(setq example '((a . 1) (b . 6) (c . 3) (d . 4)))

(helm-add-to-list 'example '(b . 2) 1 'replace)

=>((a . 1) (b . 2) (c . 3) (d . 4))

-- 
Thierry

Previous Next

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