Trigger happy autocomplete

[tomrijndorp]

It seems that autocomplete is a bit too trigger happy. The issue with this, besides being annoying, is that the undo history stack is not reachable anymore. The reason for this is that after editing a \cite command, undo will move the cursor back into the brackets, triggering the autocomplete pane.

Additionally, on my system (OS X El Capitan, Atom 1.7.0-beta0, LaTeXTools 0.8.0), autocomplete does not return keyboard focus to the editor window, which is mildly annoying.

Screen recording:

[ivlis]

+1 for this

[PaulEcoffet]

I had a similar issue and it was because I had also installed latex-friend which has a similar feature. It seems that there is a conflict between the two. I uninstalled latex-friend and everything works perfectly now.

[msiniscalchi]

The trigger-happy behavior is in part due to some internal atom limitations, though it can be ameliorated.

As for focus not returning to the editor, I am seeing this too. @ig0774 any ideas? It's not consistent, which makes this harder to debug.

[ig0774]

On the focus issue, I think this should've been resolved by #78, but if you're seeing it with those changes, I can try to dig a bit more.

[msiniscalchi]

Actually, no. I've pulled #78 into master and have been using it for the past few days (yay dogfooding!). It is very weird. What I can see is this:

(1) if you disable auto-triggering, then there is never a problem with the keybinding (C-l,x).
(2) if you enable auto-triggering, the very first time you type e.g. \ref{, you lose focus. Subsequent invocations seem to be a bit random---with \ref{ things seem to work if you actually select a label, though you may lose focus if you "esc out"; with \cite, I seem to lose focus more often
(3) there is also some weird interaction with the undo stack, as @tomrijndorp reported. If I enter a reference and CMD-z my way back to the original state of the file, I still see a blue dot in the corresponding tab. This btw happens both with and without auto-triggering.

[ig0774]

One possibility I can think of is that we may not actually be storing a reference to the TextEditor, since its actually storing document.activeElement. Could you try changing line 233 of ltselect-list-view.coffee to this:

    @previouslyFocusedElement = atom.views.getView(atom.workspace.getActiveTextEditor())

That should ensure we try to reset focus on the text editor. If that works, we could pass the triggering text editor via start(), which may result in better behaviour.

[ivlis]

@ig0774 Why not just to use the autocomplete+ for this?

[msiniscalchi]

@ig0774 yes, that seems to work!

It's a bit weird, because the problem happens in 0.8.0 as well (per @tomrijndorp), where we still use space-pen-views... anyway, that seems to fix the problem, so that's great. Would you be able to whip up a PR for this?

@ivlis autocomplete+ is not smart enough for our purposes. More precisely: it may be OK for references, but with bibliographies, I think showing more info is better---but that requires a panel, rather than a pop-up.

[ig0774]

Well, #78 was an attempt to be a really careful port of the space-pen stuff. I didn't want to introduce new behaviour (after the pain of the last ST release). I think the space-pen stuff had that behaviour because they couldn't always rely on there being an active text editor (e.g. with the command palette).

[msiniscalchi]

I just pulled #88 into master, and it does solve the focus issue. Thanks @ig0774 !

I've also pushed a small change that should fix the trigger-happy autocomplete issue for citation commands. Hopefully I'll be able to tag a new release this afternoon.