From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19861 invoked by alias); 30 Aug 2016 10:28:09 -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: 21818 Received: (qmail 17419 invoked from network); 30 Aug 2016 10:28:09 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.12):SA:0(-1.5/5.0):. Processed in 0.474117 secs); 30 Aug 2016 10:28:09 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f4-f79cb6d000001359-82-57c55d56463c Date: Tue, 30 Aug 2016 11:17:53 +0100 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: history substring search a bit too aggressive sometimes Message-id: <20160830111753.4d116fbf@pwslap01u.europe.root.pri> In-reply-to: References: Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsVy+t/xq7phsUfDDfb2qFvsOLmS0YHRY9XB D0wBjFFcNimpOZllqUX6dglcGVffXmYrWCRcsXhDUQPjVv4uRk4OCQETiVVzVjNC2GISF+6t Z+ti5OIQEljKKLFk5UkWCGcak8SRS9ehMpsYJe6uOM8K4ZxllLgw7QU7SD+LgKrE/XnHmEBs NgFDiambZoPNFREQlVi+YjNYjbCAi8SWW9tZQGxeAXuJG32vwOo5BYwkmnY/A6sRAuqdMfU+ WC+/gL7E1b+fmCDus5eYeeUMI0SvoMSPyffA5jALaEls3tbECmHLS2xe85YZYo66xI27u9kn MArPQtIyC0nLLCQtCxiZVzGKppYmFxQnpeca6hUn5haX5qXrJefnbmKEhPOXHYyLj1kdYhTg YFTi4Z3gciRciDWxrLgy9xCjBAezkgivV8zRcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8c3e9 DxESSE8sSc1OTS1ILYLJMnFwSjUwCu6/pHOae7XUOfeFt/oP20TseBvpF2M24d+lZau+NkwP rn3wftPrKe8k2roPmL6Nfi2rdbxXZ2aobWvFRA85nj0/lUXezc1ylvgSWJih1BjjudvgxXKx e00MiU0zA78b3ph/9sjjhr6yIH3je5fO9l889TvXQUOsb7uv3B277BynWVlex7cZKrEUZyQa ajEXFScCAKDlgXFjAgAA On Sun, 28 Aug 2016 09:01:56 -0400 John Covici wrote: > Hi. I am having a very annoying problem properly using history > substring search. It works great if I do up arrow after typing a > string, it will find a string which is not at the beginning which is > great, but if I type a command line and type a string for file name > completion and hit the tab key, it will find items which don't begin > with that string, but do contain a substring. Completion behaves differently from history searching --- it's a completely different system with very little in common. If your problem is really with completion the history substring search is irrelevant as far as the zsh settings are concerned. It sounds like you're complanining that e.g. (all examples fictitious): % mycommand wot-i-typed can be expanded to % mycommand stuff-at-start-wot-i-typed-stuff-at-end whereas you don't want to see matches beginning with anything other than "wot-i-typed", right? > Then, more annoying, it > will give me the first file it found as my answer, which I do not > want. I think you're saying it inserts the first file on the command line even if it is ambiguous, whereas you just want (presumably) the unambiguous prefix. It might have been put into menu completion mode, which you can test because then TAB cycles through matches (you don't have to live with this, however). If I've understood these correctly, they are both down to configuration for the completion system. You'll need to do a bit more research, but we can probably explain the results. I don't see anything in the .zshrc you posted that helps, but I do see source ~/zsh-history-substring-search.zsh which could have anything in it (it is not something supplied by the zsh development team). That's probably the first thing to look at. For the first problem, I suggest running "zstyle -L" and seeing if there are any styles referring to "matcher" or "matcher-list". One thing this can do is allow wildcards at the start of the string, i.e. the effect you have. (There are other ways of controlling matching but they're not as general so less likely to be causing the effect.) For the second, there are various ways of getting into menu completion, if that's what it is. "setopt" will tell you if the menucomplete option is on, and the "zstlye -L" list might reveal styles that refer to "menu". pws