bug#9532: 24.0.50; `special-display-regexps' is no longer respected

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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'
 

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

"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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

> 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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

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?

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> > 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

"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?

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> >> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

>> 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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

>>> 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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

>> 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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Chong Yidong]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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?

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Eli Zaretskii]

> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

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?

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

> 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

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Drew Adams]

> 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.

bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier]

> 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.

Great, thanks,


        Stefan