Re: empty-directory predicate, native implementation

[Arthur Miller <arthur.miller@live.com>]

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?