From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3832 invoked from network); 4 Aug 1999 17:00:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Aug 1999 17:00:56 -0000 Received: (qmail 15683 invoked by alias); 4 Aug 1999 17:00:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7356 Received: (qmail 15675 invoked from network); 4 Aug 1999 17:00:48 -0000 From: "Bart Schaefer" Message-Id: <990804170044.ZM14586@candle.brasslantern.com> Date: Wed, 4 Aug 1999 17:00:44 +0000 In-Reply-To: <199908040937.LAA15313@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Completion problems." (Aug 4, 11:37am) References: <199908040937.LAA15313@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Completion problems. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 4, 11:37am, Sven Wischnowsky wrote: } Subject: Re: Completion problems. } } Tanaka Akira wrote: } } > In following examples, unquoted forms are not known until runtime. } > } > % if some-complex-command; then var=xxx; else var=yyy; fi; tst $var/ } > % tst $(some-complex-command)/ } } 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'. I think (2) would be quite useful in other contexts anyway. Perhaps (Q)? (And we could add (q) which means the same as :q, just for completeness.) There is some question about what paramter unquoting should do in the case of mismatched quotes. I can think of cases where you'd want it to produce the same errors as using that same quoting in a command, and other cases (like completion) where you'd just like it to assume the closing quote. } [...] with match specs using `*'-patterns new stuff can be inserted } anywhere in the word. To retain the single quotes the completion code } would have to keep track of the original positions and would have to } calculate the new positions for every single or double quote inside } the word. This is extremly difficult, expensive (i.e. slow), and at } least I wouldn't implement it (if anyone else is interested: try to } find out how the completion code now handles completion inside braces } -- you would have to do something similar, but not only for two } places, but for a whole list of positions). I almost hate to mention this, but braces can be nested, and right now completion doesn't work in that case -- presumably *because* it isn't keeping track of a list of positions. There are similar (?) problems with nested parameter substitutions: zagzig<1> echo ${${p path perl prompt psvar zagzig<1> echo ${${pa zagzig<1> echo ${${path} ^Cursor is now here; arguably no space should have been added, because it can't possibly be correct in that context. Also, if you now type a right-curly, the trailing space is deleted, but the right-curly is not inserted (which I guess is theoretically correct). BTW, expand-or-complete is a pain in the butt when combined with braces, because as soon as you close the braces the next TAB *expands* them, leaving you with multiple half-finished words. You can prevent this by setting GLOB_COMPLETE, but in that case completion after the right-brace still doesn't work. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com