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.