--- Begin Message ---
|
Subject: |
25.1; bugs about display specfications |
|
Date: |
Tue, 21 Feb 2017 13:17:58 +0900 |
I found 4 bugs about display specifications.
------------------------------------------------------------
(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))))
------------------------------------------------------------
(2) height display specification may not be applied to STRING specification.
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))))
------------------------------------------------------------
(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))))
------------------------------------------------------------
(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))))
In GNU Emacs 25.1.1 (i686-w64-mingw32)
of 2016-09-18 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
'configure --host=i686-w64-mingw32 --without-dbus
--without-compress-install CFLAGS=-static'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: JPN
locale-coding-system: cp932
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils
misearch multi-isearch rect help-mode easymenu cl-loaddefs pcase cl-lib
debug time-date mule-util japan-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)
Memory information:
((conses 8 97029 6894)
(symbols 32 19796 0)
(miscs 32 83 406)
(strings 16 16516 4085)
(string-bytes 1 445422)
(vectors 8 13376)
(vector-slots 4 521906 4206)
(floats 8 167 397)
(intervals 28 919 15)
(buffers 520 20))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#25824: 25.1; bugs about display specfications |
|
Date: |
Sat, 04 Mar 2017 18:00:13 +0200 |
> Date: Fri, 24 Feb 2017 10:23:13 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
>
> > From: address@hidden
> > Cc: address@hidden
> > Date: Fri, 24 Feb 2017 15:01:19 +0900
> >
> > Eli Zaretskii <address@hidden> writes:
> > > Only if the replacement comes from a before- or after-string (in which
> > > case the text won't be replaced, so you will have to hide it with some
> > > invisible property). Put the 'raise' display property on the overlay
> > > string, and you will have what you want.
> >
> > Overlays are not editable with kill and yank,
> > so text properties are better.
>
> Then I'm afraid you are out of luck, because Emacs doesn't support
> recursive 'display' properties, i.e. a 'display' property that is a
> string which has another 'display' property for (a part of) that
> string.
>
> > > What the display engine does is reserve space above
> > > the baseline that is large enough for the enlarged font, and then draw
> > > the "X" with a negative offset relative to the baseline, by enlarging
> > > the 'descent' value of that particular glyph, which adds vertical
> > > space _below_ the line.
> >
> > I wonder why the display engine does not take 'rase' into account
> > when reserving space above the baseline.
>
> AFAIU, it's just a side effect of the implementation: 'raise' is
> implemented as modifications of the ascent or descent, so it behaves
> like these attributes of any glyph would.
>
> > > Does the below do what you want? If not, perhaps I don't understand
> > > what you mean by "centered".
> > >
> > > (insert "A" (propertize "X" 'display '((raise -0.2) (height 2))))
> >
> > It is enough for only one line.
> > With blank areas, emacs can display fewer lines.
>
> Yes, there are limitations of what can be done in Emacs as far as text
> layout is concerned.
I've now clarified the relations between 'raise' and 'height' in the
ELisp manual, and I'm closing this bug.
Thanks.
--- End Message ---