Re: empty-directory predicate, native implementation

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 13 Oct 2020 20:43:41 +0200
>> 
>> > directory-files (and which you missed).  For example, file names need
>> > to be encoded before they are passed to libc functions (or any
>> > external APIs that expect file names).
>> Actually I didn't; I first tested with ENCODE_FILE but I didn't know
>> what it does, and it appeared like it is working without, so I ditched
>> it.
>
> It worked without ENCODE_FILE by sheer luck: you must have tried that
> on a system where file names are encoded in UTF-8, and so most file
> names can be used without any conversion (but ENCODE_FILE already
> knows that).
I see :-). I spent quite a lot time earlier today to get it to work on
windows, mostly for the conversion between utf8 and unicode; tried first
to manually convert between utf/wide, and after several tries discovered
some functions in w32.c I could reuse: filename_to_utf16 and 
filename_to_ansi, which worked for me (minus tramp of course).

Can I ask two questions, just for my learning; you seem to handle
ascii/unicode "manually"; in w32.c I have seen quite a few places where
switch is done on if(w32_unicode_filenames); is it possible to somehow
pass to configure script if Emacs should be compiled with wide or asci
version of win api? 

Second question: block_input; is there some general rule(s) what calls you
enclose with block/unblock_input? I guess OS will anyway block the
process after call to SYS_getdents so I didn't enclosed it; but I am not
sure if that would be needed at all or not.

I have attached my patch with win code as illustration to those
questions.

dired.patch
Description: dired.c