GNU bug report logs - #79707
Line height changes with point when eglot is running

Previous Next

To reply to this bug, email your comments to 79707 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Line height changes with point when eglot is running
Date: Mon, 27 Oct 2025 20:55:47 +0530

I am editing a rust file on macos. And when I turn-on eglot, the line
height changes as the point moves.

I am using Emacs 31.0.50. And to reproduced:

1. I relaunched emacs with "-Q" option.
2. Find-file and open a rust file from a project.
3. Then start "eglot".
4. Move point and you will notice that the line hight changes as you
move.

I have captured a video, if you prefer so.

Video: https://streamable.com/wwnorc

Message #8 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 27 Oct 2025 11:56:16 -0400

[Message part 1 (text/plain, inline)]

On Mon, Oct 27, 2025 at 11:27 AM Pankaj Jangid <pankaj <at> codeisgreat.org>
wrote:

> I am editing a rust file on macos. And when I turn-on eglot, the line
> height changes as the point moves.
>
> I am using Emacs 31.0.50. And to reproduced:
>
> 1. I relaunched emacs with "-Q" option.
> 2. Find-file and open a rust file from a project.
> 3. Then start "eglot".
> 4. Move point and you will notice that the line hight changes as you
> move.
>
> I have captured a video, if you prefer so.
>
> Video: https://streamable.com/wwnorc


Surely, this is more likely a face issue than a bug.  See, for example,
https://www.reddit.com/r/emacs/comments/1lbo5jy/eldoc_undesirably_shifting_my_line_height/

[Message part 2 (text/html, inline)]

Message #11 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>,
 João Távora <joaotavora <at> gmail.com>
Cc: 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 27 Oct 2025 17:58:27 +0200

> From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> Date: Mon, 27 Oct 2025 20:55:47 +0530
> 
> I am editing a rust file on macos. And when I turn-on eglot, the line
> height changes as the point moves.
> 
> I am using Emacs 31.0.50. And to reproduced:
> 
> 1. I relaunched emacs with "-Q" option.
> 2. Find-file and open a rust file from a project.
> 3. Then start "eglot".
> 4. Move point and you will notice that the line hight changes as you
> move.
> 
> I have captured a video, if you prefer so.
> 
> Video: https://streamable.com/wwnorc

It's hard to see what causes this from the video (and I cannot afford
using the recipe for reproduction), but I can guess what happens here:
something that the LSP server causes Eglot to do uses some font that
is larger than your default font, and Emacs enlarges the current line.

This is not a bug.  To fix it, figure out what font causes the problem
and customize your fontset.  Or maybe try a different default font.

I'm adding João, in the hope that he might have other guesses or
suggestions.

Message #14 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 27 Oct 2025 18:15:30 +0000

[Message part 1 (text/plain, inline)]

On Mon, Oct 27, 2025 at 3:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> It's hard to see what causes this from the video (and I cannot afford
> using the recipe for reproduction), but I can guess what happens here:
> something that the LSP server causes Eglot to do uses some font that
> is larger than your default font, and Emacs enlarges the current line.
>
> This is not a bug.  To fix it, figure out what font causes the problem
> and customize your fontset.  Or maybe try a different default font.
>
> I'm adding João, in the hope that he might have other guesses or
> suggestions.
>

My wild guess is that this is related to the symbol highlight feature,
which is normally
done with a bold font. I can't reproduce it.  Customize
eglot-highlight-symbol-face
to see if it goes away.

[Message part 2 (text/html, inline)]

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Tue, 28 Oct 2025 00:49:21 +0530

João Távora <joaotavora <at> gmail.com> writes:

> On Mon, Oct 27, 2025 at 3:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> It's hard to see what causes this from the video (and I cannot afford
>> using the recipe for reproduction), but I can guess what happens here:
>> something that the LSP server causes Eglot to do uses some font that
>> is larger than your default font, and Emacs enlarges the current line.
>>
>> This is not a bug.  To fix it, figure out what font causes the problem
>> and customize your fontset.  Or maybe try a different default font.
>>
>> I'm adding João, in the hope that he might have other guesses or
>> suggestions.
>>
>
> My wild guess is that this is related to the symbol highlight feature,
> which is normally
> done with a bold font. I can't reproduce it.  Customize
> eglot-highlight-symbol-face
> to see if it goes away.


The font is same. With or without eglot,

mac-ct:-*-Menlo-bold-normal-normal-*-13-*-*-*-m-0-iso10646-1

But I have observed something. In the following code snippet,


    pub fn new() -> Self {
        Self {
            viewing_clients: HashSet::new(),
            last_activity: Instant::now(),
            disconnected_at: None,
            current_priority: SyncPriority::Low,
        }
    }

When the point is on any of the point S-e-l-f-<SPC>, it doesn't increase
line hight. But when it reaches '{' char, the height expands. But there
is no clear pattern elsewhere in the code.

Another observation in the font details without and with eglot:

WITHOUT EGLOT =====================
             position: 908 of 16212 (6%), column: 13
            character: { (displayed as {) (codepoint 123, #o173, #x7b)
              charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x7B
               script: latin
               syntax: (}	which means: open, matches }
             category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET 7b" or "C-x 8 RET LEFT CURLY BRACKET"
          buffer code: #x7B
            file code: #x7B (encoded by coding system undecided-unix)
              display: by this font (glyph code):
    mac-ct:-*-Menlo-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x5E)

Character code properties: customize what to show
  name: LEFT CURLY BRACKET
  old-name: OPENING CURLY BRACKET
  general-category: Ps (Punctuation, Open)
  decomposition: (123) ('{')

There is an overlay here:
 From 908 to 909
  face                 show-paren-match
  priority             1000


There are text properties here:
  fontified            t

WITH EGLOT =====================

             position: 908 of 16212 (6%), column: 13
            character: { (displayed as {) (codepoint 123, #o173, #x7b)
              charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x7B
               script: latin
               syntax: (}	which means: open, matches }
             category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET 7b" or "C-x 8 RET LEFT CURLY BRACKET"
          buffer code: #x7B
            file code: #x7B (encoded by coding system undecided-unix)
              display: by this font (glyph code):
    mac-ct:-*-Menlo-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x5E)

Character code properties: customize what to show
  name: LEFT CURLY BRACKET
  old-name: OPENING CURLY BRACKET
  general-category: Ps (Punctuation, Open)
  decomposition: (123) ('{')

There are 2 overlays here:
 From 908 to 1091
  before-string        [Show]
  eglot--actions       [Show]
 From 908 to 909
  face                 show-paren-match
  priority             1000


There are text properties here:
  fontified

Example ENDS ====================

Notice that there are two overlays in case of eglot. What are they?
Could they be causing this issue?

Message #20 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Tue, 28 Oct 2025 14:53:41 +0200

> From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> Date: Tue, 28 Oct 2025 00:49:21 +0530
> 
> João Távora <joaotavora <at> gmail.com> writes:
> 
> > On Mon, Oct 27, 2025 at 3:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >> It's hard to see what causes this from the video (and I cannot afford
> >> using the recipe for reproduction), but I can guess what happens here:
> >> something that the LSP server causes Eglot to do uses some font that
> >> is larger than your default font, and Emacs enlarges the current line.
> >>
> >> This is not a bug.  To fix it, figure out what font causes the problem
> >> and customize your fontset.  Or maybe try a different default font.
> >>
> >> I'm adding João, in the hope that he might have other guesses or
> >> suggestions.
> >>
> >
> > My wild guess is that this is related to the symbol highlight feature,
> > which is normally
> > done with a bold font. I can't reproduce it.  Customize
> > eglot-highlight-symbol-face
> > to see if it goes away.
> 
> 
> The font is same. With or without eglot,
> 
> mac-ct:-*-Menlo-bold-normal-normal-*-13-*-*-*-m-0-iso10646-1
> 
> But I have observed something. In the following code snippet,
> 
> 
>     pub fn new() -> Self {
>         Self {
>             viewing_clients: HashSet::new(),
>             last_activity: Instant::now(),
>             disconnected_at: None,
>             current_priority: SyncPriority::Low,
>         }
>     }
> 
> When the point is on any of the point S-e-l-f-<SPC>, it doesn't increase
> line hight. But when it reaches '{' char, the height expands. But there
> is no clear pattern elsewhere in the code.
> 
> Another observation in the font details without and with eglot:
> 
> WITHOUT EGLOT =====================
>              position: 908 of 16212 (6%), column: 13
>             character: { (displayed as {) (codepoint 123, #o173, #x7b)
>               charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x7B
>                script: latin
>                syntax: (}	which means: open, matches }
>              category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman
>              to input: type "C-x 8 RET 7b" or "C-x 8 RET LEFT CURLY BRACKET"
>           buffer code: #x7B
>             file code: #x7B (encoded by coding system undecided-unix)
>               display: by this font (glyph code):
>     mac-ct:-*-Menlo-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x5E)
> 
> Character code properties: customize what to show
>   name: LEFT CURLY BRACKET
>   old-name: OPENING CURLY BRACKET
>   general-category: Ps (Punctuation, Open)
>   decomposition: (123) ('{')
> 
> There is an overlay here:
>  From 908 to 909
>   face                 show-paren-match
>   priority             1000
> 
> 
> There are text properties here:
>   fontified            t
> 
> WITH EGLOT =====================
> 
>              position: 908 of 16212 (6%), column: 13
>             character: { (displayed as {) (codepoint 123, #o173, #x7b)
>               charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x7B
>                script: latin
>                syntax: (}	which means: open, matches }
>              category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman
>              to input: type "C-x 8 RET 7b" or "C-x 8 RET LEFT CURLY BRACKET"
>           buffer code: #x7B
>             file code: #x7B (encoded by coding system undecided-unix)
>               display: by this font (glyph code):
>     mac-ct:-*-Menlo-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x5E)
> 
> Character code properties: customize what to show
>   name: LEFT CURLY BRACKET
>   old-name: OPENING CURLY BRACKET
>   general-category: Ps (Punctuation, Open)
>   decomposition: (123) ('{')
> 
> There are 2 overlays here:
>  From 908 to 1091
>   before-string        [Show]
>   eglot--actions       [Show]
>  From 908 to 909
>   face                 show-paren-match
>   priority             1000
> 
> 
> There are text properties here:
>   fontified
> 
> Example ENDS ====================
> 
> Notice that there are two overlays in case of eglot. What are they?
> Could they be causing this issue?

Click on the [Show] buttons to show the overlays, and then perhaps
someone will have an idea.  Otherwise, how can we tell?

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 29 Oct 2025 07:41:33 +0530

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The font is same. With or without eglot,
>> 
>> mac-ct:-*-Menlo-bold-normal-normal-*-13-*-*-*-m-0-iso10646-1
>> ...
>> Another observation in the font details without and with eglot:
>> 
>> WITHOUT EGLOT =====================
>> ...
>> There is an overlay here:
>>  From 908 to 909
>>   face                 show-paren-match
>>   priority             1000
>> 
>> 
>> There are text properties here:
>>   fontified            t
>> 
>> WITH EGLOT =====================
>> ...
>> There are 2 overlays here:
>>  From 908 to 1091
>>   before-string        [Show]
>>   eglot--actions       [Show]
>>  From 908 to 909
>>   face                 show-paren-match
>>   priority             1000
>> 
>> 
>> There are text properties here:
>>   fontified
>> 
>> Example ENDS ====================
>> 
>> Notice that there are two overlays in case of eglot. What are they?
>> Could they be causing this issue?
>
> Click on the [Show] buttons to show the overlays, and then perhaps
> someone will have an idea.  Otherwise, how can we tell?

Sorry about the missing information. Here are the outputs from the two
show buttons,

[before-string]

#("⚡" 0 1
  (display
   ((margin left-margin)
    #("💡" 0 1
      (face eglot-code-action-indicator-face help-echo
	    "mouse-1: execute code actions at point" mouse-face
	    highlight keymap
	    (keymap
	     (left-margin keymap
			  (mouse-1 . eglot-code-actions-at-mouse))
	     (mouse-2 . eglot-code-actions-at-mouse)))))))



[eglot-actions]

[(:title "Extract into variable" :kind "refactor.extract" :data
	 (:codeActionParams
	  (:textDocument
	   (:uri
	    "file:///Users/pankaj/work/sui/alphalend/alphalend-ws/src/services/position_sync/activity_tracker.rs")
	   :range
	   (:start (:line 31 :character 13) :end
		   (:line 36 :character 9))
	   :context (:diagnostics [] :triggerKind 2))
	  :id "extract_variable:RefactorExtract:0:" :version 0))]

Message #26 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>,
 João Távora <joaotavora <at> gmail.com>
Cc: 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 29 Oct 2025 14:06:10 +0200

> From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> Date: Wed, 29 Oct 2025 07:41:33 +0530
> 
> >> Notice that there are two overlays in case of eglot. What are they?
> >> Could they be causing this issue?
> >
> > Click on the [Show] buttons to show the overlays, and then perhaps
> > someone will have an idea.  Otherwise, how can we tell?
> 
> Sorry about the missing information. Here are the outputs from the two
> show buttons,
> 
> [before-string]
> 
> #("⚡" 0 1
>   (display
>    ((margin left-margin)
>     #("💡" 0 1
>       (face eglot-code-action-indicator-face help-echo
> 	    "mouse-1: execute code actions at point" mouse-face
> 	    highlight keymap
> 	    (keymap
> 	     (left-margin keymap
> 			  (mouse-1 . eglot-code-actions-at-mouse))
> 	     (mouse-2 . eglot-code-actions-at-mouse)))))))
> 
> 
> 
> [eglot-actions]
> 
> [(:title "Extract into variable" :kind "refactor.extract" :data
> 	 (:codeActionParams
> 	  (:textDocument
> 	   (:uri
> 	    "file:///Users/pankaj/work/sui/alphalend/alphalend-ws/src/services/position_sync/activity_tracker.rs")
> 	   :range
> 	   (:start (:line 31 :character 13) :end
> 		   (:line 36 :character 9))
> 	   :context (:diagnostics [] :triggerKind 2))
> 	  :id "extract_variable:RefactorExtract:0:" :version 0))]

Thanks.  I'm guessing that the character 💡 (U+1F4A1 ELECTRIC LIGHT
BULB) is displayed using some font that is higher than the default
font.  Which probably is the reason for what you see.  Configuring
Emacs to use some other font for that will probably solve the issue.

Message #29 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 29 Oct 2025 13:08:25 +0000

[Message part 1 (text/plain, inline)]

On Wed, Oct 29, 2025, 12:06 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> > Date: Wed, 29 Oct 2025 07:41:33 +0530
> >
> > >> Notice that there are two overlays in case of eglot. What are they?
> > >> Could they be causing this issue?
> > >
> > > Click on the [Show] buttons to show the overlays, and then perhaps
> > > someone will have an idea.  Otherwise, how can we tell?
> >
> > Sorry about the missing information. Here are the outputs from the two
> > show buttons,
> >
> > [before-string]
> >
> > #("⚡" 0 1
> >   (display
> >    ((margin left-margin)
> >     #("💡" 0 1
> >       (face eglot-code-action-indicator-face help-echo
> >           "mouse-1: execute code actions at point" mouse-face
> >           highlight keymap
> >           (keymap
> >            (left-margin keymap
> >                         (mouse-1 . eglot-code-actions-at-mouse))
> >            (mouse-2 . eglot-code-actions-at-mouse)))))))
> >
> >
> >
> > [eglot-actions]
> >
> > [(:title "Extract into variable" :kind "refactor.extract" :data
> >        (:codeActionParams
> >         (:textDocument
> >          (:uri
> >
>  "file:///Users/pankaj/work/sui/alphalend/alphalend-ws/src/services/position_sync/
> activity_tracker.rs")
> >          :range
> >          (:start (:line 31 :character 13) :end
> >                  (:line 36 :character 9))
> >          :context (:diagnostics [] :triggerKind 2))
> >         :id "extract_variable:RefactorExtract:0:" :version 0))]
>
> Thanks.  I'm guessing that the character 💡 (U+1F4A1 ELECTRIC LIGHT
> BULB) is displayed using some font that is higher than the default
> font.  Which probably is the reason for what you see.  Configuring
> Emacs to use some other font for that will probably solve the issue.
>

But in the video I saw, there were no margins, but rather fringes, and this
light bulb wasn't displayed. The line still jumped.

Could an undisplayed glyph still be affecting the height? Or was this data
collected from some other case? Could this be a consequence of the changes
in the bug#77313?


João Távora

[Message part 2 (text/html, inline)]

Message #32 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 29 Oct 2025 18:19:05 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Date: Wed, 29 Oct 2025 13:08:25 +0000
> Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 79707 <at> debbugs.gnu.org
> 
>  Thanks.  I'm guessing that the character 💡 (U+1F4A1 ELECTRIC LIGHT
>  BULB) is displayed using some font that is higher than the default
>  font.  Which probably is the reason for what you see.  Configuring
>  Emacs to use some other font for that will probably solve the issue.
> 
> But in the video I saw, there were no margins, but rather fringes, and this light bulb wasn't displayed. The
> line still jumped.

I'm unsure how well the video reflects what happened in reality, due
to limited FPS rate.

> Could an undisplayed glyph still be affecting the height? Or was this data collected from some other case?
> Could this be a consequence of the changes in the bug#77313?

A glyph that is not displayed cannot cause such effects.  But a glyph
that was displayed and then immediately removed in the following
redisplay cycle, can.

I don't know if the fix of bug#77313 could cause it, but it should be
easy to check that, if the OP could revert the commit and try again.

Message #35 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>, 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Fri, 31 Oct 2025 11:44:57 +0100

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> And when I turn-on eglot, the line height changes as the point moves.

Emojis make lines taller in Emacs running on MacOS.  I have yet to see
any other MacOS application which uses fixed-pitch font that also has
this problem.  Emojis work well elsewhere, from the built-in Terminal to
all third-party software I have ever used on MacOS.  So, I consider this
is a bug in Emacs, which is why I reported it back in 2021 [1].  The bug
causes all sorts of problems in practice, from shifting text when Eglot
is active to misaligned messages in Telega.  The Eglot issue can be
worked around by customizing `eglot-code-action-indicator'.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52542

-- 
"For every problem you can't solve, there's a simpler problem that you
also can't solve."

--- Hendrik Lenstra

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #38 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Fri, 31 Oct 2025 13:43:13 +0200

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Date: Fri, 31 Oct 2025 11:44:57 +0100
> 
> Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
> 
> > And when I turn-on eglot, the line height changes as the point moves.
> 
> Emojis make lines taller in Emacs running on MacOS.  I have yet to see
> any other MacOS application which uses fixed-pitch font that also has
> this problem.  Emojis work well elsewhere, from the built-in Terminal to
> all third-party software I have ever used on MacOS.  So, I consider this
> is a bug in Emacs, which is why I reported it back in 2021 [1].  The bug
> causes all sorts of problems in practice, from shifting text when Eglot
> is active to misaligned messages in Telega.  The Eglot issue can be
> worked around by customizing `eglot-code-action-indicator'.

If the font used to show Emoji is taller than the default font, then
what you report is expected, and not a bug.

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Fri, 31 Oct 2025 22:01:04 +0530

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
>> Date: Fri, 31 Oct 2025 11:44:57 +0100
>> 
>> Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
>> 
>> > And when I turn-on eglot, the line height changes as the point moves.
>> 
>> Emojis make lines taller in Emacs running on MacOS.  I have yet to see
>> any other MacOS application which uses fixed-pitch font that also has
>> this problem.
>
> If the font used to show Emoji is taller than the default font, then
> what you report is expected, and not a bug.

Regardless of the default font configuration, emojis are always
displayed using the Apple Color Emoji-Regular font on macOS:

 mac-ct:-*-Apple Color Emoji-regular-normal-normal-*-13-*-*-*-p-0-iso10646-1 (#x6F4)

That might be the issue. How does Emacs on macOS choose which font to
use for emoji characters?

I tested this in the *scratch* buffer as well. If I paste 💡 in a line,
it increases the line height.

Message #44 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Fri, 31 Oct 2025 19:08:58 +0200

> From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> Date: Fri, 31 Oct 2025 22:01:04 +0530
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> >> Date: Fri, 31 Oct 2025 11:44:57 +0100
> >> 
> >> Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
> >> 
> >> > And when I turn-on eglot, the line height changes as the point moves.
> >> 
> >> Emojis make lines taller in Emacs running on MacOS.  I have yet to see
> >> any other MacOS application which uses fixed-pitch font that also has
> >> this problem.
> >
> > If the font used to show Emoji is taller than the default font, then
> > what you report is expected, and not a bug.
> 
> Regardless of the default font configuration, emojis are always
> displayed using the Apple Color Emoji-Regular font on macOS:
> 
>  mac-ct:-*-Apple Color Emoji-regular-normal-normal-*-13-*-*-*-p-0-iso10646-1 (#x6F4)
> 
> That might be the issue. How does Emacs on macOS choose which font to
> use for emoji characters?

I don't know, sorry.  Maybe some macOS expert does.

Message #47 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, Pankaj Jangid <pankaj <at> codeisgreat.org>
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Sun, 02 Nov 2025 19:08:39 +0100

Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:

> Emojis make lines taller in Emacs running on MacOS.

FWIW, this is what I have in my init file to reduce the effect you
describe:

  (add-to-list 'face-font-rescale-alist
               '("Apple Color Emoji" . 0.95)
               t)

Best, Arash

Message #50 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 10:19:33 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> If the font used to show Emoji is taller than the default font, then
> what you report is expected, and not a bug.

From the point of view of a CoreText programmer?  Sure, everything works
as expected.  From the point of the user?  This is a bug.  The user has
no idea we are using low-level APIs that do not adjust font metrics for
Emojis.  Then, I am tired of arguing over this philosophical point over
and over, especially on Emacs and Org mailing lists, so we can it a new
feature, say "Non-jumpy with Emojis".

But, enough of philosophy!  I rolled up my sleeves to implement the new
feature.  My first attempt was to adjust the ascent and descent, as we
do for Courier, Helvetica, and Times.  That worked, but Emojis were too
big, almost touching the surrounding text, which was unpleasant to look
at.  Knuth would not approve. :) So, I got a different idea, namely to
scale Emojis down.  I tried a factor of 0.8, and the layout was still a
bit jumpy.  Then, I tried 0.75, and Emacs calmed down.

With the attached patch I observe no shifting of text, and Emojis in
Emacs work and look like in any other Mac application.

Please review!

Rudy

[0001-MacOS-Scale-down-system-Emoji-font-to-mitigate-layou.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
"I do not fear death.  I had been dead for billions and billions of
years before I was born, and had not suffered the slightest
inconvenience from it."

--- Mark Twain, paraphrased

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #53 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 10:54:24 +0100

[Message part 1 (text/plain, inline)]

Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:

> With the attached patch I observe no shifting of text, and Emojis in
> Emacs work and look like in any other Mac application.

Apologies for the noise, but please see the updated version of the patch
attached to this message.  It fixes memory leaks, formatting, and the
font is not created twice anymore.

Rudy

[0001-MacOS-Scale-down-system-Emoji-font-to-mitigate-layou.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."

--- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #56 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 16:14:58 +0530

[Message part 1 (text/plain, inline)]

Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:

> Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:
>
>> With the attached patch I observe no shifting of text, and Emojis in
>> Emacs work and look like in any other Mac application.
>
> Apologies for the noise, but please see the updated version of the patch
> attached to this message.

I applied the v1 of this patch and I confirm that it solves the problem
of dancing eglot buffer.

But it reduces the height of emojis. This is not how other macOS apps
solves this problem. See attached images for example.

(1) Terminal

[1.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

(2) Terminal

[2.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

(3) Emacs

[3.png (image/png, inline)]

[Message part 7 (text/plain, inline)]

Image (1) and (2) are screenshots of Terminal app. Notice that only the
top and bottom margins are clipped for Emoji and the emoji size remains
same. In (3), Emacs with applied patch, the overall size of emoji is
scaled down.

But I am happy that the coding buffer is calm with the patch.

Message #59 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 14:47:19 +0200

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: pankaj <at> codeisgreat.org, 79707 <at> debbugs.gnu.org
> Date: Mon, 03 Nov 2025 10:19:33 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If the font used to show Emoji is taller than the default font, then
> > what you report is expected, and not a bug.
> 
> >From the point of view of a CoreText programmer?  Sure, everything works
> as expected.  From the point of the user?  This is a bug.  The user has
> no idea we are using low-level APIs that do not adjust font metrics for
> Emojis.

That's not what happens, though.  What happens is that Emacs asks the
font backend for a font that supports Emoji and whose size is the best
match for the size of the default font.  Emacs then uses what the font
backend gives it.

So the question IMO becomes: why didn't the font backend give us a
font whose size is the same as the default font?

> Then, I am tired of arguing over this philosophical point over
> and over, especially on Emacs and Org mailing lists, so we can it a new
> feature, say "Non-jumpy with Emojis".
> 
> But, enough of philosophy!  I rolled up my sleeves to implement the new
> feature.  My first attempt was to adjust the ascent and descent, as we
> do for Courier, Helvetica, and Times.  That worked, but Emojis were too
> big, almost touching the surrounding text, which was unpleasant to look
> at.  Knuth would not approve. :) So, I got a different idea, namely to
> scale Emojis down.  I tried a factor of 0.8, and the layout was still a
> bit jumpy.  Then, I tried 0.75, and Emacs calmed down.
> 
> With the attached patch I observe no shifting of text, and Emojis in
> Emacs work and look like in any other Mac application.
> 
> Please review!

We have a feature mentioned here by Arash:

> > Emojis make lines taller in Emacs running on MacOS.
> 
> FWIW, this is what I have in my init file to reduce the effect you
> describe:
> 
>   (add-to-list 'face-font-rescale-alist
>                '("Apple Color Emoji" . 0.95)
>                t)

Doesn't it allow you to fix this problem, in a more flexible way (like
being able to control the scale factor, instead of having it
hard-coded into the C sources)?

Message #62 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 20:49:42 +0100

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> But it reduces the height of emojis. This is not how other macOS apps
> solves this problem. See attached images for example.

Good point.  We could go a bit larger, I think.  For example, we could
try more values, combine the approach with ascent/descent tweaks, and
perhaps with a a scale transform when creating the font.

The precise size is slightly different, app by app.  Terminal does a
great job and is fine-tuned to pixel perfection.  Text Edit has slightly
different size than Terminal.  WebKit renders emojis a bit too larger
than I would like.  Finally, Xcode and Emacs do nothing.

Rudy
--- Blaise Pascal, The Provincial Letters, 1657

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #65 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 22:15:40 +0200

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79707 <at> debbugs.gnu.org
> Date: Mon, 03 Nov 2025 20:49:42 +0100
> 
> Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
> 
> > But it reduces the height of emojis. This is not how other macOS apps
> > solves this problem. See attached images for example.
> 
> Good point.  We could go a bit larger, I think.  For example, we could
> try more values, combine the approach with ascent/descent tweaks, and
> perhaps with a a scale transform when creating the font.
> 
> The precise size is slightly different, app by app.  Terminal does a
> great job and is fine-tuned to pixel perfection.  Text Edit has slightly
> different size than Terminal.  WebKit renders emojis a bit too larger
> than I would like.  Finally, Xcode and Emacs do nothing.

Don't forget that Emacs is not a text-mode terminal, on GUI frames it
must support fonts of different sizes in the same screen line.  So it
cannot just clip glyphs which are higher than the default font,
because that would make displays like in Info buffers either
impossible or just downright ugly or illegible.

Text-mode terminals live in a "paradise" of their own, but Emacs
cannot.

Once again, Arash suggested a solution for this that uses existing
Emacs features.  I wonder why no one pays attention to his suggestion.

Message #68 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Mon, 03 Nov 2025 23:19:06 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Once again, Arash suggested a solution for this that uses existing
> Emacs features.  I wonder why no one pays attention to his suggestion.

Good point!  Thanks, Arash.  How about the attached patch?

(I tried 0.85 but it was jumpy already for many Emojis.)

P.S.

Another option would be to adjust ascent, descent, and leading, like we
do for other fonts, to offset for the lack of AppKit.  I tried it, and
the Emojis were a tad too big, filling the entire line top to bottom.
So, it would need a bit of scaling on top.  But the lines did not jump
around.

Perhaps the best result would be to install both this patch and another
one I could prepare, where we *also* decrease ascent, descent, and
leading.  Again, we already do that for other fonts:

    /* AppKit and WebKit do some adjustment to the heights of
       Courier, Helvetica, and Times.  */
    family_name = CTFontCopyFamilyName (macfont);
    if (family_name)
      {
        if (CFEqual (family_name, CFSTR ("Courier"))
            || CFEqual (family_name, CFSTR ("Helvetica"))
            || CFEqual (family_name, CFSTR ("Times")))
          ascent += (ascent + descent) * .15f;
        else if (CFStringHasPrefix (family_name, CFSTR ("Hiragino")))
          {
            leading *= .25f;
            ascent += leading;
          }
        CFRelease (family_name);
      }

That said, while Emojis would look a bit better, it would also introduce
a hidden interplay between `face-font-rescale-alist` and `macfont.m'.
Not sure if fine-tuning typography with that kind of trade-off would be
worth it.

Either way, please take a look at the attached patch.

Rudy

[0001-MacOS-Scale-down-the-system-Emoji-font.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
"The whole science is nothing more than a refinement of everyday
thinking."

--- Albert Einstein, 1879-1955

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #71 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79707 <at> debbugs.gnu.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Tue, 04 Nov 2025 11:25:36 +0530

Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Once again, Arash suggested a solution for this that uses existing
>> Emacs features.  I wonder why no one pays attention to his suggestion.
>
> Good point!  Thanks, Arash.  How about the attached patch?
>
> (I tried 0.85 but it was jumpy already for many Emojis.)
>
0.8 works fine. I confirm that.

Message #74 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Tue, 04 Nov 2025 14:08:32 +0200

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: pankaj <at> codeisgreat.org, 79707 <at> debbugs.gnu.org
> Date: Mon, 03 Nov 2025 23:19:06 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Once again, Arash suggested a solution for this that uses existing
> > Emacs features.  I wonder why no one pays attention to his suggestion.
> 
> Good point!  Thanks, Arash.  How about the attached patch?
> 
> (I tried 0.85 but it was jumpy already for many Emojis.)

Thanks, but I'm not sure this should be the default.  With how many
different sizes of the default fonts did you try it?  And with how
many different fonts used for the default face?  If the factor depends
on the font and/or its size, then having this by default is not TRT;
users who want that will need to do this in their local
customizations.

In any case, (a) we should use add-to-list, to avoid overwriting
non-nil values, and (b) the right place for this is in ns-win.el,
since this is macOS-specific and names macOS-specific fonts.

> Another option would be to adjust ascent, descent, and leading, like we
> do for other fonts, to offset for the lack of AppKit.

That's even worse, IMO, since the values of ascent and descent vary
widely between different fonts which could be used for the default
face.

Message #77 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Rudolf Adamkovič <rudolf <at> adamkovic.org>,
 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Tue, 04 Nov 2025 22:11:59 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
>> Cc: pankaj <at> codeisgreat.org, 79707 <at> debbugs.gnu.org
>> Date: Mon, 03 Nov 2025 23:19:06 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Once again, Arash suggested a solution for this that uses existing
>> > Emacs features.  I wonder why no one pays attention to his suggestion.

Probably because of my low karma level in this forum 😉

>> Good point!  Thanks, Arash.

You're welcome.

> Thanks, but I'm not sure this should be the default.

I wonder if this should be added to Emacs sources at all?  I used
`face-font-rescale-alist' on Windows as well like this:

  (add-to-list 'face-font-rescale-alist
               '("Segoe UI Emoji" . 0.97)
               t)

So maybe it's a question of discoverability, so that users can play with
different values based on the font they use?

Best, Arash

Message #80 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 05 Nov 2025 11:24:25 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, but I'm not sure this should be the default.  With how many
> different sizes of the default fonts did you try it?  And with how
> many different fonts used for the default face?  If the factor depends
> on the font and/or its size, then having this by default is not TRT;
> users who want that will need to do this in their local
> customizations.

Thank you for your guidance, Eli.

I tested with the default monospace font, and also the Iosevka font, at
various font sizes.  I tested about 20 combinations, each with about 10
Emoji glyphs.  Turns out, scaling alone does not work reliably, which
led me to circle back to the adjustments in the font engine.  See below.

> In any case, (a) we should use add-to-list, to avoid overwriting
> non-nil values, and (b) the right place for this is in ns-win.el,
> since this is macOS-specific and names macOS-specific fonts.

Done.

>> Another option would be to adjust ascent, descent, and leading, like we
>> do for other fonts, to offset for the lack of AppKit.
>
> That's even worse, IMO, since the values of ascent and descent vary
> widely between different fonts which could be used for the default
> face.

At this point, I see no other way of fixing the problem.  As mentioned
previously, tweaking ascent, descent, and leading alone fixes the
problem, but the resulting Emoji glyphs are too large, visually.  But,
if we also scale them down, the result is both visually pleasing and
usable, with no shifts in line height due to the use of Emoji, with
Eglot or otherwise.

The attached patch implements this.  Yes, it is hacky, and I do not like
it either.  But, we cannot expect every Mac user to go through all this,
just to be able to edit code with Eglot without text constantly shifting
up and down in front them.  If Emacs uses Emojis to prettify itself by
default, which is a terrible idea, we need to make sure Emojis work well
out of the box.  If there is a better way to fix the problem, please do
tell!

Rudy

[0001-MacOS-Scale-down-the-system-Emoji-font.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
"If you're thinking without writing, you only think you're thinking."

--- Leslie Lamport

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #83 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 05 Nov 2025 11:28:23 +0100

[Message part 1 (text/plain, inline)]

Rudolf Adamkovič <rudolf <at> adamkovic.org> writes:

> The attached patch implements this.

I had a stray tab character in the patch.  Now fixed.

[0001-MacOS-Scale-down-the-system-Emoji-font.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
"To the unknown journeyman
 I promise to show courage
 in upholding my vows

 What is an adventure
 if not the commitment
 to keep going?"

--- Protesilaos Stavrou, To the unknown journeyman, 2025

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

Message #86 received at 79707 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79707 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#79707: Line height changes with point when eglot is running
Date: Wed, 05 Nov 2025 16:56:30 +0200

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: pankaj <at> codeisgreat.org, 79707 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 11:24:25 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks, but I'm not sure this should be the default.  With how many
> > different sizes of the default fonts did you try it?  And with how
> > many different fonts used for the default face?  If the factor depends
> > on the font and/or its size, then having this by default is not TRT;
> > users who want that will need to do this in their local
> > customizations.
> 
> Thank you for your guidance, Eli.
> 
> I tested with the default monospace font, and also the Iosevka font, at
> various font sizes.  I tested about 20 combinations, each with about 10
> Emoji glyphs.  Turns out, scaling alone does not work reliably, which
> led me to circle back to the adjustments in the font engine.  See below.

That's the wrong conclusion, IMO.

> >> Another option would be to adjust ascent, descent, and leading, like we
> >> do for other fonts, to offset for the lack of AppKit.
> >
> > That's even worse, IMO, since the values of ascent and descent vary
> > widely between different fonts which could be used for the default
> > face.
> 
> At this point, I see no other way of fixing the problem.  As mentioned
> previously, tweaking ascent, descent, and leading alone fixes the
> problem, but the resulting Emoji glyphs are too large, visually.  But,
> if we also scale them down, the result is both visually pleasing and
> usable, with no shifts in line height due to the use of Emoji, with
> Eglot or otherwise.
> 
> The attached patch implements this.  Yes, it is hacky, and I do not like
> it either.  But, we cannot expect every Mac user to go through all this,
> just to be able to edit code with Eglot without text constantly shifting
> up and down in front them.  If Emacs uses Emojis to prettify itself by
> default, which is a terrible idea, we need to make sure Emojis work well
> out of the box.  If there is a better way to fix the problem, please do
> tell!

Hard-coding this will lock all the users to use this "fixup", with no
"fire escape" for those who will dislike the results.  I have enough
gray hair to know from experience that users differ widely in their
preferences of the visuals.

And I don't understand why we cannot expect users who dislike the
default display of Emoji to customize face-font-rescale-alist.  You
are the first one (AFAIR) to complain about this, so either most users
don't care (I know I don't) or those who do care already fixed this
locally by this or that customization.

So my conclusion from this is that we should preferably leave this to
user customizations, and perhaps look for ways of making this solution
more easily discoverable.  I can only accept the kind of solution you
propose under the following two conditions, both should be true:

  (a) enough macOS users who use that font for Emoji will agree that
      the result is better in their usage patterns; and
  (b) this "fixup" is conditioned on some variable exposed to Lis, and
      is by default OFF

Thanks.

Previous Next

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