feature: add a toggle-option command

[divarvel]

This commands allows to toggle boolean options, with a dedicated completer that only suggests boolean options
It does not support other enumerated types.

:toggle softwrap.enable

Alternative options:

:set !softwrap.enable # ok as well (as long as options cannot start with a !), consistent with vim, i think
:set softwrap.enable ! # possibly ambiguous

[pascalkuthe]

Implementation LGTM. I think this feature certainly makes sense so users can bind it to their keys. I was originally leaning towards a special :set syntax for this but I think a separate command is easier to implement, more discoverable and easier to remeber.

[clo4]

How possible would it be to only complete boolean setting names instead of all of them?
BTW, this is fantastic, I would love to see this added.

[pascalkuthe]

Good idea, should be pretty trivial, all you would need to do is use value.is_boolean() in the get_keys function in helix-term/ui/mod.rs instead of !value.is_object()

[divarvel]

yeah, i'll have a shot

[divarvel]

done in a new commit

[divarvel]

i would have preferred adding a helper function used by both setting and boolean_setting, but the static KEYS can't depend on a function parameter.

[pascalkuthe]

you just have two static in the setting function:

static KEYS

and

static KEYS_BOOL

and dispatch which of those two to use with a simple if:

let keys = if only_booleans{
 KEYS_BOOL
}else{
  KEYS
};

Not a perfect solution either but would reduce code duplication slightly. I don't imagine that we would add more specialized settings keys in the future as more advanced dynamic configuration is better achieved with a future plugin system. Until then hardocind the bool keys seems like a good enough solution.

[divarvel]

done in a separate commit, i had to duplicate the .iter() call as well

[poliorcetics]

#4085 has been merged, is this a duplicate ?

[poliorcetics]

Ah, it's a partial duplicate: in #4085, the completer proposes all keys, not only boolean ones

[divarvel]

Heh, I'll rebase and rename the PR accordingly

[divarvel]

Amusing how my changes were close to #4085 without being aware of it.

I've only kept the commit adding dedicated completion.

[pascalkuthe]

Actually it seems like @archseer wants to merge #4411 too which allows cycling arbitrary settings by providing a list of available values. In that case we actually want to keep the completion for any settings. For example :toggle bufferline always multiple

I wasn't aware of those two PRs when you started working on this originally and somehow endedup missing them while searching. That was my bad! Sorry for wasting your time.

[divarvel]

ah, support for enumerated values was next on my list. i waited before working on it, thankfully ^^

no worries, i'll close this one