TAB for non-editing modes

TAB for non-editing modes

[Dan Nicolaescu]

For info, help, man, woman TAB does something like "goto the next
link". 

TAB does not do anything for pcvs, dired, log-view and maybe
others. It would be nice if TAB would do something for these modes
too.  
A navigational semantic like info/help/man do seems that would be
intuitive (it should certainly be better than the current "error
because the buffer is read-only" behavior).
(similarly for backtab)

Thoughts?

Re: TAB for non-editing modes

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
> For info, help, man, woman TAB does something like "goto the next
> link". 
> 
> TAB does not do anything for pcvs, dired, log-view and maybe
> others. It would be nice if TAB would do something for these modes
> too.  
> A navigational semantic like info/help/man do seems that would be
> intuitive (it should certainly be better than the current "error
> because the buffer is read-only" behavior).
> (similarly for backtab)
> 
> Thoughts?

Good and important idea. I think this is what most users would expect 
since both the modes you mention and programs like web browsers behaves 
this way.

Re: TAB for non-editing modes

[Richard Stallman]

    TAB does not do anything for pcvs, dired, log-view and maybe
    others. It would be nice if TAB would do something for these modes
    too.  

It seems harmless to add that functionality in modes that are
read-only and have distinguishable links.  I don't see that this
is very useful in Dired, though.

Re: TAB for non-editing modes

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     TAB does not do anything for pcvs, dired, log-view and maybe
  >     others. It would be nice if TAB would do something for these modes
  >     too.  
  > 
  > It seems harmless to add that functionality in modes that are
  > read-only and have distinguishable links.  I don't see that this
  > is very useful in Dired, though.

Why not? I'd rather have TAB run dired-next-line instead of throwing
an error "Buffer is read-only" as it does now.

RE: TAB for non-editing modes

[Drew Adams]

>   >     TAB does not do anything for pcvs, dired, log-view and maybe
others
>   >     It would be nice if TAB would do something for these modes too.
>   >
>   > It seems harmless to add that functionality in modes that are
>   > read-only and have distinguishable links.  I don't see that this
>   > is very useful in Dired, though.
>
> Why not? I'd rather have TAB run dired-next-line instead of throwing
> an error "Buffer is read-only" as it does now.

That is truly a waste of a key binding, IMO. `n' does that already. I have
nothing against giving `TAB' a useful binding in Dired, but there is no
sense duplicating `n' for that.

If no truly useful Dired binding for `TAB' can be found now, then let's
leave it alone - something will come up eventually. The problem with binding
it now to something that is not particularly useful is that that binding can
become cast in stone, a sacred cow that is later defended against replacing
with a truly useful binding.

If we don't bind `TAB' in Dired to something useful now, we might consider
unbinding it there, more precisely, binding it to `undefined'. It is silly
for `TAB' to invoke `indent-for-tab-command' in Dired.


Generalizing this (note: a topic change) -

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.

I made this suggestion on 2004-10-17 in thread "bind buffer-modifying keys
to `undefined' in buffers where nomodification should occur?". Kim suggested
perhaps using `ignore' instead of `undefined', but he pointed out some
problems with `C-h b' for `ignore'. RMS said he didn't want to make such a
change then, because the release of Emacs 22 was imminent (;-)). Perhaps
this or something similar could be reconsidered now.

FWIW, I do this rather primitively, by just having a list of
buffer-modifying commands and then binding them to `undefined'. Perhaps a
better mechanism could be devised. Here is the code I use. As you can see, I
neglected to include `indent-for-tab-command', and there are no doubt other
buffer-modifying commands that might be included.

(defun undefine-keys-bound-to (command keymap &optional oldmap)
  "Bind to `undefined' all keys currently bound to COMMAND in KEYMAP.
If optional argument OLDMAP is specified, rebinds in KEYMAP as
`undefined' all keys that are currently bound to COMMAND in OLDMAP but
are not bound in KEYMAP."
  (unless (where-is-internal command keymap 'first-only)
    (substitute-key-definition command 'undefined keymap oldmap)))

(defcustom buffer-modifying-cmds
  '(delete-char quoted-insert transpose-chars kill-region yank kill-word
                indent-new-comment-line kill-sentence fill-paragraph
                transpose-words yank-pop zap-to-char just-one-space
                indent-for-comment delete-indentation kill-sexp split-line
                transpose-sexps backward-kill-sentence)
  "*Buffer-modifying commands used in `undefine-killer-commands'."
  :type '(repeat symbol))

(defun undefine-killer-commands (keymap &optional oldmap)
  "Bind `undefined' to KEYMAP keys bound to buffer-modifying commands.
If optional arg OLDMAP is specified, rebinds in KEYMAP as `undefined'
the keys that are currently bound to buffer-modifying commands in
OLDMAP but are not bound in KEYMAP.  The buffer-modifying commands
used: `buffer-modifying-cmds'."
  (mapcar (lambda (cmd) (undefine-keys-bound-to cmd keymap oldmap))
          buffer-modifying-cmds))

A typical use:
(undefine-killer-commands Buffer-menu-mode-map (current-global-map))

Re: TAB for non-editing modes

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> Why not? I'd rather have TAB run dired-next-line instead of throwing
>> an error "Buffer is read-only" as it does now.
> 
> That is truly a waste of a key binding, IMO. `n' does that already. I have
> nothing against giving `TAB' a useful binding in Dired, but there is no
> sense duplicating `n' for that.

 From a usability point of view I think it is worth pointing out that 
TAB/S-TAB is very often used for "go to next/prev field". A new user 
would probably expect that kind of use in dired too.

RE: TAB for non-editing modes

[Drew Adams]

> >> Why not? I'd rather have TAB run dired-next-line instead of throwing
> >> an error "Buffer is read-only" as it does now.
> >
> > That is truly a waste of a key binding, IMO. `n' does that
> > already. I have nothing against giving `TAB' a useful binding
> > in Dired, but there is no sense duplicating `n' for that.
>
> From a usability point of view I think it is worth pointing out that
> TAB/S-TAB is very often used for "go to next/prev field". A new user
> would probably expect that kind of use in dired too.

Are there "fields" in Dired? If not, what you say is also true for a buffer
foo.txt: TAB and S-TAB should navigate (where?).

Making things easier for new users is as much a concern for me as for you, I
think, but key binding is not a place where we should bend over backwards to
placate what a new user might happen to be used to.

Unless there is no other reason not to. Which there is - there are always
better reasons to choose key bindings, and the number of reasonable key
sequences is limited.

New users and old alike do not need Yet Another Way to get to the next line
in Dired. Please. We already have `dired-next-line' bound to `n', `SPC',
`C-n', and `down'. Isn't that enough?

`TAB' will come in handy for something very useful in Dired one day, I'm
sure of it. Patience, Grasshopper, patience.

Re: TAB for non-editing modes

[Dan Nicolaescu]

"Drew Adams" <drew.adams@oracle.com> writes:

  > >   >     TAB does not do anything for pcvs, dired, log-view and maybe
  > others
  > >   >     It would be nice if TAB would do something for these modes too.
  > >   >
  > >   > It seems harmless to add that functionality in modes that are
  > >   > read-only and have distinguishable links.  I don't see that this
  > >   > is very useful in Dired, though.
  > >
  > > Why not? I'd rather have TAB run dired-next-line instead of throwing
  > > an error "Buffer is read-only" as it does now.
  > 
  > That is truly a waste of a key binding, IMO. `n' does that already. I have
  > nothing against giving `TAB' a useful binding in Dired, but there is no
  > sense duplicating `n' for that.
  > 
  > If no truly useful Dired binding for `TAB' can be found now, then let's
  > leave it alone - something will come up eventually. The problem with binding
  > it now to something that is not particularly useful is that that binding can
  > become cast in stone, a sacred cow that is later defended against replacing
  > with a truly useful binding.
  > 
  > If we don't bind `TAB' in Dired to something useful now, we might consider
  > unbinding it there, more precisely, binding it to `undefined'. It is silly
  > for `TAB' to invoke `indent-for-tab-command' in Dired.

Duplication is not a good way to evaluate this, we have many keys that
are duplicated. 

The question is it useful? Is it intuitive to use? Is it consistent
with other uses of the same key?  IMO the answer is YES to all those
questions.


  > Generalizing this (note: a topic change) -

Please start another thread with this, with a different subject. 

bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

>> Generalizing this (note: a topic change) -
>
> Please start another thread with this, with a different subject.

OK. The rest of this is from my mail with subject "TAB for editing modes":

------8<------------------

Why not bind commands that modify buffer content to `undefined' when the
buffer is read-only? 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.

I made this suggestion on 2004-10-17 in thread "bind buffer-modifying keys
to `undefined' in buffers where nomodification should occur?". Kim suggested
perhaps using `ignore' instead of `undefined', but he pointed out some
problems with `C-h b' for `ignore'. RMS said he didn't want to make such a
change then, because the release of Emacs 22 was imminent (;-)). Perhaps
this or something similar could be reconsidered now.

FWIW, I do this rather primitively, by just having a list of
buffer-modifying commands and then binding them to `undefined'. Perhaps a
better mechanism could be devised. Here is the code I use. As you can see, I
neglected to include `indent-for-tab-command', and there are no doubt other
buffer-modifying commands that might be included.

(defun undefine-keys-bound-to (command keymap &optional oldmap)
  "Bind to `undefined' all keys currently bound to COMMAND in KEYMAP.
If optional argument OLDMAP is specified, rebinds in KEYMAP as
`undefined' all keys that are currently bound to COMMAND in OLDMAP but
are not bound in KEYMAP."
  (unless (where-is-internal command keymap 'first-only)
    (substitute-key-definition command 'undefined keymap oldmap)))

(defcustom buffer-modifying-cmds
  '(delete-char quoted-insert transpose-chars kill-region yank kill-word
                indent-new-comment-line kill-sentence fill-paragraph
                transpose-words yank-pop zap-to-char just-one-space
                indent-for-comment delete-indentation kill-sexp split-line
                transpose-sexps backward-kill-sentence)
  "*Buffer-modifying commands used in `undefine-killer-commands'."
  :type '(repeat symbol))

(defun undefine-killer-commands (keymap &optional oldmap)
  "Bind `undefined' to KEYMAP keys bound to buffer-modifying commands.
If optional arg OLDMAP is specified, rebinds in KEYMAP as `undefined'
the keys that are currently bound to buffer-modifying commands in
OLDMAP but are not bound in KEYMAP.  The buffer-modifying commands
used: `buffer-modifying-cmds'."
  (mapcar (lambda (cmd) (undefine-keys-bound-to cmd keymap oldmap))
          buffer-modifying-cmds))

A typical use:
(undefine-killer-commands Buffer-menu-mode-map (current-global-map))

RE: TAB for non-editing modes

[Drew Adams]

> Duplication is not a good way to evaluate this, we have many keys that
> are duplicated.

Yes, for this command alone, we have `n', `SPC', `C-n', and `down'.

`C-n' and `down' often go together. `n' is a shortcut for `C-n', since Dired
is read-only.

`SPC' and `DEL' are sometimes used in Emacs (e.g. View, Info) to browse down
and up (forward or back). But in Dired we've broken that, since `DEL'
unmarks entries instead. Same thing for Buffer Menu. I wouldn't mind if
`SPC' removed the current mark and moved down, in analogy with `DEL', but
it's probably too late to change that.

> The question is it useful? Is it intuitive to use? Is it consistent
> with other uses of the same key?  IMO the answer is YES to all those
> questions.

The question is not just whether it useful, but how useful it is. When there
are already umpteen other simple keys bound to a command that is not
particularly important, is it worthwhile to waste another key on it?

Especially a key such as `TAB', which has important associations and uses in
other contexts:

- `TAB' is used for indenting, which can be context-dependent. Someday
perhaps we will have a notion of indenting for Dired. (No idea what such
indentation might mean - perhaps for inserted subdirs?)

- `TAB' is used for completion - both minibuffer and buffer text. Someday
perhaps we will have some notion of "completing" a file or directory entry
in Dired. (No idea what such completion might mean.)

- `TAB' is used for field navigation (particularly outside Emacs), as
Lennart mentioned. Someday perhaps we will have fields of some sort in
Dired.

Maybe you are thinking of a file/directory name in Dired as a field. Perhaps
that's what you think of as "consistent with other uses of the same key". In
that case, it would make sense, but I don't see `TAB' as very helpful for
this in Dired today.

Perhaps if we had a notion of "current column" and various operations were
permitted on the data in the current Dired column (e.g. change file
permissions, change the date), then `TAB' could move to the next "field" in
the current column. IOW, if a user changed the current column to
`Permissions', then `TAB' would move to the next `Permissions' field, where
you could change a permission (other than by `M', which acts regardless of
the current cursor column).

I'm not familiar with wdired, but perhaps it has such a notion of field, so
that some editing commands get their specific effect from the kind of field
the cursor is in. I don't know. In that case, letting `TAB' move among
fields might be useful.

Anyway, this is not all that important. I just don't like to see good keys
wasted.

RE: bind commands that change buffer contents to `undefined' whenread-only?

[Drew Adams]

> (defcustom buffer-modifying-cmds
>   '(delete-char quoted-insert transpose-chars kill-region yank kill-word
>                 indent-new-comment-line kill-sentence fill-paragraph
>                 transpose-words yank-pop zap-to-char just-one-space
>                 indent-for-comment delete-indentation kill-sexp split-line
>                 transpose-sexps backward-kill-sentence)
>   "*Buffer-modifying commands used in `undefine-killer-commands'."
>   :type '(repeat symbol))

That definition is pretty old and skimpy. FWIW, here are some more such
commands. Many of these are not bound to keys by default, but including them
wouldn't hurt.

(defcustom buffer-modifying-cmds
  '(align-newline-and-indent backward-delete-char
    backward-delete-char-untabify backward-kill-paragraph
    backward-kill-sentence backward-kill-sexp backward-kill-word
    bookmark-insert bookmark-insert-location canonically-space-region
    capitalize-region capitalize-word c-backslash-region
    c-context-line-break center-line center-paragraph center-region
    c-fill-paragraph c-hungry-delete-backwards
    c-hungry-delete-forward c-indent-command c-indent-defun
    c-indent-exp clear-rectangle clipboard-kill-region
    comint-kill-input comint-truncate-buffer comment-dwim
    comment-indent-new-line comment-kill comment-region
    comment-or-uncomment-region complete-symbol compose-last-chars
    compose-region dabbrev-completion dabbrev-expand decompose-region
    delete-backward-char delete-blank-lines delete-char
    delete-horizontal-space delete-indentation delete-matching-lines
    delete-non-matching-lines delete-pair delete-rectangle
    delete-region delete-trailing-whitespace
    delete-whitespace-rectangle delimit-columns-region
    downcase-region downcase-word edit-picture expand-abbrev
    expand-region-abbrevs fill-individual-paragraphs
    fill-nonuniform-paragraphs fill-paragraph fill-region
    fill-region-as-paragraph format-insert-file flush-lines
    ido-insert-buffer ido-insert-file increase-left-margin
    increase-right-margin indent-code-rigidly indent-for-comment
    indent-for-tab-command indent-line-function
    indent-new-comment-line indent-pp-sexp indent-region
    indent-rigidly insert-abbrevs insert-buffer insert-file
    insert-file-literally insert-kbd-macro insert-pair
    insert-parentheses insert-register insert-zippyism join-line
    justify-current-line just-one-space keep-lines
    kill-backward-up-list kill-comment kill-line kill-paragraph
    kill-rectangle kill-region kill-sentence kill-sexp
    kill-whole-line kill-word lisp-complete-symbol
    lisp-fill-paragraph lisp-indent-line morse-region mouse-kill
    mouse-yank-at-click mouse-yank-secondary newline
    newline-and-indent open-line open-rectangle query-replace
    query-replace-regexp quoted-insert
    reindent-then-newline-and-indent replace-regexp replace-string
    repunctuate-sentences reverse-region rot13-region
    self-insert-command set-justification-center
    set-justification-full set-justification-left
    set-justification-none set-justification-right set-left-margin
    set-right-margin skeleton-pair-insert-maybe smiley-region
    sort-columns sort-fields sort-lines sort-numeric-fields
    sort-pages sort-paragraphs split-line string-insert-rectangle
    string-rectangle studlify-region table-delete-column
    table-delete-row table-heighten-cell table-insert
    table-insert-column table-insert-row table-insert-sequence
    table-justify table-shorten-cell table-span-cell table-split-cell
    table-split-cell-horizontally table-split-cell-vertically
    table-widen-cell tab-to-tab-stop tabify texinfo-format-region
    tildify-region time-stamp todo-insert-item translate-region
    transpose-chars transpose-lines transpose-paragraphs
    transpose-sentences transpose-sexps transpose-words ucs-insert
    uncomment-region unmorse-region untabify upcase-region
    upcase-word vc-insert-headers whitespace-cleanup
    whitespace-cleanup-region yank yank-pop yank-rectangle
    zap-to-char)
  "*Buffer-modifying commands used in `undefine-killer-commands'."
  :type '(repeat symbol))

RE: bind commands that change buffer contents to `undefined'whenread-only?

[Drew Adams]

Scrap the implementation I sent. Sorry about that. The general idea is OK,
but it must not override any existing local binding of the key.

It's not enough to check that the command is not bound in the local map; the
key also must not be bound in the local map. So, for instance, even though
`self-insert-command' is not bound in `dired-mode-map', that's not enough to
determine that we should substitute `undefined' for the bindings of all keys
that are globally bound to `self-insert-command'. `R', for instance is bound
in `dired-mode-map', so it must not be rebound to `undefined'.

Re: bind commands that change buffer contents to `undefined'whenread-only?

[Stefan Monnier]

> Scrap the implementation I sent. Sorry about that. The general idea is OK,
> but it must not override any existing local binding of the key.

> It's not enough to check that the command is not bound in the local map; the
> key also must not be bound in the local map. So, for instance, even though
> `self-insert-command' is not bound in `dired-mode-map', that's not enough to
> determine that we should substitute `undefined' for the bindings of all keys
> that are globally bound to `self-insert-command'. `R', for instance is bound
> in `dired-mode-map', so it must not be rebound to `undefined'.

That's not a problem.  Your suggestion is really just an extension of
`suppress-keymap' and should be used similarly: by putting those `undefined'
bindings first and then adding the local bindings.


        Stefan

RE: bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

> That's not a problem.  Your suggestion is really just an extension of
> `suppress-keymap' and should be used similarly: by putting those
> `undefined' bindings first and then adding the local bindings.

Yes, that would be OK for Emacs. In my own use, however, the various keymaps
can be already defined before I get to them.

Re: TAB for non-editing modes

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> Especially a key such as `TAB', which has important associations and uses in
> other contexts:
>
> - `TAB' is used for indenting, which can be context-dependent. Someday
> perhaps we will have a notion of indenting for Dired. (No idea what such
> indentation might mean - perhaps for inserted subdirs?)
>
> - `TAB' is used for completion - both minibuffer and buffer text. Someday
> perhaps we will have some notion of "completing" a file or directory entry
> in Dired. (No idea what such completion might mean.)
>
> - `TAB' is used for field navigation (particularly outside Emacs), as
> Lennart mentioned. Someday perhaps we will have fields of some sort in
> Dired.

Add to this list:

- `TAB' is used to cycle through folding states in Org-mode (only when
  the point is at the beginning of a headline).

If dired-mode were able to (un)fold directories *in the same window*
then `TAB' would be the key of choice.

-- 
Bastien

Re: TAB for non-editing modes

[Richard Stallman]

    Why not? I'd rather have TAB run dired-next-line instead of throwing
    an error "Buffer is read-only" as it does now.

I don't see much of an advantage in making TAB synonymous with SPC.

Re: TAB for non-editing modes

[Richard Stallman]

    If no truly useful Dired binding for `TAB' can be found now, then let's
    leave it alone - something will come up eventually.

I think that is wise.

    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.

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.

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.

For TAB, which varies between modes anyway, making it undefined
might be good.

RE: TAB for non-editing modes

[Drew Adams]

>     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?

[Stefan Monnier]

>> That's not a problem.  Your suggestion is really just an extension of
>> `suppress-keymap' and should be used similarly: by putting those
>> `undefined' bindings first and then adding the local bindings.

> Yes, that would be OK for Emacs. In my own use, however, the various keymaps
> can be already defined before I get to them.

In any case I don't like much this idea of adding explicit `undefined'
bindings, just in order to get a "undefined" message rather than
a "buffer is read-only" error.

So maybe a better direction is to change the toplevel so that using
a command with a "*" (or a call to barf-if-buffer-read-only) in its
interactive spec when the buffer is read-only will signal "undefined" rather
than signalling the error.  And similarly C-h k may give information such as
"the global binding is foo but is of no use in this buffer because it's
read-only".


        Stefan

RE: bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

> In any case I don't like much this idea of adding explicit `undefined'
> bindings, just in order to get a "undefined" message rather than
> a "buffer is read-only" error.
>
> So maybe a better direction is to change the toplevel so that using
> a command with a "*" (or a call to barf-if-buffer-read-only) in its
> interactive spec when the buffer is read-only will signal
> "undefined" rather than signalling the error.  And similarly C-h k
> may give information such as "the global binding is foo but is of
> no use in this buffer because it's read-only".

Sounds OK to me at first, but:

1. We would need to make sure that all such bases were covered. `C-h k' is
one thing; `C-h b' might be another; the read-only error text is another;
and there are perhaps others.

2. It doesn't really help users see that such keys are, in effect, available
for binding in such read-only contexts. That was a main motivation behind my
proposal. A user might check `C-h b' in Dired, for example, and s?he would
see what? A long message explaining what you suggested, for each such key?
Is it as clear to read something like that as it is to read `undefined'? I
don't think so. And we might end up complicating the code that way, having
different kinds of such messages for different contexts (error message, `C-h
b' binding list, `C-h k', and so on).

I don't think you have given any reason _why_ you "don't like much this
idea"; you've just stated a preference. What are the disadvantages you see
to this idea? Deciding on a good way to handle this should involve weighing
the pros & cons.

Re: TAB for non-editing modes

[Juri Linkov]

> - `TAB' is used for indenting, which can be context-dependent. Someday
> perhaps we will have a notion of indenting for Dired. (No idea what such
> indentation might mean - perhaps for inserted subdirs?)
>
> - `TAB' is used for completion - both minibuffer and buffer text. Someday
> perhaps we will have some notion of "completing" a file or directory entry
> in Dired. (No idea what such completion might mean.)

FWIW, I use a combination of two functionalities with the same TAB key.
If TAB is typed on a symbol, then it is used for completion.  Otherwise -
for indenting:

(defun my-lisp-indent-or-complete ()
  (interactive)
  (if (and (memq (char-syntax (preceding-char)) (list ?w ?_)) (not (bobp)))
      (lisp-complete-symbol)
    (indent-for-tab-command)))
(define-key emacs-lisp-mode-map [tab] 'my-lisp-indent-or-complete)

This even works without a modification with the latest changes Dan made
to use TAB to indent the active region.

> - `TAB' is used for field navigation (particularly outside Emacs), as
> Lennart mentioned. Someday perhaps we will have fields of some sort in
> Dired.

I've TAB bound in dired to the command that navigates to the next/previous
directory, and I find this useful:

(defun my-dired-move-to-next-dir (arg)
  (interactive "P")
  (if (not (memq ?R (append dired-actual-switches nil)))
      (dired-next-dirline-cycle 1)
    (progn (dired-next-subdir 1))))
(define-key dired-mode-map [tab] 'my-dired-move-to-next-dir)

Another good binding for TAB in dired would be `other-window' like it is
used in most commander-like file managers to switch to another file panel.
I tried this once but have found that this is useful only in a
configuration where both Emacs windows contain dired buffers.
However, a habit of using TAB to switch between dired buffers fails
when one of dired buffers gets replaced with a visited file, and typing
TAB in a file buffer doesn't switch back to the dired buffer in another
window, because TAB has another binding in the file buffer.

> I'm not familiar with wdired, but perhaps it has such a notion of field, so
> that some editing commands get their specific effect from the kind of field
> the cursor is in. I don't know. In that case, letting `TAB' move among
> fields might be useful.

Yes, wdired has editable fields where TAB would be useful, but wdired is
a separate mode, so this fact is irrelevant here.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: TAB for non-editing modes

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

>> 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.

Of course it is. There even exists an option to remove the read-only
error--`kill-read-only-ok'.

-- 
Johan Bockgård

RE: TAB for non-editing modes

[Drew Adams]

> >> 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.
> 
> Of course it is. There even exists an option to remove the read-only
> error--`kill-read-only-ok'.

Cough; hack.

Why is this better than using the corresponding standard copy commands? What do we gain by this complexity and inconsistency?

Re: TAB for non-editing modes

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Of course it is. There even exists an option to remove the read-only
>> error--`kill-read-only-ok'.
>
> Cough; hack.
>
> Why is this better than using the corresponding standard copy commands?

There are no copy commands for killing lines, sentences, paragraphs,...

-- 
Johan Bockgård

Re: TAB for non-editing modes

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Why not? I'd rather have TAB run dired-next-line instead of throwing
  >     an error "Buffer is read-only" as it does now.
  > 
  > I don't see much of an advantage in making TAB synonymous with SPC.

AFAICT there are 4 operations in dired that have a semantic that means
something like "move to some some other element" (which is what modern
GUIs do with TAB when not used in an editing context): 

	dired-next-line
	dired-next-dirline
	dired-next-subdir
	dired-next-marked-file

Which one do you think would be the best to bind to TAB? Can you see a
better binding?

Again, users nowadays expect TAB to do something useful. IMHO it would
be better for users for us to offer some functionality for TAB in
dired instead of doing nothing, that does not help anyone.

Re: bind commands that change buffer contents to `undefined' when read-only?

[Stefan Monnier]

> 2. It doesn't really help users see that such keys are, in effect, available
> for binding in such read-only contexts. That was a main motivation behind my

*All* keys are available for binding.  The only thing that really matters in
this respect is whether the user uses the predefined binding or not.
If not, then the key is available, regardless of whether the associated
command is useless or not.

E.g. the user is free to rebind C-M-t to anything she wants.  I wouldn't do
it because I often use this binding, but if she doesn't then I see no reason
for her not to do it.


        Stefan

RE: bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

> > 2. It doesn't really help users see that such keys are, in
> > effect, available for binding in such read-only contexts.
> > That was a main motivation behind my
>
> *All* keys are available for binding.  The only thing that really
> matters in this respect is whether the user uses the predefined
> binding or not. If not, then the key is available, regardless of
> whether the associated command is useless or not.

Of course.

I, for one, am more likely to choose a key binding as "available" if it is
undefined - that's what I meant. But yes, you are strictly correct: all keys
are available for rebinding.

And yes, being bound to command `undefined' is not strictly being undefined
either... But it indicates that the current mode/buffer/map has declared no
a priori use for that key. That's a good indication to a user that s?he will
miss nothing by binding that key. I'd say it's practically an invitation.

RE: bind commands that change buffer contents to `undefined' when read-only?

[Davis Herring]

> 2. It doesn't really help users see that such keys are, in effect,
> available for binding in such read-only contexts. That was a main
> motivation behind my proposal.

Exactly how much help does an semi-knowledgeable user (who knows enough to
want to bind a key) need beyond the error?

"Hmm... dired... I'd like a key to convert DOS to Unix line endings.  How
about M-u for "Make Unix"?  That sounds good."

  M-u
 Buffer is read-only: #<buffer contrib>

 "Huh?"

  C-h c M-u
 M-u is bound to upcase-word

 "Oh, that's a nice command.  But it doesn't work...?"

  M-u
 Buffer is read-only: #<buffer contrib>

 "Yup, it's taken, but it doesn't work here.  A shame, too.  I could have
used it!"

I don't see the reaction to C-h c proceeding like that, but rather
 "Aha.  Good to know, but I can obviously use it here, since it doesn't
work anyway."

Davis

PS - Never mind that there's no command to which to bind a key that does
what this hypothetical user wants.  They found the defun scrawled on a
blackboard in a sewer or something.

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

> > 2. It doesn't really help users see that such keys are, in effect,
> > available for binding in such read-only contexts. That was a main
> > motivation behind my proposal.
>
> Exactly how much help does an semi-knowledgeable user (who knows enough to
> want to bind a key) need beyond the error?
> ...
> I don't see the reaction to C-h c proceeding like that, but rather
> "Aha.  Good to know, but I can obviously use it here, since it doesn't
> work anyway."

It's not about the reaction to `C-h c' or to the read-only error message.
It's about a user looking for available keys to bind in a particular
context.

Are you assuming that a user looking for available keys to bind starts with
that error message, that is, by trying a key and seeing if it produces an
error?

A user is more likely to try `C-h b' to see which keys are available.
Especially if s?he wants to find multiple available bindings for a set of
related commands. Have you never done that: check to see which keys are not
bound in the current mode?

So, yes, such an isolated error message might (though a bit indirectly) help
a user to see that that particular key is, in effect, available. But:

a. It is an indirect indication. It requires understanding that since that
key cannot be used here because the buffer is read-only, it is, in effect,
available for some other use. It is far clearer to simply tell the user that
the key is `undefined'.

b. The information is after the fact (after trying that particular key).

c. It provides information for only that one key - it does not help you see
that _all_ "such keys" are also available, and it doesn't tell you what
those keys are.

d. It helps only if you start by trying that key, not if you try to look up
the current bindings (`C-h b') to see all that might be available.


Please see also the rest of the referenced email - in particular, point #1
and this part of #2:

> I don't think you have given any reason _why_ you "don't like much this
> idea"; you've just stated a preference. What are the disadvantages you see
> to this idea? Deciding on a good way to handle this should
> involve weighing the pros & cons.

RE: bind commands that change buffer contents to `undefined' when read-only?

[Davis Herring]

> It's not about the reaction to `C-h c' or to the read-only error message.
> It's about a user looking for available keys to bind in a particular
> context.
>
> Are you assuming that a user looking for available keys to bind starts
> with that error message, that is, by trying a key and seeing if it
> produces an error?

I've often done something like that: chosen a key first, then made sure it
was available (though perhaps with C-h c instead for safety).

> A user is more likely to try `C-h b' to see which keys are available.
> Especially if s?he wants to find multiple available bindings for a set of
> related commands. Have you never done that: check to see which keys are
> not bound in the current mode?

I wrote unbound.el (http://www.emacswiki.org/cgi-bin/wiki/unbound.el);
does that count?  C-h b is so verbose that it's useless to me.  And anyone
who is trying to find bindings for a whole family of commands is probably
sufficiently clued to just look at C-h m (and its description of the local
map) directly.

> So, yes, such an isolated error message might (though a bit indirectly)
> help
> a user to see that that particular key is, in effect, available. But:
>
> a. It is an indirect indication. It requires understanding that since that
> key cannot be used here because the buffer is read-only, it is, in effect,
> available for some other use. It is far clearer to simply tell the user
> that the key is `undefined'.

Er, it's clearer to tell them that if that is in fact the case!  But that
supposes your conclusion, that they should be undefined.  The status quo
is that, aside from self-inserters that we don't even really think of as
commands (but rather as "keyboard keys"), major modes override keys only
when they have something better to assign them.  This means that some
useless commands slip through; more on this under (c).

> b. The information is after the fact (after trying that particular key).

This is redundant with your (c): how would any key-specific help tell you
anything -before- you told it what key you were interested in?

> c. It provides information for only that one key - it does not help you
> see that _all_ "such keys" are also available, and it doesn't tell you
> what those keys are.

I think you may have (accidentally?) found the real point here.  What are
"such keys"?  Our presumed definition is "buffer-modifying keys in modes
associated with read-only buffers", but this is vague, incomplete, and
insufficiently specific all at once:

Vague: Is M-: a "buffer-modifying key"?  What about C-u M-:?

Incomplete: C-x 4 a never modifies the current buffer, but is quite
useless in, say, *Messages*.  Should we unbind it there?  (If so, in what
map?)  Similarly I -hope- `ffap' is useless to most people in hexl-mode.

Unspecific: I often find it useful to "hack" a Dired listing by making the
buffer writable and then using something like M-x keep-lines.  Obviously
M-x wouldn't be unbound, so this would continue to work, but why shouldn't
I also be able to use M-z in such a case?

Summary: trying to second-guess the global map by deciding that some of
its keys are "useless" in some environment is trying to be too clever. 
Instead: (continued)

> d. It helps only if you start by trying that key, not if you try to look
> up the current bindings (`C-h b') to see all that might be available.

And here you have the solution.  Let's take your list of modifying
commands (and any other commands that might be useless in some environment
or another) and add a simple command that runs `where-is' on it, dropping
any results that say "not bound".  Then a user can run the new M-x
what-keys-are-useless (with a better name) and have all and only the
relevant information, without any change to any keymaps.

> Please see also the rest of the referenced email - in particular, point #1
> and this part of #2:
>
>> I don't think you have given any reason _why_ you "don't like much this
>> idea"; you've just stated a preference. What are the disadvantages you
>> see to this idea? Deciding on a good way to handle this should
>> involve weighing the pros & cons.

Please do not tell me (I know this was not originally written to me, but
you have written similar things so directly) that I have not justified my
statements simply because you do not agree with the justifications.  I
said that I didn't think the use case (of a person looking for keys to
bind) was significantly improved by your proposal, which is why I don't
like it.  (Now, with more thought, I think I have come up with a better
proposal as well as better-understood why I prefer it.)

Never mind the necessary bias in favor of the status quo (necessary to
avoid endlessly reconsidering equally justified alternatives): it is up to
the proponent of a proposal to give -more- justification for it than can
be given for anything else.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: bind commands that change buffer contents to `undefined' when read-only?

[Stefan Monnier]

> A user is more likely to try `C-h b' to see which keys are available.

Could be, but to tell you the truth I've never seen anyone use C-h b (OK,
I adimit I've used it a couple times, but always only to see what it does,
not to see the info it gives me).

And the result is always so long anyway that I doubt a user would bother to
go through it to find a useful keybinding.  Instead, I expect he'd try
a keybinding which he finds convenient/intuitive/menmonic.  Or maybe he
wouldn't even try it and would go ahead and blindly bind the key and only
(much) later he may learn that the key he chose so may years ago actually
had another useful meaning.


        Stefan

Re: bind commands that change buffer contents to `undefined' when read-only?

[Richard Stallman]

    So maybe a better direction is to change the toplevel so that using
    a command with a "*" (or a call to barf-if-buffer-read-only) in its
    interactive spec when the buffer is read-only will signal "undefined" rather
    than signalling the error.

That is clean and simple, but I think it is a change for the worse.
Sorry, but no thanks.

Re: TAB for non-editing modes

[Richard Stallman]

	    dired-next-line
	    dired-next-dirline
	    dired-next-subdir
	    dired-next-marked-file

    Which one do you think would be the best to bind to TAB? Can you see a
    better binding?

I think we should not define TAB in Dired mode
until we have a better reason to do so.

RE: bind commands that change buffer contents to `undefined' when read-only?

[Drew Adams]

> I wrote unbound.el (http://www.emacswiki.org/cgi-bin/wiki/unbound.el);
> does that count?

Cool; I didn't know about that - great idea. What about adding that to
Emacs? It could perhaps be invoked with `C-h <something>'. Or it could
perhaps be invoked with some simple binding from the `C-h b' display. (See
also the EOM.)

> C-h b is so verbose that it's useless to me.

I agree that it's too verbose, but I still find it useful. It is all that
dead-tilde, dead-asciitilde etc. stuff and the self-insert-command stuff
that gets in the way. (No, I don't see the dead-tilde stuff in emacs -Q, but
I see it in my Emacs, and I have no idea where it's from or what it's for.)

Actually, a better use for `C-u C-h b' might be to show what we see now
(verbose), and let plain `C-h b' exclude some of the uninteresting stuff
(e.g. self-insert-command).

> And anyone who is trying to find bindings for a whole family of
> commands is probably sufficiently clued to just look at C-h m
> (and its description of the local map) directly.

That's why I mentioned `C-h b', but same idea. `C-h m' usually doesn't give
you any indication of unbound keys, AFAIK. It sometimes lists the bindings,
but that is anyway part of what you see in `C-h b'. In that case, `C-h m'
too would be improved by my suggestion to bind such keys to `undefined'.

> > So, yes, such an isolated error message might (though a bit indirectly)
> > help a user to see that that particular key is, in effect, available.
> > But:
> >
> > a. It is an indirect indication. It requires understanding that
> >    since that key cannot be used here because the buffer is
> >    read-only, it is, in effect, available for some other use.
> >    It is far clearer to simply tell the user that the key is
> >    `undefined'.
>
> Er, it's clearer to tell them that if that is in fact the case!  But that
> supposes your conclusion, that they should be undefined.

Right. _If_ they should be shown to users as "undefined" and thus available
for defining, _then_ binding them to `undefined' is a better way to show
that than relying upon read-only error messages. I said that before.

> The status quo is that, aside from self-inserters that we don't
> even really think of as commands (but rather as "keyboard keys"),
> major modes override keys only when they have something better
> to assign them.  This means that some useless commands slip
> through; more on this under (c).
>
> > b. The information is after the fact (after trying that particular key).
>
> This is redundant with your (c): how would any key-specific help tell you
> anything -before- you told it what key you were interested in?

If that specific key were bound to `undefined', then _any_ mention of its
binding would show you that information, not just a read-only error.
Whatever the context where that particular key's binding is shown, it is
indicated that that key is available.

> > c. It provides information for only that one key - it does not help you
> > see that _all_ "such keys" are also available, and it doesn't tell you
> > what those keys are.
>
> I think you may have (accidentally?) found the real point here.

Not accidentally, and not the only real point here.

> What are "such keys"?  Our presumed definition is "buffer-modifying
> keys in modes associated with read-only buffers", but this is vague,
> incomplete, and insufficiently specific all at once:

That's why I submitted a specific possible list, for discussion.

And that's why the list is a customizable variable (as opposed, for example,
to using a symbol property for each such command's symbol). Programs or
users can adjust the list contextually, as needed. For instance, Dired mode
could bind that variable to a list of commands that is appropriate, and then
call the function that binds commands to `undefined'.

> Vague: Is M-: a "buffer-modifying key"?  What about C-u M-:?

It wasn't on my list. Are you suggesting to include it? I would say it
should be excluded.

> Incomplete: C-x 4 a never modifies the current buffer, but is quite
> useless in, say, *Messages*.  Should we unbind it there?  (If so, in what
> map?)  Similarly I -hope- `ffap' is useless to most people in hexl-mode.

Agreed. There are many commands, some of which might be bound to keys, that
modify buffers. Not all of them should be part of the list of "such keys". I
did not include `C-x 4 a' either.  Are you suggesting to include it?

> Unspecific: I often find it useful to "hack" a Dired listing by making the
> buffer writable and then using something like M-x keep-lines.  Obviously
> M-x wouldn't be unbound, so this would continue to work, but why shouldn't
> I also be able to use M-z in such a case?

I'm not sure I follow you, but if I do, no, you would not be able to.

If that kind of thing is thought to be generally useful, then we might
modulate what I proposed, so that the key is undefined only when the buffer
is read-only. I don't have a particular mechanism in mind for that now, not
having thought about it.

> Summary: trying to second-guess the global map by deciding that some of
> its keys are "useless" in some environment is trying to be too clever.

Maybe you're right. As you know, I am typically against Emacs trying to be
too clever. In practice, I haven't found a difficulty with what I'm
proposing (and I've used it for years), but maybe others could try it and
pound on it a bit to see if they find it limiting.

> Instead: (continued)
>
> > d. It helps only if you start by trying that key, not if you try to look
> > up the current bindings (`C-h b') to see all that might be available.
>
> And here you have the solution.  Let's take your list of modifying
> commands (and any other commands that might be useless in some environment
> or another) and add a simple command that runs `where-is' on it, dropping
> any results that say "not bound".  Then a user can run the new M-x
> what-keys-are-useless (with a better name) and have all and only the
> relevant information, without any change to any keymaps.

That's just what I do in order to bind those keys to `undefined':

(defun undefine-keys-bound-to (command keymap)
  "Undefine all keys bound only by inheritance to COMMAND in KEYMAP.
If a key is bound to COMMAND in KEYMAP, but it is not bound directly
in KEYMAP, then bind it to `undefined' in KEYMAP."
  (dolist (key (where-is-internal command keymap))
    (when (and key (not (lookup-key keymap key)))
      (define-key keymap key 'undefined))))

(defun undefine-killer-commands (keymap)
  "Undefine KEYMAP keys that are bound to buffer-modifying commands.
For each key in KEYMAP that is indirectly bound to one of the commands in
`buffer-modifying-cmds', rebind it to `undefined'."
  (mapcar (lambda (cmd) (undefine-keys-bound-to cmd keymap))
          buffer-modifying-cmds))

But as Stefan, I think, pointed out, if this is built into Emacs it would
not need to be done in this after-the-fact way.

And your point is to leave it up to the user, via a `what-keys-are-useless'
command. That's a good argument.

> Never mind the necessary bias in favor of the status quo (necessary to
> avoid endlessly reconsidering equally justified alternatives): it is up to
> the proponent of a proposal to give -more- justification for it than can
> be given for anything else.

I agree with that, of course; absolutely.

And I think your `what-keys-are-useless' proposal is OK. But the name should
perhaps be changed - maybe `list-available-keys' or some such.

And the listing could distinguish keys that are truly unbound from those
that are bound to commands that might be inappropriate in the current mode.
And the latter might be divided into groups such as Richard suggested
(local/global buffer modifiers). IOW, the display would make it clear _why_
certain keys might be inappropriate in the current context - e.g., they try
to modify a read-only buffer.

Perhaps that is the best solution. It would also satisfy those who would
like to be able to pseudo-kill in a read-only buffer. The new command could
have the `C-h' prefix, perhaps `C-h u' (for "unbound" or "undefined" or
"useless" keys, as opposed to `C-h b' for  "bound" keys).

A disadvantage of that solution is that it is not readily apparent in other
listings and other mention of such keys that they are available (as
mentioned above). A user only gets that information upon demand. I could
live with that; it's still better than no indication at all of what's
available.

Re: bind commands that change buffer contents to `undefined' when read-only?

[Richard Stallman]

    > A user is more likely to try `C-h b' to see which keys are available.

    Could be, but to tell you the truth I've never seen anyone use C-h b (OK,
    I adimit I've used it a couple times, but always only to see what it does,
    not to see the info it gives me).

I've decided not to change the way these things work, so this
thread is not going to do something useful.

Re: bind commands that change buffer contents to `undefined' when read-only?

[Stefan Monnier]

>     So maybe a better direction is to change the toplevel so that using
>     a command with a "*" (or a call to barf-if-buffer-read-only) in its
>     interactive spec when the buffer is read-only will signal "undefined"
>     rather than signalling the error.

> That is clean and simple, but I think it is a change for the worse.

As a matter of fact, I agree ;-)

> Sorry, but no thanks.

Thanks,


        Stefan

RE: bind commands that change buffer contents to `undefined' whenread-only?

[Drew Adams]

> I've decided not to change the way these things work, so this
> thread is not going to do something useful.

OK. Let me mention in parting on this that in my own code I now respect the
value of `kill-read-only-ok': If it is non-nil, then I don't bind commands
that kill text to `undefined'. IOW:

(defcustom buffer-modifying-cmds
  (append
   (and kill-read-only-ok
        '(backward-kill-paragraph backward-kill-sentence
          backward-kill-sexp backward-kill-word clipboard-kill-region
          comint-kill-input comment-kill kill-backward-up-list
          kill-comment kill-line kill-paragraph kill-rectangle
          kill-region kill-sentence kill-sexp kill-whole-line
          kill-word mouse-kill))
   '(align-newline-and-indent backward-delete-char
     backward-delete-char-untabify
     bookmark-insert bookmark-insert-location
     canonically-space-region
     capitalize-region capitalize-word c-backslash-region
     c-context-line-break center-line center-paragraph center-region
     c-fill-paragraph c-hungry-delete-backwards
     c-hungry-delete-forward c-indent-command c-indent-defun
     c-indent-exp clear-rectangle comint-truncate-buffer comment-dwim
     comment-indent-new-line comment-region
     comment-or-uncomment-region complete-symbol compose-last-chars
     compose-region dabbrev-completion dabbrev-expand decompose-region
     delete-backward-char delete-blank-lines delete-char
     delete-horizontal-space delete-indentation delete-matching-lines
     delete-non-matching-lines delete-pair delete-rectangle
     delete-region delete-trailing-whitespace
     delete-whitespace-rectangle delimit-columns-region
     downcase-region downcase-word edit-picture expand-abbrev
     expand-region-abbrevs fill-individual-paragraphs
     fill-nonuniform-paragraphs fill-paragraph fill-region
     fill-region-as-paragraph format-insert-file flush-lines
     ido-insert-buffer ido-insert-file increase-left-margin
     increase-right-margin indent-code-rigidly indent-for-comment
     indent-for-tab-command indent-line-function
     indent-new-comment-line indent-pp-sexp indent-region
     indent-rigidly insert-abbrevs insert-buffer insert-file
     insert-file-literally insert-kbd-macro insert-pair
     insert-parentheses insert-register insert-zippyism join-line
     justify-current-line just-one-space keep-lines
     lisp-complete-symbol
     lisp-fill-paragraph lisp-indent-line morse-region
     newline newline-and-indent open-line open-rectangle query-replace
     query-replace-regexp quoted-insert
     reindent-then-newline-and-indent replace-regexp replace-string
     repunctuate-sentences reverse-region rot13-region
     self-insert-command set-justification-center
     set-justification-full set-justification-left
     set-justification-none set-justification-right set-left-margin
     set-right-margin skeleton-pair-insert-maybe smiley-region
     sort-columns sort-fields sort-lines sort-numeric-fields
     sort-pages sort-paragraphs split-line string-insert-rectangle
     string-rectangle studlify-region table-delete-column
     table-delete-row table-heighten-cell table-insert
     table-insert-column table-insert-row table-insert-sequence
     table-justify table-shorten-cell table-span-cell table-split-cell
     table-split-cell-horizontally table-split-cell-vertically
     table-widen-cell tab-to-tab-stop tabify texinfo-format-region
     tildify-region time-stamp todo-insert-item translate-region
     transpose-chars transpose-lines transpose-paragraphs
     transpose-sentences transpose-sexps transpose-words ucs-insert
     uncomment-region unmorse-region untabify upcase-region
     upcase-word vc-insert-headers whitespace-cleanup
     whitespace-cleanup-region yank yank-pop yank-rectangle
     zap-to-char))
  "*Buffer-modifying commands used in `undefine-killer-commands'."
  :type '(repeat symbol))

S-SPC for non-editing modes (was: TAB for non-editing modes)

[Juri Linkov]

>> For info, help, man, woman TAB does something like "goto the next link". 
>>
>> TAB does not do anything for pcvs, dired, log-view and maybe
>> others. It would be nice if TAB would do something for these modes
>> too.  A navigational semantic like info/help/man do seems that would be
>> intuitive (it should certainly be better than the current "error
>> because the buffer is read-only" behavior).
>> (similarly for backtab)
>>
>> Thoughts?
>
> Good and important idea. I think this is what most users would expect
> since both the modes you mention and programs like web browsers behaves
> this way.

BTW, should we bind S-SPC in some read-only modes to the same command
as is bound to DEL?  In most browsers S-SPC is a synonym of DEL which
scrolls the page backwards, and possibly users might expect it to work
the same as in Emacs, particularly in Info and view-mode.  What I propose
is at least to add two following bindings:

(define-key Info-mode-map [?\S- ] 'Info-scroll-down)
(define-key view-mode-map [?\S- ] 'View-scroll-page-backward)

to info.el and view.el.  Currently S-SPC is translated to SPC in these modes
which is useless.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: S-SPC for non-editing modes (was: TAB for non-editing modes)

[Drew Adams]

> BTW, should we bind S-SPC in some read-only modes to the same command
> as is bound to DEL?  In most browsers S-SPC is a synonym of DEL which
> scrolls the page backwards, and possibly users might expect it to work
> the same as in Emacs, particularly in Info and view-mode.  What I propose
> is at least to add two following bindings:
>
> (define-key Info-mode-map [?\S- ] 'Info-scroll-down)
> (define-key view-mode-map [?\S- ] 'View-scroll-page-backward)
>
> to info.el and view.el.  Currently S-SPC is translated to SPC in
> these modes which is useless.

Spend, spend, spend. Why not save a few bindings for a future rainy day? ;-)

The argument that we should do this because most browsers do it is a good
one, if true (I take your word for it).

But the argument that S-SPC is currently useless because it is unbound is
not a reason to bind it for this purpose.

Are new users really finding their habits so terribly violated by Emacs that
we need to make changes such as this? PageUp and PageDown are also used in
most browsers, and Emacs supports them. How much is enough?

Go ahead, if you really think it's helpful. If a better use for S-SPC comes
up, I'll argue to change it then. ;-)

Re: S-SPC for non-editing modes

[Juri Linkov]

> But the argument that S-SPC is currently useless because it is unbound is
> not a reason to bind it for this purpose.

It is not unbound, it duplicates SPC.

> Are new users really finding their habits so terribly violated by Emacs that
> we need to make changes such as this? PageUp and PageDown are also used in
> most browsers, and Emacs supports them. How much is enough?

Emacs supports PageUp and PageDown, but in very inconvenient way:
typing PageUp on the first screen doesn't move point to the beginning of
the buffer.

> Go ahead, if you really think it's helpful. If a better use for S-SPC comes
> up, I'll argue to change it then. ;-)

I know a better use, but only for editing modes where S-SPC could insert a
non-breaking space.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: S-SPC for non-editing modes (was: TAB for non-editing modes)

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> Go ahead, if you really think it's helpful. If a better use for S-SPC comes
> up, I'll argue to change it then. ;-)

Since S-SPC cannot normally be input from a tty it is unlikely to become
the standard key binding for a command.

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: S-SPC for non-editing modes

[Drew Adams]

> > But the argument that S-SPC is currently useless because it is
> > unbound is not a reason to bind it for this purpose.
>
> It is not unbound, it duplicates SPC.

S-SPC is not specifically bound. It is mapped to SPC by default. But this
quibble is unimportant.

> > Are new users really finding their habits so terribly violated
> > by Emacs that we need to make changes such as this? PageUp and
> > PageDown are also used in most browsers, and Emacs supports
> > them. How much is enough?
>
> Emacs supports PageUp and PageDown, but in very inconvenient way:
> typing PageUp on the first screen doesn't move point to the beginning of
> the buffer.

OK. Should that be changed? Why have two different behaviors for such
scrolling? Better to duplicate whichever behavior is best. Unless there is a
need for each.

> > Go ahead, if you really think it's helpful. If a better use for
> > S-SPC comes up, I'll argue to change it then. ;-)
>
> I know a better use, but only for editing modes where S-SPC could insert a
> non-breaking space.

I was thinking of that also.