bug#65621: [PATCH] `dired-next-line' go to meaningful line

[Drew Adams]

> Stefan likes my original patch, so please set
> `dired-cursor-goto-meaningful-line' to `bounded' and
> `dired-headerline-is-meaningful' to nil.
> 
> > Dradams:
> > it should move to the subdir header line, skipping
> > only the blank line before it.
> > `dired-(next|previous)-line' should move to header
> > lines, as well as to file/dir lines.
> > If you really DON'T want `n'|`p' to go to header
> > lines then maybe set some option.
> 
> Have taken your advice.

No, you haven't.  Not as far as I can see.

> You like what your Dired+ does, so please set
> `dired-cursor-goto-meaningful-line' to `cycle'
> and `dired-headerline-is-meaningful' to t.

No thanks.

Based on your description and the definition
of `dired-cursor-goto-meaningful-line' in your
patch, I disagree strongly with this change.

Currently users need not do anything to be able
to move to file, directory, and dir-header lines
with `n' and `p'.  Those lines are as actionable
as any others; they should not be skipped over.

That behavior should remain the default.  Users
should not need to do anything to have `n' and
`p' move to header lines.  Making users customize
an option just to get the longstanding (and only
useful) behavior would be a big step backward.

And it would be for no gain.  AFAIK, no reason
has been given why `n' and `p' should skip over
header lines.

`dired-cursor-goto-meaningful-line' must default
to `t'.

>From my point of view it need not (should not)
even be offered as an option: the `t' behavior
should just be all there is.

Have you - has anyone - given any reason at all
why `n' and `p' should ever skip header lines?
I don't think so.

(And there's no need for "cursor" in the option
name.  That's implicit in going to a line.)