I like how "script"[1] works - you can write really simple interactive software and let script do the autocomplete and reverse lookup for you. Rob Pike even uses it in some of his presentations.
Autocomplete as an Interface (2015)
61–70 of 197 posts
Re: Autocomplete as an Interface (2015)
#62You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type if (myVector->empty()) { fillVector(myVector); } autocomplete will pop up a window like 4 t…
I used to think this way, too, so I don’t think you’re weird. At my old workplace, everyone else was a Java IDE wizard, and I was used to good old-fashioned text editors. Aren’t you distracted by that widget appearing while you’re typing, I thought? Is it really faster for you to hit the Down arrow three times instead of just typing ‘empty’? Do people not learn the libraries they’re using anymore‽ But over time, some…
This. I find it's even more valuable with the explosion of 3rd-party libraries and packages--I'm constantly interfacing with code I didn't write, and autocomplete is _way_ faster than context switching to look at the docs/source of a library.
Re: Autocomplete as an Interface (2015)
#63You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type if (myVector->empty()) { fillVector(myVector); } autocomplete will pop up a window like 4 t…
I agree, personally, but I am sure it is a minority perspective. I worry it might just be my unwillingness to change habits and workflow. If I am writing down functionality I usually want to complete my thought first, sometimes even in meta-code, then go back and make it proper. Like you say, autocomplete interrupts with several micro-decisions per line.
But I grew up coding in Notepad, so most editors feel like another part of the complexity stack I have to manage. Other devs seem to code with autocomplete almost like they are coding with a visual programming language. They use the mouse a lot more or keyboard combos if they are really efficient, but they anticipate autocomplete results and select variable names quickly, partly with a mental inventory of variable name options.
I think there are clear strengths to both methods. Pro-autocomplete devs seem to naturally follow the single responsibility principle (SRP) while I find that level of scaffolding obscuring at times.
Re: Autocomplete as an Interface (2015)
#64Fish has one of the best auto completion out of the box, I love all you get for free with zero configuration. I used zsh before, which is great, but require so much configuration.
Re: Autocomplete as an Interface (2015)
#65> I have 90 files open in emacs right now and I can find any particular one in five keystrokes. Imagine having 90 tabs open in Chrome—you could never find anything!
The Quick Tabs extension gives you autocomplete for Chrome tab titles:
https://chrome.google.com/webstore/detail/quick-tabs/jnjfein...
Just type Ctrl+Q and you get a popup with IntelliJ-style autocomplete.
Another trick for Chrome tabs (unrelated to autocomplete) is to open a new window instead of a new tab when starting a new task. If I'm searching for information about a particular programming topic, I use Ctrl+N and do the search in a new window, then Ctrl+click or middle button click to open interesting search search results in new tabs in that window. Then when I'm done I can close that whole batch of tabs at once.
This may seem like an obvious thing to do, but I have seen people who never open a second Chrome window but just have dozens of unrelated tabs in the same window.
Re: Autocomplete as an Interface (2015)
#66I wonder if there is a measurable difference between software written in a very basic text editor vs an IDE. Differences like naming conventions, name length, number of files etc. I've always thought that an IDE, while wildly useful in some scenarios, pushes/allows for unnecessarily complex design choices. Or maybe I'm just trying to justify why I use vim...
I've definitely noticed a difference.
I have been developing my current project using IntelliJ, which makes it easy to jump from function call to function definition.
Once I had to do some maintenance on a live copy using vim, where I don't know how to use those features, I decided to gradually redesign things to have fewer levels of nesting for easier maintenance.
Re: Autocomplete as an Interface (2015)
#67You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type if (myVector->empty()) { fillVector(myVector); } autocomplete will pop up a window like 4 t…
>Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting
With a proper tool you can configure if autocompletion pops up automatically or only if you request it with a hotkey. Check your tool if it can do this. If not then look for a better one.
Re: Autocomplete as an Interface (2015)
#68Earlier quoted context omitted.
I'd argue that it's not benign. I think there are very real costs. First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes when you press tab, some when you press enter. Many times I've been typing a thing, finished the line with the autocomplete window still open, pressed enter to go to the next line, and instead have auto-complete enter a bunch of stuff I don't want. The…
> regular English It looks like the trend is toward autocomplete suggestions for English too. On my phone keyboard, there are autocomplete suggestions to choose from when typing, and GMail now has Smart Compose [1] to do the same thing. [1]: https://www.theguardian.com/technology/2018/may/09/gmail-sma...
On the phone it makes sense because input is very constrained. On a keyboard/doc in a language you are fluent in, it is a distraction.
Re: Autocomplete as an Interface (2015)
#69Earlier quoted context omitted.
I'd argue that it's not benign. I think there are very real costs. First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes when you press tab, some when you press enter. Many times I've been typing a thing, finished the line with the autocomplete window still open, pressed enter to go to the next line, and instead have auto-complete enter a bunch of stuff I don't want. The…
No one would design an autocomplete for written language because we remember the words we are going to use, and anyways, if we forget them, there is no hierarchical namespace to browse and navigate. What autocomplete has enabled are deep and broad namespaces in programming languages that do support such a concept. Yes, you are definitely correct that the massive namespaces designed today are only possible because of…
Perhaps not hierarchical namespaces, but there is the knowledge that 'next word must be a verb', 'that verb requires an object', etc.
Re: Autocomplete as an Interface (2015)
#70Earlier quoted context omitted.
I find that the timing is actually worse, because then I start waiting for the menu to appear as affirmation for some assumption I made about the namespace. It’s also jarring that it appears out of sync with keystrokes. Turning off the delay and working on menu placement instead could provide for better PX, but it is something that can be user tested a lot, at least.
> I find that the timing is actually worse That's fine. Amazingly, these things are customizable to fit everyones needs. Thinking there is only one way to do it is silly, but apparently a number of developers things autocomplete can be done only one way.
They aren’t really customizable that much. I don’t think there is a property in VS or VS Code to haggle with to reduce autocomplete timing to zero, and it still doesn’t deal with it being too intrusive to be used continuously. Each design decision has a cascading consequence, making customization very difficult.