all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alex <agrambot@gmail.com>
Cc: 28771@debbugs.gnu.org
Subject: bug#28771: 26.0.60; A couple space display property feature requests
Date: Wed, 11 Oct 2017 15:59:54 +0300	[thread overview]
Message-ID: <83r2u9on5h.fsf@gnu.org> (raw)
In-Reply-To: <87bmled788.fsf@gmail.com> (message from Alex on Tue, 10 Oct 2017 15:27:03 -0600)

> From: Alex <agrambot@gmail.com>
> Cc: 28771@debbugs.gnu.org
> Date: Tue, 10 Oct 2017 15:27:03 -0600
> 
> 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".

Actually, my understanding is that 'left' is the number of pixels from
the left edge of the window to the start of "Test".  IOW, it's a pixel
width, not a position.  Right?

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

Actually, by "space" you mean space displayed with 'highlight' face,
right?  Because there's a lot of "other" space in the header-line, but
you don't mean that space.  That's what tripped me originally.

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

So what is the purpose of having the header-line or mode-line text
move relative to buffer text when some window decorations are
enabled/disabled or moved from left to right?  IOW, why did you need
the "space" on both sides of "Test" to be of the same pixel width,
independently of the scroll-bar position?  Right now, "Test" moves
together with buffer text, and so is always aligned with it, no matter
which side is the scroll bar on.  Why is that not TRT?

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

Again, why do you need that?  Also, why cannot you use the existing
functions that return dimensions of the window and its decorations?

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

It fits with the code, but not with the conceptual framework.  The
:align-to spec starts counting pixels at the left edge of the text
area, whereas with the new symbols you introduce it will start at a
different point.  That's confusing.

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

The only way to generate a stretch of whitespace is to use a 'space'
display spec.  So no, we don't have that.  The display engine cannot
display a glyph of a character with prepended or appended space,
because we ask the font back-end to produce the glyph metrics for us,
and those metrics come from the font.  That is why we must produce
stretch glyphs separately.





  reply	other threads:[~2017-10-11 12:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-10  0:20 bug#28771: 26.0.60; A couple space display property feature requests Alex
2017-10-10  2:02 ` Alex
2017-10-10  6:47 ` Eli Zaretskii
2017-10-10 17:54   ` Alex
2017-10-10 19:12     ` Eli Zaretskii
2017-10-10 21:27       ` Alex
2017-10-11 12:59         ` Eli Zaretskii [this message]
2017-10-11 15:37           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r2u9on5h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=28771@debbugs.gnu.org \
    --cc=agrambot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.