Thanks for the feedback. A new patch is attached.

> From: 	Eli Zaretskii
> Date: 	Sun, 02 Apr 2023 08:47:40 +0300

> What would be the situations where the user could want this alignment?

It's merely an aesthetic thing -- I just like having some of my
information right-aligned. I think the motivation for the tab bar
right-align function is similar?

> One possible issue with right alignment is that when the total size of
> the mode-line text changes (e.g., the mode lighter changes), the
> leftmost part of it will move horizontally, something that could be
> unpleasant and even annoying.

This doesn't happen with my proposed setup (though I agree it would be
annoying if it did!). The user includes the symbol
`mode-line-format-right-align' in their mode line format. This is a
variable which holds a mode-line construct `(:eval
(mode-line-format-right-align))'. So whenever the mode-line is reloaded
(and therefore, whenever the length could change), the space used to pad
the right-aligned part to the right is recalculated. The only situation
where this could go wrong would be if the length of the left part of the
mode-line changed /during/ the process of reloading the mode-line, which
seems unlikely to happen.

> Also, what happens if the mode-line text is longer than the window
> width.  What are user expectations in that case, and does :align-to
> meet those expectations?

Then the text overflows to the right. The behaviour with my patch is the
same as without: the text furthest to the right is not visible. The way
the patch is written would mean that the padding used to align text to
the right would be nil (i.e. a zero-width) string, but this is not
really relevant because it won't be visible (because it will be off the
right-hand edge of the screen).

> > The functin aligns to the right /fringe/ rather than the margin because
> > some modes (e.g. [visual-fill-column-mode]) mess around the margin size,
> > but the right-align should be unaffected by this.
> This detail should not be hard-coded, IMO.

On reflection, I think you're right.

> It should be up to the calling Lisp program (or maybe even user
> option) whether the alignment is to the right margin or to the window
> edge.

I found this easier to implement as a user option -- I've added
`mode-line-right-align-edge' to the patch.

> Also, did you test this when the fringe is inside the margins and the
> margins have non-zero width?

Yes. It does exactly what you expect (i.e. if
`mode-line-right-align-edge' is set to `right-fringe' then align
to the fringe, it set to `right-margin' etc.). Setting
`mode-line-right-align-edge' to `window' aligns to the right of
the window even in these circumstances.

> The call to string-pixel-width will significantly slow down redisplay
> of the mode line.

Yes, unfortunately.

> I wonder whether this feature should be implemented in C instead, to
> avoid the slowdown.

This would be great, but I definitely don't have the skills to do it.
Unless someone else does this, perhaps we could include my lisp
implementation for now, document the slowness (in the docstring),
and put a C implementation on the wishlist/TODO?

> This should use display-graphic-p, not window-system.

Fixed.

> Did you test this in a session which has both GUI and TTY frames?

Yes, it behaves correctly (i.e. right-aligns in both, even when the
same buffer is simultaneously displayed in both).

> From: 	Juri Linkov
> Date: 	Sun, 02 Apr 2023 19:19:01 +0300

> Here `format-mode-line' returns an empty string when
> `mode-line-format-right-align' was added in the middle of
> `mode-line-format'. For a strange reason, it expects that
> `mode-line-format' should start with a string. So everything is fine
> after replacing in your patch

Thanks for pointing this out. I've fixed it in the new patch (though my
fix uses a back-quote construction, but the effect is the same).

Hope the new version is better. Thoughts?