go to next unsaved buffer

go to next unsaved buffer

[Dan Jacobson]

Idea: go to next unwritten file (or whatever you call them).

The proposed "go to next unwritten file command", which merely goes
down the buffer list looking for files that are modified but not
written, will come in handy when:

It's 2:42 and the Royal Ball will start in 5 minutes.  Last time this
happened you just hit C-x s y y y y y without actually looking at
what you were saving.  Bad move.

Now with the new proposed command, you don't have to dig those buffers
out of the buffer list, you just run the command, and it's like "next
please".  And yes, if the current buffer is unwritten when the command
is executed, it cycles to the end of the list (bury-buffer) no matter
what... until there are one or none left...

Ah yes, I forgot to dot that i.  Ah yes, I forgot to cross that t.
Yes, no more hurriedly written buffers.  Each one is brought before
your face for final adjustment and approval.

I propose 'em, you implement them.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: go to next unsaved buffer

[Paul Stoeber]

On Tue, Jul 02, 2002 at 04:11:34PM +0800, Dan Jacobson wrote:
> It's 2:42 and the Royal Ball will start in 5 minutes.  Last time this
> happened you just hit C-x s y y y y y without actually looking at
> what you were saving.  Bad move.
[...]
> Yes, no more hurriedly written buffers.  Each one is brought before
> your face for final adjustment and approval.

`save-some-buffers' already has this: C-r.  Type C-M-c to exit from
the recursive edit.

Re: go to next unsaved buffer

[Dan Jacobson]

>>>>> "Paul" == Paul Stoeber <paul.stoeber@stud.tu-ilmenau.de> writes:

Paul> On Tue, Jul 02, 2002 at 04:11:34PM +0800, Dan Jacobson wrote:
>> It's 2:42 and the Royal Ball will start in 5 minutes.  Last time this
>> happened you just hit C-x s y y y y y without actually looking at
>> what you were saving.  Bad move.
Paul> [...]
>> Yes, no more hurriedly written buffers.  Each one is brought before
>> your face for final adjustment and approval.

Paul> `save-some-buffers' already has this: C-r.  Type C-M-c to exit from
Paul> the recursive edit.

It is a bug that C-h k C-x s does not mention this.

By the way I just tired what you mentioned.  Seems like a great way to
get all confused.  I ended up with lots of [[[ ]]] in the modeline and
I had to hit exit-recursive-edit several times to get out.  Anyway, my
idea is simpler in that you aren't under the gun of being in the
middle of answering the question of saving each buffer.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: go to next unsaved buffer

[Paul Stoeber]

On Wed, Jul 03, 2002 at 01:30:16PM +0800, Dan Jacobson wrote:
> Paul> `save-some-buffers' already has this: C-r.  Type C-M-c to exit from
> Paul> the recursive edit.
> 
> It is a bug that C-h k C-x s does not mention this.

The prompt "Save file /tmp/1? (y, n, !, ., q, C-r or C-h)"
mentions C-r, and C-h explains it.

> By the way I just tired what you mentioned.  Seems like a great way to
> get all confused.  I ended up with lots of [[[ ]]] in the modeline and
> I had to hit exit-recursive-edit several times to get out.

C-r puts you into view-mode.  Does this cause the problem?
It can be turned off with M-x view-mode.

> Anyway, my
> idea is simpler in that you aren't under the gun of being in the
> middle of answering the question of saving each buffer.

I've tried your idea, and it's actually more comfortable than the
the dialog with `save-some-buffers'.

A problem is: what is an "unsaved buffer"?

;; This function should be factored out of `save-some-buffers',
;; which is a moving target (see the thread
;; "[jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye]"
;; on emacs-devel).
(defun buffer-unsaved-p (buffer)
  "The definition of \"unsaved buffer\" for `switch-to-next-unsaved-buffer'."
  (and (buffer-modified-p buffer)
       (or (buffer-file-name buffer)
	   (not (string-match "\\`[ *]" (buffer-name buffer))))))

(defun switch-to-next-unsaved-buffer ()
  "Switch to next unsaved buffer if any.
The function `buffer-unsaved-p' defines \"unsaved buffer\"."
  (interactive)
  (catch 'return
    (if (buffer-unsaved-p (current-buffer))
	(bury-buffer (current-buffer)))
    (dolist (buffer (buffer-list))
      (if (buffer-unsaved-p buffer)
	  (if (eq buffer (current-buffer))
	      (error "No other unsaved buffers")
	    (switch-to-buffer buffer)
	    (throw 'return nil))))
    (error "No unsaved buffers")))

Re: go to next unsaved buffer

[Andreas Schwab]

Paul Stoeber <paul.stoeber@stud.tu-ilmenau.de> writes:

|> C-r puts you into view-mode.  Does this cause the problem?
|> It can be turned off with M-x view-mode.

Or just type `e' (View-exit).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: go to next unsaved buffer

[Dan Jacobson]

>>>>> "P" == Paul Stoeber <paul.stoeber@stud.tu-ilmenau.de> writes:

P> On Wed, Jul 03, 2002 at 01:30:16PM +0800, Dan Jacobson wrote:
Paul> `save-some-buffers' already has this: C-r.  Type C-M-c to exit from
Paul> the recursive edit.
>> 
>> It is a bug that C-h k C-x s does not mention this.

P> The prompt "Save file /tmp/1? (y, n, !, ., q, C-r or C-h)"
P> mentions C-r, and C-h explains it.

not good enough.  I want to know what I am in for before I press the
key, that's only fair and square.  What if all the C-s features were
only learnable once one was already searching.  [p.s. not talking
about reading Info here, just C-h k]

>> By the way I just tired what you mentioned.  Seems like a great way to
>> get all confused.  I ended up with lots of [[[ ]]] in the modeline and
>> I had to hit exit-recursive-edit several times to get out.

>> idea is simpler in that you aren't under the gun of being in the
>> middle of answering the question of saving each buffer.

P> I've tried your idea, and it's actually more comfortable than the
P> the dialog with `save-some-buffers'.

P> A problem is: what is an "unsaved buffer"?

i mean the kind that C-x s would ask about, with files attached.
Oh, and then there's some gnus draft buffers too...

P> (defun switch-to-next-unsaved-buffer ()

a quick test of your function seems that it does it all... hope to see
it in emacs soon, along with an official keybinding.  Pretty darn
handy actually.

uh oh, want to exclude modified *scratch* type buffers... and some
users would want *shell* to be included which seems not to now...
ok, this all should have customization instructions...
better yet, a handy 'only-if-file-associated 'processes[-too]
.... etc. predicates list...
-- 
http://jidanni.org/ Taiwan(04)25854780

more official key bindings for us follow the leader types

[Dan Jacobson]

P> Default key bindings are irrelevant anyway, once the user
P> learns .emacs and global-set-key (cf. the C-x C-q discussion :-)

RMS> I don't think we can afford to give it a global key binding, though.

I think you guys should crack open another sub keymap somewhere, as we
"follower" types like to use "official key bindings" rather than each
having different bindings for the same thing.

I mean what if, in the year 2026, they invent "personality melding",
and I get melded with John, who has drastically different ideas where
many of the emacs commands are bound.  I will then have more split
personality problems then the average guy.  Sounds funny, but you
never know.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: more official key bindings for us follow the leader types

[Miles Bader]

jidanni@dman.ddts.net (Dan Jacobson) writes:
> I mean what if, in the year 2026, they invent "personality melding",
> and I get melded with John, who has drastically different ideas where
> many of the emacs commands are bound.  I will then have more split
> personality problems then the average guy.  Sounds funny, but you
> never know.

Just meld your mind with emacs; then you won't need keybindings at all.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

bind me a/k/a leadership in the key binding dept.

[Dan Jacobson]

RMS> Default key bindings and other defaults are very important issues.
RMS> What makes Emacs powerful is the design that enables users to change
RMS> many things in a very general way.  However, what makes Emacs
RMS> convenient is the fact that we have configured a lot of convenient
RMS> things in advance.

Hmm, OK, I guess.  P.S. sounds like the Master Chinghai ;-)

Imagine a world where even the most basic keys C-a C-b ... were left
to the users to bind themselves... bad.

Imagine a world where even the most arcane optional, (however
interactive, of course) commands all had bindings right out of the
factory.  Not so bad unless the user is in the habit of random typing.

Anyways, maybe consider "binding recommendation reservation lists", to
avoid Jimmy binding to A what Jonnny binds to B causing Jimmy to have
difficulty at the demo when handed Jonnny's terminal.

Anyways, say, you provide functions with standard names, no?  You
don't just do "lambda" and let the masses "chose their favorite name
as the flower blows", no?  Well, how about the same leadership in the
key binding dept.  True, a good key binding requires thought and
feedback, but anyways, think about it.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: bind me a/k/a leadership in the key binding dept.

[Miles Bader]

jidanni@dman.ddts.net (Dan Jacobson) writes:
> Anyways, say, you provide functions with standard names, no?  You
> don't just do "lambda" and let the masses "chose their favorite name
> as the flower blows", no?  Well, how about the same leadership in the
> key binding dept.

It's much simpler to do for function names, because the namespace is
much, _much_, larger (well, the _practical_ namespace, anyway; you could
always think of `M-x name' as a binding...).

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'