Picky criticism of ls completion list formatting

Picky criticism of ls completion list formatting

[Peter Whaite]

The 'ls' completion list takes up more screen space than it need.  For example
with ls directory contents are listed as..

% zsh -f  # To get rid of LS_COLORS though doesnt make any difference...

aragorn% ls -F
CVS/           Functions/   Src/           config.guess*   configure.ac
ChangeLog      INSTALL      StartupFiles/  config.h        configure.in
ChangeLog-3.1  LICENCE      Test/          config.h.in     install-sh*
ChangeLog.3.0  META-FAQ     Util/          config.log      mkinstalldirs*
Completion/    Makefile     acconfig.h     config.modules  stamp-h
Config/        Makefile.in  aclocal.m4     config.status*  stamp-h.in
Doc/           Misc/        aczsh.m4       config.sub*     zshconfig.ac
Etc/           README       config.cache   configure*

Listing completions for 'ls' uses more lines because it formats using one less
column. 

aragorn% ls <Ctrl-D>
CVS/             LICENCE          acconfig.h       config.sub*
ChangeLog        META-FAQ         aclocal.m4       configure*
ChangeLog-3.1    Makefile         aczsh.m4         configure.ac 
ChangeLog.3.0    Makefile.in      config.cache     configure.in 
Completion/      Misc/            config.guess*    install-sh*
Config/          README           config.h         mkinstalldirs*
Doc/             Src/             config.h.in      stamp-h 
Etc/             StartupFiles/    config.log       stamp-h.in 
Functions/       Test/            config.modules   zshconfig.ac 
INSTALL          Util/            config.status*   

Mainly just curious why there is a difference.

--
peta

Re: Picky criticism of ls completion list formatting

[Bart Schaefer]

On Jun 28, 12:21pm, Peter Whaite wrote:
} Subject: Picky criticism of ls completion list formatting
}
} Listing completions for 'ls' uses more lines because it formats using
} one less column.
} 
} Mainly just curious why there is a difference.

Because zsh isn't ls.  Zsh doesn't invoke ls to generate the completion
listing, it uses its own filename-generation (globbing) routines and
computes the columns itself.

Try `setopt list_packed'.  If that doesn't make a difference, then there
may be something wrong with the "packing" code that we need to look at.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Picky criticism of ls completion list formatting

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Jun 28, 12:21pm, Peter Whaite wrote:
> } Subject: Picky criticism of ls completion list formatting
> }
> } Listing completions for 'ls' uses more lines because it formats using
> } one less column.
> 
> Try `setopt list_packed'.  If that doesn't make a difference, then there
> may be something wrong with the "packing" code that we need to look at.

list_packed still uses three spaces between columns, it just varies the
column widths.  It might be time to make the column spacing configurable.
Presumably that's not too hard.



**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Picky criticism of ls completion list formatting

[Peter Whaite]

Peter Stephenson said:
> "Bart Schaefer" wrote:
> > On Jun 28, 12:21pm, Peter Whaite wrote:
> > } Subject: Picky criticism of ls completion list formatting
> > }
> > } Listing completions for 'ls' uses more lines because it formats using
> > } one less column.
> > 
> > Try `setopt list_packed'.  If that doesn't make a difference, then there
> > may be something wrong with the "packing" code that we need to look at.
> 
> list_packed still uses three spaces between columns, it just varies the
> column widths.  It might be time to make the column spacing configurable.
> Presumably that's not too hard.

Yes list_packed made a satisfactory difference.

OK I see.  The (GNU) ls algorithm uses variable column widths separated with 2
spaces, whereas zsh by default uses the same column width for all the columns
separated by 3 spaces.  List_packed makes the widths variable but still keeps
the spacing of 3.

Configurable spacing sounds good sometime.  I assume 3 was for readability,
but 2 or 1 is better to conserve space.  TeXish stretch and shrink?

---
peta

Re: Picky criticism of ls completion list formatting

[Bart Schaefer]

On Jun 28,  3:49pm, Peter Whaite wrote:
} 
} Peter Stephenson said:
} > 
} > list_packed still uses three spaces between columns, it just varies the
} > column widths.  It might be time to make the column spacing configurable.
} > Presumably that's not too hard.
} 
} OK I see. The (GNU) ls algorithm uses variable column widths separated
} with 2 spaces, whereas zsh by default uses the same column width for
} all the columns separated by 3 spaces. List_packed makes the widths
} variable but still keeps the spacing of 3.

This is not the behavior I see.

With

listpacked            off
listtypes             on

	I get equally-sized columns with three spaces between.

With

listpacked            on
listtypes             on

	I *still* get equally-sized columns with three spaces between.

With

listpacked            on
listtypes             off

	I get differently-sized columns with *two* spaces between.

Finally, with

listpacked            off
listtypes             off

	I get equally-sized columns with *two* spaces between.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Picky criticism of ls completion list formatting

[Sven Wischnowsky]

Bart Schaefer wrote:

> ... [completion listing layout]

It's all as it should be, including this one:

> With
> 
> listpacked            on
> listtypes             on
> 
> 	I *still* get equally-sized columns with three spaces between.

because it depends on the completion strings.  If the listing code finds
out that packing the list doesn't decrease the number of lines needed,
it uses equally sized columns in the hope that they are better readable.

Try it with:

  % setopt listtypes listpacked
  % touch a12345678901234567890{a,b,c,d} b12{a,b,c,d}
  % ls <TAB>

and you'll see that the listing code can sometimes even increase the
number of spaces between columns if it can do so without needing more
lines (it currently does that only if it can give the same number of
spaces to each column).


And a `btw': with coloured completion listings setting list_types isn't
really needed anymore, so the original poster may think about unsetting it.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Picky criticism of ls completion list formatting

[Alexandre Duret-Lutz]

>>> "Peter" == Peter Whaite <peta@cortexmachina.com> writes:

[...]

 Peter> OK I see.  The (GNU) ls algorithm uses variable column
 Peter> widths separated with 2 spaces, whereas zsh by default
 Peter> uses the same column width for all the columns separated
 Peter> by 3 spaces.  List_packed makes the widths variable but
 Peter> still keeps the spacing of 3.

I looked at this about a year ago, so things maybe different
now, but IIRC both ls and zsh use 2 spaces to separate columns.
The difference is that for ls -F the file-type-character is part
of the filename while Zsh for Zsh it's separate.  If list_types
is set, Zsh will add a third column to display this additional
character.  Thus if you have only plain files, Zsh will appear
to separate column with spaces through actually one of them is a
file-type-charater.  This should be obvious if you highlight
this caracter, for instance with:

  zstyle ':completion:*:default' list-colors 'tc=03;31'

[...]

-- 
Alexandre Duret-Lutz

Re: Picky criticism of ls completion list formatting

[Bart Schaefer]

On Jun 29,  9:13am, Sven Wischnowsky wrote:
} Subject: Re: Picky criticism of ls completion list formatting
}
} It's all as it should be, including this one:
} 
} > With
} > 
} > listpacked            on
} > listtypes             on
} > 
} > 	I *still* get equally-sized columns with three spaces between.

But I'm not really getting three spaces, am I.  I'm getting two spaces
plus the one-character type-marker of a plain file, which happens to
also be a space.  The code just isn't clever enough to strip that off
when the longest name in the column is that of a plain file.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Picky criticism of ls completion list formatting

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 29,  9:13am, Sven Wischnowsky wrote:
> } Subject: Re: Picky criticism of ls completion list formatting
> }
> } It's all as it should be, including this one:
> } 
> } > With
> } > 
> } > listpacked            on
> } > listtypes             on
> } > 
> } > 	I *still* get equally-sized columns with three spaces between.
> 
> But I'm not really getting three spaces, am I.  I'm getting two spaces
> plus the one-character type-marker of a plain file, which happens to
> also be a space.  The code just isn't clever enough to strip that off
> when the longest name in the column is that of a plain file.

Yes.  One of the things I had thought about trying to write several
times but never came around to really trying.  It's one of the things
inherited from the times before I started hacking zsh (the fact that, as
Alexandre said, the code doesn't store the type character with the
matches or uses it in its calculations and that it use spaces instead of
empty strings for normal files).


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de