---
feature_story: FS_23_62_89_43
feature_title: tangent_token
feature_status: TEST
---

TODO: TODO_51_14_50_19: ensure `tangent_token` always exists

Term `tangent_token` means token which is "touched" by the cursor in the command line.

For example, `amer` is a `tangent_token`
```
some_command goto host dev amer| upstream qwer
```

`tangent_token` is always removed from consumption in case of `ServerAction.ProposeArgValues` (Tab-completion).

When all `arg_value`-s are already consumed (except the one associated with `tangent_token`) and
it is the time to decide what suggestion to generate, there are some questions:

*   If user already completed this value before, then it makes sense to try to complete it the same way, right?

    For example, if `amer` was result of previous suggestion,
    moving cursor to the center `am|er` and completing it again should result again in `amer`.

    But... it should actually depend on the context:
    have other `arg_value`-s changed between prev and next completion of `amer`?
    This moves us to the second approach.

*   Many `arg_value`-s might be skipped by consumption of other args
    (e.g. singled out `data_envelope` need no clarification).

    In case of empty `arg_value` (cursor has no `tangent_token`),
    it makes sense to continue suggesting unspecified args (especially, at the end of the line):

    ```
    some_command goto host dev amer upstream qwer |
    ```

    When it has `tangent_token`, the same logic makes sense -
    it is better to try to complete from unspecified `arg_name`-s of already narrowed down `data_envelope`-s
    (note that `upstream` will be considered unspecified because `tangent_token` is excluded from consumption):

    ```
    some_command goto host dev amer up|stream qwer
    ```

    In fact, this is naturally a default behaviour because `argrelay` tries to propose for the next missing `arg_name`.

    Once `prop_value`-s are collected from narrowed down `data_envelope`-s,
    they are filtered to `startwith` `token_left_part`.

Solution: keep the same behavior as for next non-`tangent_token` by proposing only next missing `arg_name`.

