From: DervishD <zsh@dervishd.net>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Workers <zsh-workers@sunsite.dk>
Subject: Re: Bug? in complist when filenames are longer than the screen
Date: Tue, 4 Oct 2005 19:13:51 +0200 [thread overview]
Message-ID: <20051004171351.GB20791@DervishD> (raw)
In-Reply-To: <1051004161114.ZM32268@candle.brasslantern.com>
Hi Bart :)
* Bart Schaefer <schaefer@brasslantern.com> 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...
next prev parent reply other threads:[~2005-10-04 17:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-03 14:45 DervishD
2005-10-03 17:45 ` Andrey Borzenkov
2005-10-03 18:48 ` DervishD
2005-10-04 2:07 ` Bart Schaefer
2005-10-04 4:39 ` PATCH? - " Bart Schaefer
2005-10-04 9:48 ` DervishD
2005-10-04 10:38 ` Peter Stephenson
2005-10-04 10:47 ` DervishD
2005-10-04 11:19 ` Peter Stephenson
2005-10-04 11:31 ` DervishD
2005-10-04 14:32 ` Bart Schaefer
2005-10-04 14:09 ` Bart Schaefer
2005-10-04 16:37 ` DervishD
2005-10-04 16:11 ` Bart Schaefer
2005-10-04 17:13 ` DervishD [this message]
2005-10-04 19:24 ` Andrey Borzenkov
2005-10-04 20:41 ` DervishD
2005-10-06 16:01 ` Bart Schaefer
2005-10-06 16:31 ` DervishD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051004171351.GB20791@DervishD \
--to=zsh@dervishd.net \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).