unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#48883: dired marking bugs
@ 2021-06-06 20:33 Boruch Baum
  2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
  2021-06-07 18:53 ` Arthur Miller
  0 siblings, 2 replies; 12+ messages in thread
From: Boruch Baum @ 2021-06-06 20:33 UTC (permalink / raw)
  To: 48883

In testing my diredc package, I'm coming across the following bugs
reproducable in \emacs -Q -nw:

1) Improper marking of directory heading line

   1.1) The correct and expected behavior of dired is that when one
        navigates to a directory heading line (eg. the first line of a
        simple dired buffer) and presses 'm', all "real" files of that
        directory are marked, [IMPORTANT] the lines for the "not-real"
        files '.' and '..' are not marked, and [IMPORTANT] the directory
        line itself is not marked.

   1.2) Likewise, typing 'u' on that line unmarks all said lines.

   1.3) Now, advance one line, to the line typically presenting a
        summary, beginning with the word 'total', and press the sequence
        'C-u -1 m'.

   1.4) Why is there now a mark on the prior line, the directory line?
        Note that the result differs from actually performing 'm' on
        that line also in that none of the "real" files in the directory
        are marked. Note also that performing 'u' on the line does not
        remove the mark, but performing 'U' on the buffer does.

   1.5) Attempting to perform an operation on the marked directory line
        (eg. 'C' to copy it) returns the message "No files specified"

2) Improper marking of "not-real" files '.' and '..'

   2.1) See paragraph 1.1.

   2.2) However, those lines can be manually marked using the 'm'
        command, and attempting to perform an operation on them (eg. 'C'
        to copy them) returns messaging indicating a willingness to
        overwrite whatever target directory is chosen. I haven't risked
        let it operate.

   2.3) As in paragraph 1.3, it is possible to mark the two lines using
        a negative prefix argument.

3) Improper advancing to (point-max)

   3.1) Marking the final entry in a dired buffer advances POINT to a
        blank line, which is pretty much never desirable to a user.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-06 20:33 bug#48883: dired marking bugs Boruch Baum
@ 2021-06-06 22:12 ` Drew Adams
  2021-06-06 22:44   ` Boruch Baum
                     ` (2 more replies)
  2021-06-07 18:53 ` Arthur Miller
  1 sibling, 3 replies; 12+ messages in thread
From: Drew Adams @ 2021-06-06 22:12 UTC (permalink / raw)
  To: Boruch Baum, 48883@debbugs.gnu.org

I'll chime in here, unsolicited - feel free to ignore.

Glad you reported this, Boruch.  Congratulations on
finding a decades-old problem!

> I'm coming across the following bugs
> reproducable in \emacs -Q -nw:
> 
> 1) Improper marking of directory heading line
> 
>    1.1) The correct and expected behavior of dired is that when one
>         navigates to a directory heading line (eg. the first line of a
>         simple dired buffer) and presses 'm', all "real" files of that
>         directory are marked, [IMPORTANT] the lines for the "not-real"
>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>         line itself is not marked.
> 
>    1.2) Likewise, typing 'u' on that line unmarks all said lines.

(You don't say so, but I think/hope you agree that
1.1 and 1.2 are OK, not something improper.)

>    1.3) Now, advance one line, to the line typically presenting a
>         summary, beginning with the word 'total', and press the sequence
>         'C-u -1 m'.
> 
>    1.4) Why is there now a mark on the prior line, the directory line?
>         Note that the result differs from actually performing 'm' on
>         that line also in that none of the "real" files in the directory
>         are marked. Note also that performing 'u' on the line does not
>         remove the mark, but performing 'U' on the buffer does.

Agreed - a bug.

This change to `dired-repeat-over-lines' seems to
take care of that OK:

In the second `while' (the one for negative movement),
change (save-excursion (funcall function)) to this:
(when (dired-get-filename nil t) ; <=======
  (save-excursion (funcall function)))

[I've added `dired-repeat-over-lines' to dired+.el and
made that change.  If this gets fixed in vanilla Dired
too (hopefully) then I'll be able to remove that
dired+.el change - except for older Emacs versions.] 

>    1.5) Attempting to perform an operation on the marked directory line
>         (eg. 'C' to copy it) returns the message "No files specified"

IMO, that's not a problem.  (I assume here you're
talking about point being on the dir heading line
and no (other) files being marked.)  There _are_
(should be) no files specified.

> 2) Improper marking of "not-real" files '.' and '..'
> 
>    2.1) See paragraph 1.1.
> 
>    2.2) However, those lines can be manually marked using the 'm'
>         command, and attempting to perform an operation on them (eg. 'C'
>         to copy them) returns messaging indicating a willingness to
>         overwrite whatever target directory is chosen. I haven't risked
>         let it operate.
> 
>    2.3) As in paragraph 1.3, it is possible to mark the two lines using
>         a negative prefix argument.

IMO, there's nothing wrong with marking `.' or `..',
and nothing wrong with Dired having some operations
that work on them.

It's fine for it to have some other operations that
don't work for them, of course.  In that case, users
can be informed about that when they try those ops.

> 3) Improper advancing to (point-max)
> 
>    3.1) Marking the final entry in a dired buffer advances POINT to a
>         blank line, which is pretty much never desirable to a user.

I don't see that as a problem.  FWIW, with my code
(`dired+.el') a user can optionally wrap around from
the last line to the first, and vice versa, using the
line motion commands (e.g. `SPC', `down').






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
@ 2021-06-06 22:44   ` Boruch Baum
  2021-06-07 15:24     ` Drew Adams
  2021-06-07  0:08   ` Boruch Baum
  2021-06-07  0:50   ` Boruch Baum
  2 siblings, 1 reply; 12+ messages in thread
From: Boruch Baum @ 2021-06-06 22:44 UTC (permalink / raw)
  To: Drew Adams; +Cc: 48883@debbugs.gnu.org

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

On 2021-06-06 22:12, Drew Adams wrote:
> >    1.1) The correct and expected behavior of dired is that when one
> >    ...
> >    1.2) Likewise, typing 'u' on that line unmarks all said lines.
>
> (You don't say so, but I think/hope you agree that
> 1.1 and 1.2 are OK, not something improper.)

Agreed.

>
> >    1.3) Now, advance one line, to the line typically presenting a
> >         summary, beginning with the word 'total', and press the sequence
> >         'C-u -1 m'.
> >
> >    1.4) Why is there now a mark on the prior line, the directory line?
> >         Note that the result differs from actually performing 'm' on
> >         that line also in that none of the "real" files in the directory
> >         are marked. Note also that performing 'u' on the line does not
> >         remove the mark, but performing 'U' on the buffer does.

> This change to `dired-repeat-over-lines' seems to
> take care of that OK:
>
> In the second `while' (the one for negative movement),
> change (save-excursion (funcall function)) to this:
> (when (dired-get-filename nil t) ; <=======
>   (save-excursion (funcall function)))

I don't like that change because it allows operations on '.' and '..'
which makes me uncomfortable.

I have a patch in testing, but I want to do some more work before
submitting it (and who knows, some emacs devel may insist none of this
is a bug!).

What I see as possibly the issue is function `dired-between-files'. I'm
not equipped to perform a 'git blame', but the function's comment
indicated a change at some point, and I suspect that's when the bug
arose.

> >    1.5) Attempting to perform an operation on the marked directory line
> >         (eg. 'C' to copy it) returns the message "No files specified"
>
> IMO, that's not a problem.  (I assume here you're
> talking about point being on the dir heading line
> and no (other) files being marked.)  There _are_
> (should be) no files specified.

Agreed. I should have made that clear.

> IMO, there's nothing wrong with marking `.' or `..',
> and nothing wrong with Dired having some operations
> that work on them.

I don't feel comfortable with that. Do you have any specific case in
mind?

> > 3) Improper advancing to (point-max)
> >
> >    3.1) Marking the final entry in a dired buffer advances POINT to a
> >         blank line, which is pretty much never desirable to a user.
>
> I don't see that as a problem.

I agree that it isn't a *problem*, just that it's not friendly.

OK. I've changed my mind, and am submitting my current patch. The reason
I thought not to above is that I might want to propose changing function
`dired-between-files'. However, from performing M-x rzgrep on the lisp
directory, I see it referred to 9 times, and I haven't checked them yet:

./dired.el.gz:3498:      (while (and (not (eobp)) (dired-between-files)) (forward-line 1))
./dired.el.gz:3509:      (while (and (not (bobp)) (dired-between-files)) (forward-line -1))
./dired.el.gz:3515:(defun dired-between-files ()
./dired.el.gz:3570:      (while (and (< (point) end) (dired-between-files))
./dired.el.gz:3652:        (or (dired-between-files)
./files.el.gz:6944:;;		 dired-between-files, (shortcut for (not (dired-move-to-filename)))
./net/ange-ftp.el.gz:5440:;;(or (assq 'vms ange-ftp-dired-between-files-alist)
./net/ange-ftp.el.gz:5441:;;    (setq ange-ftp-dired-between-files-alist
./net/ange-ftp.el.gz:5443:;;		ange-ftp-dired-between-files-alist)))

Also, because dired is such an old feature of emacs, and since it is the
subject of so many third-party[1] extensions, any *fix* to that function,
even if correct, might have undesirable consequences downstream, so I
want to careful about it.


[1] I know I keep saying 'third-party' but I have no idea who is the second-party.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: dired.patch --]
[-- Type: text/x-diff, Size: 1557 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
       ;;(while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (while (and (not (eobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (save-excursion (funcall function))
         ;; Advance to the next line--actually, to the line that *was* next.
         ;; (If FUNCTION inserted some new lines in between, skip them.)
         (goto-char pos))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
       ;;(while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (while (and (not (bobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
  2021-06-06 22:44   ` Boruch Baum
@ 2021-06-07  0:08   ` Boruch Baum
  2021-06-07 15:21     ` Drew Adams
  2021-06-07  0:50   ` Boruch Baum
  2 siblings, 1 reply; 12+ messages in thread
From: Boruch Baum @ 2021-06-07  0:08 UTC (permalink / raw)
  To: Drew Adams; +Cc: 48883@debbugs.gnu.org

Here's a follow-up related bug: If one marks one of what I've been
calling the "not-real" files '.' or ',,' and then perform action 't' to
toggle the marks, those elements do not toggle.


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
  2021-06-06 22:44   ` Boruch Baum
  2021-06-07  0:08   ` Boruch Baum
@ 2021-06-07  0:50   ` Boruch Baum
  2 siblings, 0 replies; 12+ messages in thread
From: Boruch Baum @ 2021-06-07  0:50 UTC (permalink / raw)
  To: Drew Adams; +Cc: 48883@debbugs.gnu.org

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

Attached are two updated fix files.

file dired.2.patch is a slight modifcation of my first submission, to
cover a case of being in an empty directory.

file dired.3.patch is possibly a 'better' fix in that it addresses a
deficiency in function `dired-between-lines'. The emacs developers may
decide that method is undesirable and prefer the first patch.

Technically, neither file is a 'patch' file, but both are simple small
drop-in replacements for content of file dired.el @line ~3500. If for
this, you decide you need a real patch file, fine, just tell me for
which option.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: dired.2.patch --]
[-- Type: text/x-diff, Size: 1590 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
       ;;(while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (while (and (not (eobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (unless (eobp)
           (save-excursion (funcall function))
           ;; Advance to the next line--actually, to the line that *was* next.
           ;; (If FUNCTION inserted some new lines in between, skip them.)
           (goto-char pos)))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
       ;;(while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (while (and (not (bobp))
                     (condition-case nil
                       (not (dired-get-filename))
                       (error t)))
           (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

[-- Attachment #3: dired.3.patch --]
[-- Type: text/x-diff, Size: 1505 bytes --]

(defun dired-repeat-over-lines (arg function)
  ;; This version skips non-file lines.
  (let ((pos (make-marker)))
    (beginning-of-line)
    (cond
     ((> arg 0)
       (while (and (> arg 0) (not (eobp)))
         (setq arg (1- arg))
         (beginning-of-line)
         (while (and (not (eobp)) (dired-between-files)) (forward-line 1))
         (save-excursion
           (forward-line 1)
           (move-marker pos (1+ (point))))
         (unless (eobp)
           (save-excursion (funcall function))
           ;; Advance to the next line--actually, to the line that *was* next.
           ;; (If FUNCTION inserted some new lines in between, skip them.)
           (goto-char pos)))
       (when (eobp)
         (forward-line -1)
         (dired-move-to-filename)))
     ((< arg 0)
       (while (and (< arg 0) (not (bobp)))
         (setq arg (1+ arg))
         (forward-line -1)
         (while (and (not (bobp)) (dired-between-files)) (forward-line -1))
         (beginning-of-line)
         (when (condition-case nil
                 (dired-get-filename)
                 (error nil))
           (save-excursion (funcall function))))
       (move-marker pos nil)
       (dired-move-to-filename)))))

(defun dired-between-files ()
  ;; This used to be a regexp match of the `total ...' line output by
  ;; ls, which is slightly faster, but that is not very robust; notably,
  ;; it fails for non-english locales.
  (not (condition-case nil
         (dired-get-filename)
         (error nil))))

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-07  0:08   ` Boruch Baum
@ 2021-06-07 15:21     ` Drew Adams
  2021-06-07 16:16       ` Drew Adams
  0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2021-06-07 15:21 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 48883@debbugs.gnu.org

> Here's a follow-up related bug: If one marks one of what I've been
> calling the "not-real" files '.' or ',,' and then perform action 't' to
> toggle the marks, those elements do not toggle.

+1.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-06 22:44   ` Boruch Baum
@ 2021-06-07 15:24     ` Drew Adams
  0 siblings, 0 replies; 12+ messages in thread
From: Drew Adams @ 2021-06-07 15:24 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 48883@debbugs.gnu.org

> > In the second `while' (the one for negative movement),
> > change (save-excursion (funcall function)) to this:
> > (when (dired-get-filename nil t) ; <=======
> >   (save-excursion (funcall function)))
> 
> I don't like that change because it allows operations
> on '.' and '..' which makes me uncomfortable.

OK.

I disagree that ALL operations on `.' and `..' should
be disallowed, but what you say follows what will
likely be wanted for vanilla Emacs, I expect.

My own position (used in Dired+), is that Dired
operations can in principle be anything.

They are operations on the buffer and its text, first
and foremost.  Only some of them are operations on
files and dirs listed in the buffer.

My position (for Dired+, and suggested but not
expected for vanilla Dired) is that it's up to the
particular function whether and how it might be
relevant for `.' or `..'.

Some operations might make sense; others might not.
The idea that NO operation could make sense on `.'
or `..' would be misguided, IMO.  It's unnecessarily
limiting.  `.' and `..' are just names for certain
directories.  Dired doesn't outlaw operations on
other lines that name directories.

[The same is true for shell commands, BTW.  They
don't exclude acting on `.' or `..'.]

> What I see as possibly the issue is function `dired-between-files'. I'm
> not equipped to perform a 'git blame', but the function's comment
> indicated a change at some point, and I suspect that's when the bug
> arose.

The bug exists at least as far back as Emacs 20.

Yes, we could consider that the bug is in
`dired-move-to-filename' (used by
`dired-between-files').  So far, I've chosen to
consider it to be just in `dired-repeat-over-lines'.

> > IMO, there's nothing wrong with marking `.' or `..',
> > and nothing wrong with Dired having some operations
> > that work on them.
> 
> I don't feel comfortable with that. Do you have
> any specific case in mind?

See above.  

BTW, even vanilla Emacs presents some specific cases.

It lets `dired-get-filename' treat `.' and `..' as
regular file names, with non-nil arg
NO-ERROR-IF-NOT-FILEP.

And `dired-find-file' operates normally on `.' and `..'.

[That has always been the case, AFAIK.  But before Emacs
21 it didn't use `dired-get-filename' (via
`dired-get-file-for-visit').  Starting with 21, it has,
passing non-nil NO-ERROR-IF-NOT-FILEP.]

Likewise, `dired-mouse-find-file-other-window' operates
on `.' and `..'.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: [External] : bug#48883: dired marking bugs
  2021-06-07 15:21     ` Drew Adams
@ 2021-06-07 16:16       ` Drew Adams
  0 siblings, 0 replies; 12+ messages in thread
From: Drew Adams @ 2021-06-07 16:16 UTC (permalink / raw)
  To: Drew Adams, Boruch Baum; +Cc: 48883@debbugs.gnu.org

> > Here's a follow-up related bug: If one marks one of what I've been
> > calling the "not-real" files '.' or ',,' and then perform action 't' to
> > toggle the marks, those elements do not toggle.
> 
> +1.

Hm, the doc string says that `.' and `..' are never
toggled.  That means that this was intentional (why?).

But (luckily) `dired-toggle-marks' is not used
anywhere in the vanilla Emacs Lisp code (except as
for key bindings).

A proper change could perhaps be one of the following:

* Just let it toggle `.' and `..', reversing the
  design (intention) for those.

* Do that only when invoked interactively (so any code
  that invokes it non-interactively isn't affected).

* Add a user option, to control whether it toggles
  `.' and `..'.

(For Dired+ I'll go with the first, at least until
or unless vanilla Emacs decides to do something
else for this.)
___

BTW, the doc string for this is not good.  It speaks
of "other flags (such as `D')".  It should say "other
marks (such as `D')."  `D' is the only mark that we
refer to also as a "flag" - there are no other flags.
___

BTW2: What is the "insdel" referred to in the code
comment?





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: dired marking bugs
  2021-06-06 20:33 bug#48883: dired marking bugs Boruch Baum
  2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
@ 2021-06-07 18:53 ` Arthur Miller
  2021-06-08  0:32   ` Filipp Gunbin
  1 sibling, 1 reply; 12+ messages in thread
From: Arthur Miller @ 2021-06-07 18:53 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 48883

Boruch Baum <boruch_baum@gmx.com> writes:

> In testing my diredc package, I'm coming across the following bugs
> reproducable in \emacs -Q -nw:
>
> 1) Improper marking of directory heading line
>
>    1.1) The correct and expected behavior of dired is that when one
>         navigates to a directory heading line (eg. the first line of a
>         simple dired buffer) and presses 'm', all "real" files of that
>         directory are marked, [IMPORTANT] the lines for the "not-real"
>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>         line itself is not marked.
I have no idea if that is "correct and expected behaviour", I don't see
it said in manual, or I missed it, but anyway, the headline in Dired is
a waste of space since you can see dir name in modeline or frame title,
and '.' and '..' are just a design misstake in Unix OS; should have
never been exposed to users as files. Just turn off those things
(dired-omit-mode), you will probably be better without them. :-). Sorry
if I sound negative.

>    1.2) Likewise, typing 'u' on that line unmarks all said lines.
'U' unmarks everything, no need to put cursor to headline ever.

>    1.3) Now, advance one line, to the line typically presenting a
>         summary, beginning with the word 'total', and press the sequence
>         'C-u -1 m'.
>
>    1.4) Why is there now a mark on the prior line, the directory line?
>         Note that the result differs from actually performing 'm' on
>         that line also in that none of the "real" files in the directory
>         are marked. Note also that performing 'u' on the line does not
>         remove the mark, but performing 'U' on the buffer does.
>
>    1.5) Attempting to perform an operation on the marked directory line
>         (eg. 'C' to copy it) returns the message "No files specified"
>
> 2) Improper marking of "not-real" files '.' and '..'
>
>    2.1) See paragraph 1.1.
>
>    2.2) However, those lines can be manually marked using the 'm'
>         command, and attempting to perform an operation on them (eg. 'C'
>         to copy them) returns messaging indicating a willingness to
>         overwrite whatever target directory is chosen. I haven't risked
>         let it operate.
>
>    2.3) As in paragraph 1.3, it is possible to mark the two lines using
>         a negative prefix argument.
Have you checked the code. Not a bug, feature :).

> 3) Improper advancing to (point-max)
>
>    3.1) Marking the final entry in a dired buffer advances POINT to a
>         blank line, which is pretty much never desirable to a user.
Yeah, that is annoying, I agree with you. For my own use, I have thse
two functions, so I never place cursor on either headline or one past
last filename:

#+begin_src emacs-lisp

(defun dired-go-to-first ()
  (interactive)
  (goto-char (point-min))
  (dired-next-line 1)
  (skip-chars-forward " \n\t"))

(defun dired-go-to-last ()
  (interactive)
  (goto-char (point-max))
  (dired-next-line -1)
  (skip-chars-forward " \n\t"))
  
#+end_src






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: dired marking bugs
  2021-06-07 18:53 ` Arthur Miller
@ 2021-06-08  0:32   ` Filipp Gunbin
  2021-06-08  4:15     ` Arthur Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Filipp Gunbin @ 2021-06-08  0:32 UTC (permalink / raw)
  To: Arthur Miller; +Cc: 48883, Boruch Baum

On 07/06/2021 20:53 +0200, Arthur Miller wrote:

> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> In testing my diredc package, I'm coming across the following bugs
>> reproducable in \emacs -Q -nw:
>>
>> 1) Improper marking of directory heading line
>>
>>    1.1) The correct and expected behavior of dired is that when one
>>         navigates to a directory heading line (eg. the first line of a
>>         simple dired buffer) and presses 'm', all "real" files of that
>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>         line itself is not marked.
> I have no idea if that is "correct and expected behaviour", I don't see
> it said in manual, or I missed it, but anyway, the headline in Dired is
> a waste of space since you can see dir name in modeline or frame title,
> [...]

The headlines are very much needed if you have -R in ls switches…





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: dired marking bugs
  2021-06-08  0:32   ` Filipp Gunbin
@ 2021-06-08  4:15     ` Arthur Miller
  2021-06-08 12:41       ` Filipp Gunbin
  0 siblings, 1 reply; 12+ messages in thread
From: Arthur Miller @ 2021-06-08  4:15 UTC (permalink / raw)
  To: Filipp Gunbin; +Cc: 48883, Boruch Baum

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 07/06/2021 20:53 +0200, Arthur Miller wrote:
>
>> Boruch Baum <boruch_baum@gmx.com> writes:
>>
>>> In testing my diredc package, I'm coming across the following bugs
>>> reproducable in \emacs -Q -nw:
>>>
>>> 1) Improper marking of directory heading line
>>>
>>>    1.1) The correct and expected behavior of dired is that when one
>>>         navigates to a directory heading line (eg. the first line of a
>>>         simple dired buffer) and presses 'm', all "real" files of that
>>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>>         line itself is not marked.
>> I have no idea if that is "correct and expected behaviour", I don't see
>> it said in manual, or I missed it, but anyway, the headline in Dired is
>> a waste of space since you can see dir name in modeline or frame title,
>> [...]
>
> The headlines are very much needed if you have -R in ls switches…

Aha, so it would insert a headline for each recursive listing. Ok, that
make sense.

Thanks for pointing it out. I have never used -R in listing
switches. Is it useful in real-world? I can just imagine how long time
would take for emacs to list entire /home/user dir. I tried it now just
for the test, but I had to press C-g after few seconds.

Actually when thinking of it, I don't use 'i' to insert a
directory either but I am aware of it, and I guess it also needs a
headline as a visual delimiter. Anyway I never really find it pretty or
useful to insert a subdir below entire content. Instead I use a
package dired-hacks which has a utility dired-subtree which lets me
toggle subdir similar to a conventional file manager. It works similar
to headlines in outline/org mode which I think is a bit more natural to use.






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#48883: dired marking bugs
  2021-06-08  4:15     ` Arthur Miller
@ 2021-06-08 12:41       ` Filipp Gunbin
  0 siblings, 0 replies; 12+ messages in thread
From: Filipp Gunbin @ 2021-06-08 12:41 UTC (permalink / raw)
  To: Arthur Miller; +Cc: 48883, Boruch Baum

On 08/06/2021 06:15 +0200, Arthur Miller wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 07/06/2021 20:53 +0200, Arthur Miller wrote:
>>
>>> Boruch Baum <boruch_baum@gmx.com> writes:
>>>
>>>> In testing my diredc package, I'm coming across the following bugs
>>>> reproducable in \emacs -Q -nw:
>>>>
>>>> 1) Improper marking of directory heading line
>>>>
>>>>    1.1) The correct and expected behavior of dired is that when one
>>>>         navigates to a directory heading line (eg. the first line of a
>>>>         simple dired buffer) and presses 'm', all "real" files of that
>>>>         directory are marked, [IMPORTANT] the lines for the "not-real"
>>>>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>>>>         line itself is not marked.
>>> I have no idea if that is "correct and expected behaviour", I don't see
>>> it said in manual, or I missed it, but anyway, the headline in Dired is
>>> a waste of space since you can see dir name in modeline or frame title,
>>> [...]
>>
>> The headlines are very much needed if you have -R in ls switches…
>
> Aha, so it would insert a headline for each recursive listing. Ok, that
> make sense.
>
> Thanks for pointing it out. I have never used -R in listing
> switches. Is it useful in real-world? I can just imagine how long time
> would take for emacs to list entire /home/user dir. I tried it now just
> for the test, but I had to press C-g after few seconds.
>
> Actually when thinking of it, I don't use 'i' to insert a
> directory either but I am aware of it, and I guess it also needs a
> headline as a visual delimiter. Anyway I never really find it pretty or
> useful to insert a subdir below entire content. Instead I use a
> package dired-hacks which has a utility dired-subtree which lets me
> toggle subdir similar to a conventional file manager. It works similar
> to headlines in outline/org mode which I think is a bit more natural to use.

Yes, I use -R and "i" all the time.  -R (together with (setq
dired-isearch-filenames t)) is useful for java projects, which usually
don't have much files, but a lot of nested directories.  "i" is
convenient for navigating when I know the directory structure.

Thanks for mentioning dired-hacks, I didn't know about it.

Filipp





^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-06-08 12:41 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-06 20:33 bug#48883: dired marking bugs Boruch Baum
2021-06-06 22:12 ` bug#48883: [External] : " Drew Adams
2021-06-06 22:44   ` Boruch Baum
2021-06-07 15:24     ` Drew Adams
2021-06-07  0:08   ` Boruch Baum
2021-06-07 15:21     ` Drew Adams
2021-06-07 16:16       ` Drew Adams
2021-06-07  0:50   ` Boruch Baum
2021-06-07 18:53 ` Arthur Miller
2021-06-08  0:32   ` Filipp Gunbin
2021-06-08  4:15     ` Arthur Miller
2021-06-08 12:41       ` Filipp Gunbin

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).