bug#52384: 26.3; dired buffer navigation tweak

bug#52384: 26.3; dired buffer navigation tweak

[Michael Perry]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

Hello,

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

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

It's truly a small issue, but it's an irritation that multiplies over time.

Thanks for your consideration.

Cheers,
A.M. Perry

[-- Attachment #2: Type: text/html, Size: 2179 bytes --]

bug#52384: 26.3; dired buffer navigation tweak

[Stefan Kangas]

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

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.

Yup.

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.

bug#52384: 26.3; dired buffer navigation tweak

[Lars Ingebrigtsen]

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

(The second line has been removed in Emacs 29, and the first line has
been made useful in Emacs 28 (you can now click on the segments).)

> and a trailing blank line. Those are a nuisance when navigating using 
> `M-<` and `M->'. 
>
> 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)))) 
>
> It's truly a small issue, but it's an irritation that multiplies over time. 

I don't think we should do something like this in Dired buffers (or
anywhere else, for that matter).  I want commands like `M-<' to be
predictable across modes, and I certainly don't want `M->' to take me to
the start of the last line.  (What if I want to copy the region to the
clipboard, for instance?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

My 2c:

Leave `<' and `>' alone, letting them move to
the previous/next directory file line.

(The Dired+ versions of these commands wrap
around, if option `diredp-wrap-around-flag'
has its default value of `t'.)

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

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

> My 2c:
>
> Leave `<' and `>' alone, letting them move to
> the previous/next directory file line.

If you keep directories sorted before or after files then < and > become almost
redundant, since 'p' and 'n' will have same effect in practice. I say almost,
because there is instance when one is deep below in files and would like to jump
do directories (when sorted before). So pressing '<' would take you to the last
directory before files listing begin, and than one can use either p/n or </> to
move cursor.

I also think dired should use by default --group-directories-first/ls-lisp-dirs-first
to group directories before/after regular files. This seems to be asked quite
few times if you search the web, there are SX/Reddit questions, Emacs Wiki
article, some blogs, etc; so it seems to be asked/desired/expected behaviour.

I understand that this was optional back in time when computers were less
powerful, but nowadays sorting dirs before files is trivial. Pesonally I think
listings with dirs/files mixed look aesthetically more noisy and harder to find
what I looking for. Might be just me getting used to this style though.

> (The Dired+ versions of these commands wrap
> around, if option `diredp-wrap-around-flag'
> has its default value of `t'.)

I would suggest this option to make it's way into Emacs. Can't you suggest a
patch? Windmove has similar option for moving left-right windows to wrap
around. It would be handy if 'p' and 'n' and '<' and '>' would behave similarly.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

> > My 2c:
> > Leave `<' and `>' alone, letting them move to
> > the previous/next directory file line.
> 
> If you keep directories sorted before or after files then < and > become
> almost redundant, since 'p' and 'n' will have same effect in practice.

For some meaning of "almost".

> I say almost, because there is instance when one is deep below in files
> and would like to jump do directories (when sorted before). So pressing
> '<' would take you to the last directory before files listing begin, and
> than one can use either p/n or </> to move cursor.

That's far from the only case/difference.

`<' and `>' move only among dir-header lines.

They do that wherever those lines might be.
Including for inserted subdirs.

If you never insert subdir listings, and you
always list dir lines first, then, within that
block of dir headers (only), yes, `<' and `>' act
like `p' and `n'.  That's one case out of many.

> I also think dired should use by default
> --group-directories-first/ls-lisp-dirs-first...

Please file a separate enhancement request for
that, if you like.

> > (The Dired+ versions of these commands wrap
> > around, if option `diredp-wrap-around-flag'
> > has its default value of `t'.)
> 
> I would suggest this option to make it's way into Emacs. Can't you suggest a
> patch? Windmove has similar option for moving left-right windows to wrap
> around.

Giving such behavior to vanilla Emacs is trivial.
And I likely did propose it long ago, and there's
a chance I even provided code for it.  In any case,
the code isn't hard.

> It would be handy if 'p' and 'n' and '<' and '>' would behave
> similarly.

`p' and `n' do behave similarly, based on the same
user option.  And yes, I generally do provide
wraparound navigation etc. in my code.  It usually
makes sense to do so.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

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

>> > My 2c:
>> > Leave `<' and `>' alone, letting them move to
>> > the previous/next directory file line.
>> 
>> If you keep directories sorted before or after files then < and > become
>> almost redundant, since 'p' and 'n' will have same effect in practice.
>
> For some meaning of "almost".
>
>> I say almost, because there is instance when one is deep below in files
>> and would like to jump do directories (when sorted before). So pressing
>> '<' would take you to the last directory before files listing begin, and
>> than one can use either p/n or </> to move cursor.
>
> That's far from the only case/difference.
>
> `<' and `>' move only among dir-header lines.
Yeah I know. 
> They do that wherever those lines might be.
> Including for inserted subdirs.
>
> If you never insert subdir listings, and you
> always list dir lines first, then, within that
> block of dir headers (only), yes, `<' and `>' act
> like `p' and `n'.  That's one case out of many.
>
>> I also think dired should use by default
>> --group-directories-first/ls-lisp-dirs-first...
>
> Please file a separate enhancement request for
> that, if you like.
>
>> > (The Dired+ versions of these commands wrap
>> > around, if option `diredp-wrap-around-flag'
>> > has its default value of `t'.)
>> 
>> I would suggest this option to make it's way into Emacs. Can't you suggest a
>> patch? Windmove has similar option for moving left-right windows to wrap
>> around.
>
> Giving such behavior to vanilla Emacs is trivial.
> And I likely did propose it long ago, and there's
> a chance I even provided code for it.  In any case,
> the code isn't hard.
I don't think it is hard to code; it was just you already made it in
dired+, so it's your code, your thing, your patch :).

>> It would be handy if 'p' and 'n' and '<' and '>' would behave
>> similarly.
>
> `p' and `n' do behave similarly, based on the same
> user option.  And yes, I generally do provide
> wraparound navigation etc. in my code.  It usually
> makes sense to do so.
Yes, It would be nice if Emacs had consistent "wrap around" for more
things, as an option of course; like in windmove.el.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

> > Giving such behavior to vanilla Emacs is trivial.
> > And I likely did propose it long ago, and there's
> > a chance I even provided code for it.  In any case,
> > the code isn't hard.
>
> I don't think it is hard to code; it was just you already made it in
> dired+, so it's your code, your thing, your patch :).

As I said, I likely already did that, long ago.
Patches I submit are generally ignored.

If you think that the slight changes I made in
Dired+ for this are worth proposing in a patch,
feel free to do so.  But there's nothing special
about that particular coding.

> >> It would be handy if 'p' and 'n' and '<' and '>' would behave
> >> similarly.
> >
> > `p' and `n' do behave similarly, based on the same
> > user option.  And yes, I generally do provide
> > wraparound navigation etc. in my code.  It usually
> > makes sense to do so.
>
> Yes, It would be nice if Emacs had consistent "wrap around" for more
> things, as an option of course; like in windmove.el.

Yes, optionally.  Sometimes, as in Dired for
different kinds of navigation, a single option
could reasonably control wraparound for different
commands.  Other times, it's more appropriate to
have separate options.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Juri Linkov]

> (The Dired+ versions of these commands wrap
> around, if option `diredp-wrap-around-flag'
> has its default value of `t'.)

Yet another feature I had already implemented since Emacs 21.1
and sent to you for review in 2007.  But I don't use it too much
because it's not so useful with --group-directories-first
that really should be the default.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

> > (The Dired+ versions of these commands wrap
> > around, if option `diredp-wrap-around-flag'
> > has its default value of `t'.)
> 
> Yet another feature I had already implemented
> since Emacs 21.1 and sent to you for review in 2007.

Interesting.  Or is that tongue in cheek?

I just searched all messages I've received from
you, including those in 2007, from mailing lists
and direct mails, and I don't find any such
suggestion or review request.  Could you point
to it - I'm curious.  I expect that if that were
the case I would most likely have added it to
Dired+ long before I did (which was not until
July 12, 2013).

> But I don't use it too much because it's not
> so useful with --group-directories-first
> that really should be the default.

I have that as default for my own use.  But I
often change sort orders, especially for date.
And as I said, `>' and `<' make a difference
(from `n' and `p') when dirs aren't listed first
- as well as when there are inserted subdirs.
___

I also use `C-M-n' and `C-M-p', which move
sequentially among subdir listings, and `C-M-u'
and `C-M-d', which move among them hierarchically
(up/down a Dired tree).

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Juri Linkov]

>> > (The Dired+ versions of these commands wrap
>> > around, if option `diredp-wrap-around-flag'
>> > has its default value of `t'.)
>>
>> Yet another feature I had already implemented
>> since Emacs 21.1 and sent to you for review in 2007.
>
> Interesting.  Or is that tongue in cheek?
>
> I just searched all messages I've received from
> you, including those in 2007, from mailing lists
> and direct mails, and I don't find any such
> suggestion or review request.  Could you point
> to it - I'm curious.  I expect that if that were
> the case I would most likely have added it to
> Dired+ long before I did (which was not until
> July 12, 2013).

I don't remember exactly, but the closest is in the
thread "TAB for non-editing modes" on emacs-devel
with the discussion about using TAB in dired
to move between directories.  When TAB/S-TAB will go
to the next/previous directory, then `<' and `>'
will be free to use for going to the first/last file.

>> But I don't use it too much because it's not
>> so useful with --group-directories-first
>> that really should be the default.
>
> I have that as default for my own use.  But I
> often change sort orders, especially for date.

When you change sort orders, directories still
remain at the top?  So first are directories
sorted by date, then below files sorted by date?

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

> >> > (The Dired+ versions of these commands wrap
> >> > around, if option `diredp-wrap-around-flag'
> >> > has its default value of `t'.)
> >>
> >> Yet another feature I had already implemented
> >> since Emacs 21.1 and sent to you for review in 2007.
> >
> > Interesting.  Or is that tongue in cheek?
> >
> > I just searched all messages I've received from
> > you, including those in 2007, from mailing lists
> > and direct mails, and I don't find any such
> > suggestion or review request.  Could you point
> > to it - I'm curious.  I expect that if that were
> > the case I would most likely have added it to
> > Dired+ long before I did (which was not until
> > July 12, 2013).
> 
> I don't remember exactly, but the closest is in the
> thread "TAB for non-editing modes" on emacs-devel
> with the discussion about using TAB in dired
> to move between directories.  When TAB/S-TAB will go
> to the next/previous directory, then `<' and `>'
> will be free to use for going to the first/last file.

This is that thread:

https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01976.html

I see nothing there that resembles anything like an 
implementation of wraparound navigation for Dired,
let alone a request by you to review that.  I don't
even find any suggestion that such wraparound be
added to Dired.  I see nothing even vaguely related
to a suggestion about wraparound navigation.

Checking your and my posts (and others) in that
thread, I find nothing about any of this.  Could
you point to the message(s) you're referring to?
A URL would be good.
___

More importantly, `<' and `>' going to the first
and last file, respectively, has nothing to do with
wraparound.  So if that's what you suggested or
implemented, it's something else entirely.

> >> But I don't use it too much because it's not
> >> so useful with --group-directories-first
> >> that really should be the default.
> >
> > I have that as default for my own use.  But I
> > often change sort orders, especially for date.
> 
> When you change sort orders, directories still
> remain at the top?  So first are directories
> sorted by date, then below files sorted by date?

For my own use, I use non-nil `ls-lisp-dirs-first',
so directories remain listed first.  (But I use
`emacs -Q` for some testing and some bug filing.)

When `ls-lisp-dirs-first' is non-nil, dirs are
listed first.  And yes, their order changes when
sorting is by date vs name, or some other order.
But as a group, yes, they remain listed first,
before ordinary files, within any given dir
listing.

The point is that it can be useful to sometimes
see some or all dir lines interspersed with
ordinary-file lines.

Again, a classic example is when subdir listings
are inserted: Directory lines in those listings
are separated from those of the main listing and
from those of other subdir listings.  `>' and
`<' let you move among consecutive dir lines
throughout the buffer.

`<' and `>' have their own raisons d'etre.  They
are not the same as `p' and `n'.  (And yes, it
makes sense for both >/< and n/p to optionally
wrap around.)

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Juri Linkov]

>> >> > (The Dired+ versions of these commands wrap
>> >> > around, if option `diredp-wrap-around-flag'
>> >> > has its default value of `t'.)
>> >>
>> >> Yet another feature I had already implemented
>> >> since Emacs 21.1 and sent to you for review in 2007.
>> >
>> > Interesting.  Or is that tongue in cheek?
>> >
>> > I just searched all messages I've received from
>> > you, including those in 2007, from mailing lists
>> > and direct mails, and I don't find any such
>> > suggestion or review request.  Could you point
>> > to it - I'm curious.  I expect that if that were
>> > the case I would most likely have added it to
>> > Dired+ long before I did (which was not until
>> > July 12, 2013).
>> 
>> I don't remember exactly, but the closest is in the
>> thread "TAB for non-editing modes" on emacs-devel
>> with the discussion about using TAB in dired
>> to move between directories.  When TAB/S-TAB will go
>> to the next/previous directory, then `<' and `>'
>> will be free to use for going to the first/last file.
>
> This is that thread:
>
> https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01976.html
>
> I see nothing there that resembles anything like an 
> implementation of wraparound navigation for Dired,
> let alone a request by you to review that.  I don't
> even find any suggestion that such wraparound be
> added to Dired.  I see nothing even vaguely related
> to a suggestion about wraparound navigation.
>
> Checking your and my posts (and others) in that
> thread, I find nothing about any of this.  Could
> you point to the message(s) you're referring to?
> A URL would be good.

Strange, I have a message in the archive from 24 Sep,
but it doesn't exist on the thread that you posted.

> More importantly, `<' and `>' going to the first
> and last file, respectively, has nothing to do with
> wraparound.  So if that's what you suggested or
> implemented, it's something else entirely.

I suggested to use TAB that goes to the next file
and wraps around at boundaries.  Then '>' could be
reused to go to the last file.

>> >> But I don't use it too much because it's not
>> >> so useful with --group-directories-first
>> >> that really should be the default.
>> >
>> > I have that as default for my own use.  But I
>> > often change sort orders, especially for date.
>> 
>> When you change sort orders, directories still
>> remain at the top?  So first are directories
>> sorted by date, then below files sorted by date?
>
> For my own use, I use non-nil `ls-lisp-dirs-first',
> so directories remain listed first.  (But I use
> `emacs -Q` for some testing and some bug filing.)
>
> When `ls-lisp-dirs-first' is non-nil, dirs are
> listed first.  And yes, their order changes when
> sorting is by date vs name, or some other order.
> But as a group, yes, they remain listed first,
> before ordinary files, within any given dir
> listing.
>
> The point is that it can be useful to sometimes
> see some or all dir lines interspersed with
> ordinary-file lines.
>
> Again, a classic example is when subdir listings
> are inserted: Directory lines in those listings
> are separated from those of the main listing and
> from those of other subdir listings.  `>' and
> `<' let you move among consecutive dir lines
> throughout the buffer.
>
> `<' and `>' have their own raisons d'etre.  They
> are not the same as `p' and `n'.  (And yes, it
> makes sense for both >/< and n/p to optionally
> wrap around.)

Maybe then like there is a user option `ls-lisp-dirs-first'
for ls-lisp.el, a similar option should be added to dired as well,
so users won't need to manually add "--group-directories-first"
to `dired-listing-switches'.  Do you agree?

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>>> >> > (The Dired+ versions of these commands wrap
>>> >> > around, if option `diredp-wrap-around-flag'
>>> >> > has its default value of `t'.)
>>> >>
>>> >> Yet another feature I had already implemented
>>> >> since Emacs 21.1 and sent to you for review in 2007.
>>> >
>>> > Interesting.  Or is that tongue in cheek?
>>> >
>>> > I just searched all messages I've received from
>>> > you, including those in 2007, from mailing lists
>>> > and direct mails, and I don't find any such
>>> > suggestion or review request.  Could you point
>>> > to it - I'm curious.  I expect that if that were
>>> > the case I would most likely have added it to
>>> > Dired+ long before I did (which was not until
>>> > July 12, 2013).
>>> 
>>> I don't remember exactly, but the closest is in the
>>> thread "TAB for non-editing modes" on emacs-devel
>>> with the discussion about using TAB in dired
>>> to move between directories.  When TAB/S-TAB will go
>>> to the next/previous directory, then `<' and `>'
>>> will be free to use for going to the first/last file.
>>
>> This is that thread:
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01976.html
>>
>> I see nothing there that resembles anything like an 
>> implementation of wraparound navigation for Dired,
>> let alone a request by you to review that.  I don't
>> even find any suggestion that such wraparound be
>> added to Dired.  I see nothing even vaguely related
>> to a suggestion about wraparound navigation.
>>
>> Checking your and my posts (and others) in that
>> thread, I find nothing about any of this.  Could
>> you point to the message(s) you're referring to?
>> A URL would be good.
>
> Strange, I have a message in the archive from 24 Sep,
> but it doesn't exist on the thread that you posted.
>
>> More importantly, `<' and `>' going to the first
>> and last file, respectively, has nothing to do with
>> wraparound.  So if that's what you suggested or
>> implemented, it's something else entirely.
>
> I suggested to use TAB that goes to the next file
> and wraps around at boundaries.  Then '>' could be
> reused to go to the last file.
>
>>> >> But I don't use it too much because it's not
>>> >> so useful with --group-directories-first
>>> >> that really should be the default.
>>> >
>>> > I have that as default for my own use.  But I
>>> > often change sort orders, especially for date.
>>> 
>>> When you change sort orders, directories still
>>> remain at the top?  So first are directories
>>> sorted by date, then below files sorted by date?
>>
>> For my own use, I use non-nil `ls-lisp-dirs-first',
>> so directories remain listed first.  (But I use
>> `emacs -Q` for some testing and some bug filing.)
>>
>> When `ls-lisp-dirs-first' is non-nil, dirs are
>> listed first.  And yes, their order changes when
>> sorting is by date vs name, or some other order.
>> But as a group, yes, they remain listed first,
>> before ordinary files, within any given dir
>> listing.
>>
>> The point is that it can be useful to sometimes
>> see some or all dir lines interspersed with
>> ordinary-file lines.
>>
>> Again, a classic example is when subdir listings
>> are inserted: Directory lines in those listings
>> are separated from those of the main listing and
>> from those of other subdir listings.  `>' and
>> `<' let you move among consecutive dir lines
>> throughout the buffer.
>>
>> `<' and `>' have their own raisons d'etre.  They
>> are not the same as `p' and `n'.  (And yes, it
>> makes sense for both >/< and n/p to optionally
>> wrap around.)
>
> Maybe then like there is a user option `ls-lisp-dirs-first'
> for ls-lisp.el, a similar option should be added to dired as well,
> so users won't need to manually add "--group-directories-first"
> to `dired-listing-switches'.  Do you agree?

After I posted my comment to Drew, I realized later, that
'--group-directories-first' does not exist in all 'ls' implementations. Bsd ls
does not seem to have it, correct me if I am wrong, so I am not sure it can be a
default for Emacs. Unless Emacs defaults to ls-lisp.el on all platforms but
gnu/Linux?

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Juri Linkov]

>> Maybe then like there is a user option `ls-lisp-dirs-first'
>> for ls-lisp.el, a similar option should be added to dired as well,
>> so users won't need to manually add "--group-directories-first"
>> to `dired-listing-switches'.  Do you agree?
>
> After I posted my comment to Drew, I realized later, that
> '--group-directories-first' does not exist in all 'ls' implementations. Bsd ls
> does not seem to have it, correct me if I am wrong, so I am not sure it can be a
> default for Emacs.

Maybe such 'ls' implementations could be detected using something like
'grep-probe'?

> Unless Emacs defaults to ls-lisp.el on all platforms but gnu/Linux?

Dired defaults to ls-lisp.el on ms-dos and windows-nt, and
'ls-lisp-dirs-first' default to t when 'ls-lisp-emulation' is 'MS-Windows'.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sun, 12 Dec 2021 20:15:44 +0100
> Cc: Michael Perry <amperry@provide.net>, Stefan Kangas <stefan@marxist.se>,
>  "52384@debbugs.gnu.org" <52384@debbugs.gnu.org>
> 
> After I posted my comment to Drew, I realized later, that
> '--group-directories-first' does not exist in all 'ls' implementations. Bsd ls
> does not seem to have it, correct me if I am wrong, so I am not sure it can be a
> default for Emacs. Unless Emacs defaults to ls-lisp.el on all platforms but
> gnu/Linux?

No, ls-lisp.el is not used on any Posix hosts.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Drew Adams]

> > This is that thread:
> > https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01976.html
> >
> > Checking your and my posts (and others) in that
> > thread, I find nothing about any of this.  Could
> > you point to the message(s) you're referring to?
> > A URL would be good.
> 
> Strange, I have a message in the archive from 24 Sep,
> but it doesn't exist on the thread that you posted.

Could you please post the URL to that message,
whatever thread it might be in?

> > More importantly, `<' and `>' going to the first
> > and last file, respectively, has nothing to do with
> > wraparound.  So if that's what you suggested or
> > implemented, it's something else entirely.
> 
> I suggested to use TAB that goes to the next file
> and wraps around at boundaries.  Then '>' could be
> reused to go to the last file.

I see.  Apparently I didn't see or notice your
suggestion.

> Maybe then like there is a user option `ls-lisp-dirs-first'
> for ls-lisp.el, a similar option should be added to dired as well,
> so users won't need to manually add "--group-directories-first"
> to `dired-listing-switches'.  Do you agree?

That's kinda outside the scope of this bug thread.
But yes, FWIW I agree: I think such an option
would make sense.

(Not that my opinion would make any difference.)

Probably `ls-lisp-dirs-first' should take precedence,
however, as someone might well want dirs-first only
on MS Windows (or more generally, when `ls-lisp.el'
is loaded).

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Juri Linkov]

>> > This is that thread:
>> > https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01976.html
>> >
>> > Checking your and my posts (and others) in that
>> > thread, I find nothing about any of this.  Could
>> > you point to the message(s) you're referring to?
>> > A URL would be good.
>>
>> Strange, I have a message in the archive from 24 Sep,
>> but it doesn't exist on the thread that you posted.
>
> Could you please post the URL to that message,
> whatever thread it might be in?

Maybe this?  I'm not sure.
https://lists.gnu.org/archive/html/emacs-devel/2007-09/msg02142.html

>> > More importantly, `<' and `>' going to the first
>> > and last file, respectively, has nothing to do with
>> > wraparound.  So if that's what you suggested or
>> > implemented, it's something else entirely.
>>
>> I suggested to use TAB that goes to the next file
>> and wraps around at boundaries.  Then '>' could be
>> reused to go to the last file.
>
> I see.  Apparently I didn't see or notice your
> suggestion.
>
>> Maybe then like there is a user option `ls-lisp-dirs-first'
>> for ls-lisp.el, a similar option should be added to dired as well,
>> so users won't need to manually add "--group-directories-first"
>> to `dired-listing-switches'.  Do you agree?
>
> That's kinda outside the scope of this bug thread.
> But yes, FWIW I agree: I think such an option
> would make sense.
>
> (Not that my opinion would make any difference.)
>
> Probably `ls-lisp-dirs-first' should take precedence,
> however, as someone might well want dirs-first only
> on MS Windows (or more generally, when `ls-lisp.el'
> is loaded).

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sun, 12 Dec 2021 20:15:44 +0100
>> Cc: Michael Perry <amperry@provide.net>, Stefan Kangas <stefan@marxist.se>,
>>  "52384@debbugs.gnu.org" <52384@debbugs.gnu.org>
>> 
>> After I posted my comment to Drew, I realized later, that
>> '--group-directories-first' does not exist in all 'ls' implementations. Bsd ls
>> does not seem to have it, correct me if I am wrong, so I am not sure it can be a
>> default for Emacs. Unless Emacs defaults to ls-lisp.el on all platforms but
>> gnu/Linux?
>
> No, ls-lisp.el is not used on any Posix hosts.

I thought so; would it be unrealistic to suggest that Emacs by default switches
to ls-lisp.el on all hosts?

I have done some measurements, not very scientific, just tested simply gnu ls vs
directory-files on my Arch Linux, with a directory ~5000 files. As I see it on
my computer, the most of time is spent on I/O, once the system has cached
inodes, it almost does not matter if I use ls binary or sl-lisp.el, or
directory-files directly:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
(0.202678959 0 0.0)

ELISP> (benchmark-run 1 (directory-files "/s/backup/unsorted"))
(0.003737047 0 0.0)

ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
(0.001892588 0 0.0)

ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
(0.001898974 0 0.0)

ls is faster of course, but not like a magnitude faster.

That is off a mechanical drive.

Switching to ls-lisp.el would let Dired be stup for consistent behavior on all
platforms and we could have directories grouped by default. At least according
to web search that seems to be often asked question for both Emacs users, and
even MacOS Finder users. With other words, it seems like it is a behavior
prefered by lot of users.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Stefan Kangas]

Arthur Miller <arthur.miller@live.com> writes:

> I thought so; would it be unrealistic to suggest that Emacs by default switches
> to ls-lisp.el on all hosts?

ls-lisp.el is intended for MS-Windows, so IMO that would be a step
backwards.

If we want to use some GNU ls specific flags, it would be better to try
to detect GNU ls in some other way.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: juri@linkov.net,  amperry@provide.net,  stefan@marxist.se,
>   52384@debbugs.gnu.org
> Date: Mon, 13 Dec 2021 11:14:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, ls-lisp.el is not used on any Posix hosts.
> 
> I thought so; would it be unrealistic to suggest that Emacs by default switches
> to ls-lisp.el on all hosts?

Yes.  ls-lisp doesn't support all of the switches that GNU ls
supports.

> I have done some measurements, not very scientific, just tested simply gnu ls vs
> directory-files on my Arch Linux, with a directory ~5000 files. As I see it on
> my computer, the most of time is spent on I/O, once the system has cached
> inodes, it almost does not matter if I use ls binary or sl-lisp.el, or
> directory-files directly:
> 
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
> (0.202678959 0 0.0)
> 
> ELISP> (benchmark-run 1 (directory-files "/s/backup/unsorted"))
> (0.003737047 0 0.0)
> 
> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
> (0.001892588 0 0.0)
> 
> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
> (0.001898974 0 0.0)
> 
> ls is faster of course, but not like a magnitude faster.

I don't understand what you compared here.  Which results are wil ls
and which with ls-lisp?  And why do you benchmark directory-files and
nit insert-directory?

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: juri@linkov.net,  amperry@provide.net,  stefan@marxist.se,
>>   52384@debbugs.gnu.org
>> Date: Mon, 13 Dec 2021 11:14:27 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > No, ls-lisp.el is not used on any Posix hosts.
>> 
>> I thought so; would it be unrealistic to suggest that Emacs by default switches
>> to ls-lisp.el on all hosts?
>
> Yes.  ls-lisp doesn't support all of the switches that GNU ls
> supports.

Yes, I know it does not.. The idea is that it does not need to support
everything. By default it only uses -la flags anyway. Users who need extra
ffeatures of gnu ls, has to add extra switches themselves anyway. Also, gnu ls
is supported out of the box, probably only on gnu/Linux systems. Those users (me
included) could set ls-lisp-use-insert-directory-program to t, as MS users do
nowadays. As said, that would allow Emacs to count on uniform interface in Dired
by default at least, and could come with option to group directories by default.

>> I have done some measurements, not very scientific, just tested simply gnu ls vs
>> directory-files on my Arch Linux, with a directory ~5000 files. As I see it on
>> my computer, the most of time is spent on I/O, once the system has cached
>> inodes, it almost does not matter if I use ls binary or sl-lisp.el, or
>> directory-files directly:
>> 
>> *** Welcome to IELM ***  Type (describe-mode) for help.
>> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
>> (0.202678959 0 0.0)
>> 
>> ELISP> (benchmark-run 1 (directory-files "/s/backup/unsorted"))
>> (0.003737047 0 0.0)
>> 
>> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
>> (0.001892588 0 0.0)
>> 
>> ELISP> (benchmark-run 1 (find-file "/s/backup/unsorted"))
>> (0.001898974 0 0.0)
>> 
>> ls is faster of course, but not like a magnitude faster.
>
> I don't understand what you compared here.  Which results are wil ls
> and which with ls-lisp?  And why do you benchmark directory-files and
> nit insert-directory?

It was just a quick run to show that file listing is dominated by I/O
not so much by extra lisp work. First run is opening a directory which was not
opened in my system earlier, so OS has to catch it from the disk. First
find-file is with with gnu ls, other with ls-lisp.el. I threw in directory-files
since I think it is the lowest built-in to list files without additional work on
top of it. I was just after showing that performance is not suffering too much
if Emacs used ls-lisp.el by default.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I thought so; would it be unrealistic to suggest that Emacs by default switches
>> to ls-lisp.el on all hosts?
>
> ls-lisp.el is intended for MS-Windows, so IMO that would be a step
> backwards.

Why is it a step backwards?

> If we want to use some GNU ls specific flags, it would be better to try
> to detect GNU ls in some other way.

Yes, that is another possibility, but it means more work for not so much
benefit (docs, manual, detection).

Personally I could imagine Emacs going over to completely use it's own
facilities and left external binary to those who find they need some extra
feature or speed.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: juri@linkov.net,  52384@debbugs.gnu.org,  stefan@marxist.se,
>   amperry@provide.net
> Date: Mon, 13 Dec 2021 17:21:56 +0100
> 
> >> I thought so; would it be unrealistic to suggest that Emacs by default switches
> >> to ls-lisp.el on all hosts?
> >
> > Yes.  ls-lisp doesn't support all of the switches that GNU ls
> > supports.
> 
> Yes, I know it does not.. The idea is that it does not need to support
> everything. By default it only uses -la flags anyway. Users who need extra
> ffeatures of gnu ls, has to add extra switches themselves anyway.

When they do add those extra switches, they will complain that those
switches have no effect, whereas they did in previous Emacs versions.

bug#52384: [External] : bug#52384: 26.3; dired buffer navigation tweak

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: juri@linkov.net,  52384@debbugs.gnu.org,  stefan@marxist.se,
>>   amperry@provide.net
>> Date: Mon, 13 Dec 2021 17:21:56 +0100
>> 
>> >> I thought so; would it be unrealistic to suggest that Emacs by default switches
>> >> to ls-lisp.el on all hosts?
>> >
>> > Yes.  ls-lisp doesn't support all of the switches that GNU ls
>> > supports.
>> 
>> Yes, I know it does not.. The idea is that it does not need to support
>> everything. By default it only uses -la flags anyway. Users who need extra
>> ffeatures of gnu ls, has to add extra switches themselves anyway.
>
> When they do add those extra switches, they will complain that those
> switches have no effect, whereas they did in previous Emacs versions.

Ok I guess further commenting would regress into the usual old  "better
defaults" discussion, so let's rather not.