Re: empty-directory predicate, native implementation

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

Arthur Miller <arthur.miller@live.com> writes:

Hi,

>> But my argument wasn't about implementation or
>> efficiency.  Even if, for some reason, C had to "get"
>> (info about) all of the files in the directory, just
>> to determine whether the dir is empty, my argument
>> would be the same wrt Lisp: have a separate predicate,
>> or have a Boolean new parameter, instead of having a
>> COUNT new parameter.
>
> I am not sure I follow; but it is a building block to build that
> predicate. I agree with you that it is much nice to have such predicate
> built-in than if anyone is building their own if it is just one liner.
>
> I have no problems to build that predicate on directory_files_internal
> either, it is trivial; and it would remove need to change the function
> signature and count confusion, but than instead of changing one
> parameter in a signature it would be a new predicate in Lisp
> implementation. Wold be nice exercise to me to learn how to write
> a tramp handler :-), but I am not sure it is desired.
>
> Don't know, what Michael and Eli have to say about?

I'm in line with Eli here. I have no glaring example that we need COUNT
greater than one. Just a vague idea, that it could help to implement a
more performant file name completion, especially in the remote
case. That is, if you have a very large directory, you let complete file
names on-the-fly (while typing in the minibuffer) with just the first 50
hits from directory-files, which could be retrieved much faster than,
say, more than 2000 file names (this is what I have in /usr/bin). The
complete file names for completion are retrieved, when the user hits TAB.

Just a vague idea; I haven't checked how to implement.

So I propose we still use the COUNT optional argument. This isn't worse
than an argument NOT-EMPTY, which would let directory-files return
immediately after the first hit has found.

Best regards, Michael.