Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160113204847.ZM14158@torch.brasslantern.com>
Date: Wed, 13 Jan 2016 20:48:47 -0800
In-Reply-To: <CAKc7PVBz1nNueRmEfyz3157kvJjEgHW3wmSXraKM+-9P-i5Atw@mail.gmail.com>
Comments: In reply to Sebastian Gniazdowski <sgniazdowski@gmail.com>
        "Re: _history-complete-older problems with $(" (Jan 13,  5:40pm)
References: <CAKc7PVCnEX1rEhNqhtx7spyUVKCWukz4Tzkqr27-OV9+4hVciQ@mail.gmail.com> 
	<CAKc7PVDVR=B8SWX+gSiNvtODWZ-25LtDz7jXVDH8BtrcxMnjXQ@mail.gmail.com> 
	<160111161501.ZM5305@torch.brasslantern.com> 
	<CAKc7PVBCEM=46YmgmhPR==Rq+pSfY+hgr8bcOMLV=zLFm6THBg@mail.gmail.com> 
	<160112113928.ZM9065@torch.brasslantern.com> 
	<20160113010147.GA4699@tarsus.local2> 
	<160112180141.ZM9984@torch.brasslantern.com> 
	<CAKc7PVBz1nNueRmEfyz3157kvJjEgHW3wmSXraKM+-9P-i5Atw@mail.gmail.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: _history-complete-older problems with $(
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Jan 13,  5:40pm, Sebastian Gniazdowski wrote:
}
} Zsh doesn't make following word active, i.e. "ls |/Users/user_na"
} with the cursor where "|" is will not complete the "user_name".

That's specific to complete_in_word -- if you have not set that, then
the cursor moves to the end of the word before attempting completion.
But if you HAVE set that, you are saying that the (empty) part of the
word to the left of the cursor is important, so zsh is correctly
responding that there isn't anything that can be completed there.

} I have chosen different approach, in such case I treat
} what's after "|" as right part of current shell word.

Zsh DOES treat what's to the right of the cursor as part of the
current word.

You can see what's going on more clearly if you complete (in the zsh
source tree, "|" indicates the cursor when TAB is pressed):

torch% setopt completeinword
torch% ls |c
Doc/  Etc/  Src/

Here "c" is part of the word and there IS something that can appear
to the left of it, so you get the completions.

If you want other behavior you use a matcher (matcher-list style).

} The same I do for zew-transpose-shell-words (former
} transpose-segments), block cursor on first letter of word makes the
} word active, selected for transposition.

That should be the way both the builtin transpose-words and the newly
patched transpose-words-match work as well, so I'm not sure 

} I have one problem. First compadd returns $found array
} populated with matches:
} 
} But nothing is displayed below the prompt, "en" replaces "wid" at
} prompt and that's all

Ah.  Another wrinkle I overlooked.  You need to store the original
values of $PREFIX and $SUFFIX somewhere, e.g.

    local origPREFIX=$PREFIX origSUFFIX=$SUFFIX

Then, after "compadd -O found" but before trimming PREFIX and SUFFIX
off of $found, you need

    PREFIX=${PREFIX#$origPREFIX}
    SUFFIX=${SUFFIX%$origSUFFIX}

This is because compadd will still try to replace the original word
prefix ("wid") with whatever you pass to that second compadd, so if
there was an original prefix/suffix you must NOT trim those off.  I
didn't test my original version with anything other than an empty
$PREFIX so didn't think of this.

} The same problem is with "ls" about which I wrote to you earlier. So
} it seems that the second compadd isn't fully working.

When _history returns nonzero, your debugging line

    echo >> /tmp/wfhistory

is clobbering that with its own zero return, so completion stops even
if no matches were found.  Move that last "echo" into the block that
is after "always" (right before "unfunction compadd").