bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related)

[Gregory Heytings]

> Alan, please take one step back and reconsider.  IIUC you added the 
> `record-window-buffer' call to read_minibuf, added the DO-MINIBUF 
> argument to `record-window-buffer' and now decide that 
> `buffer-list-update-hook' doesn't belong into `record-window-buffer'.
>
> Aren't you putting the cart before the horse?  That decision might be 
> correct but still constitutes a change that affects all applications 
> running `buffer-list-update-hook'.

As I said to Eli a week ago or so: "So far I haven't seen a single 
concrete example that demonstrates that this feature is either (a) 
necessary in some circumstances (as was bidirectional editing support), or 
(b) not necessary but at least useful in some circumstances."  Does anyone 
have such a concrete example?  I'm all ears.

It seems to me that the only benefit of this feature is a slightly 
different minibuffer behavior, that some users may perhaps find more 
convenient, as would be, for example, the possibility to display the 
minibuffer at the top of the frames.  Adding such a feature should not 
make Emacs 28 backward-incompatible in any way.

This experiment started in a bad way: its purpose was to fix a supposed 
bug, which, as it turned out, was not a bug at all, but the result of a 
misunderstanding, namely that isearch uses the echo area and not the 
minibuffer.  From then on, more and more changes were added to Emacs.

At a minimum, this experiment should be moved to a feature branch, and its 
result carefully reviewed before being merged again in the trunk.