Re: bug in 3.1.4 completion

Re: bug in 3.1.4 completion

[Sven Wischnowsky]

greg@alphatech.com wrote:

> 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.
> 

There was a missing fixsuffix() when inserting the unambiguous string
for normal completion. It's fixed by the second hunk in the patch
below (this is for 3.1.5, but you can easily insert the call to
fixsuffix() in 3.1.4 in do_ambiguous() in the else-branch of the `if(p)').

> 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.
> 

Here is another missing call to fixsuffix() (fixed by the first
hunk). This one goes into deletecharorlist() which has to do the
itself since the calling code doesn't call fixsuffix() since it may
use the completion code.

>                 
> 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".

This is fixed in 3.1.5 with my last patches.

> Setting alwaystoend helps, though it is still very picky about
> the stuff on both sides matching, which often makes the feature
> useless.  I have modified emacs to do what I believe is the right
> thing:
> 
>    * look for completions using both text on left and right.
>      if there are none, look only for completions from the left.  this 
>      way having some garbage on the right doesn't hose you, it just
>      gets pushed right (it may match later, after more completing).
>    * now, insert the completed text, placing cursor at the end of the
>      insertion.
>    * remove the longest substring to the right (with start anchored at
>      the cursor) which matches a substring to the left (with end
>      anchored at the cursor).  there may be none.
> 
> How hard would it be to add this to zsh?
> 

That would be expand-or-complete-prefix with a little hacking (the remove-
the-matched-prefix-of-the-suffix part), not too hard.

> While I'm on little nits, it would be nice if the FIGNORE variable
> were not used when listing completions:
> 
> % FIGNORE='.o'
> % touch foo.o foo.c
> % ls fo      ; type Control-d to list completions, you only see "foo.c"
> 

I'm not too sure about this one, since C-d should list the completions 
and if there are other matching files the ignored ones aren't
completions. If there are no other files fignore will be ignored and
the files will be listed. I could be convinced to list the ignored
files separately (this indeed may make sense).

> One last feature that'd be nice is automatic case conversion.  When
> completing, if no completions are found, try again for a case
> insensitive completion.  Would this be easy to add?

We got many requests for this. For 3.1.5 there is a proposed patch
that adds a generic way to control the matching behavior of
completion. With this you can get case-insensitive completion, partial 
word completion and several other things.

Bye
 Sven

diff -c os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
*** os/Zle/zle_tricky.c	Wed Nov  4 08:57:00 1998
--- Src/Zle/zle_tricky.c	Wed Nov  4 09:17:18 1998
***************
*** 309,316 ****
  
      usemenu = isset(MENUCOMPLETE);
      useglob = isset(GLOBCOMPLETE);
!     if (cs != ll)
  	deletechar();
      else
  	docomplete(COMP_LIST_COMPLETE);
  
--- 309,318 ----
  
      usemenu = isset(MENUCOMPLETE);
      useglob = isset(GLOBCOMPLETE);
!     if (cs != ll) {
! 	fixsuffix();
  	deletechar();
+     }
      else
  	docomplete(COMP_LIST_COMPLETE);
  
***************
*** 4789,4794 ****
--- 4791,4798 ----
  	int ics = cs, ocs, pl = 0, l, lp, ls;
  	char *ps;
  	Cline lc;
+ 
+ 	fixsuffix();
  
  	/* Delete the old stuff from the command line. */
  	cs = wb;

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

Re: bug in 3.1.4 completion

[Bart Schaefer]

On Nov 4, 10:04am, Sven Wischnowsky wrote:
} Subject: Re:  bug in 3.1.4 completion
}
} There was a missing fixsuffix() when inserting the unambiguous string
} for normal completion.  [...]
} 
} Here is another missing call to fixsuffix() (fixed by the first
} hunk). [...]

There seem to be an awful lot of completion bugs related to missing or
misplaced calls to fixsuffix().  Those bugs weren't present in 3.0.5.
I was was not paying much attention to 3.1 until just before 3.1.4 (too
busy with "real life") so I sort of glossed over all the changes that
turned zle into a module, etc.  Was whatever reorganization required
the addition of fixsuffix() really a good idea?  It doesn't -seem- like
something that should need to be done in so many different places ...

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

Re: bug in 3.1.4 completion

[Bart Schaefer]

On Nov 4, 10:04am, Sven Wischnowsky wrote:
} Subject: Re:  bug in 3.1.4 completion
}
} greg@alphatech.com wrote:
} 
} > % 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.
} 
} There was a missing fixsuffix() when inserting the unambiguous string
} for normal completion. It's fixed by the second hunk in the patch
} below (this is for 3.1.5, but you can easily insert the call to
} fixsuffix() in 3.1.4 in do_ambiguous() in the else-branch of the `if(p)').

Two points:  (1) This patch is NOT for 3.1.5.  It's for 3.1.5 *after*
one of Sven's other patches has been applied.  (2) I don't see the bug
that Greg reported in my copy of 3.1.5, so it presumably was addressed
by Sven's patch in zsh-workers/4412.

I don't think BOTH the 4412 patch and this one are needed; so which is
better, Sven?  (I suspect Sven's other completion patches may have
inadvertently backed out 4412, and therefore this fix got introduced
in its place, but the 4412 one looks better to me.)

} > % 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.
} 
} Here is another missing call to fixsuffix() (fixed by the first
} hunk).

This hunk *is* needed, however.

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

Re: bug in 3.1.4 completion

[Greg Klanderman]

>>>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
Sven> 
Sven> greg@alphatech.com wrote:

Thanks for the patch, I'll try it with 3.1.5 after you follow up
to Bart's question.


>> [how to improve complete-in-word]

Sven> That would be expand-or-complete-prefix with a little hacking (the remove-
Sven> the-matched-prefix-of-the-suffix part), not too hard.

OK, I implemented it as a shell function and it works nicely.
I'm having a suffix removal problem but that might be fixed 
by your patch.

>> While I'm on little nits, it would be nice if the FIGNORE variable
>> were not used when listing completions:

Sven> I'm not too sure about this one, since C-d should list the completions 
Sven> and if there are other matching files the ignored ones aren't
Sven> completions. If there are no other files fignore will be ignored and
Sven> the files will be listed. I could be convinced to list the ignored
Sven> files separately (this indeed may make sense).

I believe tcsh works as I suggest.  Not that that's a good reason 
to change, but it makes sense to me that if you're listing
completions, that you be shown everything that matches what you've
typed so far, because then you can get to an otherwise ignored file if 
you want.  This is pretty minor, I'm not going to argue it.

Sven> We got many requests for this. For 3.1.5 there is a proposed patch
Sven> that adds a generic way to control the matching behavior of
Sven> completion. With this you can get case-insensitive completion, partial 
Sven> word completion and several other things.

I'll look for it sometime in the future...

Hey, one more minor suggestion - if you abort a command you're typing
(C-c or C-g) it'd be nice to indicate that on the aborted line so it
doesn't look like you actually executed it.  Csh prints "^C" at the
end of the line, for example.

Greg

Re: bug in 3.1.4 completion

[Greg Klanderman]

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

Re: bug in 3.1.4 completion

[Sven Wischnowsky]

greg@alphatech.com wrote:

> 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.
> 

I guess for those on the list it is clear already, but to make sure
(and for you, Greg): I meant a 3.1.5 with some patches I sent to the
list. In that version the patch is needed.

> 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.

Again, this is for 3.1.5 with the (rather biggish) patches.

Bye
 Sven


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

Re: bug in 3.1.4 completion

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Nov 4, 10:04am, Sven Wischnowsky wrote:
> } Subject: Re:  bug in 3.1.4 completion
> }
> } There was a missing fixsuffix() when inserting the unambiguous string
> } for normal completion.  [...]
> } 
> } Here is another missing call to fixsuffix() (fixed by the first
> } hunk). [...]
> 
> There seem to be an awful lot of completion bugs related to missing or
> misplaced calls to fixsuffix().  Those bugs weren't present in 3.0.5.
> I was was not paying much attention to 3.1 until just before 3.1.4 (too
> busy with "real life") so I sort of glossed over all the changes that
> turned zle into a module, etc.  Was whatever reorganization required
> the addition of fixsuffix() really a good idea?  It doesn't -seem- like
> something that should need to be done in so many different places ...

It isn't that bad, three calls in zle_misc.c and three in
zle_tricky.c. I just had some trouble inserting it in all the places
where the completion code changes the line (the one in
delete-char-or-list was something special since there I had to insert
it in the if-branch that *didn't* call the completion code, it should
have been there from the beginning).

We could try to replace the calls we have now by calls in those
functions that actually alter the command line (shiftline(),
inststrlen(), and the like). This probably doesn't reduce the number
of calls but it may ensure that there aren't any places where these
functions are called and fixsuffix() is not called. But since I didn't 
write the fixsuffix() code I'd rather not fiddle with it.

Bye
 Sven


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

Re: bug in 3.1.4 completion

[Sven Wischnowsky]

"Bart Schaefer" wrote:

> 
> On Nov 4, 10:04am, Sven Wischnowsky wrote:
> } Subject: Re:  bug in 3.1.4 completion
> }
> } greg@alphatech.com wrote:
> } 
> } > % 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.
> } 
> } There was a missing fixsuffix() when inserting the unambiguous string
> } for normal completion. It's fixed by the second hunk in the patch
> } below (this is for 3.1.5, but you can easily insert the call to
> } fixsuffix() in 3.1.4 in do_ambiguous() in the else-branch of the `if(p)').
> 
> Two points:  (1) This patch is NOT for 3.1.5.  It's for 3.1.5 *after*
> one of Sven's other patches has been applied.  (2) I don't see the bug
> that Greg reported in my copy of 3.1.5, so it presumably was addressed
> by Sven's patch in zsh-workers/4412.
> 
> I don't think BOTH the 4412 patch and this one are needed; so which is
> better, Sven?  (I suspect Sven's other completion patches may have
> inadvertently backed out 4412, and therefore this fix got introduced
> in its place, but the 4412 one looks better to me.)
> 

I prefer the one from message 4528. The patch from 4412 just wanted to 
be absolutely sure and if do_single() was called, fixsuffix() got
called twice. The new patch avoids that.

Bye
 Sven


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

bug in 3.1.4 completion

[Greg Klanderman]

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.

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.

                
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".  Setting alwaystoend helps, though it is still very picky about
the stuff on both sides matching, which often makes the feature
useless.  I have modified emacs to do what I believe is the right
thing:

   * look for completions using both text on left and right.
     if there are none, look only for completions from the left.  this 
     way having some garbage on the right doesn't hose you, it just
     gets pushed right (it may match later, after more completing).
   * now, insert the completed text, placing cursor at the end of the
     insertion.
   * remove the longest substring to the right (with start anchored at
     the cursor) which matches a substring to the left (with end
     anchored at the cursor).  there may be none.

How hard would it be to add this to zsh?

While I'm on little nits, it would be nice if the FIGNORE variable
were not used when listing completions:

% FIGNORE='.o'
% touch foo.o foo.c
% ls fo      ; type Control-d to list completions, you only see "foo.c"

One last feature that'd be nice is automatic case conversion.  When
completing, if no completions are found, try again for a case
insensitive completion.  Would this be easy to add?


Please CC me in replies, I am not on the list.

many thanks,
Greg