help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using :align-to with non-spaces


From: Alex
Subject: Re: Using :align-to with non-spaces
Date: Tue, 10 Oct 2017 13:18:24 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden
>> Date: Tue, 10 Oct 2017 12:09:53 -0600
>>
>> It does to me as well, but it would be nice to have similar
>> functionality to :align-to in arbitrary strings.
>> 
>> Something like the following, that would align the string similar to
>> :align-to does a space:
>> 
>> (propertize "test"
>>             'display
>>             '(align-to EXPR))
>> 
>> where EXPR can be the same as in :align-to.
>
> :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. I believe it makes the code a bit neater when using other
text properties on the string.

>> I don't understand. The Info mode header isn't aligned at all (for
>> example, toggling fringe and linum-mode (for the margin) doesn't change
>> the position of the info header). Only headers with an `:align-to num'
>> property would be affected.
>
> Ah, you want :align-to take the line numbers into consideration!
>
> 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).

>> Here is what the manual says about :align-to:
>> 
>>    For example, ‘:align-to 0’ in a header-line aligns with the first
>>    text column in the text area.
>> 
>> I would consider "the first text column" to be column 0, so the current
>> behaviour is incorrect.
>
> 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. Essentially, I believe a user should ideally be able to
liken the display-line-numbers area to a "non-customizable second
margin", if that makes sense.

>> If line-number display is treated specially
>
> It isn't: it is treated the same as line-prefix and wrap-prefix.

Okay, then there should be a `prefix' element that includes all of
these.

>> then there should also be a `line-number' element for the :align-to
>> and :width specs.
>
> 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)?

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]