From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19381 invoked from network); 9 Aug 1999 09:58:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Aug 1999 09:58:19 -0000 Received: (qmail 7189 invoked by alias); 9 Aug 1999 09:58:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7405 Received: (qmail 7182 invoked from network); 9 Aug 1999 09:58:04 -0000 Date: Mon, 9 Aug 1999 11:58:02 +0200 (MET DST) Message-Id: <199908090958.LAA25398@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Tanaka Akira's message of 07 Aug 1999 03:53:42 +0900 Subject: Re: Completion problems. Tanaka Akira wrote: > In article <199908040937.LAA15313@beta.informatik.hu-berlin.de>, > Sven Wischnowsky writes: > > > I see two ways to go: 1) completely change the completion code to > > report strings in unquoted form or 2) add a parameter expansion > > modifier which does something like the opposite of `:q'. > > Unfortunately, 1) is extremly hard and error-prone. > > I think that (1) is right way though I didn't know it's extremly hard > because I'm not know the code internal well. I still don't think that 1) is the right thing to do because some day someone might come and want to be able to see which words are quoted. Reporting them as they appear on the line is the only way to achieve this and together with the Q modifier/flag one can always get at the unquoted forms. > > Also: changing a'#' to a\# is intentional and was discussed -- see > > 6400 and follow-ups (especially 6460 for this example). > > Ok, I understand. I didn't think match specs. But... is this > intentional? > > Z:akr@is27e1u11% zsh-3.1.6-pws-1 -f > is27e1u11% autoload -U compinit; compinit -D; compdef _tst tst > is27e1u11% _tst () { compset -P '*/'; compadd tst } > is27e1u11% var=val > is27e1u11% tst 'a'$var/ > > -> > > is27e1u11% tst 'a$var/tst' Yes, it is, err, no it isn't, err -- well I didn't think about the possibility of $var stuff after the closing quote. In a message with a completely different Subject Andrej Borsenkow wrote: > bor@itsrm2:~%> zsh -f > itsrm2% autoload compinit;compinit -D > itsrm2% l /t/b/{zsh > itsrm2% l /tool{s/bin/zsh > ^^^ > Note, that the brace was (re)inserted at the old place. If I now try to insert > something with accept-and-menu-complete, it will correctly insert the > ``s/bin/zsh-xxx'' - but, it is rather unexpected. And, users will probably > expect, that they simply can type in ``,zsh.old,zsh-what-ever}'' - and this does > not work any more. We lost it when we made _path_files do the matching via -D and add the matches with -U. This *is* a problem, because with -U the code can't know where to re-insert the braces. Trying to fix this by using matching compadds to add the matches revealed that the code also has problems when the braces are in the path-prefix/suffix under certain circumstances. Ok, in the light of these two and the problem that we still can't complete inside nested braces mentioned by Bart and the multi-quote problem I keep alluding to I'd say that maybe I should have a look at all of these together. That'll take a while, though. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de