GNU bug report logs -
#75170
add-to-alist: new function
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.