* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
@ 2011-09-17 14:55 Drew Adams
2011-09-18 15:13 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-09-17 14:55 UTC (permalink / raw)
To: 9532
I do not have the time to debug this now. Martin and I spent a _lot_ of
time getting things to work still in Emacs 24, so that Emacs 23
(22,21,...) settings are still respected. He fixed several Emacs 24
bugs in this regard.
Now, things are broken again. He says that he doesn't yet understand
the new code, and I don't have time to devote to it now either (trying
to pare down my setup to a minimal test case etc.).
I can at least say that I have this as `special-display-regexps':
("[ ]?[*][^*]+[*]")
And both `*info*' and `*unsent mail to bug-gnu-emacs@gnu.org*', which
match that option value, are _not_ displayed as special-display
buffers.
I have non-nil `pop-up-frames', and I use a different set of frame
parameters for `special-display-frame-alist'. But neither of those
buffers appears in a separate frame with those frame parameters.
Instead, they each _replace_ the current buffer in the current frame.
What's more, when I hit `q' in Info the frame disappears altogether.
(That might be because of some of my code: I do want the Info frame to
disappear.) The bug here is that there is no separate Info frame, so
the frame that disappears is the one that should still have the
original buffer.
FYI, `*Buffer List*' does not have this problem. It correctly appears
in a separate frame.
Again, all of this is with my setup. But perhaps there is enough info
here that you can track down the bug. Hope so. The bug appears in the
2011-09-12 build - there is no such bug in the 2011-09-05 build.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-09-12 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt'
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-17 14:55 bug#9532: 24.0.50; `special-display-regexps' is no longer respected Drew Adams
@ 2011-09-18 15:13 ` Chong Yidong
2011-09-18 17:33 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-09-18 15:13 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
"Drew Adams" <drew.adams@oracle.com> writes:
> I can at least say that I have this as `special-display-regexps':
> ("[ ]?[*][^*]+[*]")
>
> And both `*info*' and `*unsent mail to bug-gnu-emacs@gnu.org*', which
> match that option value, are _not_ displayed as special-display
> buffers.
This can't be debugged without a more specific bug report.
emacs -q
M-: (setq special-display-regexps '("\\*M")) RET
M-x display-buffer RET *Messages* RET
seems to work fine for me.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-18 15:13 ` Chong Yidong
@ 2011-09-18 17:33 ` Drew Adams
2011-09-20 21:52 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-09-18 17:33 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 9532
> I have this as `special-display-regexps':
> ("[ ]?[*][^*]+[*]")
>
> And both `*info*' and `*unsent mail to bug-gnu-emacs@gnu.org*',
> which match that option value, are _not_ displayed as
> special-display buffers.
I see this difference from the previous week's build (and all previous builds
and releases): `same-window-regexps' and `same-window-buffer-names' are now nil.
In the past they were not.
I do not want the buffer names/patterns in question to be treated differently
wrt `special-display-regexps' - I want such buffers, which match that
special-display pattern, to be treated as, well, special-display. So I do not
want these names/patterns on `same-window-regexps' or
`same-window-buffer-names'. So in the past I jumped through a little hoop (see
`cond' below) to remove them from those vars.
But now apparently those variables are not even used (or perhaps not used in the
same way), so it no longer does any good to simply _remove_ a match for such
buffer names from these lists in order to restore its special-display-ness.
These names are apparently being matched somewhere else now (?), in spite of
`special-display-regexps', and I want to prevent such a match. I want to
prevent such buffers from using the same window. IOW, I want
`special-display-regexps' to be respected for such buffers too.
Previously (e.g. the build of 2001/9/05), `same-window-regexps' value in emacs
-Q was this (even though `C-h v' said its "original" value was nil, "original"
here apparently being something prior to emacs -Q!):
("\\*rsh-[^-]*\\*\\(\\|<[0-9]*>\\)" "\\*telnet-.*\\*\\(\\|<[0-9]+>\\)"
"^\\*rlogin-.*\\*\\(\\|<[0-9]+>\\)" "\\*info\\*\\(\\|<[0-9]+>\\)"
"\\*gud-.*\\*\\(\\|<[0-9]+>\\)" "\\`\\*Customiz.*\\*\\'")
Now the value in emacs -Q is nil. So these variables are apparently no longer
the culprits that are overriding/disrespecting `special-display-regexps'.
Previously it was enough to do this, to make *info* and *Customize* buffers
respect `special-display-regexps', letting them be special-display frames:
(cond ((> emacs-major-version 21)
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
(remove-hook 'same-window-regexps "\\`\\*Customiz.*\\*\\'"))
((< emacs-major-version 21)
(remove-hook 'same-window-buffer-names "*info*"))
(t
(remove-hook 'same-window-buffer-names "*info*")
(remove-hook 'same-window-regexps "\\`\\*Customiz.*\\*\\'")))
Now that has no effect. These vars remain nil, so they are apparently no longer
the places where the "same-window" override of `special-display-regexps' is
coming from. What hoops must we jump through now, to let such buffers respect
`special-display-regexps'?
Note too that previously I never had to remove `*unsent mail to
bug-gnu-emacs@gnu.org*' from these "same-window" vars: such a buffer always
respected `special-display-regexps' in the past.
I generally want Emacs to display a buffer in a separate frame, which is why I
use non-nil `pop-up-frames'. I generally want buffers that match
`special-display-regexps' to be popped up in a separate, special-display frame.
I do not want Emacs deciding that more and more buffers should be exceptions to
this customized behavior.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-18 17:33 ` Drew Adams
@ 2011-09-20 21:52 ` Drew Adams
2011-09-21 1:38 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-09-20 21:52 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 9532
It should have been quite clear from my last message what the regression is, but
since there has been no reply, let me repeat the essential.
emacs -Q
(setq special-display-frame-alist
'((background-color . "LightSteelBlue")))
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
(setq pop-up-frames t)
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
C-h i
Do that in Emacs 24, and do it in Emacs 23 (or 22 or ...).
In Emacs 24, buffer `*info*' is not displayed in its own, special-display frame.
Instead, it takes the place of the original buffer in that buffer's frame.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-20 21:52 ` Drew Adams
@ 2011-09-21 1:38 ` Stefan Monnier
2011-09-21 16:06 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-09-21 1:38 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
> It should have been quite clear from my last message what the
> regression is, but since there has been no reply, let me repeat
> the essential.
> emacs -Q
> (setq special-display-frame-alist
> '((background-color . "LightSteelBlue")))
> (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> (setq pop-up-frames t)
> (remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
I think the problem here is that display-buffer--special should not just
be in display-buffer-fallback-action but should take precedence over the
ACTION argument (it's largely equivalent to display-buffer-alist).
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 1:38 ` Stefan Monnier
@ 2011-09-21 16:06 ` Chong Yidong
2011-09-21 16:30 ` Drew Adams
2011-09-21 17:59 ` Stefan Monnier
0 siblings, 2 replies; 27+ messages in thread
From: Chong Yidong @ 2011-09-21 16:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9532
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I think the problem here is that display-buffer--special should not just
> be in display-buffer-fallback-action but should take precedence over the
> ACTION argument (it's largely equivalent to display-buffer-alist).
The problem with this is that if the "special" buffer is already
displayed in a window, that window is supposed to be used instead of
popping up a special window (at least, according to old behavior).
We could accomodate this by changing display-buffer--special to also
call display-buffer--maybe-same-window and display-buffer-reuse-window
for special-display-p buffers.
Then another problem arises: all direct switch-to-buffer calls will
trigger special display for special buffers, which is not consistent
with old behavior. The key difference here is that in Emacs 23 the
`info' command calls display-buffer (using same-window-regexps to force
it into the same window), whereas currently `info' uses switch-to-buffer
(with the intention of transitioning away from same-window-*).
OTOH, I don't see an easy way to handle all the backward compatibility
exceptions in this case. One possibility is to change `info' etc. back
to using same-window-regexps with display-buffer, which mostly kicks the
can down the road to a later release. Or maybe we should just require
use of display-buffer-alist for this case.
Any thoughts?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 16:06 ` Chong Yidong
@ 2011-09-21 16:30 ` Drew Adams
2011-09-21 17:01 ` Chong Yidong
2011-09-21 17:59 ` Stefan Monnier
1 sibling, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-09-21 16:30 UTC (permalink / raw)
To: 'Chong Yidong', 'Stefan Monnier'; +Cc: 9532
> > I think the problem here is that display-buffer--special
> > should not just be in display-buffer-fallback-action but
> > should take precedence over the ACTION argument (it's
> > largely equivalent to display-buffer-alist).
>
> The problem with this is that if the "special" buffer is already
> displayed in a window, that window is supposed to be used instead of
> popping up a special window (at least, according to old behavior).
Yes, of course. And it's not just "old behavior". It's (part of) the
definition of "special-display" buffer.
> We could accomodate this...
> Then another problem arises: all direct switch-to-buffer calls will
> trigger special display for special buffers, which is not consistent
> with old behavior.
Not sure I follow. Why is that not consistent with past behavior? Why would we
not always want special display for special-display buffers?
Can you give an example for Emacs 23 and explain how the behavior would be
different for Emacs 24?
> The key difference here is that in Emacs 23 the `info' command
> calls display-buffer (using same-window-regexps to force
> it into the same window),
force it or not, depending on the value of `same-window-regexps' ;-)
> whereas currently `info' uses switch-to-buffer
> (with the intention of transitioning away from same-window-*).
Emacs 24 needs to respect `same-window-*'. It needs to be compatible with past
Emacs behavior.
> OTOH, I don't see an easy way to handle all the backward
> compatibility exceptions in this case.
FWIW, Martin's code worked fine in this regard.
And please do not call these "exceptions". Backward compatibility is backward
compatibility. The various use cases that Emacs has always supported are not
"exceptions".
What sounds like "exceptions", to me (but I'm not sure because I'm not clear
about what you mean), are proposed changes like not always having
special-display buffers be displayed as such (see above - your "not consistent
with old behavior").
The new code needs to DTRT, supporting the same use cases supported in the past.
In particular, it needs to support special-display in the same ways.
It is OK to change how that support is implemented. It is not OK to remove that
support.
> One possibility is to change `info' etc. back to using
> same-window-regexps with display-buffer, which mostly kicks the
> can down the road to a later release. Or maybe we should just require
> use of display-buffer-alist for this case.
>
> Any thoughts?
Perhaps look to Martin's code for an answer? Even if you decide not to do
everything the same way he did it, perhaps for things like this his code can
help guide you. Dunno.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 16:30 ` Drew Adams
@ 2011-09-21 17:01 ` Chong Yidong
2011-09-21 17:11 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-09-21 17:01 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
"Drew Adams" <drew.adams@oracle.com> writes:
>> OTOH, I don't see an easy way to handle all the backward
>> compatibility exceptions in this case.
>
> FWIW, Martin's code worked fine in this regard.
> ...
> Perhaps look to Martin's code for an answer? Even if you decide not
> to do everything the same way he did it, perhaps for things like this
> his code can help guide you. Dunno.
I don't know why you seem to think that there is some great mystery
here. The issue is quite clear: how to handle the transition away from
same-window-regexps in commands like `info'.
The current code, AFAICT, also "works fine" if you change info back to
using pop-to-buffer + same-window-regexps.
I am coming to the conclusion that there is no good way to handle the
change "smoothly", in the sense of having an intermediate stage where
internal Emacs code (outside of window.el) transitions away from using
same-window-regexps. That is to say, until we are prepared to outright
change the behavior of commands like `info' wrt certain combinations of
same-window-* and special-window-* settings, we have to continue using
same-window-regexps in those source files.
Stefan, any thoughts?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 17:01 ` Chong Yidong
@ 2011-09-21 17:11 ` Drew Adams
2011-10-02 18:44 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-09-21 17:11 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 9532
> >> OTOH, I don't see an easy way to handle all the backward
> >> compatibility ... in this case.
> >
> > FWIW, Martin's code worked fine in this regard.
> > ...
> > Perhaps look to Martin's code for an answer? Even if you decide not
> > to do everything the same way he did it, perhaps for things
> > like this his code can help guide you. Dunno.
>
> I don't know why you seem to think that there is some great mystery
> here.
What gives you that impression? What mystery did I speak about? What makes you
think that I "seem to think" there is a mystery, great or small?
I am ignorant of the various implementations - that's the only "mystery" I'm
aware of: ignorance. I have been speaking only about what a user sees.
If my suggestion to maybe look at how Martin kept backward compatibility is not
helpful then please ignore it. All I know is the behavior I see: his code was,
AFAICT, backward compatible. The current code has at least this bug, so far.
> The issue is quite clear: how to handle the transition
> away from same-window-regexps in commands like `info'.
> The current code, AFAICT, also "works fine" if you change info back to
> using pop-to-buffer + same-window-regexps.
Great, then there is presumably no problem. Make it work fine. DTRT.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 17:11 ` Drew Adams
@ 2011-10-02 18:44 ` Drew Adams
2011-10-19 18:51 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-10-02 18:44 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 9532
Same problem with *Customiz...* buffers.
`special-display-regexps' is not respected: buffers that should be
special-display do not appear in a special-display frame. No frame is popped up
for them at all, even with non-nil `pop-up-frames'. They simply replace the
current buffer in its frame.
Would you please fix this bug?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-10-02 18:44 ` Drew Adams
@ 2011-10-19 18:51 ` Drew Adams
2011-10-31 15:24 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-10-19 18:51 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 9532
Good news, for me at least: This bug seems to be fixed in Emacs 24 pretest #1:
In GNU Emacs 24.0.90.1 (i386-mingw-nt5.1.2600)
of 2011-10-18 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags -I"C:/Program
Files (x86)/GnuWin32/include" -ID:/devel/emacs/libXpm-3.5.8/include
-ID:/devel/emacs/libXpm-3.5.8/src -ID:/devel/emacs/gnutls-2.10.5-x86/include
--ldflags -LD:/devel/emacs/gnutls-2.10.5-x86/lib'
(I had to remove my modified version of Martin's `pop-to-buffer-same-window',
and then it worked.)
Question: I'm still doing the following, which was needed in prior releases, but
it apparently has no effect now. I say that because `same-window-regexps' is in
fact nil, regardless of whether I do this.
(cond ((> emacs-major-version 21)
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
(remove-hook 'same-window-regexps "\\`\\*Customiz.*\\*\\'"))
((< emacs-major-version 21)
(remove-hook 'same-window-buffer-names "*info*"))
(t
(remove-hook 'same-window-buffer-names "*info*")
(remove-hook 'same-window-regexps "\\`\\*Customiz.*\\*\\'")))
(a) Can you confirm that it should have no effect?
(b) How does/should a user now control these things?
Is it the case, perhaps, that things are just as before wrt
`same-window-regexps', except that now its default value is nil instead of
pre-populated? Would it be appropriate/effective to use, say, `add-hook' to add
a pattern to it? (Yes, I know and agree that customizing it is no doubt
preferable, for individual users.) Thx.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-10-19 18:51 ` Drew Adams
@ 2011-10-31 15:24 ` Drew Adams
2011-11-05 21:17 ` Drew Adams
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-10-31 15:24 UTC (permalink / raw)
To: 'Chong Yidong', 'martin rudalics'; +Cc: 9532
> Good news, for me at least: This bug seems to be fixed in
> Emacs 24 pretest #1
Alas, no; I was mistaken. The bug is still there, in both the first and second
deliveries of pretest #1.
I have non-nil pop-up-frames.
I have special-display-regexps set to: ("[ ]?[*][^*]+[*]").
And yet, when I do M-x report-emacs-bug, instead of buffer *unsent mail to
bug-gnu-emacs@gnu.org* being popped up in its own, special-display frame, that
buffer _replaces_ the current buffer in the same (non-special-display) frame.
IOW, `special-display-regexps' is still being ignored.
The reason I mistakenly thought that the bug had been fixed is that I do _not_
see the problem for *info* buffers: they are correctly opened in special-display
frames.
I don't know why there is this difference, since both buffers match
`special-display-regexps'. Note that both `same-window-buffer-names' and
`same-window-regexps' are nil.
This bug has been dragging on for a very long time now. It was fixed
temporarily with Martin's code, but things were broken again when his code was
dropped.
Please, pretty please fix this bug as a priority, before the next pretest. Thx.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-10-31 15:24 ` Drew Adams
@ 2011-11-05 21:17 ` Drew Adams
2011-11-08 2:59 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-11-05 21:17 UTC (permalink / raw)
To: 'Chong Yidong', 'martin rudalics'; +Cc: 9532
ping.
> The bug is still there, in both the first and second
> deliveries of pretest #1.
>
> I have non-nil pop-up-frames.
> I have special-display-regexps set to: ("[ ]?[*][^*]+[*]").
>
> And yet, when I do M-x report-emacs-bug, instead of buffer
> *unsent mail to bug-gnu-emacs@gnu.org* being popped up in
> its own, special-display frame, that buffer _replaces_ the
> current buffer in the same (non-special-display) frame.
>
> IOW, `special-display-regexps' is still being ignored.
>
> The reason I mistakenly thought that the bug had been fixed
> is that I do _not_ see the problem for *info* buffers: they
> are correctly opened in special-display frames.
>
> I don't know why there is this difference, since both buffers
> match `special-display-regexps'. Note that both
> `same-window-buffer-names' and `same-window-regexps' are nil.
>
> This bug has been dragging on for a very long time now. It
> was fixed temporarily with Martin's code, but things were
> broken again when his code was dropped.
>
> Please, pretty please fix this bug as a priority, before the
> next pretest. Thx.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-05 21:17 ` Drew Adams
@ 2011-11-08 2:59 ` Stefan Monnier
2011-11-08 5:39 ` Drew Adams
2011-11-08 17:37 ` Drew Adams
0 siblings, 2 replies; 27+ messages in thread
From: Stefan Monnier @ 2011-11-08 2:59 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
I've installed a change which should hopefully fix the problem (at
least it fixes the cases I bumped into). Please confirm that it's
fixed for you as well.
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-08 2:59 ` Stefan Monnier
@ 2011-11-08 5:39 ` Drew Adams
2011-11-08 6:25 ` Eli Zaretskii
2011-11-08 6:47 ` Drew Adams
2011-11-08 17:37 ` Drew Adams
1 sibling, 2 replies; 27+ messages in thread
From: Drew Adams @ 2011-11-08 5:39 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 9532
> I've installed a change which should hopefully fix the problem (at
> least it fixes the cases I bumped into). Please confirm that it's
> fixed for you as well.
That would be great, and I will be grateful.
How do I access the change? Is it Lisp somewhere that I can try with the last
pretest binary, or do I just need to wait for the next binary?
Thx.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-08 5:39 ` Drew Adams
@ 2011-11-08 6:25 ` Eli Zaretskii
2011-11-08 6:47 ` Drew Adams
1 sibling, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-11-08 6:25 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 7 Nov 2011 21:39:38 -0800
> Cc: 9532@debbugs.gnu.org
>
> > I've installed a change which should hopefully fix the problem (at
> > least it fixes the cases I bumped into). Please confirm that it's
> > fixed for you as well.
>
> That would be great, and I will be grateful.
>
> How do I access the change? Is it Lisp somewhere that I can try with the last
> pretest binary, or do I just need to wait for the next binary?
You can see the changes here:
http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/106319
and the updated window.el here:
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/lisp/window.el
However, window.el is preloaded, so if you don't build your own Emacs,
you can try the changes temporarily by manually loading the updated
window.el, like this:
emacs -Q
M-x load-file RET /path/to/window.el RET
Then do whatever it takes to reproduce past problems.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-08 5:39 ` Drew Adams
2011-11-08 6:25 ` Eli Zaretskii
@ 2011-11-08 6:47 ` Drew Adams
2011-11-08 13:26 ` Stefan Monnier
1 sibling, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-11-08 6:47 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 9532
OK, I downloaded the latest (non-pretest) Windows binary that Christophe just
published (dated 11/07). I started Emacs with my setup, as usual, and ran into
a straightforward problem at startup - one I can easily take care of, but I
would like to know first whether I should (confirmation).
I redefine `switch-to-buffer' in my code so that it autofits the frame to the
buffer content. My redefinition (so far) keeps the original (Emacs 20...23)
signature, however: (switch-to-buffer BUFFER &optional NORECORD)
The latest Emacs binary has a new version of `find-file' that calls the new
`switch-to-buffer', passing 3 args. Obviously that barfs with my redef.
This is the backtrace (from byte-compiled code, but it seems clear enough) at
startup:
---------8<----------------
Debugger entered--Lisp error: (wrong-number-of-arguments #[(buffer &optional
norecord) "..." [buffer orig-buf norecord autofit-frames-flag get-buffer-create
other-buffer window-dedicated-p selected-window switch-to-buffer-other-window
old-switch-to-buffer one-window-p t fit-frame] 3 "Select buffer BUFFER in
current window, unless the window is dedicated.
If current window is dedicated (`window-dedicated-p'), then another window
is used.
BUFFER may be a buffer, a string (a buffer name), or nil. If BUFFER
is a string that does not identify an existing buffer, then a new
buffer with that name is created. If BUFFER is nil, then function
`other-buffer' is used to choose a buffer.
Optional second arg NORECORD non-nil means do not put BUFFER at the
front of the list of recently selected buffers.
The buffer switched to is returned.
*WARNING*: This is NOT the way to work on another buffer temporarily
within a Lisp program! Use `set-buffer' instead, to avoid messing
with correspondences between windows and buffers.
Resize frame to fit sole window if `autofit-frames-flag'
(unless BUFFER is already the `current-buffer')."
(list (read-buffer "Switch to buffer: " (if (fboundp (quote another-buffer))
(another-buffer nil t) (other-buffer (current-buffer)))))] 3)
switch-to-buffer(#<buffer drews-lisp-20> nil force-same-window)
find-file("c:/drews-lisp-20")
command-line-1(("C:\\drews-lisp-20"))
command-line()
normal-top-level()
---------8<----------------
This is how I start Emacs (which explains the `find-file' call):
C:\emacs\...\bin\runemacs.exe --debug-init "C:\drews-lisp-20"
Is this really the way things will be? If so, I will add an Emacs 24+ version
of my redefinition of `switch-to-buffer'.
But it's worth asking first, since until now Emacs 24 has seemed to work OK
without that, and the development of 24 seems to be volatile still. It's hard
to know what is here to stay and what is tentative, what is a feature and what
is a bug. Even the latest pretest, from a week ago (10/31) has a single-arg
call to `switch-to-buffer' in `find-file'.
---
BTW, I see that you keep `pop-up-windows', and use it in
`switch-to-buffer-other-window', but you eliminated the parallel construction,
using `pop-up-frames', for `switch-to-buffer-other-frame'. Not very elegant, is
it? What used to be simple and symmetric is now quite kludgy, no? Why is
`pop-up-windows' still blessed but `pop-up-frames' verboten?
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-08 6:47 ` Drew Adams
@ 2011-11-08 13:26 ` Stefan Monnier
0 siblings, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2011-11-08 13:26 UTC (permalink / raw)
To: Drew Adams; +Cc: 9532
> I redefine `switch-to-buffer' in my code so that it autofits the frame to the
> buffer content. My redefinition (so far) keeps the original (Emacs 20...23)
> signature, however: (switch-to-buffer BUFFER &optional NORECORD)
If you don't like such breakage, better use an around-advice than
a redefinition (it won't protect you from all such breakages, but it'll help).
> Is this really the way things will be?
Yes.
> it? What used to be simple and symmetric is now quite kludgy, no? Why is
> `pop-up-windows' still blessed but `pop-up-frames' verboten?
It's not blessed and neither is the other verboten. Both are obsolete.
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-11-08 2:59 ` Stefan Monnier
2011-11-08 5:39 ` Drew Adams
@ 2011-11-08 17:37 ` Drew Adams
2011-11-08 19:28 ` Stefan Monnier
1 sibling, 1 reply; 27+ messages in thread
From: Drew Adams @ 2011-11-08 17:37 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 9532
> I've installed a change which should hopefully fix the problem (at
> least it fixes the cases I bumped into). Please confirm that it's
> fixed for you as well.
Yes, it seems to be fixed. At least when I use `M-x report-emacs-bug' buffer
*unsent mail to bug-gnu-emacs@gnu.org* is now displayed in a special-display
frame, as it should be. Thx.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 16:06 ` Chong Yidong
2011-09-21 16:30 ` Drew Adams
@ 2011-09-21 17:59 ` Stefan Monnier
2011-09-21 18:30 ` Chong Yidong
1 sibling, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-09-21 17:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: 9532
>> I think the problem here is that display-buffer--special should not just
>> be in display-buffer-fallback-action but should take precedence over the
>> ACTION argument (it's largely equivalent to display-buffer-alist).
> The problem with this is that if the "special" buffer is already
> displayed in a window, that window is supposed to be used instead of
> popping up a special window (at least, according to old behavior).
> We could accomodate this by changing display-buffer--special to also
> call display-buffer--maybe-same-window and display-buffer-reuse-window
> for special-display-p buffers.
Yes, that's what I'm suggesting.
> Then another problem arises: all direct switch-to-buffer calls will
> trigger special display for special buffers, which is not consistent
> with old behavior. The key difference here is that in Emacs 23 the
> `info' command calls display-buffer (using same-window-regexps to force
> it into the same window), whereas currently `info' uses switch-to-buffer
> (with the intention of transitioning away from same-window-*).
At least both Drew and I would consider it a bug fix if
special-display-* applies to *info*, so I'm not sure such a change is
a problem.
> OTOH, I don't see an easy way to handle all the backward compatibility
> exceptions in this case.
We'd have to distinguish between a switch-to-buffer which disregard
special-display-* (the one that used to use same-window-* instead) and
another switch-to-buffer which doesn't.
Let's first try without such a distinction, i.e. with a switch-to-buffer
which obeys special-display-*. This is similar to reducing the priority
of same-window-* from "above special-display-*" to below it.
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 17:59 ` Stefan Monnier
@ 2011-09-21 18:30 ` Chong Yidong
2011-09-22 1:16 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-09-21 18:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9532
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Then another problem arises: all direct switch-to-buffer calls will
>> trigger special display for special buffers, which is not consistent
>> with old behavior. The key difference here is that in Emacs 23 the
>> `info' command calls display-buffer (using same-window-regexps to force
>> it into the same window), whereas currently `info' uses switch-to-buffer
>> (with the intention of transitioning away from same-window-*).
>
> At least both Drew and I would consider it a bug fix if
> special-display-* applies to *info*, so I'm not sure such a change is
> a problem.
I think you misunderstand. Consider this:
M-: (setq special-display-regexps '("foo")) RET
M-: (get-buffer-create "foo") RET
M-x switch-to-buffer RET foo RET
In Emacs 23, this switches to the "foo" buffer in the selected window.
With the proposed change, the direct switch-to-buffer call opens it in a
special window (just like the switch-to-buffer call in `info').
So we would be swapping on backward incompatibility for another.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-21 18:30 ` Chong Yidong
@ 2011-09-22 1:16 ` Stefan Monnier
2011-09-22 3:21 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-09-22 1:16 UTC (permalink / raw)
To: Chong Yidong; +Cc: 9532
>>> Then another problem arises: all direct switch-to-buffer calls will
>>> trigger special display for special buffers, which is not consistent
>>> with old behavior. The key difference here is that in Emacs 23 the
>>> `info' command calls display-buffer (using same-window-regexps to force
>>> it into the same window), whereas currently `info' uses switch-to-buffer
>>> (with the intention of transitioning away from same-window-*).
>>
>> At least both Drew and I would consider it a bug fix if
>> special-display-* applies to *info*, so I'm not sure such a change is
>> a problem.
> I think you misunderstand. Consider this:
> M-: (setq special-display-regexps '("foo")) RET
> M-: (get-buffer-create "foo") RET
> M-x switch-to-buffer RET foo RET
> In Emacs 23, this switches to the "foo" buffer in the selected window.
> With the proposed change, the direct switch-to-buffer call opens it in a
> special window (just like the switch-to-buffer call in `info').
> So we would be swapping on backward incompatibility for another.
M-x switch-to-buffer should never call display-buffer.
Only non-interactive calls should do that.
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-22 1:16 ` Stefan Monnier
@ 2011-09-22 3:21 ` Chong Yidong
2011-09-22 3:37 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-09-22 3:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9532
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> M-: (setq special-display-regexps '("foo")) RET
>> M-: (get-buffer-create "foo") RET
>> M-x switch-to-buffer RET foo RET
>>
>> In Emacs 23, this switches to the "foo" buffer in the selected window.
>> With the proposed change, the direct switch-to-buffer call opens it in a
>> special window (just like the switch-to-buffer call in `info').
>
>> So we would be swapping on backward incompatibility for another.
>
> M-x switch-to-buffer should never call display-buffer.
> Only non-interactive calls should do that.
So, you agree to the incompatibility for the non-interactive case? That
is to say, a non-interactive call to switch-to-buffer (and ONLY a
non-interactive call) will now trigger special display. Previously, in
Emacs 23, it would use the selected window.
If you agree, I'd implement the behavior by adding a new value for
s-t-b's FORCE-SAME-WINDOW argument, `try', which would be the default
for interactive calls. That would mean to first try displaying in the
current selected window directly instead of going through p-t-b.
It would be quite unfortunate to have interactive and non-interactive
calls to s-t-b do slightly different things; but maybe it can't be
helped.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-22 3:21 ` Chong Yidong
@ 2011-09-22 3:37 ` Chong Yidong
2011-09-22 12:29 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-09-22 3:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9532
Chong Yidong <cyd@stupidchicken.com> writes:
> So, you agree to the incompatibility for the non-interactive case? That
> is to say, a non-interactive call to switch-to-buffer (and ONLY a
> non-interactive call) will now trigger special display. Previously, in
> Emacs 23, it would use the selected window.
>
> If you agree, I'd implement the behavior by adding a new value for
> s-t-b's FORCE-SAME-WINDOW argument, `try', which would be the default
> for interactive calls. That would mean to first try displaying in the
> current selected window directly instead of going through p-t-b.
It just occurred to me that it would be safer to leave switch-to-buffer
unchanged, and instead reinstate pop-to-buffer-same-window specifically
for the callers in question, i.e. the callers who used the
same-window-regexps/display-buffer trick. pop-to-buffer-same-window
would raise a special window for special buffers, instead of using the
selected window; s-t-b would use the selected window, as in Emacs 23.
There are only about 9 uses of the same-window-regexps + display-buffer
trick which would be changed to use pop-to-buffer-same-window, compared
to hundreds of users of switch-to-buffer. So unintended consequences
would be much less likely.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-22 3:37 ` Chong Yidong
@ 2011-09-22 12:29 ` Stefan Monnier
2011-09-22 16:15 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-09-22 12:29 UTC (permalink / raw)
To: Chong Yidong; +Cc: 9532
>> So, you agree to the incompatibility for the non-interactive case? That
>> is to say, a non-interactive call to switch-to-buffer (and ONLY a
>> non-interactive call) will now trigger special display. Previously, in
>> Emacs 23, it would use the selected window.
Yes.
> It just occurred to me that it would be safer to leave switch-to-buffer
> unchanged, and instead reinstate pop-to-buffer-same-window specifically
> for the callers in question, i.e. the callers who used the
> same-window-regexps/display-buffer trick. pop-to-buffer-same-window
> would raise a special window for special buffers, instead of using the
> selected window; s-t-b would use the selected window, as in Emacs 23.
It would also be a change in behavior since same-window-* took
precedence over special-display-*. But it would be a good change: users
like Drew (and myself) had to set same-window-* to nil to let
special-display-* do its job.
So I agree those callers who used same-window-* should be changed to
obey special-display-*, as for whether callers of switch-to-buffer
should also obey special-display-* (and/or display-buffer-alist) I don't
know for sure.
Basically w.r.t "same-window behavior" we have 3 options:
1- never touch another window.
2- obey special-display-* and display-buffer-alist.
3- use the selected window if at all possible, but fallback to
pop-to-buffer instead of signalling an error.
The third is the current behavior of interactive uses of switch-to-buffer.
The second is the behavior we want for former users of same-window-*.
The third is the behavior that corresponds to Emacs-23's switch-to-buffer.
We could shoehorn this into the `force-same-window' argument of
switch-to-buffer, but I'm not convinced that the difference between
options 2 and 3 is worth the trouble.
Stefan
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#9532: 24.0.50; `special-display-regexps' is no longer respected
2011-09-22 12:29 ` Stefan Monnier
@ 2011-09-22 16:15 ` Chong Yidong
0 siblings, 0 replies; 27+ messages in thread
From: Chong Yidong @ 2011-09-22 16:15 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9532
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> So I agree those callers who used same-window-* should be changed to
> obey special-display-*, as for whether callers of switch-to-buffer
> should also obey special-display-* (and/or display-buffer-alist) I don't
> know for sure.
I've brought back pop-to-buffer-same-windows for those callers.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-11-08 19:28 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-17 14:55 bug#9532: 24.0.50; `special-display-regexps' is no longer respected Drew Adams
2011-09-18 15:13 ` Chong Yidong
2011-09-18 17:33 ` Drew Adams
2011-09-20 21:52 ` Drew Adams
2011-09-21 1:38 ` Stefan Monnier
2011-09-21 16:06 ` Chong Yidong
2011-09-21 16:30 ` Drew Adams
2011-09-21 17:01 ` Chong Yidong
2011-09-21 17:11 ` Drew Adams
2011-10-02 18:44 ` Drew Adams
2011-10-19 18:51 ` Drew Adams
2011-10-31 15:24 ` Drew Adams
2011-11-05 21:17 ` Drew Adams
2011-11-08 2:59 ` Stefan Monnier
2011-11-08 5:39 ` Drew Adams
2011-11-08 6:25 ` Eli Zaretskii
2011-11-08 6:47 ` Drew Adams
2011-11-08 13:26 ` Stefan Monnier
2011-11-08 17:37 ` Drew Adams
2011-11-08 19:28 ` Stefan Monnier
2011-09-21 17:59 ` Stefan Monnier
2011-09-21 18:30 ` Chong Yidong
2011-09-22 1:16 ` Stefan Monnier
2011-09-22 3:21 ` Chong Yidong
2011-09-22 3:37 ` Chong Yidong
2011-09-22 12:29 ` Stefan Monnier
2011-09-22 16:15 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.