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

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

bug#28771: 26.0.60; A couple space display property feature requests


From: Alex
Subject: bug#28771: 26.0.60; A couple space display property feature requests
Date: Tue, 10 Oct 2017 15:27:03 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: 28771@debbugs.gnu.org
>> Date: Tue, 10 Oct 2017 11:54:41 -0600
>> 
>> 1. There is currently no robust way to specify a pixel width to the
>>    center or left/right edge of the text area in the 'space' display spec.
>
> There's some kind of miscommunication here.  For starters, what do you
> mean by "text area"?  For me, "text area" is the area of the window
> inside the fringes, see the definition in "(elisp)Frame Layout".  But
> you must mean something else, because with my interpretation,
> specifying pixel width of the text area makes no sense: it is
> determined by the window dimensions.

I'm using whatever "(elisp) Pixel Specification" uses. In this case, I
believe it's the start of either column 0 or the line-prefix (see the
gnu-emacs-help thread on that point).

To get an idea evaluate:
(setq header-line-format
      (concat (propertize " "
                          'display
                          '(space :align-to 0))
              "test"))

The start of "test" is what I mean by the "left" of the "text-area".
The point here is that :align-to has access to some pixel positions
using `left', `center', and `right'; the diff above allows :width to
return a stretch space as wide as that position.

>>    This is because there's no way to tell what's before the left edge of
>>    the text area. If there's a left-side scroll-bar, then its width
>>    should be included; but if it's on the right, its width shouldn't be.
>
> This is only true for a header-line and mode-line, right?  Because the
> rest of the window lines don't change their alignment when the scroll
> bar switches sides, as their pixel count starts where the left fringe
> ends, whether or not there's a scroll bar to the left of the fringe.

I believe so. I haven't really played around with these specs outside of
the header-line.

>>    As for an example, try this in a graphical emacs -Q:
>> 
>> (setq header-line-format
>>       (propertize
>>        (concat (propertize " "
>>                            'display
>>                            '(space :align-to 0))
>>                "Test"
>>                (propertize " "
>>                            'display
>>                            '(space :width (+ left-fringe left-margin))))
>>        'face 'highlight))
>> 
>>   
>>    By default, the spaces before and after test are equally sized.
>
> Again, there's some misunderstanding here, because this example shows
> "Text" in the header-line flushed all the way to the left, with only
> one space before "Test", to account for the left fringe (if I turn off
> fringe-mode, that space disappears).  That's not what you are
> describing, so I guess the example needs some change?

So you don't see the space after "Test"? Make sure the background of the
'highlight face is different than the 'header-line background to see the
space clearly. I mentioned `emacs -Q' since the face background should
be different there. Any face with a different background suffices.

For clarification, what you should see is 1 space before and 1 space
after "Test", each the same pixel width as the left fringe.

What should happen is that if you toggle the fringes/margins, then the
spaces shrink and grow accordingly, with the exception of faulty
scroll-bar width calculation. Using '(space :width left) does not have
this faulty calculation.

The point is that the before/after stretch whitespace must have equal
lengths at all times, regardless of fringe/margin/line-number/scroll-bar
statuses.

> And again, this is limited to header-line, right?

I believe so (and the mode-line).

>> 2. Suppose you want to align a string to the right edge of the window.
>
> What is "the right edge of the window" in this context?

The very ends of the window shown in the art in "(elisp) Window Sizes"
(i.e., past RD). Specifically, whatever is returned by
WINDOW_LEFT_PIXEL_EDGE and WINDOW_RIGHT_PIXEL_EDGE is what I'm referring
to.

>> That's my use-case at the moment.
>
> If you are talking only about header lines, maybe the solution (if we
> need one) doesn't have to be such a general one.  Are there similar
> problems with other lines in a window?

Maybe it doesn't, but since the general case is simple enough to
implement, why not do it? I think it fits in with the existing code well
enough.

I don't know of any similar problems, but I don't use these
:align-to/:width outside of the header-line.

>> Is there currently no display spec that allows for appending/prepending
>> (or would it be hard to add)?
>
> Appending/prepending what and to what kind of text/object?  Sorry,
> maybe it's too late, but I have trouble following your
> descriptions :-(

Sorry, I should have been more clear -- appending/prepending a
pixel-specified space string to an arbitrary string. Essentially a
(concat <pixel-space> string <pixel-space>).





reply via email to

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