GNU bug report logs - #18522
occasional slow performance in some Gnus code

Previous Next

Packages: gnus, emacs;

Reported by: Peter Münster <pmlists <at> free.fr>

Date: Mon, 22 Sep 2014 10:38:02 UTC

Severity: normal

Tags: fixed

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
Subject: Re: bug#18522: 24.4.50; mapcar is very slow
Date: Fri, 26 Feb 2016 11:28:05 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Peter Münster <pmlists <at> free.fr>,
>   18522 <at> debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
> 
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical?  So that should be fixed, but:
> 
> >  . set-default should skip killed buffers
> 
> Yes.  I think that would be a win in general.
> 
> > For the second issue, I propose to modify set-default to use
> > FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER.  Does anyone see a
> > problem with that?
> 
> Hm...  If a buffer is killed, do the local variables still have an
> effect?  I'm thinking of code like:
> 
> (with-temp-buffer
>   (setq-local foo 'bar)
>   (kill-buffer (current-buffer))
>   (let ((buf (current-buffer)))
>     (with-temp-buffer
>       (let ((foo 'zot))
>         (set-buffer buf)
>         foo))))
> 
> Well, that answered itself.  :-) It returns zot.  (If we don't kill it
> returns bar.)  So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
> here.

Btw, why did you fix all those on master?  I think this should be
fixed on emacs-25 instead.

Thanks.




This bug report was last modified 8 years and 170 days ago.

Previous Next


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