bug#29423: 27.0.50; ls-lisp does not handle -F switch properly

[Michael Albinus <michael.albinus@gmx.de>]

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

Hi Drew,

>> Goto the *scratch* buffer, and perform
>> M-: (ls-lisp-insert-directory "/tmp/" '(?F) nil nil nil)
>> Move the cursor into the string /tmp/, and perform
>> M-x describe-char
>>
>> There is no text property 'dired-filename, as it should.
>
> I think you're talking (only) about the final / char.
> That seems to be the only place where the property is not
> present.

Yes. Finally, it was triggered by Tramp using the F switch. This was
added by Tramp in order to get a trailing / for directory names in the
directory listing.

> Is that / part of the (directory as) file name?  Dunno
> whether that consideration helps here - probably not.
> What to cover by the property really depends on what the
> property is used for.

No, it is not part of the file name. Like the trailing " -> foo" for
symlinks.

My problem is, that the whole file name is missing the text property,
not only the trailing slash.

> Unfortunately perhaps, unlike the case for functions and
> variables, there is no doc string for text properties.
> Unless something is called out for this in some doc string
> or in code comments, only the current uses of the property
> can guide what it should apply to.

I agree. However, in the given case, the text property 'dired-filename
shall highlight exactly the file name. It is used later in dired (as the
name of the property says), but it is also used in Tramp, because for
some of the Tramp backends, ls-lisp-insert-directory is used internally,
and Tramp needs some massage on the result.

> I don't know whether the / should have that property.

No.

> I have checked and see that in Emacs 22 it has it, and
> thereafter it does not.  Regression?  Intentional change?

Likely intentionally.

> The current uses of the property, as I quickly check them
> don't suggest that it matters whether / has the property.
>
> Do you have something (e.g. some use case) particular in
> mind, where you think that the / should have the property?

Again, this is not my point. My point is, that the name itself does not
have the property.

> Should we consider code that expects the result of checking
> for that property to give the same position regardless of
> whether switch `F' is used?  Should the file name be
> considered to be the same, regardless of whether a / is
> appended?

Parsing the output of any insert-directory is a pain. Therefore, it is
helpful to know that the file name part of this output is marked with
'dired-filename.

Even in backends where Tramp does not use ls-lisp-insert-directory,
Tramp tries its best to set this text property for dired. See
tramp-sh-handle-insert-directory, for example.

> In sum, is this a bug to be fixed, a design question, or
> design that was already changed intentionally for Emacs 23?
>
> (I have no idea, and no code of mine depends on what is
> decided, AFAIK.)

I believe it is a bug.

I have just applied my patch locally, and I have rerun the whole Emacs
testsuite. Several errors did appear I haven't seen before. I'll check,
whether they are related to my change.

Best regards, Michael.