GNU bug report logs - #73592
30.0.91; delayed output with completion preview mode

Previous Next

Package: emacs;

Reported by: Christopher Howard <christopher <at> librehacker.com>

Date: Tue, 1 Oct 2024 23:06:02 UTC

Severity: normal

Found in version 30.0.91

Full log


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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Howard <christopher <at> librehacker.com>, 73592 <at> debbugs.gnu.org
Subject: Re: bug#73592: 30.0.91; delayed output with completion preview mode
Date: Wed, 02 Oct 2024 09:24:31 +0200
Hi,

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

>> From: Christopher Howard <christopher <at> librehacker.com>
>> Date: Tue, 01 Oct 2024 15:04:57 -0800
>> 
>> 
>> Hi, I don't know if I've done enough troubleshooting yet to justify
>> opening this bug, but I been struggling with this since I switched
>> to emacs-30 branch, and was wondering if others have experienced
>> this also. I have not been able to reproduce the problem with -q so
>> I suppose it must be an issue in my configuration or modes that I
>> use.
>> 
>> I use global-completion-preview-mode with Completion Preview Exact
>> Match Only set to on and Completion Preview Idle Delay set to No
>> delay. When I am in eshell, or running eshell-command, I sometimes
>> see this behavior where character output is either delayed briefly
>> (like, one second), or a character is not outputted until I press
>> another character, at which point both are outputted at the same
>> time.
>> 
>> A reproducible case (for me at least) is if I am in eshell and I type the command "gnus". It takes about a second extra for the "s" to appear.
>> 
>> If I turn CP mode of the behavior goes away. I've been experimenting with leaving CP mode on and turning off my other minor modes, like Helm, but this hasn't had any effect so far.
>> 
>> I haven't had time yet to bisect my init.el — a rather long and tedious process in my case. Wondered if anybody might have some ideas as far as the likely culprit for this behavior.
>
> Thank you for your report.
>
> One way to find the possible culprit(s) is to run the commands with
> slow responses after enabling the Lisp profiler (M-x profiler-start),
> and then looking at (and possibly posting here) the produced profile,
> after fully expanding it.
>
> Eshel, can you please look into this?

Gladly, but so far I'm unable to reproduce this, so we'll need more
information to make progress.

Christopher, in addition to Eli suggestion about using the profiler,
could you also toggle-debug-on-quit and try hitting C-g while you
observe the reported delay?  If you get a backtrace, that could give us
some useful hints.  It might also help to know your local and global
values of completion-at-point-functions.


Cheers,

Eshel




This bug report was last modified 253 days ago.

Previous Next


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