Re: dired and ls

[Lars Ingebrigtsen]

John Wiegley <address@hidden> writes:

> The /bin/ls process is asynchronous, so a really long "ls -R" listing doesn't
> need to block Emacs, does it?

That's true.  With "ls" the opportunity for async behaviour is greater.
I don't think dired currently is async, but it could be...  

>> Hm... and there are a lot of functions in Emacs that only wants to know the
>> file name and whether it's a directory or not... I mean, basically every
>> file prompting function only needs that info...
>
> Are you also suggesting another improvement (Rubs hands expectantly)?

:-)

> Or does this follow from the above, in which case I missed the
> implication...

I was thinking out loud.  :-)  I'm looking at file_name_completion now,
and the basic loop is:

  for (struct dirent *dp; (dp = read_dirent (d, dirname)); )
    {

[...]

      if (file_name_completion_stat (fd, dp, &st) < 0)
        continue;

      directoryp = S_ISDIR (st.st_mode) != 0;

and that seems to be the only data used from the stat call.  So a
`(directory-files-with-attributes DIR ... FILE-OR-DIR-ONLY-P)' function
seems like it would speed things up a lot if you hit TAB while looking
for a file in a large directory (on Linux and BSD).

The function could have two modes -- one where it only returned the file
name + dirp, and one where it returns full attributes.  The former case
would be just a readdir loop, so it would be very fast, while the second
would need to stat every file, so it would... not.

`dired' would typically need the latter, while file completion would
need the former.

Modulo that I'm reading the code right.  The completion code is terra
incognito to me.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no