[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using :align-to with non-spaces
From: |
Eli Zaretskii |
Subject: |
Re: Using :align-to with non-spaces |
Date: |
Tue, 10 Oct 2017 23:01:55 +0300 |
> From: Alex <agrambot@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 10 Oct 2017 13:18:24 -0600
>
> > :align-to doesn't align the space, it produces a stretch of white
> > space that _ends_ at the place which :align-to defines. That's why it
> > makes sense to put this property on a SPC character: it makes that SPC
> > character's width on display be as you need it.
>
> Right, I misspoke. What would be nice is to have the above 'align-to
> display property prepend a stretch space that ends at an :align-to
> expression.
Then the stretch would have no buffer/string position on it, and the
code which processes glyphs would become more complex. IMO, the gain
is too small to justify the complexity.
> I believe it makes the code a bit neater when using other text
> properties on the string.
If it does, then only slightly so, IMO. Prepending a space is not a
big deal.
> > It doesn't because neither does that happen with line-prefix or
> > wrap-prefix. IOW, :align-to measures from the edges of the window's
> > text area.
>
> I would consider it not recognizing {line,wrap}-prefix to be a bug as
> well (either in behaviour or documentation).
Everything in the text area counts: images, stretches, line numbers,
etc. This was always so, since Emacs 21.
> > The "text area" is everything inside the fringes/display margins
> > (whichever comes last), so it includes the space used for the
> > line-number display.
>
> >From a user perspective, I don't think the prefix/line-numbers should be
> considered as part of the text area. At the very least, not the
> line-numbers.
That's your linum-mode experience talking ;-) It takes time to get
used to a different view of this.
> > The solution I can suggest is to use the value returned by
> > line-number-display-width.
>
> Right, but shouldn't it be recomputed at the same times that the other
> element's widths are (i.e., toggling display-line-numbers should
> automatically change the display width of relevant :align-to/:width
> spaces)?
We discussed that briefly on emacs-devel, and decided not to, mainly
due to the line/wrap-prefix precedent. I still don't see any reason
to revise that decision, the few problems that are caused for that
were solved relatively easily.
> So even if `left' doesn't mean column 0 (I find this poor behaviour,
> though), then one can use `(:align-to (+ left prefix)' or something of
> the sort to always mean column 0, even if there are
> prefixes/line-numbers displayed.
I think you underestimate the number of different "things" that could
precede the leftmost text character. We have so many display features
that can put stuff to the left of the leftmost character that we will
have hard time deciding what should and shouldn't be considered
'prefix'. It is easier to write a function that computes their
summary width, if that's what you need.
More generally, doing layout in Lisp (which is what I think you are
trying) isn't easy, and was never supposed to be. It is better to
extend the display engine to do layout for you, if that makes sense.
- Using :align-to with non-spaces, Alex, 2017/10/09
- Re: Using :align-to with non-spaces, Eli Zaretskii, 2017/10/10
- Re: Using :align-to with non-spaces, Alex, 2017/10/10
- Re: Using :align-to with non-spaces, Eli Zaretskii, 2017/10/10
- Re: Using :align-to with non-spaces, Alex, 2017/10/10
- Re: Using :align-to with non-spaces,
Eli Zaretskii <=
- Re: Using :align-to with non-spaces, Alex, 2017/10/10
- Re: Using :align-to with non-spaces, Eli Zaretskii, 2017/10/11
- Re: Using :align-to with non-spaces, Stefan Monnier, 2017/10/11
- Re: Using :align-to with non-spaces, Eli Zaretskii, 2017/10/12