auto show available tab completion for :open and :tabopen

[serpent7776]

Import behaviour from vimperator where :open and :tabopen automatically show panel with available tab completion entries. Currently when I enter :open goo I don't know what completions are available until I press <TAB>, but then address part that I've typed is replaced with first completion which might not be what I wanted.
This could be enabled by setting to keep default behaviour.

[fanglingsu]

Hm, this is one of those features that make software slow. And as I know it fomr pentadactyl it's really slow. This would generate some list of possible completions as the user types in any url. I don'tthink that it makes much sense to show a list of completions without user requested it by pressing Tab or Shift-Tab. I don normally type in some significant parts of the url separated by space and press Tab and get a really short list of items where I pick up the one I think that's the right.

[cdlscpmv]

I don normally type in some significant parts of the url separated by space and press Tab and get a really short list of items where I pick up the one I think that's the right.

The problem with this, and the whole completion system in general, is that once Tab has been pressed, the first item from a completion list is pasted into the input field, which erases the initial query. So it becomes impossible to append something to it or to change it. Maybe it would be better just to show the corresponding completion list on the first Tab press to let the user to append/change something in the inital query, and only on the second Tab press actually paste the first completion item into the input field.

And on a side note, why not unite completion lists for :open and :tabopen? It seems quite reasonable for these two commands to have a common completion list, and I cannot think of any argument against it.

[fanglingsu]

Ah, I you like to cahnge the initial contenty you typed after you sen the too long completion list. This would be a nice feature I think too, but it's not what the users who know vim would expect. But if we have this current behavior as fallback this should be no showstopper.

And on a side note, why not unite completion lists for :open and :tabopen? It seems quite reasonable for these two commands to have a common completion list, and I cannot think of any argument against it.

Don't know if I understand you right. But the urls that are completed for the :open and :tabopen commands are always the same.

[cdlscpmv]

Don't know if I understand you right. But the urls that are completed for the :open and :tabopen commands are always the same.

Sorry, my bad. I really wanted to refer to another problem, but while I typed the text, the two issues got mixed up in my head. The actual problem is that I often use to look back at what I typed before. For example, I use :open and then after some time I can do :tabopen and I expect to see the (because I don't remember which of the two command I run to open that URL) , but since I used :open for it, it will not show up.

I don't know if there are any other people with the same kind of problem. But I also don't know how to get around it. I often use these two commands for a web-search, and after some time I may want to change something in the initial query and run the search again. I would like to do it independently of the way I run the previous search (with :open or :tabopen).

[fanglingsu]

With :open <C-P> you mean stepping to the command history, right? This is also like in vim. There is indeed no further logic. The commands history sotred in file $XDG_CONFIG_HOME/vimb/command is searched for entries starting with the content you've already typed into the inputbox. So :o, :open or :tabopen are completely different things.

[serpent7776]

Possibility to change initial content user typed after tab completion list is shown is something I would like to have in vimb. This is exactly what vimperator does by auto generating tab completion list. I can type small part of url and I instantly see what completions are available.
This should not make vimb any slower, because tab completion list should not be generated after each key stroke. It is quite common for auto completion implementations to generate completion list after e.g. 500ms delay after last key press. This way automatic completion will not get user in the way while he is typing.
Possibly pendactyl have bugged implementation of auto completion. Vimperator implementation makes me actually faster, because after I type part of url I instantly see what tab completions will be, so I can make corrections when completions are not what I want them to be. Currently in vimb after I type part of url and press <TAB> to complete I often find that completions are not what I wanted, so I have to <ESC> and type url again.
I don't really like idea of double <TAB> to auto complete - I have never seen such behaviour in any app I've used. I'd rather adopt vim behaviour with set wildmode=longest,list option - this is what I use in my .vimrc. <TAB> would be used to complete and <C-D> to only show possible completions.

[cdlscpmv]

@fanglingsu wrote

With :open <C-P> you mean stepping to the command history, right?

Yes.

This is also like in vim. There is indeed no further logic.

I see. But haven't you ever fallen into the problem I described above?

I understand your intention to make Vimb more like Vim, but Vim isn't perfect, and an enormous amount of plugins for it is an example of this fact. What's the point of cloning shortcomings of Vim? It may be useful only for those Vim users who've got used to some quirks inside Vim. People who don't want to get used to these quirks just use plugins or tweak Vim to get a satisfactory behavior. I think the main strength of Vim is that you can easily change it to suit your needs, and not its defaults. Since Vimb is not as customizable, it is wise to make it more usable by itself, even for users who are not very familiar with Vim, or users who change the standard Vim behavior to their preference.

I've expressed my opinion not particularly on this issue but rather on the future of Vimb. I'm probably not the right person to say all this, I haven't contributed a line into the project. But I've been using Vimb for quite a long time and it almost always does what I want. Thank you!

Let's return to the command history. If I am the only one affected by the issue, then I would like to know how others avoid it. The only possibility I see is to use :open or :tabopen and not both, but this seems insane.

@serpent7776 wrote

I don't really like idea of double <TAB> to auto complete - I have never seen such behaviour in any app I've used.

What shell are you using? For example, this is what Zsh does, and Bash does a similar thing. The place where I use completion the most is on the command line. The completion system there is qute simple yet effective. On the other hand, the completion system of Vim always seemed to me clumsy. It's either not simple, or it is not effective.

I have nothing against the "complete as you type" idea if it is available as an option. Some people don't like when software becomes too "interactive".

[fanglingsu]

I see. But haven't you ever fallen into the problem I described above?

I don't use the command history in conjunktion with :open or :tabopen. Mostly I use it for settings and some fancy JavaScript one liners :e! .... If I want to use open I use the completion. But you are right this does not allow you to reenter the last terms for a shortcut/searchengine.

@serpent7776 To summarize there are two issues.

1. The initial typed content for a completion is replaced by the first matching item on pressing <Tab>.
2. The stepping through the command history is confusing in case of :open and :tabopen. But do you have an suggestion how the stepping through the history should work? Maybe we could use some fuzzy search or info search here. This would allow you to filter by the part after the :open or :tabopen or if it's fuzzy :open something<Tab> would also match :tabopen something or so.

[fanglingsu]

@serpent7776 I would like to avoid to insert a new keybinding like <C-D> to show the completion list and use <Tab> only to complete. But vim does also allow in complete to change the typed text. The typed text is the last entry in the completion list so stepping through the full list brings the user back to the entered text, or faster <S-Tab>. I we mimic this wen could have both, the current and vim like behaviour, and the possibility to change the text used to filter the results.

[serpent7776]

@fanglingsu appending typed text to tab completion list seems a good way to fix this issue for me.
@cdlscpmv I use tcsh on FreeBSD and bash when on Linux (but I don't use commandline on Linux very often). For me tab completion used by tcsh is simple and effective. When I type xt<TAB> is expands to xterm, when I type a<TAB> is lists all possible commands. For bash the first works the same way, but second does nothing and I have to type <TAB> again to show possible completions. I see no reason to force user to type <TAB> twice when one should be enogh. Anyway this is probably just a matter of preference, I dont really like bash.
Default vim completion is indeed flawed, that is why I use set wildmode=longest,list. This change completion to work just like it does in shell.

[cdlscpmv]

@serpent7776 wrote

For me tab completion used by tcsh is simple and effective. When I type xt<TAB> is expands to xterm, when I type a<TAB> is lists all possible commands.

Zsh does the same but after showing you possible commands, it allows you to cycle through them by pressing <Tab>.

@fanglingsu wrote

The typed text is the last entry in the completion list so stepping through the full list brings the user back to the entered text, or faster <S-Tab>.

Sounds good to me.

About the second issue, I have an idea in mind. Can we introduce a new symbol for completion like it is done with completion for bookmarks? Let's say @. Also in the command history file we have entries of the kind:

open <something1>
tabopen <something2>

The user can type :open @<Tab> and he will see a completion list which consists of

<something1>
<something2>

and so on.

Of course, it would be nice to extend it a little bit further. For example, by typing :open @something<Tab> the user will see only items which have something in them.

[fanglingsu]

So I implemented the appending of the inital content as the item after the last real completion item. So if the completion list is to long, you can jumpt with <S-Tab> from the first entry right to the inital content and adapt the string.
Hope this solves the one part of the issue.

@cdlscpmv Kan you explain the logik behind the new @ completion a little bit more? Is this only meant to work as completion for :open and :tabopen or should this also work for completion of settings or something else? As I understand your example the :open @something<Tab> looks up all entries in the $XDG_CONFIG_HOME/vimb/command that starts with open or tabopen and use everything after the command part to build up a matching completion list, right?

[cdlscpmv]

Is this only meant to work as completion for :open and :tabopen or should this also work for completion of settings or something else?

I think it should work in exactly the same way as ! for completing bookmarks works, i.e. only after :open or :tabopen. I don't think it will be useful for other commands.

As I understand your example the:open @something<Tab> looks up all entries in the $XDG_CONFIG_HOME/vimb/command that starts with open or tabopen and use everything after the command part to build up a matching completion list, right?

Exactly. It is similar to what :open something<Tab> does to $XDG_CONFIG_HOME/vimb/history.

[fanglingsu]

@cdlscpmv I think if we introduce another char like @ to start a special completion we should make is more flexible than searching for open and tabopen commands in the command history. I fear that there is not much benefit for the completion you suggest. But it might be a big feature to use the :someCmd @somthing else to trigger a configurable shell script that is called with the two parameters someCmd and something else and generated the completion items to stdout which is used by vimb to show the completion list. This would allow the user to do even more fany stuff here.

[cdlscpmv]

@fanglingsu This is a very good idea.

[fanglingsu]

OK, I've transfered the idea of the external tool for the completion into a new issue. So we can close this.