GNU bug report logs -
#75170
add-to-alist: new function
Previous Next
Full log
View this message in rfc822 format
On Tue, Jan 21 2025, Eli Zaretskii wrote:
> 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?
You probably know better than almost everybody else what emacs is doing
under the hood, how individual user variables are being processed and
how changing their values in whatever way is going to change emacs'
behavior. Then, if add-to-list is doing what you want or need, that's
great. But is your level of expertise the benchmark for customizing
emacs?
I agree with Stefan K:
> 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.
You replied:
> And yet add-to-list is exactly what we tell users to use, see the node
> (emacs) Frame Parameters.
This quote is not about add-to-list as a feature for user init files,
but it is about default-frame-alist. It does not address what Stefan
said: with the next alist a user wants to customize, it could be the
last association for a key that will be used.
The goal of add-to-alist is to make customizing alists transparent for
non-expert users. When a user inspects an alist that has been
customized with add-to-alist, its value will be what the user expects it
to be, and not just what it can also be to achieve that purpose, if only
the first (or last) association for a key happens to be relevant.
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.