A spiritual fork of inline-autocomplete
that aims to work (almost) exactly like TextMate 2’s autocompletion.
I wrote it for switchers like me who want to pretend Atom is actually TextMate 2.
Here’s how autocompleting works in TextMate. Assume you've got a file that looks like this, except that ^
signifies where the cursor is:
fooBar
fooThud
fooBazThud
fooTrozThud
^
foo
. Press Esc.foo
, ordered by proximity to the cursor.fooTrozThud
) and puts the cursor at the end.fooBazThud
). You can keep pressing Esc to cycle through the matches, or Shift-Esc to cycle backwards.fooThud
and move the cursor to the left of the capital T. Press Esc.foo
and end with Thud
(ignoring fooThud
if it exists), ordered by proximity to the cursor.fooTrozThud
) and moves the cursor so that it's still to the left of the capital T.Thud
and move the cursor to the left of the capital T. Press Esc.Thud
, ordered by proximity to the cursor.fooTrozThud
) and moves the cursor so that it's still to the left of the capital T.TextMate 2’s autocompletion suggestions are always restricted to tokens in the same buffer. I kept one enhancement from inline-autocomplete
, but changed it to be more conservative. Instead of an option to suggest words across all open buffers, inline-autocomplete-textmate
has an option to suggest words across all visible buffers.
Whenever you create a new pane in your workspace — for instance, by right-clicking on a tab and selecting Split Right — you’re creating a new visible buffer. This package finds visible buffers like so: for each pane in the workspace, consider the pane’s active item. If it’s a text editor, its buffer is added to the list of buffers from which we draw completion suggestions.
Why? For selfish reasons. I always have far too many tabs open, and there’s no particular significance to the set of tabs that happen to be open in my workspace at once. But if I’ve set up my workspace to have more than one editor pane, it’s usually so that I can refer to one file as I’m writing another, and in those situations it’s immensely useful to have both files’ words as candidates for autocompletion.
A future version of this package might turn this setting from a checkbox to a dropdown and allow you to choose between three options: active buffer only, all visible buffers, or all open buffers.
Good question! They can’t. But we’ll pretend they can in order to deliver vaguely consistent behavior. The only thing you need to know is that completions from the current buffer are always more proximate to the cursor than completions from different buffers.
In other words, when you’re cycling through autocompletion suggestions (in the forward direction), you’ll always see all of the completion options from the current buffer before you see any options from other buffers.
Yes. TextMate 2’s concept of scope-specific “character classes” is left unimplemented; my experience is that it misfires more often than it helps. I wouldn’t rule out its addition as a setting in some future version.
I also removed a feature that was present in inline-autocomplete
: suggesting keywords for the current scope even if they aren’t present in the buffer. I don’t think I’ve needed to autocomplete a keyword in my entire coding life.
Yes. TextMate binds autocompletion to the Esc key, but Esc is already used for several things in Atom, so if we’re not careful we run the risk of breaking those other functions.
Hence there’s a setting called “Escape-key mode” that is enabled by default. In this mode, the package will ignore an Esc keypress if it thinks that the user pressed it for a different reason. For example:
If you disable the default key binding and map inline-autocomplete-textmate:cycle
to a different key, you should disable this setting.
Good catch. Let us know what about this package looks wrong to you, and we'll investigate right away.