From: Drew Adams <drew.adams@oracle.com>
To: Michael Albinus <michael.albinus@gmx.de>, 29423@debbugs.gnu.org
Subject: bug#29423: 27.0.50; ls-lisp does not handle -F switch properly
Date: Fri, 24 Nov 2017 08:30:47 -0800 (PST) [thread overview]
Message-ID: <335b6fe8-7d72-462d-a0ef-778b93955ddb@default> (raw)
In-Reply-To: <87fu93yhdy.fsf@gmx.de>
> 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.
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.
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 don't know whether the / should have that property.
I have checked and see that in Emacs 22 it has it, and
thereafter it does not. Regression? Intentional change?
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?
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?
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.)
next prev parent reply other threads:[~2017-11-24 16:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 12:45 bug#29423: 27.0.50; ls-lisp does not handle -F switch properly Michael Albinus
2017-11-24 13:37 ` Eli Zaretskii
2017-11-24 13:41 ` Michael Albinus
2017-11-24 14:56 ` Eli Zaretskii
2017-11-24 15:13 ` Michael Albinus
2017-11-24 15:47 ` Eli Zaretskii
2017-11-25 8:12 ` Eli Zaretskii
2017-11-25 8:59 ` Michael Albinus
2017-11-25 10:37 ` Eli Zaretskii
2017-11-24 16:30 ` Drew Adams [this message]
2017-11-24 16:56 ` Michael Albinus
2017-11-24 17:12 ` Drew Adams
2017-11-24 18:48 ` Michael Albinus
2017-11-24 19:28 ` Drew Adams
2017-11-24 19:51 ` Noam Postavsky
2017-11-24 20:27 ` Drew Adams
2017-11-24 20:37 ` Noam Postavsky
2017-11-24 20:51 ` Drew Adams
2017-11-24 17:02 ` Eli Zaretskii
2017-11-24 18:49 ` Michael Albinus
2017-11-24 19:52 ` Eli Zaretskii
2017-11-24 21:03 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=335b6fe8-7d72-462d-a0ef-778b93955ddb@default \
--to=drew.adams@oracle.com \
--cc=29423@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.