Re: Emphasizing the top of the frame

[John Yates]

Hi Martin,

Hi Martin,

I failed to make this obvious in my previous post, but
I have two agendas:
* Make my own life tolerable on my 42" screen at work
* Provide a sufficiently complete mockup of a top-focused
  emacs that I can trigger some interest in making such a
  mode part of the core

I envision three components to such a mockup:
* Demonstrate that a minibuffer at the top need not imply
  all of the rework that would be necessary to support
  frame relayout on minibuffer expansion
* Demonstrate mode-lines at the top of windows
* Convince maintainers of some key minibuffer interaction
  packages to support downward growth (more below)

> BTW, your minibuffer
> frames grows downw

Indeed.  And I like it.  Except that some packages assume
upward growth and so position the prompt at the bottom of
the frame, whereas in my case the more natural position
would be at the top.

> I'm using a minibuffer child frame based on that principle for several
> years now and it rarely has let me down so far.

I suspect that if I used a child frame then at least some
of the glitches that I encounter would disappear.  The
reason that I cannot use a child frame is that doing so
constrains the minibuffer frame to reside within the space
managed by emacs.  As such it would be guaranteed to
hide something.

It is interesting that you mention that your separate
minibuffer frame "rarely has let [you] down".  From
that I conclude that you too know that the separate
minibuffer experience is not as polished as that with
a traditional minibuffer.

>  > * Management of the z-axis is not great; frame
>  >    restacking triggers an error on my Ubuntu box
>
> Which error?

I solved this one...

To avoid visible flashing and resizing during frame
creation, I initially marked the frame invisible, making
it visible at the last moment once all setup was done.
Part of the setup was an attempt to get the main and
the minibuffer frames into a proper stacking relationship.
It took a night's sleep and a shower for me to realize
that perhaps restacking an invisible frame might not
be supported.  (I am a C++ compiler writer by trade
and gui concepts are quite foreign.  I am having to
learn as I go. :-)

> (add-hook
>   'move-frame-functions
>   (lambda (frame)
>     (message "Frame %s moved to %s" frame (frame-position frame))))
>
> If you don't see them, please tell us which toolkit and window manager
> you use.

I had tried essentially that same experiment on my
own.  Just to be sure, I retried with your text verbatim.
Nothing shows up in *Messages*, neither with my
init.el loaded nor when I run emacs -Q.

I am on vanilla Ubuntu 21.10.
I build emacs regularly from the tip thusly:

./configure \
  --prefix=/usr/local/emacs \
  --program-transform-name='s/^ctags$/ctags.emacs/' \
  --disable-year2038 \
  --disable-acl \
  --with-modules \
  --with-json \
  --with-file-notification \
  --with-native-compilation \
  --with-xwidgets \
  --with-pgtk \
  >/tmp/config

>  > * Occasionally the echo area enters a rapidly
>  >    flashing state; sufficient ^g tend to clear it
>
> I have never seen such behavior here.  If you do not directly interact
> with the minibuffer in such a situation, it might depend on some minor
> mode like eldoc-mode enabled (I don't show eldoc in the echo area).

Ah. Yes. eldoc-mode.  Will disable that.

> You waste cycles updating the menubar, though.

At home and at work I have a hunky desktop.  I do
not observe any impact from menubar updates.

>  Have you ever tried
> putting the minibuffer frame on top of the title bar?

Yes I have.  The subjective experience was less
pleasant as my emacs frame(s) diverged visibly
from the ui conventions.

As I stated earlier, one goal is to demonstrate an
attractive layout and experience.  Were this part
of core emacs, a minibuffer at the top of the frame
would never overlay the title bar.  Overlaying the
menubar, by contrast, places the minibuffer visually
in a very natural position.

>  > I hope that the existence of mbmb prompts owners
>  > of minibuffer-resizing packages to support growth
>  > downward in addition to today's growth upward.
>  > (Could we standardize a frame parameter to record
>  > this direction?)
>
> Do you mean we should resize the frame whenever the minibuffer window
> changes size?  That sounds hardly feasible.

No.  Not at all.  I mean various packages assume
that, in a multi-line minibuffer layout, the persistent
minibuffer line is at the bottom and any additional
space has been added above.  Similarly, there are
packages that assume adjacency of the minibuffer
and the completions buffer is achieved by having
the completions buffer sit above the minibuffer.

/john