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

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

bug#20628: 25.0.50; Incorrect line height for some fonts


From: Eli Zaretskii
Subject: bug#20628: 25.0.50; Incorrect line height for some fonts
Date: Sat, 30 May 2015 17:20:14 +0300

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: Clément Pit--Claudel <clement.pitclaudel@live.com>,
>   20628@debbugs.gnu.org
> Date: Sat, 30 May 2015 15:00:52 +0200
> 
> I still see the problem with the current branch head. Here are my settings:
> 
> (font-lock-add-keywords
>  'emacs-lisp-mode
>  `((,"\\\\\\\\|"
>     (0 font-lock-keyword-face t)
>     (0
>      (prog1
>          (compose-region
>           (match-beginning 0)
>           (match-end 0)
>           ,"∨")
>        nil)))))

Sorry, I don't understand: what do you do _after_ evaluating the
above, to show the problem?

IOW, I'm guessing that your recipe is this:

  emacs -Q
  M-: (set-frame-font "Latin Modern Math") RET
  "M-:" to eval the above form to set up font-lock-keyword
  and then ...?

If the above is correct, then what is the last part required to
produce some problematic display?

> the echo area became x7 height instead.

This is expected, if you use set-frame-font: Emacs reserves for each
window the space in pixels that is derived from the frame font's size.
This happens very early in redisplay cycle, where Emacs cannot yet
override these dimensions.  Fixing that would not be simple; I don't
see a reason for trying, as people should not have any plausible
reasons to set frame's font to one of the offending fonts discussed in
this thread.

But if you set only the font of the buffer (e.g., by clicking
S-mouse-1 in the echo area, when the minibuffer is active), then the
echo area height remains almost the same, whereas it wasn't before
these changes.





reply via email to

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