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

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

bug#60107: closed (30.0.50; Open new files very slow if eglot and which-


From: GNU bug Tracking System
Subject: bug#60107: closed (30.0.50; Open new files very slow if eglot and which-function-mode are enabled.)
Date: Fri, 16 Dec 2022 15:46:01 +0000

Your message dated Fri, 16 Dec 2022 17:45:29 +0200
with message-id <83a63njqsm.fsf@gnu.org>
and subject line Re: bug#60107: 30.0.50; Open new files very slow if eglot and 
which-function-mode are enabled.
has caused the debbugs.gnu.org bug report #60107,
regarding 30.0.50; Open new files very slow if eglot and which-function-mode 
are enabled.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
60107: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60107
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 30.0.50; Open new files very slow if eglot and which-function-mode are enabled. Date: Thu, 15 Dec 2022 23:53:30 +0100



In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35) of 2022-12-15 built on felix-lifebooka531
Repository revision: 0d60579b6b6f2648a881572783322b1bcf931a73
Repository branch: makepkg
Windowing system distributor 'The X.Org Foundation', version 11.0.12201006
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-libotf --without-m17n-flt --without-gconf
 --enable-autodepend --with-native-compilation=yes --with-xinput2
 --with-x-toolkit=gtk3 --without-xaw3d --without-cairo --with-sound=no
 --with-xwidgets --with-tree-sitter --without-gpm
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11
XDBE XFT XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8


Opening C files is very slow if which-function-mode and eglot are
enabled at the same time. I tested this with:

emacs -Q
opening a C project file
M-x eglot
M-x which-function-mode
switching to another .c project file now takes seconds until the buffer
shows up.
I use an old Laptop, but with just one of the two modes disabled,
it's quite snappy.



--- End Message ---
--- Begin Message --- Subject: Re: bug#60107: 30.0.50; Open new files very slow if eglot and which-function-mode are enabled. Date: Fri, 16 Dec 2022 17:45:29 +0200
> From: Felix <felix.dick@web.de>
> Cc: joaotavora@gmail.com, 60107@debbugs.gnu.org
> Date: Fri, 16 Dec 2022 12:26:21 +0100
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does it help to customize which-func-non-auto-modes to add the major
> > mode you are using there?  Or maybe customize which-func-maxout to a
> > small value to get the same effect in any mode?  I'm asking whether
> > this helps because it's unclear to me whether doing so will avoid
> > blocking redisplay, if and when which-func finally becomes active.
> >
> >> If this is not a bug of emacs,
> >> feel free to close this bug report.
> >
> > If the above doesn't help, I guess some changes to which-func could be
> > in order, to avoid blocking the first display of a buffer for such a
> > long time.  So in that case we shouldn't close this bug report yet.
> >
> > Thanks.
> 
> In fact both of it helps!
> Adding c-ts-mode to which-func-non-auto-modes solves the problem,
> setting which-func-maxout to 1000 works as well (that's the only value i
> tested).

Thanks, so I added these hints to the doc strings of the two optioins,
and I'm closing the bug.


--- End Message ---

reply via email to

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