[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dired and ls
From: |
Lars Ingebrigtsen |
Subject: |
Re: dired and ls |
Date: |
Sat, 20 Feb 2016 18:25:24 +1100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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
- Re: Human-readable file sorting, (continued)
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, martin rudalics, 2016/02/20
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, Michael Heerdegen, 2016/02/20
- RE: Human-readable file sorting, Drew Adams, 2016/02/20
- dired and ls (was: Human-readable file sorting), Lars Ingebrigtsen, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls,
Lars Ingebrigtsen <=
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Thierry Volpiatto, 2016/02/23
- Re: dired and ls, John Wiegley, 2016/02/23
- Re: dired and ls (was: Human-readable file sorting), Eli Zaretskii, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Eli Zaretskii, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Lars Ingebrigtsen, 2016/02/20
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, Lars Ingebrigtsen, 2016/02/20