unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / Atom feed
* Handling minibuffers in several mini-windows
@ 2021-01-08 18:54 Alan Mackenzie
  2021-01-08 20:32 ` Stefan Monnier
  2021-01-10 12:06 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 6+ messages in thread
From: Alan Mackenzie @ 2021-01-08 18:54 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Handling minibuffers in several mini-windows
  2021-01-08 18:54 Handling minibuffers in several mini-windows Alan Mackenzie
@ 2021-01-08 20:32 ` Stefan Monnier
  2021-01-10  0:56   ` Alan Mackenzie
  2021-01-10 12:06 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2021-01-08 20:32 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Handling minibuffers in several mini-windows
  2021-01-08 20:32 ` Stefan Monnier
@ 2021-01-10  0:56   ` Alan Mackenzie
  0 siblings, 0 replies; 6+ messages in thread
From: Alan Mackenzie @ 2021-01-10  0:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Handling minibuffers in several mini-windows
  2021-01-08 18:54 Handling minibuffers in several mini-windows Alan Mackenzie
  2021-01-08 20:32 ` Stefan Monnier
@ 2021-01-10 12:06 ` Lars Ingebrigtsen
  2021-01-10 12:38   ` Alan Mackenzie
  1 sibling, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-10 12:06 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Handling minibuffers in several mini-windows
  2021-01-10 12:06 ` Lars Ingebrigtsen
@ 2021-01-10 12:38   ` Alan Mackenzie
  2021-01-11 14:22     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2021-01-10 12:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Handling minibuffers in several mini-windows
  2021-01-10 12:38   ` Alan Mackenzie
@ 2021-01-11 14:22     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-11 14:22 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-01-11 14:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-08 18:54 Handling minibuffers in several mini-windows Alan Mackenzie
2021-01-08 20:32 ` Stefan Monnier
2021-01-10  0:56   ` Alan Mackenzie
2021-01-10 12:06 ` Lars Ingebrigtsen
2021-01-10 12:38   ` Alan Mackenzie
2021-01-11 14:22     ` Lars Ingebrigtsen

unofficial mirror of emacs-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-devel/0 emacs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-devel emacs-devel/ https://yhetil.org/emacs-devel \
		emacs-devel@gnu.org
	public-inbox-index emacs-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.devel
	nntp://news.gmane.io/gmane.emacs.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git