Live data from Hacker News

Autocomplete as an Interface (2015)

benkuhn.net

11–20 of 197 posts

Re: Autocomplete as an Interface (2015)

#12
post #10

While 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.

It seems to be enabled by default since 2013/Python 3.4:

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)

#14
For a better autocomplete experience in Bash (and other programs that use the readline library) I can recommend that you put some of the following in ~/.inputrc:

    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-backward

Re: Autocomplete as an Interface (2015)

#15
I wish more engineers cared about auto complete. A lot of software people I know say "just use vim" or "just remember things" and I feel these view points really stifle progress.

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

Re: Autocomplete as an Interface (2015)

#16
post #3

I 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…

[deleted]

Re: Autocomplete as an Interface (2015)

#19
The one genuinely great aspect of Ubuntu's defunct Unity environment was the "Heads Up Display" (HUD) that made searching and autocompleting through the File/Edit/etc. menus in every (supported) program as easy as hitting a hotkey and typing. I am a much bigger fan of Gnome 3 than Unity, but I think this should be resurrected as an option in every OS/DE.

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.

Re: Autocomplete as an Interface (2015)

#20
You 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 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.

Post reply on HN