Re: Using :align-to with non-spaces

[Alex <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Sure, it's not worth it if the solution is complex.

>> 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.

Hmm, then I think that "(elisp) Pixel Specification" should include more
elements to account for these.

>> > 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.

I suppose so.

Still, I think that if it's not considered as part of the "text area",
then there should be some notion of `text area modulo
prefix/line-numbers' that :align-to/:width (and other parts of display,
perhaps) could use.

Then, I believe the default offset in "(elisp) Pixel Specification"
should be changed to the start of this construct (i.e., column 0). I
believe it would be a more user-friendly default.

>> > 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.

What do you mean by "that"? I don't recall a discussion on this; the
closest I could find was:
https://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00525.html

I think we misunderstand each other here (see below).

>> 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.

Wouldn't anything between the left fringe and column 0 be considered
"prefix"?

Any "thing" that is in this area and applies to all lines should be
accounted for in "(elisp) Pixel Specification", IMO.

> 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.

There appears to be some miscommunication here; I thought I was arguing
to extend the display engine (i.e., adding new values for `space'
display specifications).