GNU bug report logs - #68081
30.0.50; derived-mode and display-buffer-alist

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: germanp82 <at> hotmail.com, 68081 <at> debbugs.gnu.org
Subject: Re: bug#68081: 30.0.50; derived-mode and display-buffer-alist
Date: Wed, 03 Jan 2024 13:59:20 +0200

> Date: Tue, 2 Jan 2024 11:46:26 +0100
> Cc: germanp82 <at> hotmail.com, 68081 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Thanks, but now I wonder whether we should revert the change which
>  > made display-buffer call buffer-match-p.
> 
> The problem is not with 'display-buffer'.  The problem is with
> 'pop-to-buffer' and 'switch-to-buffer'.  What would you tell people who
> already customized 'display-buffer-alist' and are happy with how it
> works with 'display-buffer'?
> 
>  > It sounds like fixing the
>  > breakage in any other way is either hard or fragile or nigh
>  > impossible.
> 
> 'info' initially used 'switch-to-buffer'
> 
>      (if (get-buffer "*info*")
> 	(switch-to-buffer "*info*")
>        (Info-directory))))
> 
> Later it called 'pop-to-buffer' as
> 
>      (if (get-buffer "*info*")
> 	(pop-to-buffer "*info*")
>        (Info-directory))))
> 
> The breakage occurred when it started to call
> 
>    (pop-to-buffer "*info*")
> 
> without checking whether that buffer exists.  It sometimes backfires to
> use a feature meant for interactive use (like 'pop-to-buffer' creating
> its buffer autonomously) in non-interactive calls.  Sometimes it happens
> decades after that feature was misused.

Do other places that are affected by the same change do the same
mistake of unconditionally calling pop-to-buffer?

Previous Next

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