Customizing complete menu

[romaia]

Is it possible to customize the menu for the tab completions?

For instance. This is how completion looks in fish:

And this is the current default in ble.sh

I would like to use a ligher color for the description, to focus on the commands itself.

[akinomyoga]

I would like to use a ligher color for the description, to focus on the commands itself.

I'm not sure if I got it correctly, but would you like to specify the graphic style of the description of the selected item?

[akinomyoga]

OK, I now understand what you request.

I thought you tried to show the description of the selected item in the reverse video as fish does, but then I was wondering why it makes you focus on the commands themselves because it seems to drive more attention to the description of the selected item instead of the commands.

If you want to change the color of the descriptions in general, that makes sense. There is no option to directly specify it, but you can include the ANSI control sequences in the description (such as the SGR codes of $'\e[33mdescription...\e[m' with bleopt complete_menu_style=desc. An SGR code can be embedded in the description at the generation phase. The completion settings built in ble.sh don't provide the completions for mgc, so I guess the completion is generated by some other framework or the settings you made. Where did you get the completion setting of mgc?

[akinomyoga]

OK, I think mgc uses the completion framework cobra, which is actually supported by ble.sh. I couldn't find anything on the internet about the command mgc, but the description "Generate the autocompletion script for the specified shell" is specific to cobra. With the current implementation of ble.sh, the description from cobra is not highlighted because cobra doesn't include SGR codes to highlight the description, and ble.sh just uses the description generated by cobra as is.

ble.sh/lib/core-complete.sh

Lines 3796 to 3801 in adf9ab8

	if [[ $line == *$'\t'* ]]; then
	cand=${line%%$'\t'*}
	desc=${line#*$'\t'}
	[[ $cand == "$prefix"* ]] || continue
	ble/complete/cand/yield word "$cand" "$desc"
	has_desc=1

To allow configuring the color of the description, I think it is easier to add a global option in ble.sh to specify the default color of the description.

[romaia]

mgc is the cli of a new cloud being launched in brasil (magalu.cloud). Source code is not available yet, but it can be downloaded here: https://github.com/MagaluCloud/mgccli (disclaimer: I work at magalu cloud - but not the on the cli)

Yes, it does use cobra.

but would you like to specify the graphic style of the description of the selected item

Yes!

it seems to drive more attention to the description of the selected item instead of the commands.

I agree, but on the bash with ble.sh (first screenshot), since both the command and the description use the same color, It makes it harder to see the commands, that why I would like to use a less proeminent color on it.

and ble.sh just uses the description generated by cobra as is.

Do you think this is something worth supporting? I can work around this editing the description for now, but this seems like a nice addition.

[akinomyoga]

In commit b3e7237, I added the following new faces:

• ble-face menu_desc_default
• ble-face menu_desc_type
• ble-face menu_desc_quote

You can now change the default color of the menu description by ble-face menu_desc_default. For example, you can use the following setting:

ble-face menu_desc_default='fg=olive'

@romaia Could you update ble.sh by running ble-update and check the behavior?

[romaia]

\o/

It works perfecly. Thankyou very much.

While we are talking about menu customizations, have you ever considered one that looks like a popup? something in the way neovim does?

Inshellisense does something that also looks nice (https://github.com/microsoft/inshellisense/)

[akinomyoga]

Thanks for checking the behavior.

For the popup completion menu, I did consider it as a possible option before I started to implement the completion menu, but I gave up implementing it. Some considerations and discussions can be found in the following links (though they are in Japanese):

• Enhancement of completion #5 (comment)

• ble.sh/note.txt

  Lines 6993 to 7014 in 5676525

  	2016-06-22
  	* tui: prompt-toolkit という物がある様だ。ちょっと観察してみるのも良い。
  	基本的には補完候補を勝手に出すという事と、
  	表示の仕方が emacs auto-complete と同様に
  	overlay によって実現されているという事。
  	所で overlay で実現するためには複数行で編集を行っている時に、
  	下の行にある内容を記憶しておく必要性が生じる。
  	Emacs の場合には表示している内容を完全に内部に保持しているので問題にならなかった。
  	(a) 現在の実装で実現するためには内容を完全に記憶するか、そうでなければ
  	(b) 複数行で編集を行っている場合には枠の位置・大きさを変更する際に
  	毎回下の方にある行を再描画するかといった事が必要になるだろう。
  	Bash では 2 次元配列を実現するのは辛いので
  	結局内容を完全に記憶するというのは余り嬉しくない事だろうか。
  	と思ったが、表示領域の幅 (COLUMNS) さえ把握しているのであれば、
  	実は 1 次元配列の上に terminal の内容を保持してしまっても問題ない気がする。
  	というか枠の大きささえ決まっていれば普通に sub window の様な物も
  	bash で実現する事ができる。今まで余り考えたくないとして避けていたことだが、
  	この方法ならば楽である。

• ble.sh/note.txt

  Lines 6416 to 6443 in 5676525

  	2018-08-16
  	* complete: オーバーレイによる実装?
  	現在の実装では仮挿入しているが、
  	これによって現在の入力内容でエラー着色するべき所が、
  	補完が実行された後の着色になってしまっていて、
  	補完前の現状でエラーなのかどうなのかが判別できなくなっている。
  	やはり仮挿入ではなくて overlay で実装するべきなのではないか。
  	しかし overlay の仕組みを実装するのは面倒である。
  	どの様な仕様にするのが良いのかの吟味から実装まで。
  	しかし、これについては後回しで良いだろう。
  	以下に仮入力の4種類の方法について言及がある。
  	https://mattn.kaoriya.net/software/vim/20170905113330.htm
  	リンク先は消えている。web archive のリンクを追記 (2018-09-23)。
  	https://web.archive.org/web/20110630165743/https://www.mozilla-japan.org/projects/intl/input-method-spec.html
  	* 2018-09-23 自動補完時の着色について
  	cmplstofB さんからも指摘があった。
  	https://github.com/akinomyoga/ble.sh/issues/5
  	自動補完の候補文字列は実際に挿入しているので構文着色に影響を与える。
  	"現在の内容" で着色するべきなのではないか、ということ。
  	そうしないと例えば今入力したコマンドが実際に存在するコマンドなのかどうかが分からない。

[akinomyoga]

There are two reasons that I don't feel it would be worth implementing.

• The number of items and the amount of information shown at once are limited with the popup-window interface. It looks fancy, but I'm not sure if I would continue to use it. Even if I would implement it, after enjoying it for a few hours, I'd probably go back to the full-width completion menu and will never turn on it again.
• This adds unnecessary complication to the implementation. To show a popup window, the program needs to remember the rendered content hidden by the popup window so that it can rerender the content after the popup window changes its size or position or is closed. Since ble.sh offers multiline editing, we cannot simply clear the terminal region that the popup window has occupied. If it is properly implemented in a shell script, it would also have a performance issue because the shell language does not provide the proper data structures to implement it. We need to implement everything using strings and one-dimensional string arrays. As another way, we could rerender the entire prompt and the command line every time the popup window changes its status, but this will add excessive flickering.

I wouldn't implement a feature just for the reason that it "looks nice". Do you think there are practical benefits in having the popup windows?

[romaia]

Nope, thats just something I was wondering. Although it looks nice, I agree the benefits are not worth the additional complexity.