GNU bug report logs - #69140
30.0.50; [elpa/vertico] Emacs with vertico-mode freezes if font is too big

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aleksandr Vityazev <avityazev <at> disroot.org>
Cc: luangruo <at> yahoo.com, mail <at> daniel-mendler.de, 69140 <at> debbugs.gnu.org
Subject: Re: bug#69140: 30.0.50; [elpa/vertico] Emacs with vertico-mode
 freezes if font is too big
Date: Thu, 22 Feb 2024 08:21:26 +0200

> From: Aleksandr Vityazev <avityazev <at> disroot.org>
> Cc: luangruo <at> yahoo.com,  mail <at> daniel-mendler.de,  69140 <at> debbugs.gnu.org
> Date: Wed, 21 Feb 2024 23:22:27 +0300
> 
> On 2024-02-21 21:43, Eli Zaretskii wrote:
> 
> > What you "eval-buffer", is the Emacs frame visible in its entirety on
> > the screen, or are parts of it hidden because the font is too large?
> 
> part of the mode-lane is hidden, but otherwise everything is visible

This situation works well here, it doesn't hang.

> > I tried different fonts and different sizes, and as long as I can see
> > the frame on the screen, I don't see any hangs.  Maybe this only
> > happens with pathologically large fonts, with which only a small part
> > of the frame can be seen, but if so, why is this situation
> > interesting?
> >
> 
> with (set-face-attribute 'default nil :family "monospace" :height 440)
> the result is the following:
> 
> --8<---------------cut here---------------start------------->8---
> (list (window-height) (window-width)) => (13 53)
> 
> C-u C-x = (what-cursor-position) =>
> 
> display: by this font (glyph code):
> ftcrhb:-    -Go Mono-regular-normal-normal-*-58-*-*-*-m-0-iso10646-1 (#x37)
> --8<---------------cut here---------------end--------------->8---
> 
> I think this is still a reasonable size. I usually have my font height
> set to 240, and recently I noticed that vertico was starting to lag at
> this setting. Researching further, I found that the larger the font, the
> more obvious the hang, and I also found the commit after which it all
> started. I think that there is a bug here, but we need to investigate it
> further and check it without pgtk on X.

Could someone please reproduce and investigate?  Po Lu, any
suggestions or ideas?

Previous Next

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