emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bind `q' to `quit-window' or similar in *Messages*


From: Drew Adams
Subject: RE: Bind `q' to `quit-window' or similar in *Messages*
Date: Thu, 4 Feb 2010 07:30:15 -0800

> 99% of the time, I use it that way, too.  But when debugging 
> some elisp code, I sometimes add markers there, like Drew
> pointed out.  So how about this idea:
> 
>   - *Messages* is read-only
>   - `q' buries the buffer
>   - `m' is bound to a new command that... provides an
>     interface to `message' 

I said:

> So this comes down to a choice, I think:
> 
> 1. View-mode by default, so `q' quits, and you need to do 
>    `C-x C-q' to make it writable.
> 
> 2. Writable by default, and you need to do `C-x 0' (or `C-x 
>    k') to get rid of it.
> 
> And the same or similar considerations probably apply to *Pp 
> Eval Output*. I still vote for #2, but I don't feel strongly about it.

Again, I'm OK with either. I too use it without editing most of the time.
And I don't think we need undo (with its cost) in *Messages*.

The same applies to *Pp Eval Output*. But undo there would be useful. Quitting
read-only should put *Pp Eval Output* back in Emacs-Lisp mode.

I don't see the point (need) for the proposed `m' binding in `Messages'. If it's
just in order to be able to add to the buffer text without turning off read-only
(C-x C-q), then turning it off and editing is handier, IMO. But I'm probably
missing the point here.

If we choose #1, then `q' should do what it does in other, similar situations. I
think that's more likely to be `quit-window' than `bury-buffer'. (FWIW, with my
use of frames, `bury-buffer' is almost never the behavior I want.) Let `q' do
what it does in Dired, for instance (`quit-window').






reply via email to

[Prev in Thread] Current Thread [Next in Thread]