GNU bug report logs - #25824
25.1; bugs about display specfications

Previous Next

Full log

Message #25 received at 25824-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 25824-done <at> debbugs.gnu.org
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 <eliz <at> gnu.org>
> Cc: 25824 <at> debbugs.gnu.org
> 
> > From: ynyaaa <at> gmail.com
> > Cc: 25824 <at> debbugs.gnu.org
> > Date: Fri, 24 Feb 2017 15:01:19 +0900
> > 
> > Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.