Whether file is executable or not affects sort order in netrw

[James Kanze]

Whether a file is executable or not seems to affect the sort
ordering in netrw. In my .vimrc, I have:

let g:netrw_sort_sequence='[\/]$,*,\.o$,\.info$,\.swp$,\.obj$,\.bak
$,\.orig$,^\.'

(All on one line, in case something screws up the formatting
along the way.)

In one particular directory, which contains some shell scripts
(.sh), I get:

../
Gabi/
comp-gcc/
comp-suncc-stlport/
comp-suncc/
comp-vc80/
conf/
syst-posix/
syst-windows/
GNUmakefile
makeVariants.sh*
makeVariants.sh.orig*
makeVersion.sh*
makeVersion.sh.bak*
makeVersion.sh.orig*
.makeVersion.sh.swp
GNUmakefile.orig
.nfs005545560000041a
.nfs005545580000041b

With the .orig and .bak of the executable files ordered without
regard to the sort sequence. (Adding \.bak\*$,\.orig\*$ to the
list fixes the problem.) This seems like a bug to me; I would
have expected the sorting to take place before the * got added.
(But wouldn't this prevent using the sort ordering to get the
directories to the top? So maybe it isn't a bug after all, but
a feature.)

Or perhaps there's some way of turning off the *; syntax
highlighting displays it in a different color, so it doesn't add
anything. (Or does syntax highlighting trigger on the * for the
color.) Or turning off any particular recognition whether a
file is executable or not---I know which files should be
executable (from the name, if nothing else), and when moving
files to and from Windows, the x bit often gets set for files
where it doesn't apply, so the information is in some ways
false. (x-bit or not, if I invoke a C++ source as a command,
Unix isn't going to execute it.)

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Charles Campbell]

The sort ordering process does take into account the filetype
indicators; as you've surmised,
its how it differentiates directories from other filetypes. The
trailing '*' means "executable";
the syntax highlighting itself triggers on that. Currently there's no
way to turn that filigree
off. I suppose I could add yet-another-option to disable most filigree
(not the directory indicator).

Regards,
Chip Campbell

[James Kanze]

On Dec 10, 6:19 pm, Charles Campbell <Charles.E.Campb...@nasa.gov>
wrote:

If you have the time, fine. If not, I sort of figured out what
was going on as I wrote the posting: I've added the rules to the
sort sequence, and the results are good enough for me. (The
.bak and the .bak* are still separately ordered, but it really
doesn't matter, since I'm not concerned about them.) The main
case where the proposed option might interest me is when I
import files from Windows; typically, the x bit is set on all of
them, so they all appear as executables, which is false; in such
cases, I'd prefer nothing appearing as an executable. But it's
not a big thing.