completion files sensitive to user options like RC_QUOTES

completion files sensitive to user options like RC_QUOTES

[Vincent Lefevre]

I wonder whether it is expected that completion files are sensitive
to user options.

For instance, the vendor's _journalctl file has:

    '(--directory -D -M --machine --root --file)''--root=[Operate on catalog hierarchy under specified directory]:directories:_directories' \

which fails with RC_QUOTES due to the: ''

My bug report: https://github.com/systemd/systemd/issues/4842

This is easily fixable there, but in general, I suppose that not all
external developers who write completion files know all the options.
So, isn't there anything to do on the zsh side?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion files sensitive to user options like RC_QUOTES

[Bart Schaefer]

On Dec 6,  3:27pm, Vincent Lefevre wrote:
}
} I wonder whether it is expected that completion files are sensitive
} to user options.

The intention is that completion files will be auto-loaded from the
completion system after _main_complete has started, where they will be
affected by the set of options that it controls.

RC_QUOTES is a tricky one.  We could do this --

diff --git a/Completion/compinit b/Completion/compinit
index 6612bac..7cb65d5 100644
--- a/Completion/compinit
+++ b/Completion/compinit
@@ -153,6 +153,7 @@ _comp_options=(
     NO_markdirs
     NO_octalzeroes
     NO_posixbuiltins
+    NO_rcquotes
     NO_shwordsplit
     NO_shglob
     NO_warncreateglobal

-- but then expansions of strings the user has typed on the command
line might be handled differently.

If you can verify that the above doesn't break any of your interactive
expectations, I can commit it.

Re: completion files sensitive to user options like RC_QUOTES

[Oliver Kiddle]

Bart wrote:
> The intention is that completion files will be auto-loaded from the
> completion system after _main_complete has started, where they will be
> affected by the set of options that it controls.

There's a lot of places where we want the completion system to be
sensitive to the user's choice of options. For example:

  _foo() { compadd "don't" }
  compdef _foo foo
  foo '<tab> → 'don''t'
  _comp_options+=( NO_rcquotes )
  foo '<tab> → 'don'\''t'

In the early days, _comp_options was intentionally kept minimal.
It contains a lot more than it used to so I worry that we've already
broken things in some areas.

The quoting is internal to the C code so shouldn't look at
_comp_caller_options. We'd need to add some sort of hook, though
I'd prefer to see that done as part of an effort to make the quoting
part of completion more generic in general. I can't think of a good
trivial solution.

In many respects, I think it is welcome that more vendors are including
zsh completion functions. We get functions maintained by people who know
the software but then they aren't maintained by people who know zsh so
well.

Oliver

Re: completion files sensitive to user options like RC_QUOTES

[Bart Schaefer]

On Dec 6,  6:29pm, Oliver Kiddle wrote:
} Subject: Re: completion files sensitive to user options like RC_QUOTES
}
} Bart wrote:
} > The intention is that completion files will be auto-loaded from the
} > completion system after _main_complete has started, where they will be
} > affected by the set of options that it controls.
} 
}   _comp_options+=( NO_rcquotes )
}   foo '<tab> -> 'don'\''t'

OK, that's a reasonable counter-argument to my patch.

} In the early days, _comp_options was intentionally kept minimal.
} It contains a lot more than it used to so I worry that we've already
} broken things in some areas.

There would be a case for wrapping the "eval" expressions in _expand
with temporary restoration of $_comp_caller_options, because of the
effects of NO_ksharrays etc.  There might be a few other similar
situations.

} The quoting is internal to the C code so shouldn't look at
} _comp_caller_options. We'd need to add some sort of hook

We have the "sticky emulation" mechanism.  Entry to completion could
save the current option state before invoking the user-defined code,
and then compadd could temporarily revert to that saved state.  We
could also add another builtin (compopts?) to manage it explicitly,
though the state would still need initial capture.

On a side note, maybe we need a special keyword for "emulate" that
means "make sticky whatever the current options are" -- right now
you would have to spell that out explicitly, relative to some base
emulation such as zsh or sh.

Re: completion files sensitive to user options like RC_QUOTES

[Oliver Kiddle]

Bart wrote:
> There would be a case for wrapping the "eval" expressions in _expand
> with temporary restoration of $_comp_caller_options, because of the
> effects of NO_ksharrays etc.  There might be a few other similar
> situations.

Yes:
  var=yyyyy
  setopt histsubstpattern
  : ${var:s/y*/X}<tab> → yyyyy

Similar problems for kshglob, norcexpandparam and others
For csh_junkie_quotes, it looks like the completion internals aren't
handling it anyway.

To restore $_comp_caller_options it is still best to limit the range of
options. Is there a simple way to restore it for that matter, best I can
come up with is the following which ends up duplicating the selection of
options.

optkeys=( ${(k)options[(I)(${(@~j.|.)_comp_options#NO_})]} )
set ${${${(v)options[(I)(${(@~j.|.)_comp_options#NO_})]:/on/-o}:/off/+o}:^optkeys}

> We have the "sticky emulation" mechanism.  Entry to completion could
> save the current option state before invoking the user-defined code,
> and then compadd could temporarily revert to that saved state.

Internally to the C code it needn't really use the sticky emulation
feature. Judging from a grep of the source, there's about a dozen
options that should perhaps have their values saved on entry to the
completion widgets with the code then checking those saved values
instead of the current state.

> On a side note, maybe we need a special keyword for "emulate" that
> means "make sticky whatever the current options are" -- right now
> you would have to spell that out explicitly, relative to some base
> emulation such as zsh or sh.

How about some way to create a custom emulation. So _main_complete does
something like:
  emulate -C _useropts
Then, wherever we need to, we can use sticky emulation to get the user's
setup:
  emulate _useropts -c 'var=( $expn )'
Is a pity we have to quote everything to -c.

The first feature could use current options as the default base but
allow something like:
  emulate -C bash sh -o kshglob +o shglob -o braceexpand

Oliver

Re: completion files sensitive to user options like RC_QUOTES

[Bart Schaefer]

On Dec 7,  4:45am, Oliver Kiddle wrote:
} Subject: Re: completion files sensitive to user options like RC_QUOTES
}
} Bart wrote:
} > There would be a case for wrapping the "eval" expressions in _expand
} 
} To restore $_comp_caller_options it is still best to limit the range of
} options. Is there a simple way to restore it for that matter

Just assign to $options?

  () {
    options=( "${(kv)_comp_caller_options[@]}" )
    setopt localoptions
    eval ...
  }

(But possibly even better below.)

} Internally to the C code it needn't really use the sticky emulation
} feature.

True; I just meant that we have working code for a similar situation,
which can be cannibalized.

} > On a side note, maybe we need a special keyword for "emulate" that
} > means "make sticky whatever the current options are"
} 
} How about some way to create a custom emulation.

Now that you suggest it, I realize you can do that already, because of
the way sticky emulations propagate.  To borrow your example:

  emulate sh -o kshglob +o shglob -o braceexpand -c \
    'emulate_bash() { eval "$*" }'

  emulate_bash 'show_bash_opts() { set -o }'

  show_bash_opts

You can prove this works by doing e.g.

  emulate zsh -c show_bash_opts

and noting that in spite of forcing zsh emulation outside, set -o prints
the bash options inside.

The missing bit is being able to snapshot the current state.  Which of
course you can also do with gymnastics on $options.

  emulate zsh -${(k)^options[(R)on]} +${(k)^options[(R)off]} -c \
    'emulate_useropts() { eval "$*" }'

And now Ray can shake his head some more at the emergent behavior ...