GNU bug report logs -
#65621
[PATCH] `dired-next-line' go to meaningful line
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65621 in the body.
You can then email your comments to 65621 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 13:09:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Shynur Xie <one.last.kiss <at> outlook.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 30 Aug 2023 13:09:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Cursor in Dired buffer sometimes go to a line which is not an item
line. For example, the 1st line and the last line:
> d:/Desktop/.emacs.d/site-lisp:
drwxrwxrwx shynur 4096 08/30 18:15 .
drwxrwxrwx shynur 4096 08/30 18:07 ..
-rw-rw-rw- shynur 304 08/09 3:01 subdirs.el
> \Newline here.
Avoiding these lines may improve the experience when moving cursor.
The attaching patch implements this.
If there is no visible item line, move the cursor as Dired used to do.
[0001-dired-next-line-go-to-meaningful-line.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 13:37:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> Date: Wed, 30 Aug 2023 13:02:43 +0000
>
> Cursor in Dired buffer sometimes go to a line which is not an item
> line. For example, the 1st line and the last line:
>
> > d:/Desktop/.emacs.d/site-lisp:
> drwxrwxrwx shynur 4096 08/30 18:15 .
> drwxrwxrwx shynur 4096 08/30 18:07 ..
> -rw-rw-rw- shynur 304 08/09 3:01 subdirs.el
> > \Newline here.
>
> Avoiding these lines may improve the experience when moving cursor.
> The attaching patch implements this.
>
> If there is no visible item line, move the cursor as Dired used to do.
Thanks, but I personally fail to see why people would like this. It
basically means that if I want to copy those "forbidden" lines to the
kill ring or the clipboard, I can't (except by disabling this
feature). Is it really a good idea?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 13:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> It basically means that if I want to copy those "forbidden" lines to
> the kill ring or the clipboard, I can't (except by disabling this
> feature).
Just use mouse, `{forward,backward}-{char,word}',
`{previous,next}-line', etc. Anyway, I just changed the definition of
`dired-next-line', so actually users have many ways to do what they
want.
> I personally fail to see why people would like this.
Isn't it great that no matter how you move up or down, you never leave
the item line? Without this, if you move the cursor to the last line
accidentally, to enter one of those files, you need to press one more
keystroke.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 14:22:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> CC: "65621 <at> debbugs.gnu.org" <65621 <at> debbugs.gnu.org>
> Date: Wed, 30 Aug 2023 13:50:34 +0000
> msip_labels:
>
> > It basically means that if I want to copy those "forbidden" lines to
> > the kill ring or the clipboard, I can't (except by disabling this
> > feature).
>
> Just use mouse, `{forward,backward}-{char,word}',
> `{previous,next}-line', etc. Anyway, I just changed the definition of
> `dired-next-line', so actually users have many ways to do what they
> want.
>
> > I personally fail to see why people would like this.
>
> Isn't it great that no matter how you move up or down, you never leave
> the item line? Without this, if you move the cursor to the last line
> accidentally, to enter one of those files, you need to press one more
> keystroke.
It doesn't bother me, but I will let others chime in and speak their
opinions. If enough people like this feature, we could install it,
but I think even then it will need to be an opt-in feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 14:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Be sure to consider also the behavior when
subdir listings are inserted in the buffer.
(Didn't try your patch; just sayin'.)
___
FWIW, I think that the right way to deal
with this is what's done in `dired+.el':
1. There's an option, `diredp-wrap-around-flag',
which controls wrapping around to the buffer
beginning/end when using `n'/`p'.
That is, it says whether moving down when
there's no file/dired/header line further down
wraps to the beginning (first such line in the
buffer), and similarly when moving up when
there's no such line above.
2. Commands `dired-(next|previous)-line' have
their keys remapped to commands that respect
the option (`diredp-(next|previous)-line').
Simple, useful, IMO. (Likely suggested
before to `emacs-devel' but rejected.)
___
Commands `diredp-(next|previous)-line' also
have the improvement that they respect var
`goal-column': If non-nil then they put the
cursor at that column.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 15:41:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Dradams:
> Be sure to consider also the behavior when subdir listings are
> inserted in the buffer. (Didn't try your patch; just sayin'.)
Thanks.
> Dradams:
> I think that the right way to deal with this is what's done in
> `dired+.el'.
Sounds good; I'll try it (and add it to my configuration after I learn
how to fetch a package from a URL to integrate third-party package
with my package management system).
> Eli:
> If enough people like this feature, we could install it, but I think
> even then it will need to be an opt-in feature.
It's OK. If they do like it, I'll rewrite the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 15:57:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> > I think that the right way to deal with this is what's done in
> > `dired+.el'.
>
> Sounds good; I'll try it (and add it to my configuration after I learn
> how to fetch a package from a URL to integrate third-party package
> with my package management system).
Just save file `dired+.el' locally, byte-compile
it (optional), put the directory where you saved
it into your `load-path`, and `(require 'dired+)'.
Or just `M-x load-library' or `M-x load-file', to
try it out.
Or just copy the definitions of the option and
commands and try them out.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 19:15:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> > Isn't it great that no matter how you move up or down, you never leave
> > the item line? Without this, if you move the cursor to the last line
> > accidentally, to enter one of those files, you need to press one more
> > keystroke.
>
> It doesn't bother me, but I will let others chime in and speak their
> opinions. If enough people like this feature, we could install it,
> but I think even then it will need to be an opt-in feature.
I'd probably enable it if we had such an option, FWIW.
But Drew's point about inserted subdirs would need to be addressed.
My ideal behavior in that case is that it jumps to the file in the
next/previous directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 20:59:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> I'd probably enable it if we had such an option, FWIW.
>
> But Drew's point about inserted subdirs would need to be addressed.
> My ideal behavior in that case is that it jumps to the file in the
> next/previous directory.
IMO, _definitely not_. At most it should move
to the subdir header line, skipping only the
blank line before it.
The dired+.el optional wraparound behavior I
described moves, like the vanilla behavior, to
the next line. It just wraps around, so it
doesn't move to the last line of the buffer
(which is empty).
It could be argued that the blank lines that
precede headings of inserted subdirs could be
skipped over. But it should _definitely_ move
to the header lines themselves.
There are lots of Dired operations that you can
use on directory header lines. `m', for example,
marks each line shown in the subdir listing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 21:36:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> > But Drew's point about inserted subdirs would need to be addressed.
> > My ideal behavior in that case is that it jumps to the file in the
> > next/previous directory.
>
> IMO, _definitely not_. At most it should move
> to the subdir header line, skipping only the
> blank line before it.
OK, makes sense.
> The dired+.el optional wraparound behavior I
> described moves, like the vanilla behavior, to
> the next line. It just wraps around, so it
> doesn't move to the last line of the buffer
> (which is empty).
I find wraparound rather disorienting myself, but I can see why one
might find it useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Wed, 30 Aug 2023 22:37:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> > > But Drew's point about inserted subdirs would need to be addressed.
> > > My ideal behavior in that case is that it jumps to the file in the
> > > next/previous directory.
> >
> > IMO, _definitely not_. At most it should move
> > to the subdir header line, skipping only the
> > blank line before it.
>
> OK, makes sense.
>
> > The dired+.el optional wraparound behavior I
> > described moves, like the vanilla behavior, to
> > the next line. It just wraps around, so it
> > doesn't move to the last line of the buffer
> > (which is empty).
>
> I find wraparound rather disorienting myself,
> but I can see why one might find it useful.
It's an _option_. That said, I can't imagine
wanting to go to the last (empty) line in the
buffer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 05:46:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Stefan:
> I'd probably enable it if we had such an option, FWIW.
Thank you!
> Stefan:
> But Drew's point about inserted subdirs would need to be addressed.
> My ideal behavior in that case is that it jumps to the file in the
> next/previous directory.
> Dradams:
> At most it should move to the subdir header line, skipping only the
> blank line before it.
Let's make thing simple:
I'll fix the inserting subdirs case, and make this an optional
feature which is disabled by default.
> Dradams:
> It could be argued that the blank lines that precede headings of
> inserted subdirs could be skipped over. But it should _definitely_
> move to the header lines themselves.
You can move anywhere you want _easily_ no matter whether this feature
is enabled. As I said before:
> shynur:
> Just use mouse, `{forward,backward}-{char,word}',
> `{previous,next}-line', etc. Anyway, I just changed the definition
> of `dired-next-line', so actually users have many ways to do what
> they want.
___
I've started rewriting; this shouldn't be too difficult.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 15:36:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> > Dradams:
> > It could be argued that the blank lines that precede headings of
> > inserted subdirs could be skipped over. But it should _definitely_
> > move to the header lines themselves.
>
> You can move anywhere you want _easily_ no matter whether
> this feature is enabled. As I said before:
>
> > Just use mouse, `{forward,backward}-{char,word}',
> > `{previous,next}-line', etc. Anyway, I just changed the definition
> > of `dired-next-line', so actually users have many ways to do what
> > they want.
No, no, no. `dired-(next|previous)-line' should
move to header lines, as well as to file/dir lines.
This is important.
As I said, users can perform actions (I gave the
example of `m') on header lines, just as they can
on file/dir lines. And in many cases, they can
invoke the _same_ commands (e.g. `dired-mark',
bound to `m'), often with the meaning of applying
to all files/dirs in the listing for that header.
Let's not change Dired willy nilly. Let's please
learn it well enough to take into account its
existing (and longstanding) behavior in some area,
before opting to change it.
In this case: there's a reason we have `n' and `p'
bound to Dired-specific commands. Navigation
destination should generally be somewhere you can
do something Dired-specific. Put differently, it
should _at least include_ places where you can do
something Dired-specific.
Same thing for other Dired navigation commands,
such as `>', `C-M-n', `^', `C-M-u', and `i'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 15:47:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Dradams
> there's a reason we have `n' and `p' bound to Dired-specific
> commands.
Make sense.
Now, we agree that some lines should be skipped, and we disagree on
whether header lines should be skipped.
My patch is almost done. I think it will make you happy - it doesn't
control only _whether_ to skip lines, instead it says how to skip line
(e.g., move circularly like you mentioned before). If you really want
to go to the header line:
1. set it to nil;
2. add an new meaningful value for this option.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 15:56:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> > there's a reason we have `n' and `p' bound to Dired-specific
> > commands.
>
> Make sense.
> Now, we agree that some lines should be skipped, and we disagree on
> whether header lines should be skipped.
>
> My patch is almost done. I think it will make you happy - it doesn't
> control only _whether_ to skip lines, instead it says how to skip line
> (e.g., move circularly like you mentioned before). If you really want
> to go to the header line:
> 1. set it to nil;
> 2. add an new meaningful value for this option.
If you really DON'T want `n'|`p' to go to
header lines then maybe set some option.
The _default_ behavior should go to any
Dired line that you can act on, which
includes header lines.
Otherwise, this is a real step backward,
not forward. Currently `n'|`p' take you
to any line, including a header line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 18:16:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 65621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The final patch is attached. (See the end for how to test it.)
> Eli:
> it will need to be an opt-in feature.
By default, it's disabled.
> Dradams:
> Be sure to consider also the behavior when subdir listings are
> inserted in the buffer.
Considered.
> Stefan:
> But Drew's point about inserted subdirs would need to be addressed.
Addressed.
> Stefan
> I'd probably enable it if we had such an option, FWIW.
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. You like what your Dired+ does, so please set
`dired-cursor-goto-meaningful-line' to `cycle' and
`dired-headerline-is-meaningful' to t.
___
- To Test It:
There is totally 4 (not 6) kinds of combinations of the 2 new options:
1. (setq dired-cursor-goto-meaningful-line 'bounded
dired-headerline-is-meaningful nil)
2. (setq dired-cursor-goto-meaningful-line 'cycle
dired-headerline-is-meaningful nil)
3. (setq dired-cursor-goto-meaningful-line 'bounded
dired-headerline-is-meaningful t)
4. (setq dired-cursor-goto-meaningful-line 'cycle
dired-headerline-is-meaningful t)
Test them in 3 kinds of dired buffers:
1. regular dired buffer
2. buffer inserted subdirs
3. the option `dired-listing-switches' is an empty string, the
directory is empty, and there is no subdir inserted. I.e., there
is no filename lines. Only empty lines or header lines.
Move cursor from anywhere.
[0001-dired-next-line-go-to-meaningful-line.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 19:12:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 19:18:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 65621 <at> debbugs.gnu.org (full text, mbox):
It's bad enough that some users (apparently
including some folks writing in this thread)
don't know about operating on a whole dir
listing through its header line.
It would be far worse if Emacs were to make
discovery of such a great feature more
difficult. The fact that `n' and `p' move
to header lines - especially if they skip
over blank lines - invites users to discover
that they can act there on a whole listing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 19:46:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Your words:
> Drew:
> If you really DON'T want `n'|`p' to go to header lines then maybe
> set some option.
Yours, too:
> Drew:
> Those lines are as actionable as any others; they should not be
> skipped over.
> `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.
Can you please not be inconsistent?
Again, that is an optional feature!
That's all I can say, and that patch is the final patch.
If you're still not satisfied, I'm sorry that there's nothing more I
can do, so please don't reply to me anymore.
Sorry again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 21:36:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Shynur Xie <one.last.kiss <at> outlook.com> writes:
> The final patch is attached. (See the end for how to test it.)
Thanks.
> There is totally 4 (not 6) kinds of combinations of the 2 new options:
>
> 1. (setq dired-cursor-goto-meaningful-line 'bounded
> dired-headerline-is-meaningful nil)
> 2. (setq dired-cursor-goto-meaningful-line 'cycle
> dired-headerline-is-meaningful nil)
> 3. (setq dired-cursor-goto-meaningful-line 'bounded
> dired-headerline-is-meaningful t)
> 4. (setq dired-cursor-goto-meaningful-line 'cycle
> dired-headerline-is-meaningful t)
I'll review your patch in detail as soon as I can find some time.
Just two initial comments:
I like the option `dired-cursor-goto-meaningful-line', which seems to
both add wrap-around and make the feature as a whole optional. But in
Emacs, we say "point" rather than "cursor", so we'd have to change
that. I suggest naming it `dired-movement-style', or something along
those lines.
But is `dired-headerline-is-meaningful' really needed? It seems like
an unnecessary complication.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 21:38:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> I'll review your patch in detail as soon as I can find some time.
> Just two initial comments:
This would also need an entry in etc/NEWS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 31 Aug 2023 21:53:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 65621 <at> debbugs.gnu.org (full text, mbox):
1. I see now that the default value of
`dired-headerline-is-meaningful' is t.
For some reason I thought you had it as
nil. I thought you were changing the
default behavior so it skipped header
lines. My bad; sorry.
2. Doc nits:
The doc of `dired-headerline-is-meaningful'
should say that it affects only commands
`dired-(next|previous)-line', instead of
giving the impression that it affects
navigation in general ("when moving cursor").
There are many ways to move the cursor, and
there are even several other Dired-specific
ways.
The doc of `dired-(next|previous)-line'
should refer to the behavior variants or
to `dired-cursor-goto-meaningful-line'.
3. FWIW, for vanilla Dired, lines `.'
and `..' are generally "meaningless"
in your terms: you generally can't act
on them. (In Dired+ you can.) Dunno
whether you want to include optionally
skipping over them with `n'|`p', i.e.,
via `dired-cursor-goto-meaningful-line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Fri, 01 Sep 2023 17:30:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Stefan:
> I like the option `dired-cursor-goto-meaningful-line', which seems
> to both add wrap-around and make the feature as a whole optional.
Thx! Yes, to use the `wrap-around' you mentioned, just set the option
to `cycle'.
> Stefan:
> But in Emacs, we say "point" rather than "cursor", so we'd have to
> change that. I suggest naming it `dired-movement-style'.
OK.
> Drew:
> there's no need for "cursor" in the option name.
I'll try not to mention cursor/point in docstring when possible.
> Drew:
> The doc should say that it affects only commands
> `dired-(next|previous)-line'.
Yeah, docstring should state it.
> Drew:
> FWIW, for vanilla Dired, lines `.' and `..' are generally
> "meaningless".
You can discard them by setting `dired-listing-switches' to an
appropriate value if you don't like them. The value is passed to the
program `ls'. On MS-Windows things seem to be a little different, not
sure.
___
To sum up, new patch will provide an option which controls the style
of moving point.
--
Responses may be delayed as I have classes during the day
(UTC+8, not 0, contrary to what my email program indicates).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Fri, 01 Sep 2023 18:47:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> You can discard them by setting `dired-listing-switches' to an
> appropriate value if you don't like them. The value is passed to the
> program `ls'. On MS-Windows things seem to be a little different, not
> sure.
Sorry; I wasn't clear. It wasn't about not
listing `.' and `..'. I meant that vanilla
Emacs sometimes doesn't let you apply actions
to those lines.
For example, `dired-toggle-marks' doesn't act
on them. (Dired+ has an option to decide
whether to do so.)
Anyway, this isn't important here - vanilla
`n' and `p' don't skip over `.' and `..'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Fri, 01 Sep 2023 20:52:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 65621 <at> debbugs.gnu.org (full text, mbox):
Let's use this option to settle our differences:
(defcustom dired-movement-style '((move . bounded)
(skip-pathname
. (empty-line ...
"regexp1" "regexp2" ...)))
"..."
...)
;; 1. change `bounded' to `cycle' to use the 'wrap-around'.
;; 2. symbol (empty-line or hearder) appears in the second CDR
;; means skip the corresponding lines.
;; 3. if the pathname matches any regexp, that line will be
;; skipped.
Drew wants to skip the current directory and the parent directory;
someone (one of my classmates) said I should make it skip LICENSE
because this file won't be touched again in the subsequent development
process;
I speculate that some people will also suggest that ".git" should be
skipped. They may say most people will never delve into this folder,
though it needs to be displayed to indicate that the current directory
is a Git repository (although there are other ways to remind of this).
So I decided to withdraw from the argument. Making decisions for
users has no benefits for me. People have their own thoughts; just
let them set the option themselves.
Any suggestion, Stefan and Drew?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Fri, 01 Sep 2023 21:07:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Drew wants to skip the current directory and the parent directory;
No, he doesn't. Not at all. Definitely not.
I think maybe you misread what I wrote.
What I said was that for _vanilla_ Emacs some
actions aren't allowed on `.' and `..'. And
so based on that, you or someone else (NOT I),
might want those lines, in addition to blank
lines, to be skipped over as "meaningless".
My main point in this thread is that directory
header lines (main dir and subdirs) are _not_
meaningless. You _can_ perform actions on them,
so they should not be skipped when navigating.
(If you must make it possible to skip them as
an option, so be it. But they shouldn't be
skipped by default, IMO.)
FWIW, Dired+ doesn't skip any lines, except
the final empty line at eob.
> someone (one of my classmates) said I should make it skip LICENSE
> because this file won't be touched again in the subsequent development
> process;
> I speculate that some people will also suggest that ".git" should be
> skipped. They may say most people will never delve into this folder,
> though it needs to be displayed to indicate that the current directory
> is a Git repository (although there are other ways to remind of this).
>
> So I decided to withdraw from the argument. Making decisions for
> users has no benefits for me. People have their own thoughts; just
> let them set the option themselves.
>
> Any suggestion, Stefan and Drew?
In addition to the clarification I offered above,
I'd say that none of the complications you've
offered with this latest suggestion are helpful.
Let's keep it simple. If users file enhancement
requests to allow other behaviors those can be
considered later.
I'd suggest that skipping over blank lines, if
you want to do that, is enough. And offering
cycling is a nice-to-have, but is orthogonal to
the bug report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sat, 02 Sep 2023 12:06:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 65621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
New patch is done. Only 2 features: skipping empty lines; cycling.
___
> Drew:
> > Drew wants to skip the current directory and the parent directory;
> No, he doesn't. Not at all. Definitely not. I think maybe you
> misread what I wrote.
You really confused me. If you don't want it, why mentioned it twice?
You proposed this idea:
> Drew:
> What I said was that for _vanilla_ Emacs some actions aren't allowed
> on `.' and `..'. And so based on that, you or someone else (NOT I),
> might want those lines, in addition to blank lines, to be skipped
> over as "meaningless".
and then rejected it:
> Drew:
> I'd say that none of the complications you've offered with this
> latest suggestion are helpful.
Inconsistent.
If you don't want it and you don't want anyone else to use it, then
do not mention it in the first place.
[0001-dired-next-line-movement-style.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sat, 02 Sep 2023 12:15:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Cc: "65621 <at> debbugs.gnu.org" <65621 <at> debbugs.gnu.org>
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> Date: Sat, 2 Sep 2023 12:05:23 +0000
>
> New patch is done. Only 2 features: skipping empty lines; cycling.
Thanks, but I believe Stefan asked for a NEWS entry. Would you like
to write one and add it to the patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sat, 02 Sep 2023 12:19:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 65621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Would you like to write one and add it to the patch?
I thought it was the maintainers' job.
Yes, I will write it.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sat, 02 Sep 2023 12:40:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> CC: "65621 <at> debbugs.gnu.org" <65621 <at> debbugs.gnu.org>
> Date: Sat, 2 Sep 2023 12:18:11 +0000
>
> > Would you like to write one and add it to the patch?
>
> I thought it was the maintainers' job.
> Yes, I will write it.
Thank you.
We prefer that the documentation accompanies the code changes. If
nothing else, this enlarges the group of people who can write good
documentation for Emacs. It also lowers the probability that we will
forget to document changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sat, 02 Sep 2023 14:41:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 65621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> We prefer that the documentation accompanies the code changes. If
> nothing else, this enlarges the group of people who can write good
> documentation for Emacs. It also lowers the probability that we
> will forget to document changes.
Understood. This is my first time to write a NEWS entry, so it may
not be considered good documentation.
New patch is attached. Thanks in advance for reviewing.
[0001-dired-next-line-movement-style.patch (application/octet-stream, attachment)]
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 03 Sep 2023 11:02:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Sun, 03 Sep 2023 21:48:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> > > Drew wants to skip the current directory
> > > and the parent directory;
> >
> > No, he doesn't. Not at all. Definitely not.
> > I think maybe you misread what I wrote.
>
> You really confused me. If you don't want it,
> why mentioned it twice?
I mentioned it only because you were defining a
Boolean option `dired-headerline-is-meaningful'.
I wanted to let you know that `.' and `..' are
also lines that you might want to let the
option skip over, because vanilla Emacs doesn't
allow actions on them sometimes.
IOW, IF you're going to have an option for
choosing which lines are "meaningful", THEN you
might want to allow for header lines too, as
another kind of line to skip.
I clearly introduced that FYI with "FWIW", and
added:
Dunno whether you want to include optionally
skipping over them with `n'|`p', i.e., via
`dired-cursor-goto-meaningful-line.
Clearly I wasn't _requesting_ being able to
skip `.' and `..' lines, and a conclusion that
Drew _asked_ for that was unwarranted. As was
the further conclusion that his supposed ask
for that conflicted with his (repeated) FYIs
that this was _not_ something he requested.
The contradiction and confusion were in your
imagination, I'm afraid. I think I was clear
from the outset.
If it were I, I'd have done what I did in
Dired+: no option to decide what lines are
"meaningful".
I do think it's fine to skip over blank lines
(which Dired+ hasn't done). But I saw and I
see no real need for an option such as
`dired-headerline-is-meaningful'. (I think
Stefan said that too, and I see you've now
removed it.)
What I argued for was having `n' and `p' go
to header lines, as they always have. To
accommodate _your_ wish to _not_ do that I
suggested you make that optional (but have
skipping such lines be opt-in).
IOW, I suggested an option to accommodate
your new behavior (skip header lines) as
well as to respect Emacs's longstanding
(and more useful) behavior of not skipping
them.
> You proposed this idea:
>
> > What I said was that for _vanilla_
> > Emacs some actions aren't allowed
> > on `.' and `..'. And so based on
> > that, you or someone else (NOT I),
> > might want those lines, in addition
> > to blank lines, to be skipped over
> > as "meaningless".
>
> and then rejected it:
>
> > I'd say that none of the complications
> > you've offered with this latest
> > suggestion are helpful.
You elided the real point I made there:
I'd suggest that skipping over blank lines, if
you want to do that, is enough. And offering
cycling is a nice-to-have, but is orthogonal to
the bug report.
And that matches what you ended up with.
> Inconsistent.
>
> If you don't want it and you don't want anyone else to use it, then
> do not mention it in the first place.
I mentioned it because you were looking to
have users customize the kinds of lines
they want to consider "meaningless" (and
thus skip over).
I was just trying to help you in your attempt
to do that, by offering an FYI about another
kind of line that vanilla Emacs sometimes
allows no action on.
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65621
; Package
emacs
.
(Thu, 07 Sep 2023 15:06:01 GMT)
Full text and
rfc822 format available.
Message #103 received at 65621 <at> debbugs.gnu.org (full text, mbox):
> Drew:
> I think I was clear from the outset.
Yes, it's me who wasn't clear whether that is what you want.
> I do think it's fine to skip over blank lines (which Dired+ hasn't
> done). But I saw and I see no real need for an option such as
> `dired-headerline-is-meaningful'.
Hope this time I understand your point:
You suggest I also skip `.' and `..' if the option
`dired-headerline-is-meaningful' is provided, though
you don't suggest to provide such an option.
> I see you've now removed it.
Yes, it's unnecessary.
Anyway,
> I was just trying to help you in your attempt to do that, by
> offering an FYI about another kind of line that vanilla Emacs
> sometimes allows no action on.
Thank you.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sun, 10 Sep 2023 07:47:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Shynur Xie <one.last.kiss <at> outlook.com>
:
bug acknowledged by developer.
(Sun, 10 Sep 2023 07:47:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 65621-done <at> debbugs.gnu.org (full text, mbox):
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> CC: "65621 <at> debbugs.gnu.org" <65621 <at> debbugs.gnu.org>
> Date: Sat, 2 Sep 2023 14:40:29 +0000
> msip_labels:
>
> > We prefer that the documentation accompanies the code changes. If
> > nothing else, this enlarges the group of people who can write good
> > documentation for Emacs. It also lowers the probability that we
> > will forget to document changes.
>
> Understood. This is my first time to write a NEWS entry, so it may
> not be considered good documentation.
>
> New patch is attached. Thanks in advance for reviewing.
Thanks, installed on the master branch, and closing the bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 08 Oct 2023 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 260 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.