Minibuffer positioned at a location other than the bottom of the frame?

Minibuffer positioned at a location other than the bottom of the frame?

[Evgeny Roubinchtein]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Dear Emacs developers and users,

Has any consideration been given to having the option of displaying the
minibuffer window somewhere other than the bottom of the frame?  For
example, if I have a frame split horizontally with bufferA on top and
bufferB at the bottom, and I do an isearch in bufferA, it might (arguably)
be nice to have the minibuffer window appear below bufferA's mode line, as
opposed to below bufferB's mode line.

I have found this thread:
https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00114.html, and I
am aware of the possibility of moving a separate minibuffer frame to
achieve something similar, but I am specifically curious about loosening
the "if a frame has a minibuffer window, the minibuffer window is displayed
at the bottom of the frame" assumption.

Please Cc me on the replies.

Thank you in advance!

-- 
Best,
Zhenya

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

Re: Minibuffer positioned at a location other than the bottom of the frame?

[martin rudalics]

 > Has any consideration been given to having the option of displaying the
 > minibuffer window somewhere other than the bottom of the frame?

No, because ...

 > For
 > example, if I have a frame split horizontally with bufferA on top and
 > bufferB at the bottom, and I do an isearch in bufferA, it might (arguably)
 > be nice to have the minibuffer window appear below bufferA's mode line, as
 > opposed to below bufferB's mode line.

... if you now decide to delete the window showing bufferA, where would
the minibuffer window move to?  Keeping the minibuffer window constantly
below a frame's selected window, for example, could be very annoying
because the window configuration would change continuously.  Moving it
to the window where a user interaction via the minibuffer is initiated
as well.  So ...

 > moving a separate minibuffer frame to
 > achieve something similar,

... seems indeed the only practicable way to do what you want.

martin

Re: Minibuffer positioned at a location other than the bottom of the frame?

[Eli Zaretskii]

> Date: Tue, 21 Nov 2017 10:27:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Has any consideration been given to having the option of displaying the
>  > minibuffer window somewhere other than the bottom of the frame?
> 
> No, because ...
> 
>  > For
>  > example, if I have a frame split horizontally with bufferA on top and
>  > bufferB at the bottom, and I do an isearch in bufferA, it might (arguably)
>  > be nice to have the minibuffer window appear below bufferA's mode line, as
>  > opposed to below bufferB's mode line.
> 
> ... if you now decide to delete the window showing bufferA, where would
> the minibuffer window move to?  Keeping the minibuffer window constantly
> below a frame's selected window, for example, could be very annoying
> because the window configuration would change continuously.  Moving it
> to the window where a user interaction via the minibuffer is initiated
> as well.

Indeed, there seems to be a lot of hidden aspects of this, which were
never mentioned, nor is there any proposal I'm aware of that describes
them.  This must be clarified and agreed upon first, before we
consider implementing anything like that.  First and foremost, the
design and the user-facing aspects should make sense.

Re: Minibuffer positioned at a location other than the bottom of the frame?

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

​​The OP suggested a dynamic positioning of the minibuffer. That would be a
significant change in the UI and as Eli points out would present many
aspects that would need to be worked out.

A little over a year ago I broached a more modest change in this thread:​​

https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00859.html

There I raised the notion of (optionally) moving the modeline to the top of
each window and positioning the minibuffer to the top of the frame.

Screen technology keeps​,​ evolving enabling ever larger screens with ever
more pixels. At the time ​that ​I initiated that thread I owned a 3​0​"
(diagonal) 2560x1600 monitor. Since that time my employer has provided me a
43" 3840x2160 monster (HxW = 26"x38"). This is a thing of beauty but sadly
a miserable experience when emacs ​tries​ to manage the whole screen as ​a
single frame. Yes, I can have many full height windows side by side showing
me an unprecedented amount from each buffer. ​And​ I ​can ​cope with the
38" screen width by ​collecting the two or three windows of most current
interest side by side at the center of the frame. But _very_ often buffer
content fails to fill ​its​ window. This means that I cannot scroll ​that​
content to the middle of the screen. This leaves buffer content often
displayed nearly 2 feet removed from its mode line and the minibuffer.

Trying to work in this configuration is essentially impossible. ​My current
compromise is to waste 2/3 of the screen​'s pixels​, creating a 1/3 height,
full width frame.

Interestingly, I feel much less disoriented using the ​full screen height
with a tiling window manager (awesome) displaying full height web pages and
GUI desktop productivity apps. My conclusion is ​​that ​some ​aspects of
the emacs UI ​(​rooted​ at least partially ​in considerations of repainting
early glass TTYs​)​ could stand to be reassessed.  For instance,
positioning the modeline at the top of our windows would align emacs with
the now nearly universal UI idiom that positions a titlebar at the top of a
window.

/john​

[-- Attachment #2: Type: text/html, Size: 3668 bytes --]

Re: Minibuffer positioned at a location other than the bottom of the frame?

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Sat, 25 Nov 2017 09:43:13 -0500
> Cc: martin rudalics <rudalics@gmx.at>, zhenya1007@gmail.com, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> A little over a year ago I broached a more modest change in this thread:​​
> 
> https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00859.html
> 
> There I raised the notion of (optionally) moving the modeline to the top of each window and positioning the
> minibuffer to the top of the frame.

This should be much easier, see

  https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00895.html

and followups.

Volunteers are welcome to try making that happen.  I think it would be
an important feature.

Re: Minibuffer positioned at a location other than the bottom of the frame?

[martin rudalics]

 >> There I raised the notion of (optionally) moving the modeline to the top of each window and positioning the
 >> minibuffer to the top of the frame.
 >
 > This should be much easier, see
 >
 >    https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00895.html
 >
 > and followups.

I doubt that "Positioning the minibuffer to the top of the frame" would
be "much easier": When Emacs enlarges the minibuffer window it then has
to move all windows beneath down by the number of lines the minibuffer
window has been enlarged.  To not make these windows' texts move down
accordingly (which would constitute a very unpleasent visual experience)
we would have to try to change these windows' start positions and
restore them accordingly when shrinking the minibuffer window back.
Obviously, with point near the top of the window or varying line heights
such an attempt might become very tricky or even impossible.

Putting the minibuffer window below some arbitrary (maybe even internal)
window of a frame would not run into such difficulties.

martin

Re: Minibuffer positioned at a location other than the bottom of the frame?

[Eli Zaretskii]

> Date: Sun, 26 Nov 2017 11:26:13 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: zhenya1007@gmail.com, emacs-devel@gnu.org
> 
>  >> There I raised the notion of (optionally) moving the modeline to the top of each window and positioning the
>  >> minibuffer to the top of the frame.
>  >
>  > This should be much easier, see
>  >
>  >    https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00895.html
>  >
>  > and followups.
> 
> I doubt that "Positioning the minibuffer to the top of the frame" would
> be "much easier"

"Much easier" than positioning it dynamically below the selected
window, or some other dynamic positioning.  I'm sure you will agree.

> When Emacs enlarges the minibuffer window it then has
> to move all windows beneath down by the number of lines the minibuffer
> window has been enlarged.

Why "all"? why not just the next window below the minibuffer?  That's
what we do now: we resize only the window immediately above the
minibuffer.  Right?

> To not make these windows' texts move down
> accordingly (which would constitute a very unpleasent visual experience)
> we would have to try to change these windows' start positions and
> restore them accordingly when shrinking the minibuffer window back.

That's probably true, but we need to redisplay that window anyway, so
we can choose a different window-start while we are at that.

> Obviously, with point near the top of the window or varying line heights
> such an attempt might become very tricky or even impossible.

I don't see why it would be impossible.  And in any case, this will be
an opt-in feature, so those who don't like the result will not use it.

> Putting the minibuffer window below some arbitrary (maybe even internal)
> window of a frame would not run into such difficulties.

I'm okay with that as well, if someone figures out how to implement
it.

Re: Minibuffer positioned at a location other than the bottom of the frame?

[Yuri Khan]

On Sat, Nov 25, 2017 at 9:43 PM, John Yates <john@yates-sheets.org> wrote:

> Screen technology keeps, evolving enabling ever larger screens with ever
> more pixels. At the time that I initiated that thread I owned a 30"
> (diagonal) 2560x1600 monitor. Since that time my employer has provided me a
> 43" 3840x2160 monster (HxW = 26"x38"). This is a thing of beauty but sadly a
> miserable experience when emacs tries to manage the whole screen as a single
> frame.

If that 43" is at a standard arm’s length, you could use a tiling
window manager to split it into a matrix of three columns by two rows,
then treat it as six separate 16.3" monitors, 1280×1080 pixels each.

Also, how is it positioned? Ergonomic guidelines say the top of the
monitor should be at eye level, but then the bottom edge will probably
be below desk surface.

Re: Minibuffer positioned at a location other than the bottom of the frame?

[John Yates]

On Sun, Nov 26, 2017 at 11:29 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> If that 43" is at a standard arm’s length, you could use a tiling
> window manager to split it into a matrix of three columns by two rows,
> then treat it as six separate 16.3" monitors, 1280×1080 pixels each.

I want the simplicity of managing a single concept: emacs windows.
Put another way, I do not want to get involved with emacs windows
versus frames, nor emacs windows versus window manager windows.

> Also, how is it positioned? Ergonomic guidelines say the top of the
> monitor should be at eye level, but then the bottom edge will probably
> be below desk surface.

My physical desk is a motorized stand-up desk.  I can position that
massive monitor as I choose.  Currently I would say that it is about
1 1/3 arm's length away and positioned so that when I stare straight
ahead I am looking at a point about 1/4 of the way down the screen.
Looking upwards closer to the top of the screen is no issue.  Having
to jump frequently to the bottom of the screen is dizzying.

/john

very large displays

[Stephen Leake]

John Yates <john@yates-sheets.org> writes:

>
> ... Since that time my employer has provided me a
> 43" 3840x2160 monster (HxW = 26"x38"). ...
>
> Trying to work in this configuration is essentially impossible. ​My current
> compromise is to waste 2/3 of the screen​'s pixels​, creating a 1/3 height,
> full width frame.

Did you try creating multiple Emacs frames (all from the same Emacs process),
and using the Gnu ELPA package other-frame-window to help place buffers
in the appropriate frames?

I use two Emacs frames side-by-side, and never have Emacs windows
side-by-side.

--
-- Stephe

Re: Minibuffer positioned at a location other than the bottom of the frame?

[martin rudalics]

 >> I doubt that "Positioning the minibuffer to the top of the frame" would
 >> be "much easier"
 >
 > "Much easier" than positioning it dynamically below the selected
 > window, or some other dynamic positioning.  I'm sure you will agree.

Logistically, yes.  But not when it comes to handling the visual
appearance.  I recall that I once tried to resize a frame's windows
proportionally when resizing the echo area.  You were not amused.

 >> When Emacs enlarges the minibuffer window it then has
 >> to move all windows beneath down by the number of lines the minibuffer
 >> window has been enlarged.
 >
 > Why "all"? why not just the next window below the minibuffer?  That's
 > what we do now: we resize only the window immediately above the
 > minibuffer.  Right?

When you have two side-by-side windows on the top of a frame you have to
resize them both.  Just as we do now when there are two side-by-side
windows right above the echo area.  If such windows have fixed height or
are too small, we have to resize other windows as well.

 >> To not make these windows' texts move down
 >> accordingly (which would constitute a very unpleasent visual experience)
 >> we would have to try to change these windows' start positions and
 >> restore them accordingly when shrinking the minibuffer window back.
 >
 > That's probably true, but we need to redisplay that window anyway, so
 > we can choose a different window-start while we are at that.

But there's a great visual difference when the entire contents of a
window move on screen instead of when just some of its bottom lines get
hidden or revealed.

 >> Obviously, with point near the top of the window or varying line heights
 >> such an attempt might become very tricky or even impossible.
 >
 > I don't see why it would be impossible.

To keep the text exactly in place, we would possibly have to start a
window with a partly obscured line.  IIUC we could do that but there are
no functions for it (have the iterator step backward, calculate how much
to show of the first line of a window).  So it's "impossible" with our
current means.

 > And in any case, this will be
 > an opt-in feature, so those who don't like the result will not use it.
 >
 >> Putting the minibuffer window below some arbitrary (maybe even internal)
 >> window of a frame would not run into such difficulties.
 >
 > I'm okay with that as well, if someone figures out how to implement
 > it.

A first step would be to allow not showing echo area and minibuffer at
all and, in case of a user interaction, show them just in the selected
window or on a separate frame as a fallback.  And, obviously, create a
minibuffer window on the fly whenever and wherever it's needed.

Note that while some comments in our sources still consider it vital
that the minibuffer window is always visible, in practice this has no
importance since you can always shrink a frame to its title bar (which
for a GUI might be the most convenient position for showing echo area
and minibuffer anyway).

martin