default to first completion when opening new buffers?

[anoda9]

It'd be great if there was a preference that let vimperator default to the 1st completion when opening new buffers, rather than opening a google search.

To illustrate: currently, if I want to open a new tab with GitHub, I type "t", then "gith...", then press tab to select the 1st autocomplete result, then press enter. What I'd prefer to do: type "t", then "githu...", then press enter and have cvim follow the 1st autocomplete result, without having to bother with tab. Opening a search could be moved to be the 2nd default option, so if I wanted to google "githu", I could type "gith...", press tab once to select the "google gith" autocompletion.

This would be very useful since I find the most common action when browsing is opening an address that you have already visited before (not searching google for a phrase.)

[coachshea]

With all due respect I find this a very counterintuitive suggestion. I have never seen an application where tab wasnt used for completion and enter for entering the current info. You would have enter do what tab followed by enter usually does, and tab would do absolutely nothing other than make the next enter do what enter is supposed to do. Have you considered using qmarks for your common addresses?

[anoda9]

It's odd that you find it counterintuitive, considering that both chrome and firefox's omnibars function this way. The developers of those apps clearly thought about the problem and came to the conclusion that the most useful functionality is to default to the first autocompletion rather than to a google search.

I have never seen an application where tab wasnt used for completion and enter for entering the current info.

Not having seen something before is by itself a very poor argument against an idea. As I mentioned above, chrome and firefox's omniboxes both function this way.

You would have enter do what tab followed by enter usually does, and tab would do absolutely nothing other than make the next enter do what enter is supposed to do.

But "what enter is supposed to do" is a matter of opinion/perspective. From my perspective, this change would make enter do what enter is supposed to do. You, on the other hand, want to have enter do what tab followed by enter usually does. :)

The key point to me is: 95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go. Given that the main purpose of vimperator (and vim before it) is to minimize the amount of keystrokes it takes to perform common actions, this seems unacceptable to me.

Keep in mind that I am suggesting this as an option (that could be toggled on or off by the user), not a "one size fits all" change.

[gkatsev]

Personally, I find that chrome's omnibus auto-using the first auto-complete item constantly trips me up when I'm using it. If this feature request is accepted, it would probably be under a setting and not a default because it will be changing user expectations of how things work. Also, all feature requests are on the backburner while we try and keep vimperator alive with each subsequent firefox release. If a PR is submitted, it is much more likely to get this feature request accepted.

[coachshea]

anodo,

You make some excellent points, I'll try to clarify my own and then hopefully end on a point of agreement.

First, I am aware of omnibar behavior, I personally feel that omnibars are a bad comparison to command lines. I was referring to the fact that in vim and all of the vim-like products (of which I use many), this would be odd command-line behavior. I realize that once you type open (or have it typed for you by typing '0' in normal mode) it's easy to compare the command-line to an omnibar, but then you have an interesting choice. Do you have different completion mechanisms for the open function than the rest of the functions, or do you institute it for all command-line completion and have a behavior that, at lest in my experience, would be very odd for a command-line? As far as my use of the word "supposed" I was assuming the above perspective, but I appreciate that if you disagree with those, then "supposed" can take on a completely different meaning.

The point that I will agree with is that it could be worthwhile as an option, I can just leave it unset and it won't bother me and those who agree with your perspective can have it (it still needs to be decided whether it applies to all completions or just open, but that won't be my concern).

Lastly, you never answered my question. Have you considered using qmarks for those sites? That's how I handle common sites and find it easier than typing 'o' followed by part of the site followed by enter. Just a thought.

On Wed, Aug 19, 2015 at 06:37:03PM -0700, anoda wrote:

It's odd that you find it counterintuitive, considering that both chrome and firefox's omnibars function this way. The developers of those apps clearly thought about the problem and came to the conclusion that the most useful functionality is to default to the first autocompletion rather than to a google search.

I have never seen an application where tab wasnt used for completion and enter for entering the current info.

Not having seen something before is by itself a very poor argument against an idea. As I mentioned above, chrome and firefox's omniboxes both function this way.

You would have enter do what tab followed by enter usually does, and tab would do absolutely nothing other than make the next enter do what enter is supposed to do.

But "what enter is supposed to do" is a matter of opinion/perspective. From my perspective, this change would make enter do what enter is supposed to do. You, on the other hand, want to have enter do what tab followed by enter usually does. :)

The key point to me is: 95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go. Given that the main purpose of vimperator (and vim before it) is to minimize the amount of keystrokes it takes to perform common actions, this seems unacceptable to me.

Keep in mind that I am suggesting this as an option (that could be toggled on or off by the user), not a "one size fits all" change.

— Reply to this email directly or view it on GitHub.*

[ff2000]

On Wed, 19 Aug 2015 18:37:03 -0700, anoda notifications@github.com wrote:

It's odd that you find it counterintuitive, considering that both chrome and firefox's omnibars function this way. The developers of those apps clearly thought about the problem and came to the conclusion that the most useful functionality is to default to the first autocompletion rather than to a google search.

No, that's not how those "omnibars" work. At first you do not run blindly an URL but you get an inline completion. Second this inline completion has nothing to do with the completion list, especially it is not the same as the first entry in the list. It is simply the toplevel domain of the highest rated search result, which most likely happens to be the first item.

---

// CORRETION It only works if the word you type into omnibar is the beginning of an URL. If it happens to be a random search term or the beginning of an URL you do not have in your bookmarks/history, the omnibar will stay empty and pressing ENTER will also launch a google/whatever search.

---

Just try it: Go to google.de, search for something that just comes to your mind, open a link that is NOT simply a top level domain (and of course it should not be in your history/bookmarks). Then open a new tab and start typing the toplevel URL and you will see that at some point the line edit shows that URL, though you never visited it - hence it is not really a "completion" but a hint.

If you don't know what to search here is an URL you most likely never visited: http://freelux.de/lastChanges.php?ref_param=lastChanges.php

I also would vote against such a feature, even with inline completion being implemented, because it is not how a COMMAND bar should work (IMHO) ;)

I have never seen an application where tab wasnt used for completion and enter for entering the current info.

Not having seen something before is by itself a very poor argument against an idea. As I mentioned above, chrome and firefox's omniboxes both function this way.

You would have enter do what tab followed by enter usually does, and tab would do absolutely nothing other than make the next enter do what enter is supposed to do.

But "what enter is supposed to do" is a matter of opinion/perspective. From my perspective, this change would make enter do what enter is supposed to do. You, on the other hand, want to have enter do what tab followed by enter usually does. :)

The key point to me is: 95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go. Given that the main purpose of vimperator (and vim before it) is to minimize the amount of keystrokes it takes to perform common actions, this seems unacceptable to me.

Keep in mind that I am suggesting this as an option (that could be toggled on or off by the user), not a "one size fits all" change.

---

Reply to this email directly or view it on GitHub: https://github.com/vimperator/vimperator-labs/issues/263#issuecomment-132845655Non-text part: text/html

[anoda9]

I see where you guys are coming from, but I think it's counterproductive to lock yourself into thinking of vimperator as strictly a command line. Different problems call for different solutions/tools - no default autocompletion is the ideal functionality for the command line (where commands are powerful and mistakes can be costly), but for web browsing I think most users would prefer behavior closer to an intelligent omnibar (convenience over caution). Personally, I'm fine accepting the risk of occasionally opening a tab I didn't intend to if it means I save hundreds of keystrokes over the course of the day.

Do you have different completion mechanisms for the open function than the rest of the functions, or do you institute it for all command-line completion and have a behavior that, at lest in my experience, would be very odd for a command-line?

Just for the ones that make sense (the ones where you are navigating to a webpage - t, o, w). Sure, it's slightly inconsistent, but absolute consistency at the price of usability is dumb imo. (except in cases where inconsistency could lead to costly mistakes i.e. terminals. But again, we're designing for a web browser, not a terminal.)

Note that Vimperator already autocompletes to some degree - if you type ":he" then enter, it will take you to the :help page. (Yes, it's not a perfect example, because ":he" is enough to uniquely identify the :help command, but still.)

@ff2000 You're correct, I guess I just assumed they were more intelligent. :) Still, it's not the specifics of how they work, but idea/direction behind their implementation: increased convenience at the cost of slightly reduced accuracy/consistency. Those designers came to the (imo correct) conclusion that that tradeoff was worth it.

[anoda9]

@coachshea I do use qmarks for my most commonly visited sites (gmail, reddit, amazon, etc.) but a large portion of my web browsing is to sites that I don't visit often enough to qmark, and I'd still like to be able to access them quickly and easily. (i.e. what was the item I just looked at on ebay 5 minutes ago? let's load that tab again.)

The crux of the issue for me is the point I mentioned above: (apologies for repeating)

95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go.

[maxauthority]

I fully agree that the default omnibox behavior is much better for quickly opening URLs (especially how the chrome one works). It's like having quickmarks available without having to configure them. That's why i actually have just mapped 'o' to ctrl-l in Vimperator. :)

Anyway, with the pending webextensions rewrite, we'd had to rethink the command line anyway. On Aug 25, 2015 07:52, "anoda" notifications@github.com wrote:

@coachshea https://github.com/coachshea I do use qmarks for my most commonly visited sites (gmail, reddit, amazon, etc.) but a large portion of my web browsing is to sites that I don't visit often enough to qmark, and I'd still like to be able to access them quickly and easily. (i.e. what was the item I just looked at on ebay 5 minutes ago? let's load that tab again.)

The crux of the issue for me is the point I mentioned above: (apologies for repeating)

95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go.

— Reply to this email directly or view it on GitHub https://github.com/vimperator/vimperator-labs/issues/263#issuecomment-134488788 .

[coachshea]

Perhaps that mapping is the answer to the problem. That way anybody that wants it can get the behavior they want and the rest of us will still have our commandline.

On August 25, 2015, at 5:24 PM, Martin Stubenschrott notifications@github.com wrote:

I fully agree that the default omnibox behavior is much better for quickly opening URLs (especially how the chrome one works). It's like having quickmarks available without having to configure them. That's why i actually have just mapped 'o' to ctrl-l in Vimperator. :)

Anyway, with the pending webextensions rewrite, we'd had to rethink the command line anyway. On Aug 25, 2015 07:52, "anoda" notifications@github.com wrote:

@coachshea https://github.com/coachshea; I do use qmarks for my most commonly visited sites (gmail, reddit, amazon, etc.) but a large portion of my web browsing is to sites that I don't visit often enough to qmark, and I'd still like to be able to access them quickly and easily. (i.e. what was the item I just looked at on ebay 5 minutes ago? let's load that tab again.)

The crux of the issue for me is the point I mentioned above: (apologies for repeating)

95% of the time when I open a new buffer, I am trying to navigate to an address from history, not do a google search. (I don't think I'm alone in this regard). Under the current functionality, that means that 95% of the time, I have to hit 2 keys (instead of 1) to get where I want to go.

— Reply to this email directly or view it on GitHub https://github.com/vimperator/vimperator-labs/issues/263#issuecomment-134488788; .

— Reply to this email directly or view it on GitHub.

[gkatsev]

Just wanted to circle back, we'd accept a PR that adds an option for this that defaulted to false. Thus not changing the current default behavior but gave users the choice for this.