quit-window is broken

quit-window is broken

[Sam Steingold]

A recent change broke quit-window:
I have it bound to f9, and when I hit f9 I now get this:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
   get-buffer(nil)
   switch-to-buffer(nil)
   quit-window(nil)
   call-interactively(quit-window nil nil)

Re: quit-window is broken

[martin rudalics]

 > A recent change broke quit-window:
 > I have it bound to f9, and when I hit f9 I now get this:
 >
 > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >   get-buffer(nil)
 >   switch-to-buffer(nil)
 >   quit-window(nil)
 >   call-interactively(quit-window nil nil)

I changed this because it didn't do anything when you had two windows on
a frame, one of them was dedicated, and you wanted to delete that
window.  Later Juanma dedected that I had changed its semantics and I
rewrote it once more.

Does it still happen with today's sources?  If so, please give me a
precise recipe so I can reproduce it.

Thanks, martin.

Re: quit-window is broken

[Sam Steingold]

martin rudalics wrote:
>  > A recent change broke quit-window:
>  > I have it bound to f9, and when I hit f9 I now get this:
>  >
>  > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>  >   get-buffer(nil)
>  >   switch-to-buffer(nil)
>  >   quit-window(nil)
>  >   call-interactively(quit-window nil nil)
> 
> I changed this because it didn't do anything when you had two windows on
> a frame, one of them was dedicated, and you wanted to delete that
> window.  Later Juanma dedected that I had changed its semantics and I
> rewrote it once more.
> 
> Does it still happen with today's sources?  If so, please give me a
> precise recipe so I can reproduce it.

it does happen to me with the current cvs head - always, whether I have 10 or 2 
or 1 windows in the frame.
alas, this does not happen with "emacs -q", so I guess I will have to 
investigate further.

Re: quit-window is broken

[martin rudalics]

 >>  > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >>  >   get-buffer(nil)
 >>  >   switch-to-buffer(nil)
 >>  >   quit-window(nil)
 >>  >   call-interactively(quit-window nil nil)
[...]
 > it does happen to me with the current cvs head - always, whether I have
 > 10 or 2 or 1 windows in the frame.
 > alas, this does not happen with "emacs -q", so I guess I will have to
 > investigate further.

(switch-to-buffer nil) should not fail the way it does in your backtrace.

martin

Re: quit-window is broken

[Sam Steingold]

martin rudalics wrote:
>  >>  > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>  >>  >   get-buffer(nil)
>  >>  >   switch-to-buffer(nil)
>  >>  >   quit-window(nil)
>  >>  >   call-interactively(quit-window nil nil)
> [...]
>  > it does happen to me with the current cvs head - always, whether I have
>  > 10 or 2 or 1 windows in the frame.
>  > alas, this does not happen with "emacs -q", so I guess I will have to
>  > investigate further.
> 
> (switch-to-buffer nil) should not fail the way it does in your backtrace.

yes, it turned out that the problem was with my advice to switch-to-buffer not 
to create new buffers by default.
I wish there were an option for that.

Re: quit-window is broken

[martin rudalics]

 > yes, it turned out that the problem was with my advice to
 > switch-to-buffer not to create new buffers by default.
 > I wish there were an option for that.

But `switch-to-buffer' doesn't create a new buffer by default.  It
switches to the buffer returned by `other-buffer' instead.

If it helps we can always hardcode `other-buffer' in the call in
`quit-window'.  When `pop-to-buffer' is rewritten we might have to do
that anyway.  Then the semantics of `switch-to-buffer' changes too ...

martin

Re: quit-window is broken

[Sam Steingold]

martin rudalics wrote:
>  > yes, it turned out that the problem was with my advice to
>  > switch-to-buffer not to create new buffers by default.
>  > I wish there were an option for that.
> 
> But `switch-to-buffer' doesn't create a new buffer by default.  It
> switches to the buffer returned by `other-buffer' instead.

it is called with the nil argument which was not handled properly by the advice.

> If it helps we can always hardcode `other-buffer' in the call in
> `quit-window'.  When `pop-to-buffer' is rewritten we might have to do
> that anyway.  Then the semantics of `switch-to-buffer' changes too ...

it would help if there were a user option switch-to-buffer-create-new-buffer 
with values t (like it does not), nil (signal an error) and 'ask (ask for a 
confirmation).

Re: quit-window is broken

[Stefan Monnier]

> it would help if there were a user option switch-to-buffer-create-new-buffer
> with values t (like it does not), nil (signal an error) and 'ask (ask for
> a confirmation).

I'd rather have it use the same new behavior as C-x C-f: if you type in
a non-existing buffer name, the completion requests confirmation.
Any objection to the patch below?


        Stefan


=== modified file 'lisp/files.el'
--- lisp/files.el	2008-11-15 03:29:10 +0000
+++ lisp/files.el	2008-11-17 21:58:51 +0000
@@ -1111,7 +1111,7 @@
   (let ((rbts-completion-table (internal-complete-buffer-except)))
     (minibuffer-with-setup-hook
         (lambda () (setq minibuffer-completion-table rbts-completion-table))
-      (read-buffer prompt (other-buffer (current-buffer))))))
+      (read-buffer prompt (other-buffer (current-buffer)) 'confirm-only))))
 
 (defun switch-to-buffer-other-window (buffer &optional norecord)
   "Select buffer BUFFER in another window.

Re: quit-window is broken

[martin rudalics]

 >> it would help if there were a user option switch-to-buffer-create-new-buffer
 >> with values t (like it does not), nil (signal an error) and 'ask (ask for
 >> a confirmation).
 >
 > I'd rather have it use the same new behavior as C-x C-f: if you type in
 > a non-existing buffer name, the completion requests confirmation.

C-x C-f is guided by an option - `find-file-confirm-nonexistent-file'.

BTW, we still have that

          ;; FIXME: This behavior is carried over from the previous C version
          ;; of pop-to-buffer, but really we should use just
          ;; `get-buffer' here.

issue in `pop-to-buffer'.

martin

Re: quit-window is broken

[Stefan Monnier]

>>> it would help if there were a user option switch-to-buffer-create-new-buffer
>>> with values t (like it does not), nil (signal an error) and 'ask (ask for
>>> a confirmation).
>> 
>> I'd rather have it use the same new behavior as C-x C-f: if you type in
>> a non-existing buffer name, the completion requests confirmation.

> C-x C-f is guided by an option - `find-file-confirm-nonexistent-file'.

Right.  I think this customization variable is an instance of "Emacs at
its worst", so I'd be happy to throw it away.  But we could also just
rename this variable and reuse it in read-buffer-to-switch.

> BTW, we still have that
>          ;; FIXME: This behavior is carried over from the previous C version
>          ;; of pop-to-buffer, but really we should use just
>          ;; `get-buffer' here.
> issue in `pop-to-buffer'.

AFAIK, this shouldn't affect the user because pop-to-buffer is not an
interactive function.


        Stefan


PS: Or we could also add a gzillion foo-confirm-nonexistent-bar
variables for all the places where such a confirmation feature would
come in handy and some user gets annoyed because she occasionally needs
to press RET twice rather than once.

RE: quit-window is broken

[Drew Adams]

> > C-x C-f is guided by an option - 
> `find-file-confirm-nonexistent-file'.
> 
> Right.  I think this customization variable is an instance of 
> "Emacs at its worst", so I'd be happy to throw it away.

I disagree. Emacs development at its worst would be to change the behavior of
basic things such as `C-x C-f' from lax completion to "confirmed" completion
without providing users an option to get back the (superior, IMO) original
behavior.

It's OK to decide, after discussion, that the completion behavior for some new
function should be confirmed, not lax or strict. And it's OK to decide, for some
existing function, that confirmed should be offered as an alternative to the
traditional behavior (whether lax or strict).

For a given function, it can happen that there is no need to allow users a
choice of completion behaviors - that is probably usually the case. But that is
not the case when the behavior is to be changed for a long-existing command,
such as `find-file'. In such cases, please keep the traditional behavior as the
default behavior, and let users decide. Or change the default if that's better,
but give users the choice.

> PS: Or we could also add a gzillion foo-confirm-nonexistent-bar
> variables for all the places where such a confirmation feature would
> come in handy and some user gets annoyed because she 
> occasionally needs to press RET twice rather than once.

Please don't exaggerate. In general, Emacs designers can just pick the most
appropriate confirmation behavior for a new function and be done with it - no
need to let users choose; no option needed.

But that might not apply to a few new functions where there would be some value
in giving users a choice (I have none in mind - perhaps there are none). And it
generally does not apply to existing functions that affect traditional behavior.
Again, "generally" - such cases should be examined case by case.

Re: quit-window is broken

[Stefan Monnier]

>> `find-file-confirm-nonexistent-file'.
>> Right.  I think this customization variable is an instance of 
>> "Emacs at its worst", so I'd be happy to throw it away.
> I disagree.

I know.  But you're wrong.


        Stefan

RE: quit-window is broken

[Drew Adams]

> >> `find-file-confirm-nonexistent-file'.
> >> I think this customization variable is an instance of 
> >> "Emacs at its worst", so I'd be happy to throw it away.
> >
> > I disagree.

 (reasons snipped;
  argument against cavalier development snipped;
  exceptional cases when such options might be needed snipped)

> I know.  But you're wrong.

 (no reasons given)

Oooooh, that's convincing.
A new model of development leadership.
Vive le Roi !

Re: quit-window is broken

[Stefan Monnier]

> Vive le Roi !

Merci,


        Stefan