[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TAB for non-editing modes
From: |
Drew Adams |
Subject: |
RE: TAB for non-editing modes |
Date: |
Sun, 23 Sep 2007 09:43:59 -0700 |
> Similarly for other bindings that invoke commands that modify
> the buffer - why not bind them to `undefined'? I do that in
> read-only buffers such as *Buffer List*. Besides preventing
> the read-only error message, it prevents users from thinking
> that a key sequence might be unavailable for their own use.
>
> suppress-keymap already does this with self-inserting commands. Your
> idea is to do this with the other normal commands that alter the text.
Yes. And for the same reasons. Individual character insertion is but one way
to modify a buffer. There are other ways, both local and global, as you
point out.
> Doing this with kill commands would take away a feature: you can use
> them in read-only buffers to copy text to the kill ring. That feature
> may not be very useful in read-only buffers, but I am not convinced it
> is an improvement to make it entirely unavailable there.
Granted. But it could be argued that this "feature" is really a bug that we
exploit (because it seems useful) ;-). Because it is inconsistent with
normal use (killing) of those commands/keys, it promotes user error and
possibly confusion. The user does not even get proper feedback about this
"trick" - s?he still gets the read-only error message/reminder, and there is
no indication that anything was copied. I don't know if this "feature" is
even documented.
Emacs has no lack of copy (vs kill) commands - it's better for users to get
in the consistent habit of using the copy commands (not using kill commands
in read-only buffers). You might have a habit to break, but that's all.
> Aside from that, I think it is more coherent for global
> buffer-modifying commands to give errors "buffer read-only" in
> read-only buffers, rather than acting as if they did not exist.
By the qualifier "global", I assume you do not mean things such as
`backward-delete-char-untabify'. So I guess you are agreeing to extending
`suppress-keymap' (or creating an additional function that extends it) to
such "local" buffer modifying commands. Is that right?
> For TAB, which varies between modes anyway, making it undefined
> might be good.
Here, I see you suggesting that there are even some "global"
buffer-modifying keys that should be undefined - namely `TAB', at least. Is
that right?
I don't disagree with your reservation for global buffer modifiers, but that
(e.g. the `TAB' case) really means that it would be good to take a look at
such commands on a case-by-case basis.
- RE: bind commands that change buffer contents to `undefined' when read-only?, (continued)
- Re: bind commands that change buffer contents to `undefined' when read-only?, Richard Stallman, 2007/09/24
- Re: bind commands that change buffer contents to `undefined' when read-only?, Stefan Monnier, 2007/09/25
- RE: TAB for non-editing modes, Drew Adams, 2007/09/22
- Re: TAB for non-editing modes, Bastien, 2007/09/23
- Re: TAB for non-editing modes, Juri Linkov, 2007/09/23
- Re: TAB for non-editing modes, Richard Stallman, 2007/09/23
- RE: TAB for non-editing modes,
Drew Adams <=
- Re: TAB for non-editing modes, Johan Bockgård, 2007/09/23
- RE: TAB for non-editing modes, Drew Adams, 2007/09/23
- Re: TAB for non-editing modes, Johan Bockgård, 2007/09/23
- Re: TAB for non-editing modes, Richard Stallman, 2007/09/23
- Re: TAB for non-editing modes, Dan Nicolaescu, 2007/09/23
- Re: TAB for non-editing modes, Richard Stallman, 2007/09/24