kill-buffer-if-not-modified: Wrong type argument: bufferp, t

kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Sven Joachim]

The following change in EMACS_22_BASE:

,----
| 2008-01-12  Eli Zaretskii  <eliz@gnu.org>
| 
| 	* view.el (view-file-other-window, view-file-other-frame): Don't
| 	kill the buffer if it is modified.  Doc fixes.
| 	(kill-buffer-if-not-modified): New function.
| 	(view-file): Don't kill the buffer if it is modified.
`----

causes the error mentioned in the subject every time view-mode is
exited.  It seems that this patch fixes the issue:

--8<---------------cut here---------------start------------->8---
--- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
+++ view.el	21 Jan 2008 19:26:10 +0100	
@@ -244,7 +244,9 @@
 ;; types C-x C-q again to return to view mode.
 (defun kill-buffer-if-not-modified (buf)
   "Like `kill-buffer', but does nothing if the buffer is modified."
-  (let ((buf (or (bufferp buf) (get-buffer buf))))
+  (let ((buf (if (bufferp buf)
+		 buf
+	       (get-buffer buf))))
     (and buf (not (buffer-modified-p buf))
 	 (kill-buffer buf))))
 
--8<---------------cut here---------------end--------------->8---

Changelog entry:

2008-01-21  Sven Joachim  <svenjoac@gmx.de>

	* view.el (kill-buffer-if-not-modified): Fix argument to kill-buffer.

Eli, is switching away from the buffer even if it is modified the
intended behavior?

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Andreas Schwab]

Sven Joachim <svenjoac@gmx.de> writes:

> --- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
> +++ view.el	21 Jan 2008 19:26:10 +0100	
> @@ -244,7 +244,9 @@
>  ;; types C-x C-q again to return to view mode.
>  (defun kill-buffer-if-not-modified (buf)
>    "Like `kill-buffer', but does nothing if the buffer is modified."
> -  (let ((buf (or (bufferp buf) (get-buffer buf))))
> +  (let ((buf (if (bufferp buf)
> +		 buf
> +	       (get-buffer buf))))

get-buffer returns the argument if it is already a buffer, thus the
conditional is not needed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Eli Zaretskii]

> From: Sven Joachim <svenjoac@gmx.de>
> Date: Mon, 21 Jan 2008 19:44:37 +0100
> 
> The following change in EMACS_22_BASE:
> 
> ,----
> | 2008-01-12  Eli Zaretskii  <eliz@gnu.org>
> | 
> | 	* view.el (view-file-other-window, view-file-other-frame): Don't
> | 	kill the buffer if it is modified.  Doc fixes.
> | 	(kill-buffer-if-not-modified): New function.
> | 	(view-file): Don't kill the buffer if it is modified.
> `----
> 
> causes the error mentioned in the subject every time view-mode is
> exited.

Sorry for messing up.  Please show me the full traceback, I didn't
expect this function to be called with t as its argument.

> It seems that this patch fixes the issue:
> 
> --8<---------------cut here---------------start------------->8---
> --- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
> +++ view.el	21 Jan 2008 19:26:10 +0100	
> @@ -244,7 +244,9 @@
>  ;; types C-x C-q again to return to view mode.
>  (defun kill-buffer-if-not-modified (buf)
>    "Like `kill-buffer', but does nothing if the buffer is modified."
> -  (let ((buf (or (bufferp buf) (get-buffer buf))))
> +  (let ((buf (if (bufferp buf)
> +		 buf
> +	       (get-buffer buf))))
>      (and buf (not (buffer-modified-p buf))
>  	 (kill-buffer buf))))

I'm not sure this is the right fix, that's why I want to see the
traceback.

> Eli, is switching away from the buffer even if it is modified the
> intended behavior?

Sorry, I don't understand the question.  Could you please explain?

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Stefan Monnier]

> +  (let ((buf (if (bufferp buf)
> +		 buf
> +	       (get-buffer buf))))

AKA

+  (let ((buf (get-buffer buf)))


-- Stefan

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Sven Joachim]

On 2008-01-21 21:07 +0100, Eli Zaretskii wrote:

> Sorry for messing up.  Please show me the full traceback, I didn't
> expect this function to be called with t as its argument.

Here it comes:

,----
| Debugger entered--Lisp error: (wrong-type-argument bufferp t)
|   buffer-modified-p(t)
|   kill-buffer-if-not-modified(#<buffer junk>)
|   view-mode-exit(((#<window 249 on sven> nil #<buffer sven> 6889 8214) (#<window 177> nil #<buffer sven> 7472 8351) (#<window 164> nil #<buffer sven> 7755 8214)) kill-buffer-if-not-modified)
|   View-quit()
|   call-interactively(View-quit)
`----

The reason is that (bufferp buf) returns t if buf is a buffer, so
(or (bufferp buf) (get-buffer buf)) returns t as well and buf is set to t.

>> It seems that this patch fixes the issue:
>> 
>> --8<---------------cut here---------------start------------->8---
>> --- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
>> +++ view.el	21 Jan 2008 19:26:10 +0100	
>> @@ -244,7 +244,9 @@
>>  ;; types C-x C-q again to return to view mode.
>>  (defun kill-buffer-if-not-modified (buf)
>>    "Like `kill-buffer', but does nothing if the buffer is modified."
>> -  (let ((buf (or (bufferp buf) (get-buffer buf))))
>> +  (let ((buf (if (bufferp buf)
>> +		 buf
>> +	       (get-buffer buf))))
>>      (and buf (not (buffer-modified-p buf))
>>  	 (kill-buffer buf))))
>
> I'm not sure this is the right fix, that's why I want to see the
> traceback.

As Andreas and Stefan already noted, just

(let ((buf (get-buffer buf)))

would suffice.

>> Eli, is switching away from the buffer even if it is modified the
>> intended behavior?
>
> Sorry, I don't understand the question.  Could you please explain?

In a Dired buffer, I typed v to view the file at point.  Then I typed
C-x C-q, edited the buffer and pressed C-x C-q again to re-enter view
mode.  Then I typed q and the result was that I was back in the Dired
buffer.  Yet C-x C-b showed the modified (now writable) file buffer at
the top of the buffer list.  I would expect that it would either

a) not be switched away from; or
b) buried.

But maybe this is not so important.  There is another inconsistency,
though: pressing C-x C-q in the modified buffer does not enter view mode
again.

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Sven Joachim]

On 2008-01-21 21:44 +0100, Sven Joachim wrote:

> But maybe this is not so important.  There is another inconsistency,
> though: pressing C-x C-q in the modified buffer does not enter view mode
> again.

Please disregard this comment.  Having slept over it, I now realize that
C-x C-q should _not_ enter view mode, since Emacs was already told to
exit view mode before.

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[martin rudalics]

 > Please disregard this comment.  Having slept over it, I now realize that
 > C-x C-q should _not_ enter view mode, since Emacs was already told to
 > exit view mode before.

By default C-x C-q _should_ re-enter view-mode when the buffer was in
view-mode before:

      ((and (not buffer-read-only) view-read-only
	   ;; If view-mode is already active, `view-mode-enter' is a nop.
	   (not view-mode)
            (not (eq (get major-mode 'mode-class) 'special)))
       (view-mode-enter))

But note that Emacs 22.1 resets `view-exit-action' to nil when leaving
`view-mode' and `view-mode-enter' without argument does _not_ set it
again.

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Sven Joachim]

On 2008-01-21 21:44 +0100, Sven Joachim wrote:

> On 2008-01-21 21:07 +0100, Eli Zaretskii wrote:
>
>> Sorry for messing up.  Please show me the full traceback, I didn't
>> expect this function to be called with t as its argument.
>
> Here it comes:
>
> ,----
> | Debugger entered--Lisp error: (wrong-type-argument bufferp t)
> |   buffer-modified-p(t)
> |   kill-buffer-if-not-modified(#<buffer junk>)
> |   view-mode-exit(((#<window 249 on sven> nil #<buffer sven> 6889 8214) (#<window 177> nil #<buffer sven> 7472 8351) (#<window 164> nil #<buffer sven> 7755 8214)) kill-buffer-if-not-modified)
> |   View-quit()
> |   call-interactively(View-quit)
> `----
>
> The reason is that (bufferp buf) returns t if buf is a buffer, so
> (or (bufferp buf) (get-buffer buf)) returns t as well and buf is set to t.

And buffer-modified-p does not accept t as argument, I should add.


>>> It seems that this patch fixes the issue:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> --- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
>>> +++ view.el	21 Jan 2008 19:26:10 +0100	
>>> @@ -244,7 +244,9 @@
>>>  ;; types C-x C-q again to return to view mode.
>>>  (defun kill-buffer-if-not-modified (buf)
>>>    "Like `kill-buffer', but does nothing if the buffer is modified."
>>> -  (let ((buf (or (bufferp buf) (get-buffer buf))))
>>> +  (let ((buf (if (bufferp buf)
>>> +		 buf
>>> +	       (get-buffer buf))))
>>>      (and buf (not (buffer-modified-p buf))
>>>  	 (kill-buffer buf))))
>>
>> I'm not sure this is the right fix, that's why I want to see the
>> traceback.
>
> As Andreas and Stefan already noted, just
>
> (let ((buf (get-buffer buf)))
>
> would suffice.


Here is a cleaned up patch (that I've been using for two days) and
Changelog entry.  Would you please install that?

--8<---------------cut here---------------start------------->8---
--- view.el	21 Jan 2008 18:51:02 +0100	1.84.2.9
+++ view.el	22 Jan 2008 08:30:22 +0100	
@@ -244,7 +244,7 @@
 ;; types C-x C-q again to return to view mode.
 (defun kill-buffer-if-not-modified (buf)
   "Like `kill-buffer', but does nothing if the buffer is modified."
-  (let ((buf (or (bufferp buf) (get-buffer buf))))
+  (let ((buf (get-buffer buf)))
     (and buf (not (buffer-modified-p buf))
 	 (kill-buffer buf))))
--8<---------------cut here---------------end--------------->8---


2008-01-24  Sven Joachim  <svenjoac@gmx.de>

	* view.el (kill-buffer-if-not-modified): Don't pass t to
	buffer-modified-p.

Re: kill-buffer-if-not-modified: Wrong type argument: bufferp, t

[Glenn Morris]

Sven Joachim wrote:

> Here is a cleaned up patch (that I've been using for two days) and
> Changelog entry.  Would you please install that?

ack