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

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Vertico version 1.7, version 1.3 has also been tested, is incompatible
with the changes made by the commit -
caea0c1649d1df96b811c1388fde396e66bc356b. This commit was found via
git bisect.

To reproduce:
1. Run emacs -Q
2. M-x load-library vertico RET
3. M-x vertico-mode RET
4. Set a large font, the following is suitable for my 13 inch monitor:
(set-face-attribute 'default nil :family "monospace" :height 440)
5. Call M-x
Emacs should freeze, sometimes you can unfreeze it with a few presses
of C-g

profiler-report below:

#+begin_example
5555  81% - command-execute
5555  81%  - call-interactively
5555  81%   - byte-code
5555  81%    - read-extended-command
5555  81%     - read-extended-command-1
5555  81%      - completing-read
5555  81%       - completing-read-default
5555  81%        - apply
5555  81%         - vertico--advice
5555  81%          - apply
5555  81%           - #<compiled -0x109324e03480587c>
5555  81%            - read-from-minibuffer
2795  40%             - redisplay_internal (C function)
  76   1%              + window--resize-root-window-vertically
  50   0%              + eval
  12   0%              + file-remote-p
  12   0%              + mode-line-default-help-echo
2520  36%             - minibuffer-error-function
2520  36%              - minibuffer-message
2520  36%               - sit-for
2516  36%                - redisplay
2516  36%                 - redisplay_internal (C function)
  72   1%                  - window--resize-root-window-vertically
  56   0%                   + window-sizable
   8   0%                   + walk-window-tree
   4   0%                   + window--resize-this-window
  68   0%                  + eval
  32   0%                  + mode-line-default-help-echo
  20   0%                  + file-remote-p
   4   0%                  input-pending-p
 135   1%             + vertico--exhibit
1104  16%   Automatic GC
 180   2% + redisplay_internal (C function)
   8   0% + timer-event-handler
   0   0%   ...
#+end_example


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.16.0)
System Description: Guix System

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/f9faac619qdhgybd0ddfvwdazcvv41qq-emacs-rrr-next-30.0.50-49.3a93e30
 --enable-fast-install --with-pgtk --without-libsystemd
 --with-tree-sitter --with-native-compilation --with-cairo
 --with-modules --with-native-compilation=aot --disable-build-details'




-- 
Best regards,
Aleksandr Vityazev

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

[Eli Zaretskii]

> Cc: mail@daniel-mendler.de
> Date: Thu, 15 Feb 2024 14:23:28 +0300
> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Vertico version 1.7, version 1.3 has also been tested, is incompatible
> with the changes made by the commit -
> caea0c1649d1df96b811c1388fde396e66bc356b. This commit was found via
> git bisect.
> 
> To reproduce:
> 1. Run emacs -Q
> 2. M-x load-library vertico RET
> 3. M-x vertico-mode RET
> 4. Set a large font, the following is suitable for my 13 inch monitor:
> (set-face-attribute 'default nil :family "monospace" :height 440)
> 5. Call M-x
> Emacs should freeze, sometimes you can unfreeze it with a few presses
> of C-g

Thanks, but why do you think the bug is in Emacs and not in vertico?
The fact that you can unfreeze Emacs with C-g indicates that some Lisp
is involved in what probably is an infloop.  At the very least, could
you please catch a Lisp backtrace when you type C-g, so that we could
see what Lisp is involved?  Also, what exactly does vertico do with
resizing the mini-window, and what should be the value of
resize-mini-windows for reproducing this issue.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: mail@daniel-mendler.de
>> Date: Thu, 15 Feb 2024 14:23:28 +0300
>> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Vertico version 1.7, version 1.3 has also been tested, is incompatible
>> with the changes made by the commit -
>> caea0c1649d1df96b811c1388fde396e66bc356b. This commit was found via
>> git bisect.
>> 
>> To reproduce:
>> 1. Run emacs -Q
>> 2. M-x load-library vertico RET
>> 3. M-x vertico-mode RET
>> 4. Set a large font, the following is suitable for my 13 inch monitor:
>> (set-face-attribute 'default nil :family "monospace" :height 440)
>> 5. Call M-x
>> Emacs should freeze, sometimes you can unfreeze it with a few presses
>> of C-g
>
> Thanks, but why do you think the bug is in Emacs and not in vertico?
> The fact that you can unfreeze Emacs with C-g indicates that some Lisp
> is involved in what probably is an infloop.  At the very least, could
> you please catch a Lisp backtrace when you type C-g, so that we could
> see what Lisp is involved?  Also, what exactly does vertico do with
> resizing the mini-window, and what should be the value of
> resize-mini-windows for reproducing this issue.

Also, if at all possible, please attempt to interrupt Emacs while it is
so frozen under GDB until you have collected several unique backtraces
containing entries for `redisplay_internal', and post them here.

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-02-15 22:29, Po Lu wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Cc: mail@daniel-mendler.de
>>> Date: Thu, 15 Feb 2024 14:23:28 +0300
>>> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>> 
>>> Vertico version 1.7, version 1.3 has also been tested, is incompatible
>>> with the changes made by the commit -
>>> caea0c1649d1df96b811c1388fde396e66bc356b. This commit was found via
>>> git bisect.
>>> 
>>> To reproduce:
>>> 1. Run emacs -Q
>>> 2. M-x load-library vertico RET
>>> 3. M-x vertico-mode RET
>>> 4. Set a large font, the following is suitable for my 13 inch monitor:
>>> (set-face-attribute 'default nil :family "monospace" :height 440)
>>> 5. Call M-x
>>> Emacs should freeze, sometimes you can unfreeze it with a few presses
>>> of C-g
>>
>> Thanks, but why do you think the bug is in Emacs and not in vertico?
>> The fact that you can unfreeze Emacs with C-g indicates that some Lisp
>> is involved in what probably is an infloop.  At the very least, could
>> you please catch a Lisp backtrace when you type C-g, so that we could
>> see what Lisp is involved?  Also, what exactly does vertico do with
>> resizing the mini-window, and what should be the value of
>> resize-mini-windows for reproducing this issue.
>
> Also, if at all possible, please attempt to interrupt Emacs while it is
> so frozen under GDB until you have collected several unique backtraces
> containing entries for `redisplay_internal', and post them here.

No backtrace yet, but I found another reproducer without vertico, all
used packages are from Emacs core.

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/1gij4r65kyw6lm2m9clqpraigivjgzq9-emacs-test-test
 --enable-fast-install --with-pgtk --without-libsystemd
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 --with-native-compilation=no --with-cairo --with-modules
 --disable-build-details 'CFLAGS=-O0 -g3''

1. Run emacs -Q
2. Paste the following code into the scratch buffer and run eval-buffer
--8<---------------cut here---------------start------------->8---
(load-library "transient")
(fido-vertical-mode 1)
(defclass test-transient-multi (transient-option) ()
  ((key         :initform "-")
   (argument    :initform "-")
   (multi-value :initform t)
   (reader      :initform completing-read-multiple))
  "")

(transient-define-argument test:--1 ()
  :description "test1"
  :class 'transient-option
  :shortarg "a"
  :argument "test1=")

(transient-define-argument test:--2 ()
  :description "test2"
  :class 'test-transient-multi
  :key "r"
  :argument "test2"
  :multi-value t
  :prompt "Test2: "
  :reader (lambda (prompt _initial-input _history)
            (completing-read-multiple
             prompt
             '("nonsdlslde" "slsdl" "2323" "ldslld" "30203" "llx" "ldslsd"))))

(transient-define-argument test:--3 ()
  :description "test3"
  :class 'test-transient-multi
  :key "l"
  :argument "test3"
  :multi-value t
  :prompt "Test3: "
  :reader (lambda (prompt _initial-input _history)
            (completing-read-multiple
             prompt
             '("nonsdlslde" "slsdl" "2323" "ldslld" "30203" "llx" "ldslsd"))))

(transient-define-argument test:--4 ()
  :description "test4"
  :class 'test-transient-multi
  :key "y"
  :argument "test4"
  :multi-value t
  :prompt "Test4: "
  :reader (lambda (prompt _initial-input _history)
            (completing-read-multiple
             prompt
             '("nonsdlslde" "slsdl" "2323" "ldslld" "30203" "llx" "ldslsd"))))

(defun test-hello ()
  ""
  (interactive)
  (message "hello"))

(transient-define-prefix test-dispatch ()
  ["Test parameters"
   (test:--1)
   (test:--2)
   (test:--3)
   (test:--4)
   ]
  [["Search"
    ("s" "test" test-hello)]])
(set-face-attribute 'default nil :family "monospace" :height 440)
--8<---------------cut here---------------end--------------->8---

3. M-x test-dispatch
4. Try playing with the parameters test1, test2, test3, test4. At the
same time you can put Emacs into full screen mode and back into windowed
mode, where it will occupy half of the screen. Initially, calling the
parameters test1, test2, test3, test4 in the transient window will be
delayed and everything can be canceled with C-g, after a few repetitions
Emacs hangs completely.

-- 
Best regards,
Aleksandr Vityazev

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

[Eli Zaretskii]

> From: Aleksandr Vityazev <avityazev@disroot.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  69140@debbugs.gnu.org,
>   mail@daniel-mendler.de
> Date: Wed, 21 Feb 2024 19:15:57 +0300
> 
> 3. M-x test-dispatch
> 4. Try playing with the parameters test1, test2, test3, test4. At the
> same time you can put Emacs into full screen mode and back into windowed
> mode, where it will occupy half of the screen. Initially, calling the
> parameters test1, test2, test3, test4 in the transient window will be
> delayed and everything can be canceled with C-g, after a few repetitions
> Emacs hangs completely.

Thanks, but I don't understand what to do after "m-x test-dispatch".
Please tell in more details what you mean in Step 4, in terms of what
I need to type after "M-x test-dispatch".  (I tried several things,
but couldn't get any interesting effects, let alone a hang.)

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On 2024-02-21 18:38, Eli Zaretskii wrote:

>> From: Aleksandr Vityazev <avityazev@disroot.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  69140@debbugs.gnu.org,
>>   mail@daniel-mendler.de
>> Date: Wed, 21 Feb 2024 19:15:57 +0300
>> 
>> 3. M-x test-dispatch
>> 4. Try playing with the parameters test1, test2, test3, test4. At the
>> same time you can put Emacs into full screen mode and back into windowed
>> mode, where it will occupy half of the screen. Initially, calling the
>> parameters test1, test2, test3, test4 in the transient window will be
>> delayed and everything can be canceled with C-g, after a few repetitions
>> Emacs hangs completely.
>
> Thanks, but I don't understand what to do after "m-x test-dispatch".
> Please tell in more details what you mean in Step 4, in terms of what
> I need to type after "M-x test-dispatch".  (I tried several things,
> but couldn't get any interesting effects, let alone a hang.)

I run test-dispatch, for example I press "r", which calls the
minibuffer. At this point, Emacs is already starting to freeze for me; if
I change the full-screen to windowed mode several times, everything gets
worse.  If nothing happens after pressing "r" you can try other bound
letters.

In fact, I can call commands through the tool-bar or menu-bar, but
everything that is displayed in the window or minibuffer does not
change. Was able to switch to the *Bactrace* buffer and save it via the
menu bar.

Bactrace is attached.

[-- Attachment #2: bactrace --]
[-- Type: text/plain, Size: 6809 bytes --]

Debugger entered--Lisp error: (quit)
  apply(debug (error (quit)))
  transient--exit-and-debug(error (quit))
  redisplay_internal\ \(C\ function\)()
  read-from-minibuffer("Test2: " nil (keymap (remap keymap (minibuffer-completion-help . crm-completion-help) (minibuffer-complete-word . crm-complete-word) (minibuffer-complete . crm-complete)) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (M-down . minibuffer-next-completion) (M-up . minibuffer-previous-completion) (27 keymap (13 . minibuffer-choose-completion) (103 keymap (27 keymap (99 . switch-to-completions))) (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (backtab . minibuffer-complete) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the minibuffer") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuffer") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "\15" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (24 keymap (down . minibuffer-complete-defaults) (up . minibuffer-complete-history)) (13 . exit-minibuffer) (10 . exit-minibuffer) (7 . abort-minibuffers) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (60 . minibuffer-beginning-of-buffer) (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil nil nil nil)
  completing-read-multiple("Test2: " ("nonsdlslde" "slsdl" "2323" "ldslld" "30203" "llx" "ldslsd"))
  (lambda (prompt _initial-input _history) (completing-read-multiple prompt '("nonsdlslde" "slsdl" "2323" "ldslld" "30203" "llx" "ldslsd")))("Test2: " nil transient--history)
  #f(compiled-function (obj) "Read a value while taking care of history.\n\nThis method is suitable for a wide variety of infix commands,\nincluding but not limited to inline arguments and variables.\n\nIf you do not use this method for your own infix class, then\nyou should likely replicate a lot of the behavior of this\nmethod.  If you fail to do so, then users might not appreciate\nthe lack of history, for example.\n\nOnly for very simple classes that toggle or cycle through a very\nlimited number of possible values should you replace this with a\nsimple method that does not handle history.  (E.g., for a command\nline switch the only possible values are \"use it\" and \"don't use\nit\", in which case it is pointless to preserve history.)" #<bytecode 0x1d0443cdbe7f1dda>)(#<test-transient-multi test-transient-multi-47e882>)
  apply(#f(compiled-function (obj) "Read a value while taking care of history.\n\nThis method is suitable for a wide variety of infix commands,\nincluding but not limited to inline arguments and variables.\n\nIf you do not use this method for your own infix class, then\nyou should likely replicate a lot of the behavior of this\nmethod.  If you fail to do so, then users might not appreciate\nthe lack of history, for example.\n\nOnly for very simple classes that toggle or cycle through a very\nlimited number of possible values should you replace this with a\nsimple method that does not handle history.  (E.g., for a command\nline switch the only possible values are \"use it\" and \"don't use\nit\", in which case it is pointless to preserve history.)" #<bytecode 0x1d0443cdbe7f1dda>) #<test-transient-multi test-transient-multi-47e882>)
  #f(compiled-function (&rest args) #<bytecode 0xe3ded132d7c1c5e>)(#<test-transient-multi test-transient-multi-47e882>)
  #f(compiled-function (cl--cnm obj) #<bytecode -0xa6f70d64c5256f0>)(#f(compiled-function (&rest args) #<bytecode 0xe3ded132d7c1c5e>) #<test-transient-multi test-transient-multi-47e882>)
  apply(#f(compiled-function (cl--cnm obj) #<bytecode -0xa6f70d64c5256f0>) #f(compiled-function (&rest args) #<bytecode 0xe3ded132d7c1c5e>) #<test-transient-multi test-transient-multi-47e882>)
  #f(compiled-function (obj) "Refresh the transient buffer buffer calling the next method.\n\nAlso wrap `cl-call-next-method' with two macros:\n- `transient--with-suspended-override' allows use of minibuffer.\n- `transient--with-emergency-exit' arranges for the transient to\n  be exited in case of an error." #<bytecode -0x9d330106cd54cf8>)(#<test-transient-multi test-transient-multi-47e882>)
  apply(#f(compiled-function (obj) "Refresh the transient buffer buffer calling the next method.\n\nAlso wrap `cl-call-next-method' with two macros:\n- `transient--with-suspended-override' allows use of minibuffer.\n- `transient--with-emergency-exit' arranges for the transient to\n  be exited in case of an error." #<bytecode -0x9d330106cd54cf8>) #<test-transient-multi test-transient-multi-47e882> nil)
  transient-infix-read(#<test-transient-multi test-transient-multi-47e882>)
  transient--default-infix-command()
  apply(transient--default-infix-command nil)
  #f(compiled-function (fn &rest args) (interactive nil) #<bytecode 0x1599241be4a7ac75>)(transient--default-infix-command)
  funcall-interactively(#f(compiled-function (fn &rest args) (interactive nil) #<bytecode 0x1599241be4a7ac75>) transient--default-infix-command)
  apply(funcall-interactively #f(compiled-function (fn &rest args) (interactive nil) #<bytecode 0x1599241be4a7ac75>) transient--default-infix-command)
  #f(compiled-function (fn &rest args) (interactive '#f(compiled-function (spec) #<bytecode 0x16ce9cc417f12940>)) #<bytecode -0x52683015c5ccb0c>)(transient--default-infix-command)
  apply(#f(compiled-function (fn &rest args) (interactive '#f(compiled-function (spec) #<bytecode 0x16ce9cc417f12940>)) #<bytecode -0x52683015c5ccb0c>) transient--default-infix-command nil)
  test:--2()
  funcall-interactively(test:--2)
  call-interactively(test:--2 nil nil)
  command-execute(test:--2)

[-- Attachment #3: Type: text/plain, Size: 39 bytes --]



-- 
Best regards,
Aleksandr Vityazev

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-02-21 20:20, Aleksandr Vityazev wrote:

> On 2024-02-21 18:38, Eli Zaretskii wrote:
>
>>> From: Aleksandr Vityazev <avityazev@disroot.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  69140@debbugs.gnu.org,
>>>   mail@daniel-mendler.de
>>> Date: Wed, 21 Feb 2024 19:15:57 +0300
>>> 
>>> 3. M-x test-dispatch
>>> 4. Try playing with the parameters test1, test2, test3, test4. At the
>>> same time you can put Emacs into full screen mode and back into windowed
>>> mode, where it will occupy half of the screen. Initially, calling the
>>> parameters test1, test2, test3, test4 in the transient window will be
>>> delayed and everything can be canceled with C-g, after a few repetitions
>>> Emacs hangs completely.
>>
>> Thanks, but I don't understand what to do after "m-x test-dispatch".
>> Please tell in more details what you mean in Step 4, in terms of what
>> I need to type after "M-x test-dispatch".  (I tried several things,
>> but couldn't get any interesting effects, let alone a hang.)
>
> I run test-dispatch, for example I press "r", which calls the
> minibuffer. At this point, Emacs is already starting to freeze for me; if
> I change the full-screen to windowed mode several times, everything gets
> worse.  If nothing happens after pressing "r" you can try other bound
> letters.

You could also try enlarging the font

> In fact, I can call commands through the tool-bar or menu-bar, but
> everything that is displayed in the window or minibuffer does not
> change. Was able to switch to the *Bactrace* buffer and save it via the
> menu bar.

> Bactrace is attached.


-- 
Best regards,
Aleksandr Vityazev

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

[Eli Zaretskii]

> From: Aleksandr Vityazev <avityazev@disroot.org>
> Cc: luangruo@yahoo.com,  mail@daniel-mendler.de,  69140@debbugs.gnu.org
> Date: Wed, 21 Feb 2024 20:47:22 +0300
> 
> > I run test-dispatch, for example I press "r", which calls the
> > minibuffer. At this point, Emacs is already starting to freeze for me; if
> > I change the full-screen to windowed mode several times, everything gets
> > worse.  If nothing happens after pressing "r" you can try other bound
> > letters.
> 
> You could also try enlarging the font

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?

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?

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-02-21 21:43, Eli Zaretskii wrote:

>> From: Aleksandr Vityazev <avityazev@disroot.org>
>> Cc: luangruo@yahoo.com,  mail@daniel-mendler.de,  69140@debbugs.gnu.org
>> Date: Wed, 21 Feb 2024 20:47:22 +0300
>> 
>> > I run test-dispatch, for example I press "r", which calls the
>> > minibuffer. At this point, Emacs is already starting to freeze for me; if
>> > I change the full-screen to windowed mode several times, everything gets
>> > worse.  If nothing happens after pressing "r" you can try other bound
>> > letters.
>> 
>> You could also try enlarging the font
>
> 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

> 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.

-- 
Best regards,
Aleksandr Vityazev

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

[Eli Zaretskii]

> From: Aleksandr Vityazev <avityazev@disroot.org>
> Cc: luangruo@yahoo.com,  mail@daniel-mendler.de,  69140@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?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Alexandr, please send me an archive containing the font files for "Go
Mono", and I'll try to reproduce.

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On 2024-02-22 14:37, Po Lu wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> 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?
>
> Alexandr, please send me an archive containing the font files for "Go
> Mono", and I'll try to reproduce.

I also checked the following fonts: Iosevka, Liberation Mono, DejaVu
Sans Mono, the behavior is the same.

Go Mono fonts archive attached.


[-- Attachment #2: go-mono-font --]
[-- Type: application/octet-stream, Size: 164200 bytes --]

[-- Attachment #3: Type: text/plain, Size: 39 bytes --]



-- 
Best regards,
Aleksandr Vityazev

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Aleksandr Vityazev <avityazev@disroot.org> writes:

> On 2024-02-22 14:37, Po Lu wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> 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?
>>
>> Alexandr, please send me an archive containing the font files for "Go
>> Mono", and I'll try to reproduce.
>
> I also checked the following fonts: Iosevka, Liberation Mono, DejaVu
> Sans Mono, the behavior is the same.
>
> Go Mono fonts archive attached.

Should be fixed now, thanks.

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2024-02-23 10:19, Po Lu wrote:

> Aleksandr Vityazev <avityazev@disroot.org> writes:
>
>> On 2024-02-22 14:37, Po Lu wrote:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> 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?
>>>
>>> Alexandr, please send me an archive containing the font files for "Go
>>> Mono", and I'll try to reproduce.
>>
>> I also checked the following fonts: Iosevka, Liberation Mono, DejaVu
>> Sans Mono, the behavior is the same.
>>
>> Go Mono fonts archive attached.
>
> Should be fixed now, thanks.

Thanks for the fix, I tested it and it works fine for me.

-- 
Best regards,
Aleksandr Vityazev

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

[Eli Zaretskii]

> From: Aleksandr Vityazev <avityazev@disroot.org>
> Cc: mail@daniel-mendler.de,  Eli Zaretskii <eliz@gnu.org>,
>   69140@debbugs.gnu.org
> Date: Fri, 23 Feb 2024 20:12:12 +0300
> 
> On 2024-02-23 10:19, Po Lu wrote:
> 
> > Should be fixed now, thanks.
> 
> Thanks for the fix, I tested it and it works fine for me.

Thanks for testing, I'm therefore closing this bug.

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

[Eli Zaretskii]

> From: Aleksandr Vityazev <avityazev@disroot.org>
> Cc: luangruo@yahoo.com,  69140@debbugs.gnu.org,  mail@daniel-mendler.de
> Date: Wed, 21 Feb 2024 20:20:14 +0300
> 
> > Thanks, but I don't understand what to do after "m-x test-dispatch".
> > Please tell in more details what you mean in Step 4, in terms of what
> > I need to type after "M-x test-dispatch".  (I tried several things,
> > but couldn't get any interesting effects, let alone a hang.)
> 
> I run test-dispatch, for example I press "r", which calls the
> minibuffer. At this point, Emacs is already starting to freeze for me; if
> I change the full-screen to windowed mode several times, everything gets
> worse.  If nothing happens after pressing "r" you can try other bound
> letters.

I tried all the letters, and didn't see any hangs.

Maybe this only happens in a GTK build with Cairo.

You say "set a large font", but running your recipe I don't see any
large fonts, except in the help-echo tooltips.  Maybe that's why I
cannot see any problems.  Perhaps the problem is with the
set-face-attribute part of the recipe, in that it doesn't produce the
same effect on my system as on yours?

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

[Aleksandr Vityazev via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

On 2024-02-15 15:46, Eli Zaretskii wrote:

>> Cc: mail@daniel-mendler.de
>> Date: Thu, 15 Feb 2024 14:23:28 +0300
>> From:  Aleksandr Vityazev via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Vertico version 1.7, version 1.3 has also been tested, is incompatible
>> with the changes made by the commit -
>> caea0c1649d1df96b811c1388fde396e66bc356b. This commit was found via
>> git bisect.
>> 
>> To reproduce:
>> 1. Run emacs -Q
>> 2. M-x load-library vertico RET
>> 3. M-x vertico-mode RET
>> 4. Set a large font, the following is suitable for my 13 inch monitor:
>> (set-face-attribute 'default nil :family "monospace" :height 440)
>> 5. Call M-x
>> Emacs should freeze, sometimes you can unfreeze it with a few presses
>> of C-g
>
> Thanks, but why do you think the bug is in Emacs and not in vertico?
> The fact that you can unfreeze Emacs with C-g indicates that some Lisp
> is involved in what probably is an infloop.  At the very least, could
> you please catch a Lisp backtrace when you type C-g, so that we could
> see what Lisp is involved?  Also, what exactly does vertico do with
> resizing the mini-window, and what should be the value of
> resize-mini-windows for reproducing this issue.

resize-mini-windows is set to default ‘grow-only’
All vertico customs are also default.

I couldn’t reproduce it any other way, but it seemed to me that there
might be some problems with the redisplay. 

I couldn't get a backtrace because if you set the debug-on-quit to t,
then C-g no longer helps. 2 screenshots in the attachment, but the
backtrace is only partially visible.

I'm not very familiar with gdb, I'll look into the matter and attach the
backtraces.


[-- Attachment #2: image1 --]
[-- Type: image/jpeg, Size: 308868 bytes --]

[-- Attachment #3: image2 --]
[-- Type: image/jpeg, Size: 122825 bytes --]

[-- Attachment #4: Type: text/plain, Size: 39 bytes --]



-- 
Best regards,
Aleksandr Vityazev