all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Chong Yidong'" <cyd@stupidchicken.com>
Cc: 9532@debbugs.gnu.org
Subject: bug#9532: 24.0.50; `special-display-regexps' is no longer respected
Date: Sun, 18 Sep 2011 10:33:18 -0700	[thread overview]
Message-ID: <1D79C6CD14EE4C76B74C446E04B9CA65@us.oracle.com> (raw)
In-Reply-To: <87y5xlg9xq.fsf@stupidchicken.com>

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






  reply	other threads:[~2011-09-18 17:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1D79C6CD14EE4C76B74C446E04B9CA65@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=9532@debbugs.gnu.org \
    --cc=cyd@stupidchicken.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.