From: greg@alphatech.com (Greg Klanderman)
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
Cc: zsh-workers@math.gatech.edu, greg@alphatech.com
Subject: Re: bug in 3.1.4 completion
Date: Thu, 5 Nov 1998 11:12:26 -0500 (EST) [thread overview]
Message-ID: <13889.52842.202224.110281@catbus.alphatech.com> (raw)
In-Reply-To: <199811040904.KAA29172@beta.informatik.hu-berlin.de>
Sven,
I grabbed 3.1.5 and have a few comments...
(remember to copy me on replies. thanks)
>>>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
Sven>
Sven> greg@alphatech.com wrote:
Sven>
>> Hi,
>>
>> I have found a minor bug in zsh 3.1.4 completion related to the
>> automagic removal of completed slashes. If I invoke zsh -f,
>>
>> % mkdir test
>> % cd test
>> % mkdir foo
>> % mkdir foo/bar foo/barbaz
>>
>> % ls f ; now type TAB
>> -> foo/ ; now type TAB
>> -> foo/bar ; now type SPACE
>> -> foo/ba ; notice the "r" got removed.
>>
>> This only seems to happen if you complete "foo" then
>> immediately hit TAB again. If you type part of "bar" and
>> then TAB it functions correctly.
Sven> There was a missing fixsuffix() when inserting the unambiguous string
Sven> for normal completion. It's fixed by the second hunk in the patch
Sven> below (this is for 3.1.5, but you can easily insert the call to
Sven> fixsuffix() in 3.1.4 in do_ambiguous() in the else-branch of the `if(p)').
As Bart noted, this is fixed in 3.1.5 as found on the ftp site.
Your second hunk is not even close to applying.
>> While I'm at it I have a few other nits about the completion system
>> (which on the whole I think is excellent).
>>
>> First, another somewhat inconvenient behavior related to slash removal
>> (again zsh -f, and with the same directories created above):
>>
>> % ls fo bar ; position the cursor on the space after the "o", hit TAB
>> -> foo/ bar ; now, the cursor is still on the space after the "/".
>> ; hit Control-d to delete the space
>> -> foo/bar ; with cursor on "b". now Control-e (end-of-line) and
>> -> foobar ; the "/" gets removed. ugh.
Sven> Here is another missing call to fixsuffix() (fixed by the first
Sven> hunk). This one goes into deletecharorlist() which has to do the
Sven> itself since the calling code doesn't call fixsuffix() since it may
Sven> use the completion code.
Fixed with the first hunk. Thanks.
>> Another behavior that's not quite right IMHO is completeinword:
>>
>> % setopt noalwaystoend completeinword
>> % ls fo/bar ; position cursor on "/", hit TAB
>> -> foo/bar/ ; hit TAB again
>> -> foo/bar// ; hit TAB again
>> -> foo/bar/// ; etc, never listing possible completions
>>
>> Even if I move past the "/", or even "b" it never jumps to the end of
>> "bar".
Sven> This is fixed in 3.1.5 with my last patches.
Do you mean a patch on top of 3.1.5, or one included in 3.1.5?
This does not appear to be fixed in 3.1.5 proper.
Greg
next prev parent reply other threads:[~1998-11-05 16:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-04 9:04 Sven Wischnowsky
1998-11-04 17:31 ` Bart Schaefer
1998-11-04 17:59 ` Bart Schaefer
1998-11-05 0:32 ` Greg Klanderman
1998-11-05 16:12 ` Greg Klanderman [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-11-05 16:34 Sven Wischnowsky
1998-11-05 10:47 Sven Wischnowsky
1998-11-05 8:02 Sven Wischnowsky
1998-11-03 17:28 Greg Klanderman
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=13889.52842.202224.110281@catbus.alphatech.com \
--to=greg@alphatech.com \
--cc=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@math.gatech.edu \
/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).