bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

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'
 

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

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?

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

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

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

ping

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@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

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

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

bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@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#10122: [External] : Re: bug#10122: 24.0.91; C-x C-v, invisible text: "Cannot switch...dedicated window"

[Drew Adams]

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