GNU bug report logs - #78545
31.0.50; project-mode-line is slow because it tries to read files on each update

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yikai Zhao <yikai <at> z1k.dev>
Cc: dancol <at> dancol.org, 78545 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#78545: 31.0.50;
 project-mode-line is slow because it tries to read files on each
 update
Date: Thu, 22 May 2025 22:25:05 +0300

> Cc: 78545 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: Yikai Zhao <yikai <at> z1k.dev>
> Date: Fri, 23 May 2025 01:02:02 +0800
> 
>  We could also just have the IO functions signal error if called during a mode line update.
> 
> Personally I think this is a great idea. Aside from mode line updates, IO functions can cause undesired delay
> in many other functions (like tab bar or maybe post command hook). If we have a general way to mark
> certain hooks as “should not block by IO” and be able to capture those violations, it would be very helpful. 

Signaling an error inside redisplay is not useful.  It just writes a
message into *Messages* and that's it.  Unless you are very vigilant,
it will take you a long time to even look in *Messages* and realize
Emacs signaled that error.

If a function doesn't want to do its job in some situation, it should
return without doing anything, rather than signaling an error.

Besides, I see nothing wrong with calling from redisplay functions
that access the filesystem, not in general, anyway.  Sure, calling
locate-dominating-file from a deep directory is not a very wise thing
to do as part of updating the mode line, but Emacs always gives us
enough rope to hang ourselves, trusting us that we won't.  We should
live up to that trust by not doing silly things.

Previous Next

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