Subject: bug#75170: add-to-alist: new function

From: Stefan Kangas <[email-masked]>
Date: Tue, 21 Jan 2025 13:41:17 -0600

Roland Winkler <[email-masked]> writes:

> 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 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.