From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 657 invoked from network); 3 Nov 1998 17:33:41 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 3 Nov 1998 17:33:41 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.9.1/8.9.1) id MAA25845;
	Tue, 3 Nov 1998 12:31:36 -0500 (EST)
Resent-Date: Tue, 3 Nov 1998 12:31:36 -0500 (EST)
Message-ID: <13887.15691.65156.627407@catbus.alphatech.com>
Date: Tue, 3 Nov 1998 12:28:43 -0500 (EST)
From: greg@alphatech.com (Greg Klanderman)
To: zsh-workers@math.gatech.edu
Subject: bug in 3.1.4 completion
Reply-To: greg@alphatech.com
X-Mailer: VM 6.62 under 21.0 "Pyrenean-pre4" XEmacs Lucid
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Resent-Message-ID: <"kz1Np3.0.mJ6.ttpFs"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/4519
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu


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