Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about relation to other completion frameworks #938

Closed
SuperSandro2000 opened this issue Feb 17, 2022 · 9 comments
Closed

Question about relation to other completion frameworks #938

SuperSandro2000 opened this issue Feb 17, 2022 · 9 comments
Labels

Comments

@SuperSandro2000
Copy link

I am bit confused how the relation of carapace-bin is to other completion frameworks like bash-completion, fzf or bleh.sh. Is it supposed to be an addition to them or does it replace them complete? So far I saw no compatibility issues with bash-completion or fzf since it overwrites their handling but ble.sh breaks at least chmod and the result is chmod '0 (none)' carapace-bin_0.9.1_Linux_x86_64.tar.gz.

@rsteube
Copy link
Member

rsteube commented Feb 17, 2022

It depends. I myself switched to elvish, so I use it for all my completions.
There are certainly some cases where overriding the completion is not desired and there will be a need to exclude specific completers when using carapace _carapace.`

  • bash-completion:
    Regarding the completions it provides it can be seen as either a replacement or addition. But a lot of the completion scripts existing depend on some functions it provides (carapace doesn't need it though).
  • fzf:
    AFAIK this is just a fuzzy finder or not? I know there is a plugin for zsh to use it to filter during completion like elvish does (not done by carapace).
  • bleh.sh:
    Don't know that one yet but from i can see the problem is that the bash completions from carapace have descriptions "hacked in" (when more than one option exists it won't be inserted so you can add a description to the value). It seems ble.sh behaves differently than bash and inserts it directly (does it provide sth. like menu completion?).

@SuperSandro2000
Copy link
Author

AFAIK this is just a fuzzy finder or not?

It also adds some completion to for example ssh or dig.

does it provide sth. like menu completion?

yeah, it does.

@rsteube
Copy link
Member

rsteube commented Feb 20, 2022

does it provide sth. like menu completion?

yeah, it does.

It would need a different output then. Leaving out the descriptions is certainly possible, just not very useful.
Seems bleh.sh does have some support for descriptions: akinomyoga/ble.sh#155 , but from what I am reading it is generated internally from help/man pages.

@akinomyoga
Copy link

akinomyoga commented Feb 20, 2022

It's just undocumented, but it is possible to generate descriptions with candidates for ble.sh. I'm not sure if you are interested in supporting it, but here is an example:

_comp_cmd_test1() {
  if [[ ${BLE_ATTACHED-} ]]; then
    # If ble.sh is in the attached state.

    # Change the menu style to "desc" for the current completion
    bleopt complete_menu_style=desc

    # Generate filename or directory name (The description is automatically
    # generated from the filename for "file").
    ble/complete/cand/yield file 'file.txt'

    # Generate words with description.
    ble/complete/cand/yield word 'my-word' 'This is a description for my-word.'

    # Generate option with OPTARG indicated in the list.  In the third argument
    # $'OPTION\x1cOPTARG\x1cSUFFIX\x1cDESCROPTION', FS ($'\x1c') is used to
    # separate OPTION, OPTARG indicator, SUFFIX that is inserted after inserted
    # the unique completion, and DESCRIPTION
    ble/complete/cand/yield mandb '--option' $'--option\x1c=<something>\x1c=\x1cThis is a description for the option'

  else
    # If ble.sh is not loaded or is in the detached state, just generate
    # candidates for the default progcomp system of Bash.

    COMPREPLY+=(file.txt)
    COMPREPLY+=(my-word)
    COMPREPLY+=(--option)

  fi
}
complete -F _comp_cmd_test1 test1

image

Some additional adjustments might be needed for the detailed behavior.

  • For example, the word specified to the second argument of ble/complete/cand/yield should not be quoted. It will be automatically quoted by ble.sh when the candidate contains special characters.
  • For another example, the directory suffix / is only inserted for the directory names generated as file, etc. If you want to show a description for directory names, you need to define a new completion "action" (that is specified to the first argument of ble/complete/cand/yield). To define a new action, maybe you can reference the existing implementation for action:mandb or action:file. But, actually these internal APIs might be changed in the future, so please let me know if you want to maintain it. I'll add it to my list of external dependencies on ble.sh and will submit PR when there will be breaking changes.

This was referenced Feb 20, 2022
@rsteube
Copy link
Member

rsteube commented Feb 20, 2022

Added experimental support. There are likely some issues, but basics seem to work alright.

  • optarg not yet working
  • seems like there is some automatic invocation of completion (complete_auto_complete)? which is bad for slow completions
  • BLE_ATTACHED is not exported so bash-ble must be passed explicitly (no automatic detection yet)
bleopt complete_auto_complete=
source <(carapace _carapace bash-ble)

asciicast

@SuperSandro2000
Copy link
Author

Great! I am going to test that for some completions in the next days.

So far I always detected ble.sh with the BLE_VERSION env which is exported I think.

@akinomyoga
Copy link

akinomyoga commented Feb 21, 2022

  • seems like there is some automatic invocation of completion (complete_auto_complete)?

Yes. You can detect whether the current completions are automatically invoked one or not by the following test:

[[ :$comp_type: == *:auto:* ]]

If the completion function returns without generating any candidates, the default completion by ble.sh will be used.

  • which is bad for slow completions

If the bottleneck is the for loop at the ble.sh side, there is a mechanism to detect the user input and cancel the completion. You can insert the following line:

   for cand in "${c[@]}"; do
+    ((cand_iloop++%bleopt_complete_polling_cycle==0)) && ble/complete/check-cancel && return 148
     [ ! -z "$cand" ] && ble/complete/cand/yield mandb "${cand%%$'\t'*}" "${cand##*$'\t'}"
   done
  • BLE_ATTACHED is not exported so bash-ble must be passed explicitly (no automatic detection yet)

There is no plan of exporting BLE_ATTACHED because it indicates that ble.sh is in the attached state in the current Bash process. If we export it, then the child Bash shells started from a ble.sh session also inherit the variable regardless of whether ble.sh is loaded in the child shells.

So far I always detected ble.sh with the BLE_VERSION env which is exported I think.

BLE_VERSION is not exported for the same reason.

Anyway, if the determination of the completion type would be determined at the initialization stage, we should use BLE_VERSION rather than BLE_ATTACHED, because ble.sh is not yet attached in the initialization stage. Another problem of referencing some variables might be the sourcing order of ble.sh and "$(carapace _carapace)". If carapace is initialized before ble.sh is sourced, carapace cannot automatically detect ble.sh. So, I think the current source <(carapace _carapace bash-ble) is more reasonable than automatic detection.

It should be noted that, if the type of completion is statically determined at the initialization time, the completion will not work when ble.sh is in the detached state (though ble-detach is currently an undocumented feature). But I think it's rare to use Bash in the detached state when ble.sh is loaded, so we don't have to care about it too much.

So far I couldn't take time to see how to use carapace, but later I will try to test them. Thank you.

@rsteube
Copy link
Member

rsteube commented Feb 21, 2022

Ah, i expected ble.sh to be continously activated - needs the fallback then.
Regarding the automatic completions my main problem was that I couldn't cancel them.
There are a couple of slow completions (due to the background service being queried) where this can cause some issues - might be best to skip these in the script with the check for now.
Automatic detection is just a convenience function anyway.

@akinomyoga
Copy link

akinomyoga commented Feb 21, 2022

Regarding the automatic completions my main problem was that I couldn't cancel them. There are a couple of slow completions (due to the background service being queried) where this can cause some issues - might be best to skip these in the script with the check for now.

Ah, OK, if so. maybe you can call the command using ble/util/conditional-sync. For example, for chmod, the invocation of carapace chmod bash-ble may be replaced by the following one:

ble/util/conditional-sync \
  "carapace chmod bash-ble \"\${words[@]}\"" \
  '! ble/complete/check-cancel <&$_ble_util_fd_stdin' 128 progressive-weight

edit (2022-05-13): fixed a code for the redirection of stdin.

ble/util/conditional-sync kills the command (specified to the first argument) when the condition (specified to the second argument) becomes unsatisfied. The third argument specifies the interval of checking the condition (128 milliseconds in this case). The fourth argument is a colon-separated list of options to control the detailed behavior. The accepted options are progressive-weight and timeout=TIMEOUT where TIMEOUT is an integer in millisecond unit. Edit: When progressive-weight is specified, the interval of checking the condition is gradually increased and stops at the value specified by the third argument. When timeout=TIMEOUT is specified, the command is unconditionally terminated when it doesn't end until the time specified by TIMEOUT. The exit status of ble/util/conditional-sync is 148 when the command is canceled by the condition. When the command is terminated by the timeout, the exit status is 142. Otherwise, when the command has been completed by itself, the exit status is that of the command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants