alphapapa
Give one more space for the annotation for minibuffer right align
Currently the annotation is perfectly right aligned, but this gives unpleasant display under console, which will force a line-wrap and push the ending `*' to the next line. For example:
some-activitiy-1 1 bufs, 0 files, 2 days*
some-activitiy-2 2 bufs, 0 files, 3 days*
Will become
some-activitiy-1 1 bufs, 0 files, 2 days\
*
some-activitiy-2 2 bufs, 0 files, 3 days\
*
This commit adds one more space so that it looks better when running Emacs under console.
This change might solve the problem on terminal frames, but it will have a negative effect on GUI frames, right?
It will add one extra space for the right alignment on GUI, yes, and it will be consistent to what it looks like under CLI.
I wouldn't call it a "negative" effect as I don't consider an extra space on the right an eyesore. But it would be good to hear from @jdtsmith on what he thinks of this change.
Sounds like a potential bug in the underlying alignment code. Have you tried this in TTY with emacs -Q?
If you evaluate this in *scratch*, what do you see?
(insert "FOO: " (propertize " " 'display '(space :align-to (- right 3))) "XXX")
I get perfect right-alignment:
If you don't, try right-fringe instead of right and report.
Hi @jdtsmith,
I can reproduce this under emacs -Q with any of right or right-fringe (see screenshots at the end). Have you tried this under console?
Actually this is the intended behavior under console: for a line of width X, it will only display X-1 characters and add an extra \ as a line-wrap indicator and push the rest of the characters into the next line. So effectively, it will only show X-1 characters in one line.
Indeed I can confirm this. Not taking into account this final wrap or continuation character in the right-alignment calculation on TTY strikes me as a bug that should be submitted upstream. I don't think it's useful to impose extra padding on GUI that's needed only for TTY.
If there's no easy upstream solution, I suppose:
(if (display-graphic-p) 1 2)
could be used. But man, ugly.
If we have to add the display-graphic-p test, that's not a huge deal. But we can't be the first ones to encounter this problem, as there are many other packages that display right-aligned text in the minibuffer, like Vertico/Marginalia/etc. It would be good to check how they handle it; there are subtleties here, and something minor but important might have been overlooked (I've done that many times).
FYI I have updated the patch as suggested to keep the display in GUI unchanged.
It seems marginalia + vertico face this same problem:
(package-initialize)
(require 'marginalia)
(require 'vertico)
(vertico-mode)
(marginalia-mode)
(setq marginalia-align 'right)
then C-x C-f, leads to:
Note the truncation character $ overwriting the last char in the date field. It appears vertico turns on truncate-lines locally in the minibuffer. This smells more like a bug in emacs' specified space calculation when you have no fringe (TTY) and need to consume one column for a wrap or truncation character. I have not found an option to disable display of either.
BTW, if you disable the fringe in GUI with (set-fringe-style 0) you get the same problem with activities or vertico + marginalia:
So display-graphic-p is an insufficient test.
Copying @minad in case he has any thoughts on right-alignment via specified space in TTY emacs where a wrap/truncation character is required.
Note the truncation character $ overwriting the last char in the date field. It appears vertico turns on truncate-lines locally in the minibuffer. This smells more like a bug in emacs' specified space calculation when you have no fringe (TTY) and need to consume one column for a wrap or truncation character. I have not found an option to disable display of either.
See https://github.com/minad/vertico/pull/628#issuecomment-3229741786 for a theory.
One can overwrite the $ with a space to "disable" it, but the space will still be there. On GUI the solution is of course a fringe, even a 1px fringe suffices.
(set-display-table-slot standard-display-table 'truncation ?\s)
One can overwrite the $ with a space to "disable" it, but the space will still be there
Maybe that's the right solution. It feels like :align-to (- right ,width) should not require a truncation char if the text occupies the full width precisely. Or that it should know that it will insist on one, and insert one fewer specified spaces.
One can overwrite the $ with a space to "disable" it, but the space will still be there
Maybe that's the right solution. It feels like
:align-to (- right ,width)should not require a truncation char if the text occupies the full width precisely. Or that it should know that it will insist on one, and insert one fewer specified spaces.
I think you suggestion was to emulate the appearance by enabling "truncate-lines" and replace the truncation character with "*". It does sound promising, so I tried to put those in my init.el to see how it looks. It almost works well, except that the display engine seem to have some issue that is causing the last character to be missing, and can be dragged to more lines when scrolling (see the bottom right corner with the empty space instead of "*" in the screenshot.)
This is happening both on Konsole and iTerm2 under macOS.
The proposed patch works around this issue obviously because it's not using the last character. It's a bit ugly, yes, but seems to provide a more consistent display and fast. Meanwhile for the emulation we need to carefully restore the user setting if they prefer not to truncate-lines, could be slower due to the mode toggle gymnastics, and still being affected by the display engine limitations.
Wdyt?