Eli Zaretskii writes: >> From: >> Cc: acm@muc.de, 49700@debbugs.gnu.org >> Date: Fri, 23 Jul 2021 10:34:45 +0200 >> >> > I'd prefer not to expose minibuffer-alist to Lisp if it can be >> > avoided. This is a tricky area of Emacs, and exposing it to Lisp IMO >> > gives Lisp programmers too much rope to hang themselves. >> >> Well, the minibuffer list is already kind of exposed to lisp, try: >> (seq-filter #'minibufferp (buffer-list)) > > Then why did you need to introduce a new function? It's fine with me > to use the above if it does the job. > Yes, the above returns an unsorted list of minibuffers and I don't know of any way to sort them according to depth. minibuffer-alist would return a sorted list. >> minibuffer-alist returns a newly constructed list, similar to >> buffer-list, so modifying the list structure is safe. What could be >> unsafe is modifying the minibuffers themselves, renaming or killing >> them. > > Exactly. And there are more atrocities that can be done with these > buffers. > >> I believe that, since such actions are possible without the use >> of minibuffer-alist >> (for example, by evaluating (kill-buffer " *Minibuf-1")), they should >> not mess up Emacs internals and it should be treated as a bug if they >> do. > > I'd like to make that as difficult as possible. When someone reports > a bug, it could take some time and effort to discover that the code > does something it shouldn't, and that eats up our precious resources. > Also, if we expose the list of minibuffers explicitly, and with > auxiliary information on top of that, it is hard to defend the > position that Lisp programs should not do anything they want with that > information. > OK, I understand. >> > Is it feasible to make these changes without exposing the alist? >> >> Yes it is feasible. If the above didn't convince you, please send >> another e-mail and I will try. Thanks. > > Yes, please try, and thanks in advance. OK, I will, but it might take about a week as I'm currently away.