GNU bug report logs -
#10122
24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Wed, 23 Nov 2011 23:36:02 UTC
Severity: minor
Found in version 24.0.91
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10122 in the body.
You can then email your comments to 10122 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Wed, 23 Nov 2011 23:36:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 23 Nov 2011 23:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is with my setup. I don't have a recipe from emacs -Q.
Among other things, buffers that have names `*...*' are special-display,
and I have non-nil `pop-up-frames'.
In a small elisp file buffer, I make a couple of contiguous
definitions invisible, using (put-text-property (region-beginning)
(region-end) 'invisible t).
Then I do `C-x C-v' and accept the default, which is the same file.
I enter `no' to the question about saving modified buffer, and
`yes' to the question about killing and replacing without saving.
Buffer *Pp Eval Ouput* pops up (in a separate frame), with value `nil'
displayed. Just after it pops up, buffer *Backtrace* pops up, with this:
Debugger entered--Lisp error: (error "Buffer name `throw-test.el' is in use")
rename-buffer("throw-test.el")
byte-code("..." [obuf ofile buffer-file-name onum buffer-file-number
otrue lock-buffer rename-buffer buffer-file-truename
odir dired-directory oname] 2)
signal(error ("Cannot switch buffers in a dedicated window"))
error("Cannot switch buffers in a dedicated window")
old-switch-to-buffer(#<buffer throw-test.el> nil force-same-window)
switch-to-buffer(#<buffer throw-test.el> nil force-same-window)
find-file("c:/drews-lisp-20/throw-test.el" t)
find-alternate-file("c:/drews-lisp-20/throw-test.el" t)
call-interactively(find-alternate-file nil nil)
Also, buffer `**lose**' has taken the place of the original elisp file
buffer in the same (undedicated) window. The content of buffer `**lose**'
is the elisp buffer content, with the hidden sexps still invisible.
The original lisp buffer still exists, but is not displayed.
If I display it I see the whole buffer - nothing is invisible.
It seems like maybe:
(a) something causes an evaluation, which shows *Pp Eval Output*
(even for the small value `nil' - no idea why)
(b) perhaps *Pp Eval Output* becomes the current buffer (?)
(c) since it is in a dedicated window, Emacs barfs, saying it is
unable to show the orginal file in that same window.
I do not see the same problem if there is no invisible text. Buffer
*Messages* shows nothing particular. I have no idea what evaluation
led to *Pp Eval Output* being shown, nor why it would be shown for as
simple a value as nil.
Note that the elisp file buffer was NEVER shown in a dedicated window.
There were NO dedicated windows when I used `C-x C-v'. The first
dedicated window shown was *Pp Eval Output*, and the second was
*Backtrace*. There were no other dedicated windows.
This is the (re)definition of `switch-to-buffer' that I use:
(defun switch-to-buffer (buffer-or-name &optional norecord force-same-window)
"..."
(interactive
(list (read-buffer-to-switch "Switch to buffer: ")
nil 'force-same-window))
(let ((orig-buf (current-buffer))
(switch-buf (old-switch-to-buffer
buffer-or-name norecord force-same-window)))
(when (and (one-window-p t)
(not (eq switch-buf orig-buf)) ; Don't resize if same buffer.
autofit-frames-flag
(fit-frame)))
switch-buf))
where `old-switch-to-buffer' was defined this way:
(fset 'old-switch-to-buffer (symbol-function 'switch-to-buffer))
This is 100% reproducible, but as I say, this is with my setup.
Perhaps you have enough info to figure the problem out?
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'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Thu, 24 Nov 2011 00:28:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 10122 <at> debbugs.gnu.org (full text, mbox):
Some more info, which should help:
I typed this into the file buffer:
(put-text-property (region-beginning) (region-end) 'invisible t)
I selected that sexp, leaving point just after it, then hit `C-x C-e'.
Then I used `C-x C-v' and got the same problem as before.
Before, I had evaled the sexp using `M-:', which I bind to a command that uses
`pp-eval-expression'. It apparently does not matter how I eval it, as long as
the evaluation produces a buffer *Pp Eval Output* (which is dedicated, because
of my value of `special-display-regexps').
Even if I move point around a bit in the buffer, to be sure that it (and not,
say, buffer *Pp Eval Output*) is the current buffer, the problem arises.
However, if, after making the region invisible, I kill buffer *Pp Eval Output*
(doesn't matter whether using Buffer Menu or `C-x b'), and I then hit `C-x C-v',
there is no problem.
It seems that it is the mere presence of the *Pp...* buffer that causes the
problem. Note that *Pp...* was never displayed by evaluating the sexp, since
the value (`nil') was so simple (no need to show it in a separate buffer). But
the buffer remained in existence, even though it was not displayed.
My guess is that somehow Emacs is thinking that that (dedicated) buffer is the
one being replaced - even though it is definitely not the `current-buffer'.
Sounds like more fallout from the display-buffer makeover?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Thu, 24 Nov 2011 00:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 10122 <at> debbugs.gnu.org (full text, mbox):
Playing around a little more, I see that when you use `C-x C-v', even when there
is no problem, it temporarily switches to another existing buffer in the same
window. That would seem to be the cause of the problem: If that buffer switched
to is, like *Pp Eval Output* in my case, dedicated, then suddently it throws a
monkey wrench in the system.
The dedicated nature of that temporarily substituted buffer should presumably
not enter into the picture at all (if we in fact need to temporarily substitute
some other buffer in that window).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Mon, 17 Sep 2012 00:25:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 10122 <at> debbugs.gnu.org (full text, mbox):
ping
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Thu, 28 Apr 2016 11:44:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 10122 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> Playing around a little more, I see that when you use `C-x C-v', even when there
> is no problem, it temporarily switches to another existing buffer in the same
> window. That would seem to be the cause of the problem: If that buffer switched
> to is, like *Pp Eval Output* in my case, dedicated, then suddently it throws a
> monkey wrench in the system.
>
> The dedicated nature of that temporarily substituted buffer should presumably
> not enter into the picture at all (if we in fact need to temporarily substitute
> some other buffer in that window).
There is no clear recipe, starting from -Q, to reproduce this problem.
Are you still seeing it? If so, can you create a recipe?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 28 Apr 2016 11:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Thu, 28 Apr 2016 14:07:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 10122 <at> debbugs.gnu.org (full text, mbox):
> There is no clear recipe, starting from -Q, to reproduce this problem.
> Are you still seeing it? If so, can you create a recipe?
I do not have a recipe from emacs -Q, as I said at the outset.
But I pointed out what the code does.
You can see that if a dedicated frame is involved then the
code does not handle things correctly (at all).
The problem has not been fixed.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 01 Oct 2019 15:53:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Mon, 31 Jan 2022 16:39:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 10122 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> This is 100% reproducible, but as I say, this is with my setup.
> Perhaps you have enough info to figure the problem out?
This was ten years ago, and nobody had, and you couldn't come up with a
case to reproduce it, so I doubt there's going to be any progress here,
and I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
10122 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 31 Jan 2022 16:39:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10122
; Package
emacs
.
(Mon, 31 Jan 2022 16:51:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 10122 <at> debbugs.gnu.org (full text, mbox):
> > This is 100% reproducible, but as I say, this is with my setup.
> > Perhaps you have enough info to figure the problem out?
>
> This was ten years ago, and nobody had, and you couldn't come up with a
> case to reproduce it, so I doubt there's going to be any progress here,
> and I'm closing this bug report.
I supplied a recipe and lots of additional info.
And as I said:
You can see that if a dedicated frame is involved then
the code does not handle things correctly (at all).
The problem has not been fixed.
Did you even take a look at all? Or did you
just demand a complete recipe from emacs -Q
and then close the ticket?
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 01 Mar 2022 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 123 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.