Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: _history-complete-older problems with $(
- X-seq: zsh-workers 37588
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: _history-complete-older problems with $(
- Date: Tue, 12 Jan 2016 11:39:28 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version:content-type; bh=3cyCcMFU77Ws1F+yCN1rP+CuR7BR8vfnQ23FISHkj+g=; b=AURZzy3TjLlpdrChPrXKrBFp0QxTpS+9KtRVgyeCveKxUlC+JOEMYr5unUPh3Q4w6Z RDwnap/K1PSxlPGuSt0P4pp6yv26MZ/PD7KShjDV9daW7x13KnIkRa87q+nbhNFWD6yZ /k3+ROdp4Me7h7cjHzNyoCFHlz8Q312SeVqw8gEcNGyU17F3J8HvE75KQK5ZkiZSJOpR Hnpconx80IGdNi0r6S+q4OQNw6d/LSg9ZGHmB+crXaauobQxs/ferlziktrlu+Kav/RW cDReGiKyGbnajXxENC24GEHp+tKOyjcGdC26AfpB5z57MwYpvJXbXjY4yYY+yytA1bA0 9uUQ==
- In-reply-to: <CAKc7PVBCEM=46YmgmhPR==Rq+pSfY+hgr8bcOMLV=zLFm6THBg@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- 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>
On Jan 12, 2:09pm, Sebastian Gniazdowski wrote:
} Subject: Re: _history-complete-older problems with $(
}
} I think the hacks are acceptable if the code will be used only by
} Alt-/ (_history-complete-older). How to accomplish this, btw?
You would need to change the _history_complete_word_gen_matches
function in the _history_complete_word file to replace
_main_complete _history
with
_main_complete _widen_for_history
} Are this expected values? Because despite proposing $(( 0 + 1 ))
} correctly after $(<TAB> (btw., not after $(<Alt-/>), the completer
} behaves weird. For "ls <TAB>" it doesn't propose any files.
I can't reproduce this. There may need to be some tests for success
of the calls to "builtin compadd" in the substitute compadd function;
given
zstyle ':completion:*' completer _widen_for_history _complete
(the _complete at the end is important) there will only be completions
generated by _complete when _widen_for_history returns nonzero. It is
possible you've found some circumstance in which it returns 0 but does
not add any actual matches.
I'm not trivally able to reproduce that.
} > This needs some work around the issue of empty words, i.e., when
} > completing in empty parens such as $(<TAB>) then $words[CURRENT] is
} > empty and the trailing paren must be copied from $RBUFFER to SUFFIX.
} > I haven't dived into that detail.
}
} I would gladly perform the work but the code is quite difficult. Could
} you state in one sentence what it is doing? Variables $CURRENT, $word
} aren't documented in zshzle.1.
They're documented in "man zshcompwid".
} What does the {} always {} block of code do?
{ TRY-LIST } always { ALWAYS-LIST }
First execute TRY-LIST. Regardless of errors, or break, continue,
or return commands encountered within TRY-LIST, execute
ALWAYS-LIST. Execution then continues from the result of the
execution of TRY-LIST; in other words, any error, or break,
continue, or return command is treated in the normal way, as if
ALWAYS-LIST were not present. The two chunks of code are referred
to as the `try block' and the `always block'.
} Next, I would guess that "builtin compadd -O found "$@""
} performs one run of matching, is this correct?
-O ARRAY
If this option is given, the WORDS are _not_ added to the set
of possible completions. Instead, matching is done as usual
and all of the WORDS given as arguments that match the string
on the command line will be stored in the array parameter
whose name is given as ARRAY.
} Why second comadd, and
} what does "${(@)${(@)found#$PREFIX}%$SUFFIX}" do?
Suppose you have "$(" on the line, and the completion is $((1+2)). The
$found array will contain "$((1+2))" (and possibly other elements). In
the setup to at the beginning of _widen_for_history, PREFIX="$(" was
assigned (that $left[-1]). So now we need to remove "$(" from the
values in $found to get the actual string to insert to finish the word,
i.e., "(1+2))". Similarly we would need to remove $SUFFIX (taken from
$right) from the end of the values if there were one.
${...#$PREFIX} removes from the left and ${...%$SUFFIX} removes from
the right.
Normally "builtin compadd" would handle this for us, but internally it
still thinks it is populating command words that must follow the open
paren; so we have to fix things up before we make the final call.
(That's not an entirely accurate description of the "internally" part
but it suffices to explain why we must trim the prefix/suffix.)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author