GNU bug report logs - #10135
24.0.91; `special-display-regexps' is still not respected (again)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10135 in the body.
You can then email your comments to 10135 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.91; `special-display-regexps' is still not respected (again)
Date: Fri, 25 Nov 2011 07:16:09 -0800

emacs -Q
 
1. Download hexrgb.el and oneonone.el:
 
http://www.emacswiki.org/emacs/download/hexrgb.el
http://www.emacswiki.org/emacs/download/oneonone.el
 
2.runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
 
3. (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
 
4. C-h i
 
5. C-x 5 2
 
In step 4, a special-display frame is used, correctly (the buffer name
matches `special-display-regexps').
 
In step 5, a special-display frame should also be used, for the same
reason, but it is not.

In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-21 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'
 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10135 <at> debbugs.gnu.org
Subject: Re: bug#10135: 24.0.91;
	`special-display-regexps' is still not respected (again)
Date: Fri, 25 Nov 2011 22:59:39 -0500

> 5. C-x 5 2
[...]
> In step 5, a special-display frame should also be used, for the same
> reason, but it is not.

I could agree that it's a problem, but IIUC this is not a new issue,
since I think that's how C-x 5 2 has always worked, right?


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10135 <at> debbugs.gnu.org
Subject: RE: bug#10135: 24.0.91;
	`special-display-regexps' is still not respected (again)
Date: Sat, 26 Nov 2011 06:54:26 -0800

> > 5. C-x 5 2
> > In step 5, a special-display frame should also be used, for the same
> > reason, but it is not.
> 
> I could agree that it's a problem, but IIUC this is not a new issue,
> since I think that's how C-x 5 2 has always worked, right?

You are right, sir - my bad.

Feel free to close this bug or (IMO better) keep it open, perhaps as a wishlist
item.

Since the buffer displayed matches `special-display-regexps', a special-display
frame should be used.  But you are correct that this bug is very old (at least
as old as Emacs 20).

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10135 <at> debbugs.gnu.org
Subject: Re: bug#10135: 24.0.91;
	`special-display-regexps' is still not respected (again)
Date: Mon, 28 Nov 2011 10:59:37 -0500

>> > 5. C-x 5 2
>> > In step 5, a special-display frame should also be used, for the same
>> > reason, but it is not.
>> I could agree that it's a problem, but IIUC this is not a new issue,
>> since I think that's how C-x 5 2 has always worked, right?
> You are right, sir - my bad.

Thanks for confirming.

> Feel free to close this bug or (IMO better) keep it open, perhaps as
> a wishlist item.

The fact that it's not new doesn't change the fact that you dislike
this behavior, so it's not a reason to close the bug.

> Since the buffer displayed matches `special-display-regexps',
> a special-display frame should be used.

As you know I use a similar setup to yours so I have gone through
similar thoughts.  I haven't actually tried to make C-x 5 2 "obey"
special-display-regexps, but if someone wants to try it, here are some
things to consider:
- The default behavior for special-display-* is to reuse any window that
  already displays the buffer, so in order to make C-x 5 2 meaningful
  we'd clearly want to skip this part of the usual
  special-display-* behavior.
- Maybe C-x 5 2 should be more like "clone frame" instead, i.e. don't
  pay attention to special-display-* but instead try to reproduce the
  existing frame (including dedicatedness of the window it displays).
  This opens the question of what to do when the selected frame has
  several windows, of course.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10135 <at> debbugs.gnu.org
Subject: RE: bug#10135: 24.0.91;
	`special-display-regexps' is still not respected (again)
Date: Mon, 28 Nov 2011 08:24:28 -0800

> > Feel free to close this bug or (IMO better) keep it open, perhaps as
> > a wishlist item.
> 
> The fact that it's not new doesn't change the fact that you dislike
> this behavior, so it's not a reason to close the bug.

Thanks.

> > Since the buffer displayed matches `special-display-regexps',
> > a special-display frame should be used.
> 
> As you know I use a similar setup to yours so I have gone through
> similar thoughts.  I haven't actually tried to make C-x 5 2 "obey"
> special-display-regexps, but if someone wants to try it, here are some
> things to consider:
> - The default behavior for special-display-* is to reuse any 
>   window that already displays the buffer, so in order to make
>   C-x 5 2 meaningful we'd clearly want to skip this part of the
>   usual special-display-* behavior.

But the only window that already displays the buffer is the _same_ window, and
the purpose of C-x 5 2 is to open a new frame.  Seems like the meaning of
special-display would prescribe respecting `special-display-alist' whenever a
special-display buffer is shown in a new frame.  I guess I don't understand why
any special treatment of "already displayed" would override that.

> - Maybe C-x 5 2 should be more like "clone frame" instead, i.e. don't
>   pay attention to special-display-* but instead try to reproduce the
>   existing frame (including dedicatedness of the window it displays).
>   This opens the question of what to do when the selected frame has
>   several windows, of course.

I would think that the only consideration would be the special-display-ness of
the buffer to be displayed.  If it is special-display, and if a new frame is
being created for it, then I would think that that frame should respect
`special-display-alist'.  What am I missing?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10135 <at> debbugs.gnu.org, 'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Subject: Re: bug#10135: 24.0.91; `special-display-regexps' is still not
 respected (again)
Date: Tue, 07 Sep 2021 19:44:02 +0200

"Drew Adams" <drew.adams <at> oracle.com> writes:

> Feel free to close this bug or (IMO better) keep it open, perhaps as a wishlist
> item.
>
> Since the buffer displayed matches `special-display-regexps', a special-display
> frame should be used.  But you are correct that this bug is very old (at least
> as old as Emacs 20).

This is adjacent to bug#16767, I guess.  But `special-display-regexps'
is deprecated now, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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