bug#27801: 26.0.50; Dired: Use relative file names when DIR-OR-LIST is a cons

[Drew Adams]

> >> ;; Following form shows the full file name in the Dired buffer.
> >> (let* ((dir source-directory)
> >>        (file1 (expand-file-name "lisp/subr.el" dir))
> >>        (file2 (expand-file-name "src/data.c" dir)))
> >>   (dired (list dir file1 file2)))
> >>
> >> ;; Usually, Dired just shows the relative file name to
> >> ;; 'default-directory'. That is more clear, specially for
> >> ;; long file names.
> >
> > Sorry, but I've only read this bug report quickly - no time
> > now.  If you are suggesting that when DIR-OR-LIST is a cons
> > the file names shown should be relative then I think I
> > disagree strongly.
> >
> > The typical use case for a cons DIR-OR-LIST is a list
> > of files from anywhere, in which case absolute file
> > names are appropriate.
>
> I am OK with adding a new variable `foo' so that i can get
> this behavior if i locally bind `foo' to a non-nil value.

I don't see why you need that.

> This idea comes while i am trying to implement Bug#27631; to
> have this feature working with 'ls-lisp' my implementation
> do something like:
> 
> 1) Collect all matches with `find-lisp' in a variable FILES.

(What is `find-lisp'?  I don't see it in Emacs 25.2 or earlier.
But I see 4 functions whose names start with `find-lisp-'.)

>     (This is just a first approach to the problem; for large
>     number of matches would be better to not store the matches
>     in a list).
> 
> 2) [Suppose DIR is the default-directory i the Dired buffer]
>     Then call: (dired (list DIR FILES))
> 
> My implementation works as with GNU ls; the only difference is
> that 2) shows full file names in the Dired buffer.  I rather
> prefer is the output has same format regarless on if the user
> use `ls-lisp' or not.
> 
> With the var `foo' mentioned above, we could change 2) with:
> 3) (let ((foo t)) (dired (list DIR FILES)))

Again, sorry, but I don't really have time to look into this
now.  Two quick comments though, which might be misguided:

1. IIUC, bug #27631 is not a bug.  It is an enhancement request,
for a new feature.  That's not a reason to change a longstanding,
essentially unrelated, behavior that is very general and very
useful.

2. If you call (dired (list DIR FILES)) and you want FILES
to be relative rather than absolute, why can't you just
(for your particular use case) use something like
(dired (list DIR (mapcar #'dired-make-relative FILES)))?
What am I missing?

Possibly you would want to pass DIR or some other directory to
`dired-make-relative' ; dunno.  Or maybe `file-relative-name'
would be more appropriate for your use case; dunno.

I don't understand why you would propose changing `dired'
so that a cons argument is interpreted in some new, more
restrictive way.

I say "more restrictive" because currently you can get
absolute or relative file names, just by passing the
forms of names that you want.  You can even get a mix
of absolute and relative names - that's sometimes handy.

Dired should be able to list file names in either or
both forms.  I see no reason that it shouldn't.

I don't see why you would need to add a variable, as
you describe, instead of just passing the file names
you want in the form(s) that you want.  But I'm probably
missing something in what you're suggesting.