From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3138 invoked from network); 25 May 2000 15:20:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 May 2000 15:20:42 -0000 Received: (qmail 5766 invoked by alias); 25 May 2000 15:20:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11580 Received: (qmail 5751 invoked from network); 25 May 2000 15:20:30 -0000 From: "Bart Schaefer" Message-Id: <1000525152017.ZM2840@candle.brasslantern.com> Date: Thu, 25 May 2000 15:20:17 +0000 In-Reply-To: <200005250757.JAA32547@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: Re: TAB and PS2 and multiline buffers and vared" (May 25, 9:57am) References: <200005250757.JAA32547@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: PATCH: Re: TAB and PS2 and multiline buffers and vared MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 25, 9:57am, Sven Wischnowsky wrote: } Subject: Re: PATCH: Re: TAB and PS2 and multiline buffers and vared } } Bart Schaefer wrote: } } > The test case was to run `vared functions[_complete_debug]', scroll up } > to the line `local w="${(qq)words}"', then type ^E ESC RET to open a } > line, and begin completing on that line. } } The fact that you used `functions[_complete_debug]' was an important } information, because with that I found a buglet in _in_vared that made } _value complete alternatingly assoc keys and values, as if for a } assingment to $functions. Aha! } I still can't see why it completed commands, but it might have } something to do with this (I could understand it if you had tried it } with commands[...]). Actually, although I hadn't noticed it before, the number of completions offered changes depending on which variable I'm editing, so that probably is in fact the issue. If it's still broken after the patch I'll let you know. } There is another thing I noticed: ^X? with only one match did not show } the _message, because with only one match it didn't show the list at } all. The patch fixes this in _complete_debug. Aha, again. That explains another "bug" I was about to report. } Hm, should we change the C-code to enforce showing the list when a } `compadd -x' message was added (that *seems* sensible, but I think } there may also be cases where one doesn't want that)? Alternatively, } we could enhance $compstate[list]: if it contains `messages', only the } messages are shown (like the `explanations' we have now). Either or both. I don't have a strong opinion, at least not yet. } Well, another thing I noticed is that with a really large prompt and } completion list scrolling it doesn't stop at the end of the list, so } that the re-printed prompt scrolls most of the list out of the } screen. So the patch makes it wait at the very end, allowing us to } have a look at the whole list before printing the next prompt. Yay! Yet another thing I was about to report. You're batting 300% on this one. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com