From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23616 invoked by alias); 13 Feb 2014 05:47:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18435 Received: (qmail 940 invoked from network); 13 Feb 2014 05:47:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140212214707.ZM25929@torch.brasslantern.com> Date: Wed, 12 Feb 2014 21:47:07 -0800 In-reply-to: Comments: In reply to "Yuri D'Elia" "widget special PREFIX variable and cursor position with complete_in_word" (Feb 12, 10:02pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: widget special PREFIX variable and cursor position with complete_in_word MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 12, 10:02pm, Yuri D'Elia wrote: } } I was writing a zstyle widget I'm not understading what you mean by this. Are you writing an actual completion widget, or are you writing a function that will be used as an argument to compdef, or are you writing a function whose name will be used as the value of a zstyle? If the last, which zstyle? (By "an actual completion widget" I mean it's name will be the third argument to a "zle -C" command.) } Without complete_in_word it works fine, PREFIX contains the word up to } the cursor indeed. However, with complete_in_word, the following: } } $ ls //x } dev/ etc/ lib/ sbin/ } } moves the cursor to the first slash (/): } } $ ls //x } ^ } dev/ etc/ lib/ sbin/ } } In this case, PREFIX contains //x, and not '/' as I would expect. I'm going to guess that you mean you hit TAB a second time immediately after the cursor is moved to that spot. I believe you'll find that the behavior is different depending on whether you have hit TAB twice in succession or whether you moved the cursor there yourself before you hit TAB. Whether what I'm about to describe is what happens may be changed by some of the setopts and styles, but the default behavior is: The first time you press TAB, if the result is ambiguous (in your example, four possible results) a completion listing and the cursor is moved to the first disambiguating location. At this point you have a choice: Enter a character that will remove the ambiguity, or hit TAB again to enter menu completion. If you hit TAB again, the same completion that created the listing is repeated in order to populate the menu. If you were to replay it in slow motion, you'd see the cursor return to the end of the word before the completion is begun, and then jump back to the point of disambiguation to insert the first choice from the menu. Because the original completion is being repeated, PREFIX="//x" as it was before. You can detect this by examining $compstate[old_list]. The _oldlist completer takes explicit advantage of this behavior to avoid calling all the other completers when a list has already been created. If instead you were to move the cursor yourself and press TAB, or press TAB e TAB to explicitly select "etc", *then* the second tab is beginning a brand new completion with a new PREFIX value. } Fine with that as long as I can know where the cursor is, but I was } looking into the $compstate hash and found nothing. I was hoping for } some offset. $CURSOR won't lie to you, but you'll find that it reflects what I described above, i.e., that the cursor returns to the end of the word before resuming the completion.