bug#1503: feature request: multiline header (and mode) lines

bug#1503: feature request: multiline header (and mode) lines

[Peter Mao]

I realize this requires tweaking of the C-code, but I'm not awesome
enough to do it myself:

Can emacs be given the gift of a header-line that word wraps, so that
the header can be more than one line tall?  I imagine the same could
go for the mode line, but I don't have a clear need for that right
now.  I know that the fringes can occupy > 1 column, so it seems like
an oversight if the header and mode lines are restricted to 1 line.

I've written a minor mode for reading/sorting physics abstracts from
the physics arXiv.  The mode either lists subdirectories directly
under the current directory, or recursively lists all subdirectories
of the pwd.  Either way, the list could potentially be longer than the
width of the screen, making some directory names unviewable.  A
multiline header would make it perfect.

I thought of putting that text in the buffer, but that makes it much
harder to update the text.

Peter Mao

bug#1503: feature request: multiline header (and mode) lines

[martin rudalics]

 > Can emacs be given the gift of a header-line that word wraps, so that
 > the header can be more than one line tall?  I imagine the same could
 > go for the mode line, but I don't have a clear need for that right
 > now.  I know that the fringes can occupy > 1 column, so it seems like
 > an oversight if the header and mode lines are restricted to 1 line.
 >
 > I've written a minor mode for reading/sorting physics abstracts from
 > the physics arXiv.  The mode either lists subdirectories directly
 > under the current directory, or recursively lists all subdirectories
 > of the pwd.  Either way, the list could potentially be longer than the
 > width of the screen, making some directory names unviewable.  A
 > multiline header would make it perfect.
 >
 > I thought of putting that text in the buffer, but that makes it much
 > harder to update the text.

At the moment, we can't do that because the fact that a header-line
occupies exactly one line of text is hardwired into many lower-level
primitives.  In principle, what you want could be accomplished by the
routines below, but this will certainly have wrinkles (Emacs is not
really good at handling zero-length overlays).

martin


(defvar my-overlay (make-overlay (point-min) (point-min)))

(defun my-move (window start)
   (move-overlay my-overlay start start))

(add-hook 'window-scroll-functions 'my-move nil t)

(defun my-text (text)
   (overlay-put
    my-overlay 'before-string (propertize text 'face 'header-line)))

(my-text "a first line\nand another one\nand a third one\n")

bug#1503: feature request: multiline header (and mode) lines

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

>> Can emacs be given the gift of a header-line that word wraps, so that
>> the header can be more than one line tall?  I imagine the same could
>> go for the mode line, but I don't have a clear need for that right
>> now.  I know that the fringes can occupy > 1 column, so it seems like
>> an oversight if the header and mode lines are restricted to 1 line.
>>
>> I've written a minor mode for reading/sorting physics abstracts from
>> the physics arXiv.  The mode either lists subdirectories directly
>> under the current directory, or recursively lists all subdirectories
>> of the pwd.  Either way, the list could potentially be longer than the
>> width of the screen, making some directory names unviewable.  A
>> multiline header would make it perfect.
>>
>> I thought of putting that text in the buffer, but that makes it much
>> harder to update the text.
>
> At the moment, we can't do that because the fact that a header-line
> occupies exactly one line of text is hardwired into many lower-level
> primitives.

Could those primitives be changed to support this use-case?

I'm not very interested in a multi-line mode-line myself, but I can see
many uses for a multi-line header line.

bug#1503: feature request: multiline header (and mode) lines

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 20 Oct 2021 08:53:45 -0700
> Cc: 1503@debbugs.gnu.org
> 
> >> I thought of putting that text in the buffer, but that makes it much
> >> harder to update the text.
> >
> > At the moment, we can't do that because the fact that a header-line
> > occupies exactly one line of text is hardwired into many lower-level
> > primitives.
> 
> Could those primitives be changed to support this use-case?

Of course.  It's just a lot of work, and will probably have a long
tail (because many places assume that without stating the assumption
clearly enough for you to catch it).

bug#1503: feature request: multiline header (and mode) lines

[martin rudalics]

 >>> Can emacs be given the gift of a header-line that word wraps, so that
 >>> the header can be more than one line tall?  I imagine the same could
 >>> go for the mode line, but I don't have a clear need for that right
 >>> now.  I know that the fringes can occupy > 1 column, so it seems like
 >>> an oversight if the header and mode lines are restricted to 1 line.
 >>>
 >>> I've written a minor mode for reading/sorting physics abstracts from
 >>> the physics arXiv.  The mode either lists subdirectories directly
 >>> under the current directory, or recursively lists all subdirectories
 >>> of the pwd.  Either way, the list could potentially be longer than the
 >>> width of the screen, making some directory names unviewable.  A
 >>> multiline header would make it perfect.
 >>>
 >>> I thought of putting that text in the buffer, but that makes it much
 >>> harder to update the text.
 >>
 >> At the moment, we can't do that because the fact that a header-line
 >> occupies exactly one line of text is hardwired into many lower-level
 >> primitives.
 >
 > Could those primitives be changed to support this use-case?
 >
 > I'm not very interested in a multi-line mode-line myself, but I can see
 > many uses for a multi-line header line.

IIUC the OP would be better served with a separate buffer for listing
these subdirectories shown above the window of his buffer.  To glue them
together, the two windows could be put into an atomic window.  Omitting
all decorations for that separate buffer, it would not be discernible
from a header line.

So if you see any use for a multi-line header line, please give me
details where a specification via 'header-line-format' would be
preferable to one that puts that stuff into a separate buffer.

martin

bug#1503: feature request: multiline header (and mode) lines

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

> IIUC the OP would be better served with a separate buffer for listing
> these subdirectories shown above the window of his buffer.  To glue them
> together, the two windows could be put into an atomic window.  Omitting
> all decorations for that separate buffer, it would not be discernible
> from a header line.
>
> So if you see any use for a multi-line header line, please give me
> details where a specification via 'header-line-format' would be
> preferable to one that puts that stuff into a separate buffer.

One benefit of the header line is that it always stays in place, whereas
with a buffer you never know where it might end up.  Or is there a way
to force a buffer in place with the same strong guarantee?

We also might not want users to switch to that buffer, as it would be
more annoying than useful (e.g. headers in tabulated-list-mode).  AFAIU,
with a regular buffer you will always be able to switch to them with
`other-window'.

I was also going to say that with header-line-format you get horizontal
scrolling automatically, but it turns out that you don't.  In any case,
it seems like this feature shouldn't be too hard to add.  (I remember
now that I added code to fix that in one of my packages.)

bug#1503: feature request: multiline header (and mode) lines

[martin rudalics]

 > One benefit of the header line is that it always stays in place, whereas
 > with a buffer you never know where it might end up.  Or is there a way
 > to force a buffer in place with the same strong guarantee?

Why not?  Have you ever seen windows deliberately change places on a
frame?  Atomic windows are glued together like a window and its mode
lines.

 > We also might not want users to switch to that buffer, as it would be
 > more annoying than useful (e.g. headers in tabulated-list-mode).  AFAIU,
 > with a regular buffer you will always be able to switch to them with
 > `other-window'.

That's what the 'no-other-window' parameter is for.  With the slight
difference that with a window you can turn it off temporarily.

 > I was also going to say that with header-line-format you get horizontal
 > scrolling automatically, but it turns out that you don't.  In any case,
 > it seems like this feature shouldn't be too hard to add.  (I remember
 > now that I added code to fix that in one of my packages.)

XEmacs has it, IIRC.

martin