GNU bug report logs - #18051
24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?

Previous Next

Full log

Message #35 received at 18051 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: michael_heerdegen <at> web.de, 18051 <at> debbugs.gnu.org
Subject: Re: bug#18051: 24.3.92; ls-lisp: Sorting;
 make ls-lisp-string-lessp a normal function?
Date: Fri, 18 Jul 2014 15:57:52 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: michael_heerdegen <at> web.de,  18051 <at> debbugs.gnu.org
> Date: Fri, 18 Jul 2014 12:12:48 +0200
> 
> >> Tramp uses ls-lisp only in case it cannot use a native method on the
> >> remote host. Experience shows, that ls-lisp has a much worse performance
> >> for remote directories than native implementations.
> >
> > Any insight as to why this happens?  Perhaps the Tramp implementation
> > of directory-files-and-attributes needs some love?
> 
> Maybe it is a misunderstanding. Tramp's native implementation is much
> faster, because it sends exactly one remote command. For ssh-like
> connections, this is for example
> 
> # echo "("; (/bin/ls --color=never -a | sed -e s/\$/\"/g -e s/^/\"/g | xargs \stat -c '("%n" ("%N") %h %ue0 %ge0 %Xe0 %Ye0 %Ze0 %se0 "%A" t %ie0 -1)' 2>/dev/null); echo ")" 2>/dev/null

We could easily add this to ls-lisp, in case the directory is remote.
Right now, it simply doesn't support remote directories, because I
didn't know there was any interest in that.

> I would oppose only if there is an additional mandatory functionality in
> ls-lisp other file name primitives are urged to use. If there would
> be changes in, let's say, directory-files-and-attributes, there's no
> problem for me. But that's not what Michael has asked for.

I don't think you understood what Michael wanted, but I'll let Michael
speak for himself.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.