From: Eli Zaretskii <eliz@gnu.org>
To: hugo@heagren.com
Cc: 62606@debbugs.gnu.org
Subject: bug#62606: [PATCH] function to align mode-line elements to right
Date: Fri, 09 Jun 2023 16:13:06 +0300 [thread overview]
Message-ID: <83ilbw22zh.fsf@gnu.org> (raw)
In-Reply-To: <c96392b62dfb1d3311ee64401e027d89@heagren.com> (hugo@heagren.com)
> Date: Fri, 09 Jun 2023 13:47:55 +0100
> From: hugo@heagren.com
> Cc: 62606@debbugs.gnu.org
>
> On 2023-06-06 12:24, Eli Zaretskii wrote:
> >> I modelled my function on
> >> `tab-bar-format-align-right', which works in a very similar way.
> >
> > IMNSHO, that mopdel is not the ideal one.
>
> I'm not sure what you mean? If you're talking about what the function
> /does/, isn't this just a matter of preference? You might not like using
> it, but I /do/ like it. I wanted a function which does exactly what that
> function does, but for the modeline. I find the way it displays
> information perfectly natural. Clearly enough other people also do that
> the tab-bar equivalent was worth building and using. If you're talking
> about the internals, could you explain a bit more?
Put mildly, the implementation is IMO very complicated, and hard to
follow and maintain/develop.
> > Yes. But with left alignment the beginning of the text never moves,
> > only the end. With right alignment, the beginning moves. It's
> > jarring, IMO.
>
> Right, I see. But that's only true of the text as a whole isn't it?
> Consider a modeline with two constructs, FOO and BAR: '(FOO " " BAR).
> Both are left aligned. Say FOO prints "foo" and BAR prints "bar", so we
> have:
>
> foo bar
>
> If FOO now prints something longer (e.g. "foooooooo", the beginning of
> the
> BAR part will move, thus:
>
> foo bar
> ----->
> foooooooo bar
>
> So with left aligned text, sometimes the beginning (of some piece of
> information) moves as well). This happens for real if FOO is something
> like the buffer name -- BAR will move whenever we switch to a buffer
> with a name of a different length. I think if people who want
> left-aligned text can put up with this, then people who want
> right-aligned text will probably put up with the equivalent problem.
Yes, but with the current mode-line structure, we take care to prevent
that by leaving enough padding for the extra text to have space,
before it starts shifting what's after it. With right-alignment,
that's harder to accomplish.
> In fact, it was precisely /because/ of this kind of situation, that I
> originally wanted to right-align some of my information, so that it
> /wouldn't/ move when elements to the left of it changed length. By
> right-aligning, I can completely control the space between them.
You can accomplish that by padding, even without right-alignment, I
think.
> Overall, I can see that this isn't a feature you like, and probably not
> one you would use either, but it's similar enough (in function and in
> problems) to other stuff already in Emacs
Sadly.
next prev parent reply other threads:[~2023-06-09 13:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-01 22:27 bug#62606: [PATCH] function to align mode-line elements to right hugo
2023-04-02 5:47 ` Eli Zaretskii
2023-05-06 14:14 ` hugo
2023-05-06 14:39 ` Eli Zaretskii
2023-06-05 20:45 ` hugo
2023-06-06 11:24 ` Eli Zaretskii
2023-06-09 12:47 ` hugo
2023-06-09 13:13 ` Eli Zaretskii [this message]
[not found] ` <f60acc21a937b413f6528264f233ebfe@heagren.com>
2023-06-09 14:52 ` Eli Zaretskii
2023-04-02 16:19 ` Juri Linkov
2023-06-09 16:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09 16:17 ` Eli Zaretskii
2023-06-09 16:52 ` bug#62606: R2L modelines (was: bug#62606: [PATCH] function to align mode-line elements to right) Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-19 19:06 ` bug#62606: [PATCH] function to align mode-line elements to right hugo
2023-06-24 12:05 ` Eli Zaretskii
2023-06-26 10:06 ` hugo
2023-06-26 11:55 ` Eli Zaretskii
2023-07-02 12:43 ` hugo
2023-07-06 7:35 ` Eli Zaretskii
[not found] ` <handler.62606.D62606.168862894016990.notifdone@debbugs.gnu.org>
2023-07-14 16:37 ` Juri Linkov
2023-07-17 17:56 ` Juri Linkov
[not found] ` <CALDnm53v4O9cYcYwcqGpYVb4xVOw6t+FM1xX21k7HFxWyuiSaQ@mail.gmail.com>
[not found] ` <83fryrs1l8.fsf@gnu.org>
[not found] ` <87edebjcku.fsf@gmail.com>
[not found] ` <835xznro5i.fsf@gnu.org>
2024-01-21 10:20 ` João Távora
2024-01-21 10:27 ` Eli Zaretskii
2024-01-21 10:39 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ilbw22zh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62606@debbugs.gnu.org \
--cc=hugo@heagren.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).