Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: clang completion
- X-seq: zsh-workers 43151
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- Subject: Re: clang completion
- Date: Sun, 08 Jul 2018 14:40:55 +0200
- Authentication-results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
- Cc: zsh-workers@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1531053657; bh=tE+5m0KUY8IDvbz2zUzVAs7/IUUi8Du9eHykRZ65A3A=; h=From:References:To:Subject:Date:From:Subject; b=aJgFIvBhpZfTbm79dWygxDTJMo+GnKa2wboZwj6FLO5DpiGgv/hNRXq+lgXnsfSS/apum8yg5HtypFZwzlCEARuQU6O17S6QlW0jmB+eI+8ZDcy1wFMCkAEgmFseBths8UJdDxpuaPolAMMUB/uAFqulXyGTRGFrjq1PyWC5v/REVD0K3nigcUxsEE7F7r2/lnUllOInOf8ot2Ap9jpi8MsIbTjpo1f2PytGdXt9yGk2coYx6LZ9aIT778UDI/n1NZUQanzzUJog1YKXmRPE3HDOgQGpP5mMHatYS44LM5ShR/FB6MpZ7sefWLcKhubXEvPY8HNL+y4lbjVuB/cTLg==
- In-reply-to: <20180708064008.rkjzh2h376kqehs6@tarpaulin.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAF6rxgk2uiZ1wxHYtVKEZO=b4Voitz9sB8jU1ta1Evxv78FU-A@mail.gmail.com> <20180707205750.GA62923@CptOrmolo.darkstar> <20180708064008.rkjzh2h376kqehs6@tarpaulin.shahaf.local2>
Matthew wrote:
> I believe there were also concerns that clang cannot be split from gcc
> and cc since clang is cc sometimes (for instance on OpenBSD for some
> architectures).
I don't see a problem there.
cc can be any one of a variety of different C compilers. We just need to
have an _cc that probes cc to see what it is and either dispatches to
_gcc, _clang or falls back on only completing traditional options. Same
goes for completing CFLAGS. We'll also need to try to detect the linker.
Daniel wrote:
> Note that it's not trivial to support _approximate or _correct here, because
> the --autocomplete contract is "give me a prefix", not "give me all possible
> matches for me to sort out". That is: clang wants to do the matching itself,
> and it doesn't honour zstyle's.
This sort of design tends to follow from the way bash programmable
completion is designed. I'd far prefer to have clear options for listing
all warnings, languages, options etc. Those potentially have wider uses.
We likely can at least extract useful information using this interface.
We still need our own rules for where and how to split up the
command-line. A proof of concept using some basic patterns is below.
There will be further patterns that would be useful to cover along with
much of the other functionality already in _gcc.
> (still hoping for a world in which all commands have
> a --output-my-grammar-in-a-well-known,-machine-parseable-format flag)
I can see the appeal of such a format. But I also have my reservations.
If you look back at compctl and tcsh completions you'll see some of the
limitations that led to taking the simple and pragmatic approach of just
using the scripting language that is already built into the shell. A
formal grammar also tends to be finicky which for a command-line that by
definition is expected to be incomplete is not always helpful. You can
see this if you use _regex_arguments for a non-trivial completion – it
is harder to make it forgiving because you need to account for whatever
may be in the command-line and not just split on key tokens. The grammar
style approach of _regex_arguments may lend itself to certain use cases
but if you review some of our limited uses of it, I think you'll agree
that they aren't especially readable or simple to follow. It is also the
case that most commands follow a fairly familiar pattern in terms of
their grammar as covered by _arguments. _arguments specs can be fairly
concise but it is far from being comprehensive.
I've wondered whether writing bashcompinit wasn't perhaps a mistake and
that the opposite mightn't have been better. Zsh's interface is more
extensible to begin with.
Completion definitions being included with upstream projects also makes
sense in many ways. Except I now have the additional frustration of
numerous outstanding and ignored github pull requests.
Oliver
#compdef clang clang++
local tag pre filt
local -a mat eq
for tag pre filt in \
directories '--*-(dir|path)=' '^*' \
values '-*=' '^*' \
warnings '-Wno-' '^*' \
warnings '-W' $'-W(\t|?,|no-)*' \
target-options '-mno-' '^*' \
target-options '-m' '-mno-*' \
debug-options '-g' '^*' \
target-options '-fno-' '^*' \
language-options '-f' '-fno-*' \
options '-' '-[fgmWX]?*' \
files '' '^*'
do
if [[ -prefix $~pre ]]; then
case $tag in
directories)
compset -P 1 '*='
_directories && return
;;
files)
_files -g "*.([cCmisSoak]|cc|cpp|cxx|ii|k[ih])(-.)" && return
;;
*)
compset -P 1 '*=' && pre="${IPREFIX},"
mat=( ${${${${(f)"$(_call_program $tag $words[1] --autocomplete=$pre)"}//:/\\:}%%[[:blank:]]#}:#$~filt} )
eq=( ${${(M)mat:#[^[:blank:]]##=*}/=$'\t'/:} )
mat=( ${${mat:#[^[:blank:]]##=*}/$'\t'/:} )
(( $#mat + $#eq )) && _describe -t $tag ${${tag//-/ }%s} mat -- eq -qS= && return
;;
esac
fi
done
return 1
Messages sorted by:
Reverse Date,
Date,
Thread,
Author