dired and ls (was: Human-readable file sorting)

[Lars Ingebrigtsen <larsi@gnus.org>]

This all reminds me of something I forgot to prattle on about in that
dired bug report: ls-lisp.el.

dired (on Unixey systems) uses "ls" to get the contents of directories,
and then parses the results.  And generates a buffer.  Not all systems
have "ls", so in that case it uses ls-lisp.el, which just calls
directory-files and then file-attributes in a loop.

I think this is rather suboptimal for many reasons:

1) dired look unnecessarily different on different systems

2) the customisability is limited -- both the look of the buffers and
the sorting is limited by what the native "ls" returns

3) Reasons!  So many reasons!

I've asked "but why" before, but the only response I can remember is "ls
is faster".  Which may be true!  (I may be misremembering this being the
only answer.)  Because `directory-files' uses opendir/readdir first to
get the file names, and then we have to stat each and every file just to
find out whether they're files or directories.

If we instead had `directory-files-with-attributes' in C, we could just
do what "ls" does, which is...  opening the directory, reading it, and
then statting all the files.  (I just straced "ls -l".)  So it should be
just as fast?  I think?  And if you have your dired set up not to show
ownership, date or file permissions, you don't even have to stat
anything on Linux/BSD -- the d_type says whether something is a file or
a directory directly.

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...

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