zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: zsh-workers@zsh.org
Subject: Re: clang completion
Date: Sun, 08 Jul 2018 14:40:55 +0200	[thread overview]
Message-ID: <2431.1531053655@thecus> (raw)
In-Reply-To: <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


  reply	other threads:[~2018-07-08 12:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-30  8:34 Eitan Adler
2018-07-07 20:57 ` Matthew Martin
2018-07-08  6:40   ` Daniel Shahaf
2018-07-08 12:40     ` Oliver Kiddle [this message]
2018-07-08 14:02       ` Eric Cook
2018-07-08 21:34         ` Oliver Kiddle
2018-07-09 10:19           ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2431.1531053655@thecus \
    --to=okiddle@yahoo.co.uk \
    --cc=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).