bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#48257: [kisara.moe] Re: [kisara.moe] Re: bug#48257: [kisara.moe] 28.


From: Eli Zaretskii
Subject: bug#48257: [kisara.moe] Re: [kisara.moe] Re: bug#48257: [kisara.moe] 28.0.50; Align to right doesn't account for window separator in terminal frames
Date: Tue, 11 May 2021 20:19:49 +0300

[Please use Reply All to keep the bug address on the CC list.]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Date: Tue, 11 May 2021 18:10:03 +0100
> 
> So what would be the recommended approach for mode-line developers
> detect that their not on a rightmost window and then add the extra space
> to prevent the mode-line being truncated?

We have the window-at-side-p function; is that what you want?

> Personally I still think this is a bug because the mode-line doesn't
> control whether the window-separator glyph is shown or not.

It is controlled by the current display-table.

> If the
> mode-line intends to right-align some text it should be right-aligned
> without having to consider corner-cases such as the window position.
> Especially seeing as this isn't an issue on GUI frames, only terminal
> frames. I'd suggest adding a right-separator alongside right-fringe and
> right-margin so that mode-line developers don't have to concern
> themselves with this.
> 
> Alternatively it'd be nice if emacs just took care of spacing and
> alignment itself. With so many mode-lines re-implementing the same
> general logic to right align a segment, a built-in construct might be
> more general and avoid the issue of alignment here. It'll also avoid the
> need to evaluate the right-segment twice (first to get it's width and
> then to actually render it).
> 
> For example vim has a status-line construct (I believe %=) which is
> replaced with the appropriate number of spaces to separate two or more
> groups.
> For example with a window width of 12 and a status-line format of
> "foo%=bar", we'd get a rendered status-line of "foo      bar".
> Similarly with a format of "foo%=bar%=baz" we'd get "foo bar baz".

If someone wants to work on providing patches to support any of your
suggestions, I'm sure it will be welcome, at least as an optional
feature.  TIA.





reply via email to

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