From: Eli Zaretskii <eliz@gnu.org>
To: ynyaaa@gmail.com
Cc: 25824@debbugs.gnu.org
Subject: bug#25824: 25.1; bugs about display specfications
Date: Tue, 21 Feb 2017 19:37:54 +0200 [thread overview]
Message-ID: <83h93no365.fsf@gnu.org> (raw)
In-Reply-To: <87poicrxc9.fsf@gmail.com> (ynyaaa@gmail.com)
> From: ynyaaa@gmail.com
> Date: Tue, 21 Feb 2017 13:17:58 +0900
>
> I found 4 bugs about display specifications.
Thank you for your report.
I don't think these are bugs, but perhaps we should clarify the
expected behavior in the docs some more.
> (1) raise display specification may be affected by height specification.
>
> This form displays two X's on the same height.
>
> (insert "A"
> (propertize "X" 'display '((raise 1) (height 1)))
> (propertize "X" 'display '((raise 1) (height 2))))
>
> But the form below displays second X heigher than first X.
> The order in the display property is swapped.
>
> (insert "A"
> (propertize "X" 'display '((height 1) (raise 1)))
> (propertize "X" 'display '((height 2) (raise 1))))
This should be expected. The display properties in a spec that is a
list or a vector are processed one after the other, left to right
(which is really the only way that makes sense and that will produce
deterministic results). And the documentation about 'raise' says:
‘(raise FACTOR)’
[...]
FACTOR must be a number, which is interpreted as a multiple of the
height of the affected text.
So when the previous element of the display spec changes the height,
FACTOR converted to pixels will also change accordingly. (The
documentation goes on to say something that could be interpreted as
contradicting the above, but that is just plain confused/wrong, and
certainly doesn't match the implementation.)
> (2) height display specification may not be applied to STRING specification.
As expected: 'height' affects display of the text in the buffer
covered by the property, but a display string completely conceals that
text, so the result is undefined.
> This form displays a large string.
>
> (insert (propertize "X" 'display '((height 2) "TEST")))
>
> But the form below displays a normal size string.
>
> (insert (propertize "X" 'display '("TEST" (height 2))))
The latter is just a side effect of implementation details. Display
string and 'raise'/'heaight' specs don't make sense together in the
same display spec.
> (3) raise display specification is not applied to STRING specification.
>
> This form displays strings on the base line.
>
> (insert (propertize "X" 'display '((raise 1) "TEST1"))
> (propertize "X" 'display '("TEST2" (raise 1))))
Likewise.
> (4) raise display specification may display needless space.
>
> This form displays needless space over A,
> as if raise specification is not specified.
>
> (insert "A" (propertize "X" 'display '((raise -1) (height 2))))
The space is needed to accommodate the enlarged X on the same screen
line. Emacs display engine doesn't require that all the glyphs on a
line be of the same size, but it does require them to have the same
baseline (the display geometry is that of a canvas).
Thanks.
next prev parent reply other threads:[~2017-02-21 17:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 4:17 bug#25824: 25.1; bugs about display specfications ynyaaa
2017-02-21 17:37 ` Eli Zaretskii [this message]
2017-02-23 2:53 ` ynyaaa
2017-02-23 15:51 ` Eli Zaretskii
2017-02-24 6:01 ` ynyaaa
2017-02-24 8:23 ` Eli Zaretskii
2017-03-04 16:00 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83h93no365.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=25824@debbugs.gnu.org \
--cc=ynyaaa@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).