Handling minibuffers in several mini-windows

Handling minibuffers in several mini-windows

[Alan Mackenzie]

Hello, Emacs.

This post probably belongs in the thread "Stop frames stealing
eachothers' minibuffers!", but I think people are beginning to suffer
thread-fatigue wrt that thread.  Only Martin R. is currently posting
things to me in that thread.  (Thanks, Martin!)

The problem arises when minibuffer-follows-selected-frame is configured
to nil, thus allowing several mini-windows to be simultaneously visible
in several frames.  As long as the user attempts to use only the most
deeply nested MB, that isn't a problem, but when she tries to type into,
terminate, or abort another MB, we've got to decide how to handle it.

My proposal (which I've already implemented and tried out, though not
published at all), is that
(i) it should be possible to type into, and edit text in any visible
  minibuffer;
(ii) it should be possible to terminate (by RET `exit-minibuffer') only
  the most deeply nested MB.  The attempt elsewhere should display an
  error message, leaving the MBs unchanged;
(iii) it should be possible to abort (with C-g `abort-recursive-edit'),
  any minibuffer.  This will have the effect of aborting all more deeply
  nested MBs at the same time.

What do people think about this?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Handling minibuffers in several mini-windows

[Stefan Monnier]

> My proposal (which I've already implemented and tried out, though not
> published at all), is that
> (i) it should be possible to type into, and edit text in any visible
>   minibuffer;
> (ii) it should be possible to terminate (by RET `exit-minibuffer') only
>   the most deeply nested MB.  The attempt elsewhere should display an
>   error message, leaving the MBs unchanged;
> (iii) it should be possible to abort (with C-g `abort-recursive-edit'),
>   any minibuffer.  This will have the effect of aborting all more deeply
>   nested MBs at the same time.
>
> What do people think about this?

(i) and (ii) look fine to me.

I haven't thought very much about (iii) but it sounds OK tho maybe
making it behave more like (ii) would be safer (but more annoying).


        Stefan

Re: Handling minibuffers in several mini-windows

[Alan Mackenzie]

Hello, Stefan

On Fri, Jan 08, 2021 at 15:32:40 -0500, Stefan Monnier wrote:
> > My proposal (which I've already implemented and tried out, though not
> > published at all), is that
> > (i) it should be possible to type into, and edit text in any visible
> >   minibuffer;
> > (ii) it should be possible to terminate (by RET `exit-minibuffer') only
> >   the most deeply nested MB.  The attempt elsewhere should display an
> >   error message, leaving the MBs unchanged;
> > (iii) it should be possible to abort (with C-g `abort-recursive-edit'),
> >   any minibuffer.  This will have the effect of aborting all more deeply
> >   nested MBs at the same time.

> > What do people think about this?

> (i) and (ii) look fine to me.

> I haven't thought very much about (iii) but it sounds OK tho maybe
> making it behave more like (ii) would be safer (but more annoying).

Thanks for the reply.  Having thought about it for a day, I think I'll
go with (iii) anyway.  I've posted a patch in the other thread, and
barring any negative comments, will soon be committing it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Handling minibuffers in several mini-windows

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> My proposal (which I've already implemented and tried out, though not
> published at all), is that
> (i) it should be possible to type into, and edit text in any visible
>   minibuffer;
> (ii) it should be possible to terminate (by RET `exit-minibuffer') only
>   the most deeply nested MB.  The attempt elsewhere should display an
>   error message, leaving the MBs unchanged;
> (iii) it should be possible to abort (with C-g `abort-recursive-edit'),
>   any minibuffer.  This will have the effect of aborting all more deeply
>   nested MBs at the same time.
>
> What do people think about this?

i and ii sound good to me.  I'm not sure about iii -- I think trying it
out and see what it feels like in practice might be a good idea, though.

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

Re: Handling minibuffers in several mini-windows

[Alan Mackenzie]

Hello, Lars.

On Sun, Jan 10, 2021 at 13:06:12 +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > My proposal (which I've already implemented and tried out, though not
> > published at all), is that
> > (i) it should be possible to type into, and edit text in any visible
> >   minibuffer;
> > (ii) it should be possible to terminate (by RET `exit-minibuffer') only
> >   the most deeply nested MB.  The attempt elsewhere should display an
> >   error message, leaving the MBs unchanged;
> > (iii) it should be possible to abort (with C-g `abort-recursive-edit'),
> >   any minibuffer.  This will have the effect of aborting all more deeply
> >   nested MBs at the same time.

> > What do people think about this?

> i and ii sound good to me.  I'm not sure about iii -- I think trying it
> out and see what it feels like in practice might be a good idea, though.

An idea: in (iii), how about asking the user with yes-or-no-p before
aborting more than one level?  It's something which is unlikely to come
up more than occasionally.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Handling minibuffers in several mini-windows

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> An idea: in (iii), how about asking the user with yes-or-no-p before
> aborting more than one level?  It's something which is unlikely to come
> up more than occasionally.

Yeah, that sounds like a good idea.  And we can see whether it
interferes with anybody's work patterns, but I agree with you that it
seems unlikely.

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