Autocomplete as an Interface (2015) • Hacker News Board

Re: Autocomplete as an Interface (2015)

#101

Post by j88439h84 » Thu, Jan 16, 2020, 6:19 PM UTC

carreau wrote: post #23

ktpsns wrote: 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…

IPython dev here, 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 mi…

> if you don't have complaints you are not using it enough

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.

Re: Autocomplete as an Interface (2015)

#102

Post by j88439h84 » Thu, Jan 16, 2020, 6:23 PM UTC

pcr910303 wrote: post #87

Autocomplete, IMO is a crude effort to make text based interfaces more interactive. 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 s…

Well said

Re: Autocomplete as an Interface (2015)

#103

Post by bewuethr » Thu, Jan 16, 2020, 6:25 PM UTC

Other people have shared improvements to Bash's default autocomplete behaviour; here's mine, specifically addressing the criticisms that you have to hit tab twice and the pollution of terminal history:

  # Complete unambiguously on first tab, then show completions
  set show-all-if-unmodified on

(These settings go into your ~/.inputrc file.)

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

This will make the list of completions omit the part they all have in common.

The combined behaviour is then like this: for a directory with a few files,

  $ ls
  file1  file2  file3

I can start typing:

  $ cat f

Now, hitting tab (just once) gets me the unambiguous part:

  $ cat file

Hitting it again shows me the possible completions with the common part replaced by an ellipsis:

  $ cat file
  ...1  ...2  ...3
  $ cat file

Re: Autocomplete as an Interface (2015)

#104

Post by gnulinux » Thu, Jan 16, 2020, 6:28 PM UTC

ehnto wrote: post #52

OskarS wrote: post #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 t…

> 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. 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 hundre…

I disagree, there is nothing particularly different about "enterprise software" that requires a different naming scheme than other software. This is simply a cultural habit, and this cultural habit is supported by the fact that this same community uses IDEs that have good autocomplete feature. You can write enterprise software without naming your classes that long and be absolutely fine, and I argue this is not a trade-off it's merely a convention.

Re: Autocomplete as an Interface (2015)

#105

Post by gnulinux » Thu, Jan 16, 2020, 6:31 PM UTC

gravypod wrote: post #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 confi…

This is a very poorly constructed argument that's repeated over and over. There is nothing in vim that makes you not be able to use autocomplete. If you want autocomplete you got it. I'm an emacs user and I have a lot MORE features including MORE autocomplete features than my coworkers using IDEs.

Re: Autocomplete as an Interface (2015)

#106

Post by gnulinux » Thu, Jan 16, 2020, 6:35 PM UTC

kuon wrote: post #64

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

there are zsh distros that come with good defaults such as oh-my-zsh.

Re: Autocomplete as an Interface (2015)

#107

Post by cloverich » Thu, Jan 16, 2020, 6:36 PM UTC

pcr910303 wrote: post #87

Autocomplete, IMO is a crude effort to make text based interfaces more interactive. 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 s…

Text is generic. With interfaces you have to design abstractions that are suited to the application. Like code, great UI abstractions make solving problems easier and pleasant. Wrong abstractions do the opposite, leaving users powerless to accomplish their goals. Text both fills a gap for when no abstraction is present and provides a fallback when the abstraction isn't good enough or discoverable.

Re: Autocomplete as an Interface (2015)

#108

Post by wavefunction » Thu, Jan 16, 2020, 6:37 PM UTC

OskarS wrote: post #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 t…

Perhaps you would benefit from a customizable latency on autocomplete, similar to what I've implemented when building autocomplete form fields. You don't want stuff popping up with every key press or even as someone is still typing and presumably understands what they want to type next.

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.

Re: Autocomplete as an Interface (2015)

#109

Post by PaulDavisThe1st » Thu, Jan 16, 2020, 6:38 PM UTC

I see no mention of emacs' dynamic completion, which I've been an addict of for several decades now. Rather than autocompletion based on some defined domain of possibilities, dynamic completion backward searches through the buffer to find completions. Keep hitting the key (I use Ctrl-/) and it will eventually search every buffer you currently have loaded.

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.

Re: Autocomplete as an Interface (2015)

#110

Post by gwbas1c » Thu, Jan 16, 2020, 6:38 PM UTC

Autocomplete is the main reason why I preferred Microsoft Visual Studio over other environments when I was in school; and then why I gravitated towards Microsoft tools as a professional.

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.