It's not just how zsh displays the completions. The fact that I can complete from the middle of the filename is quite important to me.
Autocomplete as an Interface (2015)
11–20 of 197 posts
Re: Autocomplete as an Interface (2015)
#12While IPython is cool, lets not forget autocomplete exists even in the default python interpreter 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.__setatt…
That's the case now, but it wasn't in 2015 when this post was published.
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.
Re: Autocomplete as an Interface (2015)
#13Re: Autocomplete as an Interface (2015)
#14 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-backwardRe: Autocomplete as an Interface (2015)
#15Just 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
Re: Autocomplete as an Interface (2015)
#16I could not agree more to this article. Not only am I a happy IPython and zsh user, but also like searchable menus (also refered to as "OSD search" or similar in non-Mac OS X contexts). 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 permanen…
Re: Autocomplete as an Interface (2015)
#17Re: Autocomplete as an Interface (2015)
#18Re: Autocomplete as an Interface (2015)
#19Anecdotally, 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.
Re: Autocomplete as an Interface (2015)
#20 if (myVector->empty()) {
fillVector(myVector);
}
autocomplete will pop up a window like 4 times while writing. For no real reason: i can type "empty()" on the keyboard faster than I can look at a screen and choose "empty()" from a list, and having having the list pop up is distracting.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.