Re: Bug? in complist when filenames are longer than the screen

[DervishD <zsh@xxxxxxxxxxxx>]

    Hi Bart :)

 * Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> dixit:
> On Oct 3,  4:45pm, DervishD wrote:
> }     $ touch a b c filename1 filename2 d e
> }     $ zmodload zsh/complist
> }     $ COLUMNS=3
> I didn't look at this all that closely before, but it's not at all
> surprising that the display gets messed up when COLUMNS is not the
> same as the actual width of the window.  The complist module relies
> on the terminal emulator to have wrapped long lines, etc., when
> they were output; it does not insert its own line breaks at an
> imaginary window boundary.  (ZLE sometimes appears to do so, but it
> has a lot of extra smarts regarding terminals that don't
> auto-scroll, very few of which smarts were ever incorporated into
> complist.)

    OK, but I used COLUMNS=3 just to avoid to "touch" very long file
names. The problem is the same here with "COLUMS=100" (the default in
my system) and very long file names, even without a long prompt.

> Are you sure you don't mean MENUSELECT=3 in that example?  If you
> have never set MENUSELECT, then loading the zsh/complist module is
> not going to have any effect, and in this next step ...

    No, I'm sure. When testing, I didn't set up MENUSELECT, but I'm
afraid it got inherited from the login shell :((( with a value of 0.

    I'm going to make another test, using a clean environment. OK,
here are the results with the UNPATCHED version of zsh: if I use very
long names (much longer than COLUMNS), the bug doesn't happen!. It
only happens with a list of files in one directory :??? Mmm,
interesting, it looks like a corner case: the bug only happens when
in the file listing is there a file whose name length is *exactly*
$COLUMNS. Longer or shorter files doesn't cause the bug to happen.
I've tested this with different prompts and in a clean environment
(that is, the login shell doesn't source ANY file, because no RC file
is present).

    I've found the bug to be repeatable with this sequence (try this
in a clean zsh environment, no /etc/zshenv, no any other rcfile, and
it must be a login shell, just to make sure):

    $ rm -rf test
    $ mkdir test ; cd test
    $ PS1=
    $ touch ${(l:$COLUMNS::a:):-} a b c
    $ zmodload zsh/complist
    $ MENUSELECT=0

    It's very important to create the other three files (a, b and c)
in the directory (otherwise you won't get a list ;)).

    This causes a crash, always, without looping, even with your
patches.

> }     $ ls <TAB><TAB><TAB><TAB><UP><DOWN>
> ... the up/down are going to scroll through the history, not through
> the completions.  If you're getting a reproducible crash exactly as
> described above, then it's not completion that's crashing, and we
> need to be looking elsewhere.

    The command above runs through the completions if MENUSELECT is
0, of course. My fault, I should have carried the tests in a fully
clean and default environment, not just "zsh -f", because variables
and the like are inherited. Sorry :(((

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...