bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> + DEFVAR_BOOL ("read-minibuffer-restore-windows",
>> read_minibuffer_restore_windows,
>> + doc: /* Non-nil means restore window configurations on exit from
>> minibuffer.
>> +If this is non-nil (the default), reading input with the minibuffer will
>> +restore, on exit, the window configurations of the frame where the
>> +minibuffer was entered from and, if it is different, the frame that owns
>> +the associated minibuffer window.  If this is nil, no such restorations
>> +are done.  */);
>> +  read_minibuffer_restore_windows = true;
>
> I recommend to install this patch.  Maybe it's not perfect, but works
> reasonably well, and there is the high demand for this feature.

Oh, I didn't realise that it hadn't been applied already, so I redid it
for the current trunk and tested it, and it seems to work as expected,
so I went ahead and pushed it.

> Only such additional patch is necessary:

[...]

> +  ;; When read_minibuf doesn't restore all previous windows,
> +  ;; then at least pop down the completions window.
> +  (unless read-minibuffer-restore-windows
> +    (minibuffer-hide-completions))

Hm...  Well, I guess that's what most people would want...  but...
should it be user-controllable?  Perhaps read_minibuffer_restore_windows
shouldn't be a boolean, but allow values like t, 'completions and nil,
where 'completions would trigger this behaviour?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no