From: Drew Adams <drew.adams@oracle.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: Eli Zaretskii <eliz@gnu.org>,
Arthur Miller <arthur.miller@live.com>,
emacs-devel@gnu.org
Subject: RE: empty-directory predicate, native implementation
Date: Sun, 18 Oct 2020 14:13:43 -0700 (PDT) [thread overview]
Message-ID: <dbac0852-2562-41e1-962a-b302a6fefec0@default> (raw)
> > `directory-files-no-dot-files-regexp' was added to Emacs 23.
> > Its value then was the same as that of `diredp-re-no-dot':
> > "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*". The value was
> > changed in Emacs 27, to "[^.]\\|\\.\\.\\.".
> >
> > For my purposes (Dired) I want the former, not the latter,
> > so `diredp-re-no-dot' remains the former. The two behave
> > quite differently.
> >
> > See https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs-
> devel/2020-
> 04/msg00764.html__;!!GqivPVa7Brio!PWSpyl3EDfFC2LKEXIP7mdNKcGl6HzDDLwE2SFOWdxS
> ZaQ3phv5AVvVuUb-CN6kG$
>
> FTR, I have also problems to understand how the current value of
> directory-files-no-dot-files-regexp works. But I fail to find a case
> where it is wrong.
>
> (string-match directory-files-no-dot-files-regexp ".") => nil
> (string-match directory-files-no-dot-files-regexp "..") => nil
> (string-match directory-files-no-dot-files-regexp ".a") => 1
> (string-match directory-files-no-dot-files-regexp "..a") => 2
>
> Could you pls give me an example which shows the problem with that
> constant? In case there is, I'll lobby for your request in the given
> message :-)
Dunno. And perhaps I misspoke in saying they behave quite
differently. They _can_ behave quite differently, depending
on how they're used.
And frankly I think that the only current Dired+ uses of the
regexp don't depend on the difference, as they all just pass
it to `directory-files' as the MATCH arg. And in that case
the new regexp is just as usable.
In general, the difference between the two is this, AFAICT:
the old one (which is the one still used by Dired+) matches
the complete file name (the nondirectory part), whereas the
new one matches only enough of it to distinguish the . and
.. cases.
IOW, what's different, AFAICS, is the match data: the match.
So if you use the regexp only with `string-match-p' (which
doesn't care about the match data), or if you use it only
with `directory-files', then there's no real difference in
the effect. But if you use it for some context where the
matched parts are important, that is, where the match-data
matters, then there's a big difference.
Perhaps in the past I used the regexp also for purposes of
grabbing the matched part(s). I don't recall.
I didn't complain about Emacs changing the value of the
variable - no lobbying is needed. What I said was that
"it's not clear to me" why people were claiming that the
new regexp is "more correct" than the old one. (No one
ever responded to that, explaining in what way the old
one was somehow incorrect.)
Paul's mail responding to my mail in that emacs-devel
thread says, BTW:
As Drew's comments make evident, the doc string is
unclear. It should be something like 'Regexp that
matches part of a nonempty string if the string is
^^^^^^^^^^^^
neither "." nor "..".'
But I couldn't find where in that thread I said that.
Anyway, I've said it now. The old regexp matches all
chars in the nondir part of the file name. The new
regexp doesn't. The match data for the old regexp
gives you the matched name. But no, that's not
needed for `directory-file-names'.
___
[BTW, neither manual nor doc string for `directory-files'
says what MATCH is matched against, other than "file names".
But apparently it's matched only against the nondirectory
part of file names, even if FULL is non-nil.]
next reply other threads:[~2020-10-18 21:13 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-18 21:13 Drew Adams [this message]
2020-10-18 22:15 ` empty-directory predicate, native implementation Stefan Monnier
2020-10-19 7:54 ` Michael Albinus
2020-10-19 0:24 ` Arthur Miller
2020-10-19 0:37 ` Drew Adams
2020-10-19 2:15 ` Arthur Miller
2020-10-19 7:51 ` Michael Albinus
2020-10-19 15:25 ` Drew Adams
[not found] <<VI1PR06MB4526ACBABDE795DDD49A5A5896040@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<83y2ka18t7.fsf@gnu.org>
[not found] ` <<87y2kaj799.fsf@gmx.de>
[not found] ` <<83blh60wgr.fsf@gnu.org>
[not found] ` <<VI1PR06MB452688C9C71D5463D9497A2A96050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87h7qxjh7g.fsf@gmx.de>
[not found] ` <<VI1PR06MB45269B3924B44A555428F00596050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<878sc8kgy8.fsf@gmx.de>
[not found] ` <<VI1PR06MB4526FDD3D3EB4867AF837C8F96050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87imbcls71.fsf@gmx.de>
[not found] ` <<83eem0zt0b.fsf@gnu.org>
[not found] ` <<87k0vsrd6m.fsf@gmx.de>
[not found] ` <<83a6wozs7h.fsf@gnu.org>
[not found] ` <<VI1PR06MB45267C7D83E77C3F307FF34E96020@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87sgafq2e2.fsf@gmx.de>
[not found] ` <<AM6PR06MB4518BCD25B93987390D7D6D596020@AM6PR06MB4518.eurprd06.prod.outlook.com>
[not found] ` <<87h7qvptm3.fsf@gmx.de>
[not found] ` <<VI1PR06MB452605D66CDE84BAA25A257696030@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<871rhxp8we.fsf@gmx.de>
[not found] ` <<VI1PR06MB45261F3309D31EC7DEDE4C8B96000@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<237bd21b-96c7-4433-a5bc-34b64a9f4250@default>
[not found] ` <<83ft6cs10u.fsf@gnu.org>
2020-10-18 4:05 ` Drew Adams
-- strict thread matches above, loose matches on Subject: below --
2020-10-13 2:22 Arthur Miller
2020-10-13 8:01 ` Michael Albinus
2020-10-13 11:42 ` Arthur Miller
2020-10-13 13:16 ` Michael Albinus
2020-10-13 18:32 ` Arthur Miller
2020-10-13 18:39 ` Michael Albinus
2020-10-13 23:20 ` Arthur Miller
2020-10-14 9:19 ` Michael Albinus
2020-10-14 13:53 ` Arthur Miller
2020-10-13 14:48 ` Eli Zaretskii
2020-10-13 18:43 ` Arthur Miller
2020-10-13 19:12 ` Eli Zaretskii
2020-10-13 19:59 ` Arthur Miller
2020-10-14 14:08 ` Eli Zaretskii
2020-10-14 14:43 ` Arthur Miller
2020-10-13 18:44 ` Michael Albinus
2020-10-13 19:14 ` Eli Zaretskii
2020-10-13 20:08 ` Arthur Miller
2020-10-14 1:52 ` Arthur Miller
2020-10-14 9:21 ` Michael Albinus
2020-10-14 13:56 ` Arthur Miller
2020-10-14 14:41 ` Michael Albinus
2020-10-14 15:07 ` Arthur Miller
2020-10-14 15:53 ` Michael Albinus
2020-10-14 16:12 ` Eli Zaretskii
2020-10-14 16:21 ` Michael Albinus
2020-10-14 16:29 ` Eli Zaretskii
2020-10-15 5:53 ` Arthur Miller
2020-10-15 9:12 ` Michael Albinus
2020-10-15 11:33 ` Arthur Miller
2020-10-15 12:21 ` Michael Albinus
2020-10-15 13:29 ` Arthur Miller
2020-10-15 14:01 ` Arthur Miller
2020-10-15 14:41 ` Michael Albinus
2020-10-15 15:22 ` Arthur Miller
2020-10-16 23:31 ` Arthur Miller
2020-10-17 8:13 ` Michael Albinus
2020-10-17 19:03 ` Arthur Miller
2020-10-17 20:03 ` Drew Adams
2020-10-17 20:27 ` Arthur Miller
2020-10-17 21:18 ` Drew Adams
2020-10-17 22:06 ` Arthur Miller
2020-10-17 21:02 ` Arthur Miller
2020-10-17 21:27 ` Drew Adams
2020-10-17 21:58 ` Arthur Miller
2020-10-18 12:06 ` Michael Albinus
2020-10-18 2:47 ` Eli Zaretskii
2020-10-18 11:52 ` Michael Albinus
2020-10-18 16:15 ` Drew Adams
2020-10-18 16:43 ` Michael Albinus
2020-10-18 20:15 ` Stefan Monnier
2020-10-18 21:25 ` Drew Adams
2020-10-19 0:03 ` Arthur Miller
2020-10-18 22:21 ` Arthur Miller
2020-10-19 8:04 ` Michael Albinus
2020-10-19 14:01 ` Arthur Miller
2020-10-19 14:50 ` Michael Albinus
[not found] ` <VI1PR06MB45266BE5DFC72AEB27567A6C961E0@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <87a6wixoim.fsf@gmx.de>
[not found] ` <VI1PR06MB4526280D5B81531D06E58BC1961D0@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <87wnzev6i3.fsf@gmx.de>
[not found] ` <VI1PR06MB45264E1CB34EECE86672581C96100@VI1PR06MB4526.eurprd06.prod.outlook.com>
2020-11-02 17:02 ` Michael Albinus
2020-11-03 15:20 ` Arthur Miller
2020-10-15 13:38 ` Stefan Monnier
2020-10-16 23:33 ` Arthur Miller
2020-10-14 14:49 ` Arthur Miller
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=dbac0852-2562-41e1-962a-b302a6fefec0@default \
--to=drew.adams@oracle.com \
--cc=arthur.miller@live.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@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.