[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How can I force updating mini window's header line when mode line is

From: Amos Bird
Subject: Re: How can I force updating mini window's header line when mode line is updated?
Date: Fri, 27 Apr 2018 10:52:55 +0800
User-agent: mu4e 1.0-alpha3; emacs 27.0.50

Yeah, I think using mini window's header line is indeed a nasty idea,
but it somehow fits my need (both in GUI and terminal emacs).

I've hacked some xdisp code and it works now.

Here is what I've done.

1. turn on the head line of mini window by tweaking window_wants_header_line. 2. change a bunch of functions that initialize mini-window size to 2 instead of 1.
3. hide normal window's mode line if it's at bottom
4. always use inactive mode line format and empty string content for normal window
(used to build horizontal divider in terminal)
5. refresh mini window's header line on every window's redisplay action. 6. make sure mode line format uses previous-window if mini window is selected

It seems to cover all the corner cases I can reach in both GUI and terminal. (minibuffer resizing, frame/window switching, frame creation/deletion...)

Here is a demo screencast in terminal emacs.


martin rudalics <address@hidden> writes:

Emacs code has deep assumption of mini window having only one line.

This is not entirely correct. As long as other windows on the same
frame fit, a minibuffer window can get quite large (see
'max-mini-window-height').  But in some parts of the window and
redisplay code we assume that minibuffer windows behave like pseudo windows (those used for displaying the tool bar or the menu bar on some platforms) or internal windows - they can't have dividers, a mode or a header line because these are simply not counted when displaying the window or calculating its height. That's why you observe that

After I turn on the header line, things become messy.

For example, 'window_wants_header_line' in window.c cannot deal with

I'll try
collecting all the hard-coded logic and see if this route indeed

Good idea.  Note that I'm currently changing a number of things
related to minibuffer windows which, among others, should allow them to appear anywhere on a frame or even not being displayed at all. So I do not think that displaying the mode line of a frame within the minibuffer window is a good idea in the first place. Even presently,
people who use standalone minibuffer frames might not be very
enthralled by the idea that they have to look on their minibuffer
frame for consulting the mode line contents.

I think that if we want frame-local modelines which, IIUC should
display the mode line contents of the frame's selected window, it might be a better idea to add a new kind of pseudo window on top or
bottom of a frame for that.


Amos Bird

reply via email to

[Prev in Thread] Current Thread [Next in Thread]