Highlighting completion state

[mhanne]

I'm not quite sure how this is supposed to work, so I'm probably missing some ingenious feature here..

But to me the highlighting on the first word of the command seems a bit random. For example if I type mplayer, it stays yellow/underlined until I type the r, then turns green. When I type pidgin, it turns red after typing the g, and then green when the whole word is there. What's that supposed to tell me?

My suggestion would be to leave the word white by default, change it to red if it doesn't match anything in the path (i.e. pressing <tab> gives you nothing), and green if it's a valid command. Now that we have the yellow color freed up, we can use that to indicate when there is a unique completion already matching our command (telling me I can simply press <tab> now), and maybe even something else to "warn" me that I typed more than would strictly be necessary for a unique completion)

For example, pidg<tab> completes to pidgin, so pid should be white (since it has other possible completions like pidof), pidg yellow (now I can simply press <tab>), pidgi magenta (or whatever, to tell me I wouldn't have had to type that last character) and pidgin green.

[danielshahaf]

But to me the highlighting on the first word of the command seems a bit random. For example if I type mplayer, it stays yellow/underlined until I type the r, then turns green. When I type pidgin, it turns red after typing the g, and then green when the whole word is there. What's that supposed to tell me?

I guess your cwd is ~ when you try this. When you type mplaye (sic), that helpfully gets matched against your ~/.mplayer directory and highlighted as yellow+underline by the path_approx style. Pidgin isn't affected because it uses ~/.purple.

The yellow underline is path_approx highlighting, which has no right to kick in for the command word, unless the "approximately spelled file" is an executable, or is a cd-able directory and AUTO_CD is set. So that's a bug.

In any case, I like your suggestion of revisiting the command-word highlighting. What possible states need the highlighting distinguish?

How about [valid command / invalid command] × [unique completion / ambiguous completion]? All four combinations (valid/unique, valid/ambiguous, invalid/unique, invalid/ambiguous) are possible. "Ambiguous" would mean that there is more than one possible completion, including the word-so-far itself, that is a valid command word (e.g., vi is ambiguous since either vi or vim could be intended). If the command word is valid and the cursor isn't inside the command word, then the "unambiguous" variant would be used. There is a fifth option, "invalid command / no completions", which would be red/bold like today.

Does that sounds like a good specification? Does it cover all cases?

Are there other variables the command word's highlighting should depend on? For example, the kind of the potential completions (whether they are aliases or functions or external commands, etc)?

[danielshahaf]

The yellow underline is path_approx highlighting, which has no right to kick in for the command word, unless the "approximately spelled file" is an executable, or is a cd-able directory and AUTO_CD is set. So that's a bug.

Now tracked as #187.

[danielshahaf]

path_approx has been removed (see #187).

[vegerot]

5 years later and this still hasn't been implemented yet? I can see this is somewhat true for paths to files/directories (if I'm in ~ and start typing Downloads, it will be green/underlined, and when I type Downloadsx it turns red), but this is untrue for commands (e.g. if I type ifconfi the text is red, and only turns green when I type ifconfig).

It seems like #152 and #244 were attempting to solve it, but has not been merged

[danielshahaf]

@vegerot Feel free to start a design discussion if you're interested in helping make this happen. Sorry for the late reply.

[vegerot]

@danielshahaf thank you! I don't really know how to go about doing that.

[danielshahaf]

@vegerot That's not hard. We hold discussions on github (IRC is doable too). Just propose a user-facing behaviour. For example, how should ifconfi be highlighted? What's the general rule?

(Don't worry about implementation right now; just about observable behaviour.)

[danielshahaf]

Cross-referencing #695.