[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: empty-directory predicate, native implementation
From: |
Arthur Miller |
Subject: |
Re: empty-directory predicate, native implementation |
Date: |
Mon, 19 Oct 2020 02:24:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Drew Adams <drew.adams@oracle.com> writes:
>> > `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.]
Thanks, that was really informative! Thank you for writing and
explaining all that. I guess for purpose of tests and manual where I
have used your regex, we can live with built-in one.
Please ignore my other mail; I sent it before I red the rest of resonses.
I am obviously to new here, so before I suggest something again :-), can
I ask if you have already considered having a predicate as a filter
function instead of regex? Is it considered as too much work to
implement?
- Re: empty-directory predicate, native implementation, (continued)
- Re: empty-directory predicate, native implementation, Arthur Miller, 2020/10/18
- Re: empty-directory predicate, native implementation, Michael Albinus, 2020/10/19
- Re: empty-directory predicate, native implementation, Arthur Miller, 2020/10/19
- Re: empty-directory predicate, native implementation, Michael Albinus, 2020/10/19
- Re: empty-directory predicate, native implementation, Stefan Monnier, 2020/10/15
- Re: empty-directory predicate, native implementation, Arthur Miller, 2020/10/16
- Re: empty-directory predicate, native implementation, Arthur Miller, 2020/10/14
RE: empty-directory predicate, native implementation, Drew Adams, 2020/10/18
Re: empty-directory predicate, native implementation, Michael Albinus, 2020/10/19