Autocomplete as an Interface (2015)
benkuhn.net
benkuhn.net
if (myVector->empty()) {
fillVector(myVector);
}
In fact, I strongly disagree with this:
> If I were writing a sophisticated user interface today—say, a programming language or a complex application—autocompletion is one of the primary constraints I would design it around. It’s that important.
Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. A programming language should be easily typeable on a keyboard without having to resort to auto-complete for everything.
Regarding nightmarish Java type names I'd rather the name for things be the fully written out description (like "httpClientFactory") than something that's easier to type - at a glance I know what it is and does, and autocomplete is smart enough that I can type "h" and tab and it has the variable there already. And if I don't know what it does, all that takes is a "h", a tab, and a ".", and now I have access to all its functions with descriptions, saving me a context switch and jump to the documentation.
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. These kinds of annoyances go away if you learn the system properly, so it's not a huge deal, but it's there.
More serious is the visual noise. I type while looking at the screen, and having a window pop up like that is distracting. It forces attention to itself since it's right next to the cursor (which is where I'm focused), and you have to process it. There's a reason people build elaborate "distraction free" practices, and we all know that being distracted by sudden inputs can break "programming flow". Auto-complete does this for me. It's not that I can't work with it, I just feel much more focused when not using it.
Like, imagine if auto-complete was enabled when writing just regular English. Every time you get half-way through writing a word, a window pops up suggesting that the ending of the word "parli" is probably either "parliament" or "parlimentary". That would be super-annoying, right? There's a reason Microsoft Word doesn't have autocomplete in this way, and it's how I prefer to program.
Third, I do think there's a more insidious effect of over-reliance on auto-complete. I genuinely think it leads to bad practices when designing a language, because you come to rely on it. Type names and lines become longer and you start to use more inline namespaces.
I think of C++ chrono library as an example of this. It seems like a library entirely designed to be used with autocomplete, because no sensible human without autocomplete would design a library like this:
auto start = std::chrono::high_resolution_clock::now();
// .. do stuff
auto end = std::chrono::high_resolution_clock::now();
auto elapsed = std::chrono::duration_cast<std::nanoseconds>(end - start).count();
Again: I know I'm the weird one. Tons of programmers I've worked with and respect love auto-complete, and for good reasons. But I think there's a downside that most people don't consider, but maybe should.
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...
Regarding the autocomplete, GMail does do this. It was a bit jarring initially but now I either accept the option or continue on as if it didn't exist.
I'm not sure what your argument for the third is - that it leads to code that relies on auto-complete? Isn't that in fact an optimization? Those lines don't seem particularly egregious to me. I don't know much C++, but I could see exactly what it was doing with those lines of code by being able to read the variables. Is it verbose? Yes it is. I don't take the idea that coming to rely on a tool is a necessarily a bad thing. C# visual studio debugging is head and shoulders above Console.WriteLine() - is it necessary? No, but it's greatly sped up the development process. Same with not having to go to the command line each time I want to compile and run my application.
I understand you understand you're an outlier, and I know you're just making personal arguments, but it kind of feels a bit "old man yells at cloud" - and that's not bad, I just thought there was value in debate.
Yes, that is a very accurate description of how I feel when making this argument :)
Sublime Text often inserts "matching" quotes and parentheses. But it doesn't always do the right thing, so I usually have to go back and erase it. But then it erases the original one, too. So I have to move the cursor, add a space, and then erase it.
And when the feature does do what I wanted, it's only saving me literally 1 character --- ~0.1 seconds at my typing speed.
'I think there are very real costs.'
First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes with you.
IN ORWELLS REALITY: It isn’t doing the quote matching to save on your typing, but to keep the scanner from providing the wrong tokens to the parser of a compiler that is running all the time while you are typing.
So... 'Human Interface' ? ^^
A common example is copying some PHP source code into a new file, then entering "<?php" at the very top of the file. If I'm working quickly and do the natural thing (i.e. hit ENTER afterwards), I end up with "<?phpversion" and I either have to manually delete it, or do a cmd-z dance. Or I have to remember to press RIGHT after "<?php" instead of ENTER.
Many other similar examples (quote characters often seem to cause a problem). But, on the other hand, I know I've made use of autocomplete to help me type a long constant name which happened to be in the same file. So ... swings and roundabouts.
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 autocomplete: libraries can cram in more functionality because developers will be able to use autocomplete to find it. But what’s the alternative? Less functionality in the libraries so they can be used with autocomplete turned off? There is some merit to that point of view, but simplification can only go so far before you are just missing things you wanted to use in some niche use case.
The right word for that would be code completion or more specific brandings of intellisense, which is completely different from things like T9.
Er... that happens all the time: various word processors, text messaging, etc. Even Google's autocomplete (which is a rare example of autocomplete being really good) is essentially this.
The right word for that would be code completion or more specific brandings of intellisense, which is completely different from things like T9.
The visual display functions a bit like subtitles on TV: I don't really notice it's there, until it can help me. Just like subtitles help when I don't immediately understand something, autocomplete helps when typing something takes a bit longer than I'd like it to or when I'm not entirely sure what I want to write.
The "misuse" of autocomplete always continues to affect my workflow, because I can never ignore it. When it's wrong I have to explicitly opt-out from having it do the wrong thing, instead of quickly opting in to the right thing when it makes sense. It's a lot like auto-correct on phones, correcting words that weren't wrong in the first place. The fact that the popups capture arrow keys makes this effect significantly worse.
After some configuration I now have Emacs set up to handle this perfectly. Enter and movement commands always work like they normally do, never depending on the state of the autocomplete popup. Whenever it's there I can quickly make use of the autocomplete popup using Alt. It never does the wrong thing, because I would have to consciously tell it to do the wrong thing. When it's opt-in, autocomplete for regular English is actually a delight. I notice myself quickly auto-completing long words that take longer to type out.
I fully agree with your third argument. In my experience libraries and language ecosystems that fully expect autocomplete, like Java, tend to become overly verbose. The length of a name or expression affects the reading cost, but autocomplete mostly removes the equivalent writing cost. This then allows programmers to quickly give up on finding better names, or clearer ways of doing things.
I personally am in the affected by visual noise camp. But it appears that some aren't that bothered by it.
you should try typing with closed eyes. after some time you see the code directly in your mind.
start writing loop, realize I need another variable, go back and initialize the variable, back to where I was, oh this should be brought out into a function, ah this function should is now getting quite large I need to split it, back to where I was, oh that should be an array not a map etc.
I like Visual Studio's 'jump back to where I was' (Ctrl+-) feature because it leaves a trail of bread crumbs across the many files I'm working in of what I've been doing and what's left to be done to implement feature x.
hm, that's interesting. I generally know pretty well the code I want to write before writing it. The question is what is the fastest way to get it from mind to buffer.
iOS does this and I assume Android does also. In fact, it’s based on what you type frequently. For instance, I use some phrases so often that I get autocomplete suggestions for them as well as company specific acronyms.
For example, `err.nn` expands to ``` if err != nil {
} ```
And that's a default for GoLand. I have set up a few custom ones that are pretty handy as well, which frees up time from typing, to actually thinking through and solving problems, as well as making any necessary verbosity easier to deal with.
While most variable names are kept short, I do go for 2-3 word variables when necessary, and have some pretty long winded function names that, IMO, improve readability by a mile, like `GetNonEmptySliceElements()`.
I also don't know of a single language that requires auto-complete for everything. I do know languages that make more use of it, but I also don't now of a single language that benefits from not having some form of autocomplete. Even your myVector example could benefit from autocomplete (either having a better name them "myString" or "myInt" or me just typing 3 keys instead of 8 for completing myVector.
Do bad interfaces exist? Sure, I don't know of a single UI element that can't be done poorly or messed up.
That's a negative experience for me. If I'm pausing, it's because I need to think about something.
In that instant, a suggestion distracts me.
The chances of the suggestion being relevant to my pause are pretty low.
The best option is when you can invoke the autocomplete/docs on demand - using a convenient shortcut.
Sure, I wasn't talking to you. I was referencing another user and a specific element of their comment. I also wasn't giving an exhaustive list of all the options available in modern autocomplete features.
> The best option is when you can invoke the autocomplete/docs on demand - using a convenient shortcut.
Autocomplete has that as well. Seems like people are assuming that there is only one way to do things, which is silly. Instance, delayed, and activated. These all exist.
So yes, you can customize things to fit your easily distracted nature.
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.
``` // Controls the delay in ms after which quick suggestions will show up. "editor.quickSuggestionsDelay": 10, ```
Some people might still be annoyed by the code completion menu placement, which isn't configurable (yet).
https://www.ibiblio.org/john_henry/
Just bang away at keyboard as fast as you can, hitting keys tens of millions of times over a lifetime.
Humans are tool builders. At some point, the tools will mature to the point where sudden bursts of typing at 100 wpm will become irrelevant.
But they don't always build useful tools ! And more notably, useful tools don't necessarily become widespread, and widespread tools aren't necessarily useful
And of course widespread tooling is often not actually best-in-class
But so human advancement is not sufficient reasoning -- it's not uncommon that doing nothing at all is more optimal than doing the thing we did (eg the recent flight boarding article on frontpage, which described the common back-to-front, and front-to-back, load orders being worse than random load -- the optimal solution is quite convoluted)
But over time, something changed, and I’m now a big fan of autocomplete interfaces. There was something wrong with my initial assumptions, and I think that’s the same assumption you make when you say this:
> i can type “empty()” on the keyboard faster than I can look at a screen and choose “empty()” from a list
You’re right, I can type ‘empty()’ faster than selecting it from a list. I have the muscle memory already there, and I don’t need to stop and look and think about which method I’m autocompleting.
The reason I still use autocomplete is not that I need my IDE to tell me that there’s an ‘empty’ method there as if that’s something I don’t already know, but to tell me that my assumption that ‘myVector’ has an ‘empty’ method is correct!
I occasionally write code like this:
auto myVector = someFunction();
if (myVector->empty()) {
fillVector(myVector);
}
Once I started programming this way, having the window appear was not ever a distraction, because I expected it to appear. In fact, the only distraction was when it stopped appearing, when I’ve made a mistake!
Exactly, autocomplete is an excellent discovery tool. I may not even be aware productModel->hasConfigurableOptions was a function, or Product\Model\Configurable\Options was a model until I check with autocompletes.
https://boto3.amazonaws.com/v1/documentation/api/latest/refe...
Once you get familiar with a particular editor then these problems become less acute. What remains is the obscuring of other lines of code which can be fixed by making the autocomplete box only appear when you press tab.
Both of these could be achieved by somehow decoupling the front-end (as in before semantic analysis) of compilers and making them output the AST in some standardized tree-structured format like XML.
In addition to his workflow, I want to add that I really appreciate having the parameters and types displayed when calling a function or method. Sometimes it’s unavoidable asking yourself questions like “which way round are those arguments?” or “is that a signed/unsigned integer?” Sure you can look at the code behind the function you want to call but having the IDE prompt that saves you navigating away from the code you’re currently writing. That’s a massive win for me. Particularly for projects that require less active development
If you know you have an array and you know what you want to do with that array but don't know the name of the operation you want to do with that array, then completion as a form of discover sucks. No one is likely to stumble upon, say, JS's ".some()" method without having prior knowledge that this function exists and have it do exactly what they want.
Anecdotally, I use Typescript and code completion is exactly how I discovered Javascript's "some" and "every" methods. It involved lots of scrolling because I didn't know it would be named like that, but based on the presence of other list comprehension methods I had a good suspicion that they were there somewhere...I still often mistakenly write LINQ-named "all" and "any", but the online type checking quickly snaps me out of it. Code completion can actually be improved to deal with these cases with more utility, by not only matching on the parts of the member's name, but a system could also match on synonyms to parts of what you typed as well (or document aka's in the interface that play no other role than hooking into code completion).
It’s like a rounded edge on plug pins, you still have to know where the plug socket is to plug something in but the rounded pins mean You don’t need to be millimetre perfect when inserting it because the plug will slide along the curve and guide itself into the socket.
That’s the point of autocomplete, it’s about enabling developers to focus on remembering the important stuff while the IDE helps guide them around the more granular bits that are still syntactically important to the compilation of software but don’t really matter to the logic you’re writing.
Not that I'm saying that was a great workflow. But I liked the subtle feedback as I typed. I've also used autocompleters in the fashion you describe. Syntax highlighting can also provide this kind of feedback and I feel like these tools could probably morph into a single, more cohesive tool that provides a smoother experience than the pop-up window.
Autocomplete is and was never about saving on typing. It is an aide to help you browse and navigate large namespaces, it doesn’t enable long names, it enables deep and vast libraries. The complaint then isn’t about some straw man class name, but about the 200+ methods that can be called on that class.
You have it the wrong way around. Naming like that comes from the structure of the application, which just happens to benefit the ability for autocomplete tools to understand it.
If you've ever worked on enterprise software, with hundreds of classes across a half a dozen domains, you'll know the structure comes from a need for organisation and discoverability, and without that organisation you would have a harder time finding the parts of the application you need to be aware of. Autocomplete is just a convenient way to search the codebase for what you want. But that structure is the real hero.
Is it really that hard to create a Helpers class with static methods?
I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for
- the niceness of having a IDE that can almost replace pair programming
- an ecosystem were dependency resolution works
My coffee just shot out my mouth.... What?
Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much).
I really like that nodejs can handle diamond dependancies.
sidenote: I do like the simplicity of Java code though too.
If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it.
Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%.
It is now upgraded, faster and easier to understand and upgrade :-)
And since the wording is pretty much directly defined by laws and regulations you better get used to it since unlike in small businesses you cannot just argue with the product owner that these two mean the same.
I disagree that there's nothing different about enterprise software, the needs are inherently different to a product-owner/single-purpose software platform. By enterprise software, I really mean enterprise frameworks that are used across many projects and many teams. Patterns are simply a shared language of concepts. The need for strict structure so anyone can work on it or extend it without messing the whole thing up or introducing new concepts or legacy code is what drives the patterns.
You could absolutely build super simple large scale software without all those concepts, but then you get yourself a boutique app that only your team is familiar with. Which is fine for a single product owner platform, not fine for a framework with hundreds of devs working on it who all need to collaborate without ever talking to eachother.
I treat it like eye candy: Just some fun, animated blandishment that makes me feel all 1337 while banging out code.
What would be nice is if the auto-complete window could be detached from the cursor and float in a corner of the editor, so I can look at it for those times when I have a brain fart and can't remember which parameter comes first in a function.
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.
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.
It's very tricky to get right and requires a lot of attention to detail in timings, human attention span, UX, and even psychology.
IDEA's auto completion is mostly good, in my experience, not sure if you've tried it.
> i can type "empty()" on the keyboard faster than I can look at a screen and choose "empty()" from a list,
Sure, but that's a five letter word with no camel case nor special symbols. Your observation stops applying very quickly as the code base grows.
Not mentioning that having to type all these letters and symbols (especially if you need to use the shift key) is pretty bad from a carpal tunnel standpoint.
If you could customize the lag after ceasing to type a key and match it to your normal typing cadence I imagine your experience and utility from IDE autocomplete would be much greater.
I suppose this is really just a matter of opinion, but it seems strange to argue that autocomplete is bad because it can be so useful that you'll definitely want to use it. Sure, it's a separate argument whether "Factory" and "Bean" are useful, but long, verbose, meaningful names are good in my opinion. A random example taken from the React source code: `attemptHydrationAtCurrentPriority`.
Without knowing anything about React or what Hydration is, I’m suspicious of this name - “AtCurrentPriority” doesn’t sound like useful information, everything should happen at current priority otherwise what does the concept of a “current” priority mean?
In a shell you don’t list files in the current directory with “ls —in-current-directory”, because the current directory is what you get if you don’t specify anything.
Similarly, in a language with exceptions and a library with error results, “attempt” is a non-description; everything is an attempt by default, the interesting things might be things which somehow can’t or mustn’t fail.
This smells like it ought to be “Hydrate” and then have a version which can be specified at some other priority if that’s needed.
Incremental search is finally appearing in some browsers, bringing them into the 70s. But just as software itself has seemingly gotten slower as the machines have sped up, I feel like the interfaces have gotten significantly more cumbersome.
How about everyone with less than two years experience with both IDEs and editors stand back so we grown ups can sort this out ;-)
On a more serious note and as someone who has been on both sides of the fence:
How about we accept that people are different? Some people like Mac, some like Linux and some - gasp - enjoy their Windows desktop.
That said, and as someone who has extensive experience from both sides, I think that if people put the same effort into learning and configuring their IDE as they put in learning and configuring vim then that might very increase productivity a lot more than last ten years worship of vim.
(And: do learn a bit of vim. It comes in really handy sometimes, just don't fall for the idea that some people sell that you cannot become a good developer without using it all the time.)
Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on...
I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler errors, full -Wall and -pedantic.
After using an IDE for awhile, I noticed my ability to get things right diminished. I gave up knowing things for relying on technology.
One area I notice this the most is spelling. I used to be able to spell. Now I critically depend on browser or editor highlighting of errors, or throwing a word into Google to see what Google tells me. And it's not just new or complex words. It's words that I used to know how to spell. If all I had were pen and paper, I would be helpless.
Some will say technology frees you to memorize other more important things. But the downside is you give up agency. And very well may just become that much more of a replaceable cog in the machine.
There are certain classes of autocomplete bugs that just can't happen when you're typing every #include/import/require that I find myself continually cleaning up and writing static analysis for.
I spend far more time reading other people's code than writing it. Autocomplete doesn't provide any assistance there.
Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc.
Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposefully avoid the front framework of the week.
The scope of what I am expected to know changes.
But on the other hand, for the good of the company, it’s often good to sub optimize the individual for the good of the team. You usually don’t want only one person knowing the entire feature and while you will lose out on individual productivity, you can get features out sooner if you have more people working on it.
On a personal level, I love having not to wait on other departments/props to get my work done especially in a dev environment.
I admire those who stick with their old tools and forgo modern ones so they can stay sharp. They tend to miss the forest for the trees though.
The point I was making that when I was writing C day in and day out and mostly just working with a combination of my own code and my companies vote libraries, it was easy to use just a text editor and the command line to build.
But things have gotten more complicated since then. No one could be expected to know the hundreds of functions that make up the entire AWS SDK or all of the options that you need to specify for a typical CloudFormation stack in yml. Of course now it’s even better with the Cloud Developer Kit that lets you generate yml programmatically using a static language - with autocomplete.
This sounds good to me. I'm not qualified to judge the quality of the linux kernel, but judging by the adoption, many features, and hardware support, they must do something right.
I definitely had this experience with CodeWarrior back in the day. I really loved that IDE. But then when Mac OS X came out and Objective-C became the native language, the tools weren't there yet, and I had to either program "alone" without autocomplete/fancy dynamic highlighting/etc, or use Project Builder (the predecessor to Xcode), which was lacking in all these departments. I found myself much slower, and not for the obvious reason of "of course, I'm missing all these great tools", but as you say, slower at things I knew I used to be fast at. It's kind of like discovering that no, you don't like broccoli, you actually just like the melted cheese on top. That was a big moment for me deciding to focus on generally applicable skills vs. IDE-specific skills.
Interestingly enough, I think this legitimately doesn't apply to a lot of people because they spend most, if not all, their career in one domain. In that environment I think learning IDE-specific things makes a lot of sense. I discovered that this wasn't for me and move around a lot, so its nicer to not be dependent on those things.
Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol?
sometimes its because a product gets discontinued, or your employer forces a different IDE, etc.
I wouldn’t work for a company that forced an IDE on me.
In that environment I think learning IDE-specific things makes a lot of sense.
Visual Studio Code works with multiple languages as does Visual Studio.
Most new languages until someone implements it. Again, this is very dependent on what you like to do. If you like trying bleeding edge stuff then you’ll probably run up against this.
> I wouldn’t work for a company that forced an IDE on me.
Sure, sometimes it’s kind of out of their control (or understandable). For example Xcode at Apple. Or if you work in a dev feature that needs to work with some tool or something. Again, my position is that it’s probably fine for most people.
> Visual Studio Code works with multiple languages as does Visual Studio.
OK, it’s interesting you bring up a fairly new entrant as proof this (at least I’m the Mac). Again, my interest is in trying lots of syntax extensions and stuff that usually just breaks these sorts of things. As I mentioned before, if you’re doing application development on a specific set of established languages for a very long time it’s probably the right move.
Now you’re giving me flashbacks. I worked for a company where the founder wrote his own VB like IDE/Compiler/VM for Windows CE. I hated every minute of that job until I got the chance to work on the actual compiler written in C++/MFC.
Perhaps, it is not so much giving up knowledge but filling the first-level cache with other stuff, like the larger picture of the software you are developing or the ever growing number of abstraction layers below the code you are writing. And whether that is good or bad thing is an interesting question. I am not aware, that it has an definite answer, yet.
That being said, even if I programmed with the intent of continuing to be syntactically correct during the entire process (which I do when I am editing an existing file usually), I still cannot stand autocomplete, or really anything beyond simple syntax highlighting, because I feel like everything about today's computing experience is yelling at me. Notifications constantly popping up, linters yelling about stuff I don't care about yet, and autocomplete acting like clippy telling me every possible method that starts with an S. I find it severely distracting. I wouldn't want Microsoft Word to tell me every verb that starts with "s" just because it knows that in this position of the sentence I must be typing a verb and I just hit an "s".
I just checked my key sequence for writing that :
if<ctrl+space><enter>myv<enter>.em<enter><down arrow>fill<enter>myv<enter><right button>;
It's most certainly faster for me to press a single enter when it does than the four remaining letters, and the parentheses
The way most people use it is they type enough letters to be specific enough then hit tab to fill in the rest.
For example in intellij I'd type something like "my" then hit tab immediately.
Just recently I've been trying to use Bazel for for a personal project. When you use gRPC you don't get any auto completions on generated code. I haven't been able to locate anyone who cares about this because they use some text editor configuration that doesn't have autocompletion so this is basically never going to get fixed or have traction.
If more people prioritized type hinting and IDE friendliness I feel a lot of interesting tools would take off
They are not very well versed in vim if they don't know about the autocomplete capabilities of it.
The most basic form is matching with ctrl-n in insert mode. http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-N
This can be beefed up by coupling it with ctags and even goes up to 11 with full language server protocol support by using coc.nvim.
Never let anyone tell you can't do that in vim. Most of the time, they are wrong.
Or, can you recommend a good book on vim package management and debugging?
It's perfectly fine to get a full featured IDE. If you miss the vi stuff, most IDEs nowadays have pretty good vim emulations (and thanks to to neovim, many have even perfect vim emulations).
Nevertheless, for an intro into vim plugin management, a good book is "Modern Vim by Drew Neil".
I took a look at that on Amazon[1], but the reviews seem to indicate that it gives a surface-level walkthrough of some of the available plugins. I'd need something that gives me a mental model I can use for debugging.
[1] https://www.amazon.co.uk/dp/B07DFBWVMB/ref=dp-kindle-redirec...
You can follow this issue for updates: https://github.com/bazelbuild/rules_go/issues/512
My feeling is that we experience a revival of keyboard-based searchable/explorable GUIs due to two reasons:
(1.) Many people use notebooks where both hands rest on the keyboard (in contrast to an external mouse where one hand permanently rests).
(2.) Desktop searches, or virtually any kind of search with a fast index took over (clearly pioneered by Apples Spotlight). That's the Google spirit of searching for things instead of clicking menus.
This is probably one of the changes where in the retrospective we can say "the 2010s" brought us. :-)
Thanks to you (and the author) for being happy users of IPython; but if you don't have complaints you are not using it enough :-) We do our best to provide good completion; but most of the work is thanks to Jedi (Dave Halter) for the completion and prompt_toolkit (Jonathan Slenders) for the UI , at least in terminal.
There is a lot of improvement that could be done to completion (time and funding missing), and we are always looking for Feedback and Pull Requests.
Side Note while I agree about the statement about Julia and bar(foo) vs foo.bar(); nothing prevent the completer to add text not at the cursor position. Having foo)<tab> suggesting to prepend `bar(` is a possibility.
(also hijacking top comment...)
I'm a daily user. I wish there were a way to enable the autocomplete and doc display that ptipython has. In both the terminal and jupyter it would be very helpful.
In JupyterLab you can open the "Inspector" that should have the equivalent and show the doc for the current token under cursor.
I'd love to have time to implement that for IPython, or even have for the completer the documentation that pops up for the current highlighted option of the completer.
As IPython is now based on Prompt toolkit there is no reason not to have that; it's mostly a question of finding the time to implement it !
# Complete unambiguously on first tab, then show completions
set show-all-if-unmodified on
This means that if I hit tab for the first time, Bash will autocomplete as far as the completion isn't ambiguous; single keypress, no history pollution.
If I then hit tab again, I get a list of the possible completions.
The other single biggest improvement over default behaviour for me is this:
# Replace common prefix with ellipsis for completion
set completion-prefix-display-length 2
The combined behaviour is then like this: for a directory with a few files,
$ ls
file1 file2 file3
$ cat f
$ cat file
$ cat file
...1 ...2 ...3
$ cat fileActually, this, coupled with the "complete on first tab hit" is the reason I stayed away from zsh. I tried it a few times, simply because so many people are raving about how much better it is than bash, but never really switched and the autocomplete is one of the major reasons.
1. I like to see autocomplete as a history. I hit tab (twice, but I will get to that in a second) and see what my options are. I type another letter or a few and hit tab again. If I made a mistake, I can catch it by comparing the previous set of choices to the new one. With zsh, if I made a typo, all I get is an empty list and a sense of confusion.
2. Every once in a while (more often than I a willing to admit), I will hit tab for completion when I don't really mean to. Like I will type something like ls -l /usr/local/bin/<TAB>. Bash will beep at me to ask if I am really sure. Zsh will freeze and compile a list of hundreds of completions. Not much else to say about that.
Recent zsh will (configurably) ask if you really want completion it detects there will be more than a smallish number of candidates
Still a pain for other completion sources though
I agree with your point about the extra tab keystroke being useful before a giant list gets printed. I like that about bash.
But sometimes I hit tab too many times. I don't really count keystrokes, I just kind of mash the tab key until I get a list. And I don't need bash to print the list again if I hit tab an extra time. (This seems like it could be changed without breaking compatibility with anything. If you hit tab 3 times, don't print the list twice. Instead, only re-print the list if the string (that the completion is based off of) has changed.)
I guess I don't care too much either way about having the list in my scrollback buffer. I can see how it's useful to refer to it, at least while in the process of trying to use the completion.
Not sure if I understand correctly:
Ctrl-r shows command history, filtered by fzf as you type
I find that particularly useful for frequent stuff that I don't bother to put in a script. Optionally add some search keywords in a trailing comment.
(might be not zsh itself, but oh-my-zsh or so)
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> s=""
>>> s.[TABTAB]
s.__add__( s.__getattribute__( s.__lt__( s.__rmul__( s.encode( s.isdecimal( s.join( s.rjust( s.title(
s.__class__( s.__getitem__( s.__mod__( s.__setattr__( s.endswith( s.isdigit( s.ljust( s.rpartition( s.translate(
s.__contains__( s.__getnewargs__( s.__mul__( s.__sizeof__( s.expandtabs( s.isidentifier( s.lower( s.rsplit( s.upper(
s.__delattr__( s.__gt__( s.__ne__( s.__str__( s.find( s.islower( s.lstrip( s.rstrip( s.zfill(
s.__dir__( s.__hash__( s.__new__( s.__subclasshook__( s.format( s.isnumeric( s.maketrans( s.split(
s.__doc__ s.__init__( s.__reduce__( s.capitalize( s.format_map( s.isprintable( s.partition( s.splitlines(
s.__eq__( s.__iter__( s.__reduce_ex__( s.casefold( s.index( s.isspace( s.replace( s.startswith(
s.__format__( s.__le__( s.__repr__( s.center( s.isalnum( s.istitle( s.rfind( s.strip(
s.__ge__( s.__len__( s.__rmod__( s.count( s.isalpha( s.isupper( s.rindex( s.swapcase(
>>>https://bugs.python.org/issue5845
https://github.com/python/cpython/commit/1a6cb30a346ba8812d6...
https://docs.python.org/3.4/whatsnew/3.4.html#sys
Support already existed in Python 2, so it's sad that it took so long for it to be enabled by default.
Or maybe I'm just trying to justify why I use vim...
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.
For really messy javascript or things you don't know well autocomplete helps though.
Compare "save-lisp-and-die" vs "s-l-a-d<TAB>". The latter is much easier to type and the former much easeier to read.
I'm sure one could set up some automatic completions-generating target in a build system that could be fed into an IDE. Well, I'd certainly hope so. But emacs' dynamic completion works so well for me, with no work to get the full benefit no matter what I'm writing - code, a letter, financial docs, anything at all where I just want to hit Ctrl-/ to finish off that slightly-longer than usual term that I just used a few lines earlier.
Yum.
Anecdotally, I hide the header in Google Docs/Sheets most of the time to save space, and have come to rely on the Menu Search field in the upper left (Alt+/, which works regardless of whether the header is shown) for things like renaming the doc, accessing conditional formatting, etc. Basically the few commands I use regularly which don't have a corresponding hotkey.
However I do agree that Bash generally feels outdated these days. In fact autocompletion was the primary reason behind me writing my own readline API
...however Bash can still do the items you'd described earlier. In fact back when Bash was my primary shell (which is a few years ago now), it literally did do those things you described and it came already pre-written as part of whatever Linux package I was using. ie I didn't have to write those scripts myself.
But yes, I do agree Bash is pretty horrible at writing and using autocompletion compared to more recent shells. There no doubt about that :)
The best I’ve seen in this regard of discovering hidden things is the Visual Studio C# auto suggestions which refractors your code to use modern language features. It’s quite magical, sometimes doing non-trivial refactors.
I find it a great way to get exposed to the ongoing evolution of C# without actively polling the language spec.
set editing-mode vi # if you're a fan of VI-style editors
set visible-stats on
set colored-stats on
set show-all-if-ambiguous on
set completion-ignore-case on
set colored-completion-prefix on
set completion-prefix-display-length 1
set menu-complete-display-prefix on
tab: menu-complete
"\e\t": menu-complete-backward
"\e[Z": menu-complete-backwardThis may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.
It's not just memorizing: When working with a new or unfamiliar API, it's very easy to guess and navigate this way.
To be quite honest, when I work in environments without autocomplete, I feel like I'm learning slower then when I learn in Microsoft Visual Studio.
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.
And, to be fair I thought Chrome had copied the Awesomebar by now?
Early php did something like that just not for the same reason. https://news-web.php.net/php.internals/70691
While it does address some shortcomings of text based interfaces, text based interfaces are inherently flawed to provide enough feedback or context to the user. The only reason we are still using text based interfaces is that the computing system has revolved around UNIX and the command line.
The fact that autocomplete is needed for sanely using text based interfaces (especially the command line and programming languages) are proving that we need a better interface.
GUIs became popular due to providing the users instant feedback of what the user can and cannot do, providing context implicitly with the user interface elements. Autocomplete's corresponding features are flag/function name completion, context (like the current directory) based completion... but they really don't do their job well.
I do not have any ideas about what the interfaces of the future will be... but text based interfaces won't be the future. Hence autocomplete might become obsolete...
<Sorry for the useless rant :-(>
The reason we're still using keyboards, which are basically late-19th century technology, is because we've yet to figure out a faster and more precise method of getting words out of a human brain and into a machine. You could quibble over qwerty vs dvorak or chorded stenotype keyboards, but all share the premise of speaking using your fingers.
(Voice recognition isn't there yet and probably never will be if human-to-human interactions are anything to go by (it's common for humans to use text to communicate with each other when they need to be precise, even when both share a common spoken language.))
My biggest issue with IPython notebooks is that it holds state between cells. Sure it makes things faster, but it also lends itself to bad programming techniques.
https://github.com/CeleritasCelery/emacs-native-shell-comple...
Imagine how efficient is is to type "kubectl get pod my_pod" versus clicking around in a clunky web-based dashboard. Now imagine if your smart speaker's set of commands were as strict or well documented as most CLI apps.
Now, if there were a way to use the same technology with [subvocal recognition](https://en.wikipedia.org/wiki/Subvocal_recognition), that would really be something. I'd be onboard with more or less thinking my code and watching it appear on the screen, since that's what I do now, just with a few finger steps in between.
I speak from personal experience as this happens regularly in Xcode for large iOS projects. Xcode is notorious for its fragile indexing system. Symbols are often not correctly picked up, and autocomplete is notoriously unreliable when the projects get large. This happened often enough that it actually trained me to become much more comfortable writing code for long periods of time without relying on autocomplete at all.
If autocomplete/IDE indexing system lags behind or is unavailable for even 0.5% of the time, that translates to real time where the developer is waiting for the autocomplete list to appear.
With Python, Ruby, and other languages, one has a plethora of IDEs/editors/environments to choose from. However for Objective-C or Swift, the environment is severely limited. AppCode does exist, and it does have a much better indexer and autocomplete, but it is very different than Xcode and most iOS developers will not be able/willing to move to AppCode. And that's even before considering their licensing costs.
With most helpful aids, I would say that autocomplete is a gift and useful day-to-day, but to make it a central dependency during the development phase seems to be a mistake.
If you're referring to anything your parent mentioned, those tools already exist.
Autocomplete in early versions of IntelliJ IDEA and NetBeans is basically how I learned to really program Java. After a 10 year break from serious coding, it's also how I caught back up :)