[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal

From: Eli Zaretskii
Subject: 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 <address@hidden>
> Cc: address@hidden,  address@hidden
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]