I just want VSCode to stop "fixing" "import numpy as np" to "import numpy as numpy" when I press enter.
Took me a while to find them, but life is so much nicer without needing to manually correct stuff.
121–130 of 151 posts
I just want VSCode to stop "fixing" "import numpy as np" to "import numpy as numpy" when I press enter.
Took me a while to find them, but life is so much nicer without needing to manually correct stuff.
Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…
This irritates me as well and my brain now registered that to autocomplete on chrome I need to hit return/enter.
Issue is that on most forms where chrome suggests autocomplete based on what you fill other forms with, return/enter does not autocomplete and usually submits the form or goes to the next field..
So, here is the thing. Modern browsers (at least Firefox and Chromium, haven't tried the others in a while) have AWESOME autocomplete widgets for their URL bars. They incorporate multiple data sources (URLs and page titles from history, bookmarks, the search engine's keyword autocompletion, probably more), build statistical models (when I start typing "y" I want to go to Youtube 95% of the time, so suggest that first…
In terms of the UI - I made a react component for showing dynamic suggestions (essentially a wrapper for downshift). And I've found the options out there for the sorting part quite good (e.g. match-sorter for sync or Elasticsearch completion suggester for async)
Earlier quoted context omitted.
There are two problems with adding widgets to browsers: 1: Once they are in, you have to support them forever. Or you will break the few websites that use them. 2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button. I think it's better to get the basics right instead of building more and more '…
> 2) Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. I'd argue that's because the native widgets haven't changed much since I've started using computers around 1994 (probably longer), and simply aren't up to the modern standards anymore. If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to…
Awareness and training matter a lot here. There is now a usable and element, but a number of people I know simply use bootstrap's data-toggle or a custom onclick handler because they don't actually know about the existence of these tags nor the gotchas you need to account for. Safari will have support in the next major version, but I expect it will be a year or so before libraries begin to use it and developers won't use it until it is well documented and supported by libraries. The HTML spec introduced native attributes for a bunch of form states including valid/invalid state, required state, min/max values and more, but most libraries don't take advantage of them because they built the functionality before it had browser support and so developers don't use them either. We'll see these things gain adoption, but it will take time.
Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…
The second is very annoying and has even caused me to abandon the tool / software.
Earlier quoted context omitted.
We already have sitemap.xml that could be used for this purpose
You're right actually. Building a web extension for this would be pretty cool. I'll take that on when I get some free time.
Earlier quoted context omitted.
> If I type the next letter of the top match, it should remain the top match. How would this not always be the case anyway given the other rules in place?
You're right in that this example violates, "When one option is the prefix of another, put the shortest one first." But a personal peeve of mine is Apple Spotlight. When I type d-a-s it autocompletes to dash.app, as soon as I type d-a-s-h it autocompletes to dashboard.app. Since it's built-in I felt limited in what I could do about it. Thanks to this post I looked up how to suppress it from Spotlight since I dont use…
So, here is the thing. Modern browsers (at least Firefox and Chromium, haven't tried the others in a while) have AWESOME autocomplete widgets for their URL bars. They incorporate multiple data sources (URLs and page titles from history, bookmarks, the search engine's keyword autocompletion, probably more), build statistical models (when I start typing "y" I want to go to Youtube 95% of the time, so suggest that first…
The closest we have now is datalist[1], which acts as a data source that you can attach to a text input to give it autocomplete. Unfortunately, it isn't nearly as fully-featured as it could be, possibly because no one uses it so there's no incentive to make it better (although Chrome's implementation has gotten markedly better over the past two years or so, mostly by fixing blatant bugs). [1] https://developer.mozill…
I was with them right until here. Tab is a well-known button that has one function: going to the next selectable element. Not do something funky with your autocomplete list. If I want to tab to the "go" button that is after the autocomplete list, then I expect tab to take me there. How else would I do it? I'm not visually impaired, but I hate having to move over to the mouse to leave your input field (feels like Flash Player all over again).
Of course, if I selected an item and then press tab, then the value of the suggestion should be used together with sending my focus on its way.
An earlier item should solve this, so you don't need to use tab to use the suggestion:
> The action to make use of [your input] must be a different key than the action to [make use of the autocomplete]
(If I understood that correctly in the first place, the sentence is a little convoluted.) But to hijack a perfectly useful button? That's a no-go. I'm not even sure what other keys you could use: space should usually be a space, enter would go using your input (unless you selected a suggestion with the down arrow maybe), so what's left that does not have an alternate function, caps lock? Sysrq? Or something like shift+enter?