bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Michael Perry <amperry@provide.net> writes:
>
>> When visiting a directory in dired-mode, you get not only a list of contents,
>> but also a two-line header ('/path/to/directory' and 'total used ...')
>> and a trailing blank line. Those are a nuisance when navigating using
>> `M-<` and `M->'.
I have already raised this once, a year or two ago. Header in dired is quite
meaningless, for all these years I have ever never wanted to move cursor to
header in dired intentionally.

>> Can I suggest the following become standard?
>>
>> (with-eval-after-load "dired"
>>   (define-key dired-mode-map (kbd "M-<")
>>     (lambda () (interactive) (beginning-of-buffer) (next-line 2)))
>>   (define-key dired-mode-map (kbd "M->")
>>     (lambda () (interactive) (end-of-buffer) (previous-line 1))))

I have used those shortcut myself for quite some time, maybe a couple of years
or so. They are not so handy as I thought they would be. Mainly because I use
european keyboard, and have to fold in my thumb to access the M, and < and > are
next to shift key, so I have to move entire hand to reach those. I would rather
have Dired to use < and > to go to first and last 'filename' in dired, and M-<
and M-> to go to header. Or just jsut 'p' to go to header from the first line
with a filename, since I think it is so rarely used to actually go to header. I
guess header is useful if modeline is turned off?

> I'm fine with that, but
>
> a) I'd rather have something more general in place that works in more
>    modes than just Dired.
>
> b) I think you should be able to go to the absolute beginning or end of
>    the buffer with a subsequent M-< or M->.

Yes, in this case that would be better, and use < to move to first filename in
dired.

> For example, in message-mode, I often want to do `message-goto-body',
> but it would be nice if this would happen when I pressed M-< so I don't
> need to remember a special key binding for every mode.
>
> See the package beginend for previous work:
>
>     https://github.com/DamienCassou/beginend
>
> (Unfortunately, that package is not on GNU ELPA.)
>
>> It's truly a small issue, but it's an irritation that multiplies over time.
>
Agree with that one too.