bug#49700: 27.2; [PATCH] Refactor minibuffer aborting

[Eli Zaretskii]

> From: <miha@kamnitnik.top>
> 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.

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

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