Ultisnips: "Autotrigger" should be optional

[bohrshaw]

I prefer manual triggering and don't need auto-triggering (and arguably a little performance hit) at all.
How about adding an option to disable related auto-commands? @seletskiy

[SirVer]

@BohrShaw Can you benchmark the actual slow down? I am very reluctant of adding options - it always complicates the code and is one more complexity users have to read about and understand. So I'd rather not.

But if the slow down is substantial and annoying, there should be an option or the feature should go again. I'd like us to make this decision on some data basis if possible though.

[seletskiy]

@BohrShaw: I agree with @SirVer about additional options. If you feel significant slowdown, let's look at times and maybe there is a room for improvement.

By the way, I highly recommend you to master autotrigger, because it offers _significant_ productivity improvement on frequent cases.

[bohrshaw]

I briefly benchmarked with the Time command defined in scriptease on Neovim(Ubuntu):

" On a blank file without any auto-trigger snippets defined
:999Time call UltiSnips#TrackChange()    " consume 0.922 seconds

That's about 1ms delay on every key stroke in Insert Mode, which seems not significant. But let's imagine further:

• Firstly, this's not about the time, but the frequency these auto-commands execute.
• It's also not only performance-wise, but battery-power-wise.
• Complex macros inserting frequently would slow down a lot.
• Personally, in a user case like writing a novel I just prefer a dumb editor. Knowing it's so active under the hood is not delightful.

@SirVer I don't think optionally disabling this feature would complicate the code or have a comprehension burden.

@seletskiy I don't find auto-trigger provides any more convenience. ^p and p<Tab> is comparable. And implementation wise, we could use something like: iabbrev <expr>^p getcurpos()[2] == 3 ? a_UltiSnips_func() : '^p'. It has limitations but I hope this trick could be useful to you.

[seletskiy]

@BohrShaw: I guess you are confusing autotrigger with something else. The main point of this feature is typing just p instead of ^p or p<Tab>. That ^ in the examples is part of regular expression which specify beginning of the line, so every p which is first char in the line will be expanded.

Just look, how decent usage of autotrigger can look like:

_Don't look on ISO_Level5_Shift, it's Right Alt; I have system-wide mapping of Right Alt+a to type -._

[bohrshaw]

@seletskiy I did misunderstand the new snippet syntax. That's quiet useful.
But I would do it in a more efficient way if I decide to go a step further on snippet usage, like:

" <M-l> is my snippet trigger key
imap <buffer><expr><Space> getcurpos()[2] == 2 ? "<M-l>" : ' '

[SirVer]

@SirVer I don't think optionally disabling this feature would complicate the code or have a comprehension burden.

That is an easy thing to say for you, but I need to maintain the project :). You might even be right for this instance, but I need to careful consider each instance where slabbing in another option seems like an easy way out: Every option potential doubles the number of code paths (once with the option enabled and once without) and therefore also doubles the number of required tests (in an ideal world where everything could be tested). Also each option needs space to be documented and needs tume for users to understand it. I am always reluctant to make something optional.

Also, timing in neovim will be significantly slower (I estimate factor 100, but I did not measure) since they need to emulate the python interface of Vim through their IPC system - which is slow. Here are replies to your other arguments:

Firstly, this's not about the time, but the frequency these auto-commands execute.

I do not understand what you want to say with this. They execute when you type, like everything else in Vim.

It's also not only performance-wise, but battery-power-wise.

This claim needs benchmarking. I bet a beer + dinner that the battery time of your laptop will not be significantly different when using Vim + UltiSnips with autoexpand enabled vs disabled. My main argument is that you spend most of your time in the editor not typing (i.e. the editor sits idle for 90% of the time), even if you are a very fast typer. Also the amount of extra computation that UltiSnips does now vs before is not significant.

Complex macros inserting frequently would slow down a lot.

I do not understand what you want to say here. What would slow down? And which data makes you think so?

Personally, in a user case like writing a novel I just prefer a dumb editor. Knowing it's so active under the hood is not delightful.

You can using a plugin manager like NeoSnippets to not load UltiSnips when writing plain text, respectively only load UltiSnips for certain filetypes. That problem is already solved on a more generic level, so I do not think we should spend code lines on that in UltiSnips.

[bohrshaw]

@SirVer I'm glad to know your perspective on project management and I appreciate that and your thoughtful response.

You are right on the potential complication should an option be introduced. And I'll give my opinion hopefully more clearly.

On the performance side

The frequency combined with 1ms delay _is_ a concern to me. And I mentioned macros as they are kind of like automatic typing which is so fast that can make me sense the increased delay.

For example, Feed the register q with oiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii, then :Time normal! @q:

• With auto-trigger, it's 0.828 seconds.
• Without auto-trigger, it's 0.028 seconds.

I mentioned "power consumption" as I was saying the word "imagine". :)

On the usability side

My only resident auto-commands running on TextChangedI-like-frequently occurred events are from "matchparen". They aren't very fast but I find it useful to me. Compared to the auto-trigger functionality, I sincerely doubt its usefulness to me. And I represented an alternative way to achieve a closer productivity with a prototype command: imap <buffer><expr><Space> getcurpos()[2] == 2 ? "<M-l>" : ' '.

[SirVer]

Thanks for the benchmark, data is always great. These numbers scare me a bit, that is factor 40x slower with auto-trigger. Is this with neovim or is this vanilla Vim?

@seletskiy I am afraid that auto-trigger might still be too slow. Do you have more ideas for improving the performance?

[bohrshaw]

@SirVer It's Neovim actually.
Is it _safe_ to do autocmd! UltiSnips_AutoTrigger? If so, then, regarding to code complication, it's more likely to be "0 or 1 code path" as opposed to "1 or 2 code path".

[seletskiy]

@BohrShaw: It's safe and you can do it in your vimrc.

Regarding neovim: it has it's own quirks. I have no problem in the original vim with :Time normal! @q:

• Without autotrigger: 0.007 seconds to run :normal! @q
• With autotrigger: 0.011 seconds to run :normal! @q

So, my guess that problem in the neovim, not in the autotrigger.

Regarding your note about usability side: it's soon becomes burden to make it work in cases autotrigger was designed to work with. Consider case: else snippet automatically expanded when user typing anything after closing bracket for if clause:

It's impossible to achieve using imap, because you need to remap all keys!

Also, autotrigger is not blindly expanding snippets, it can be used for checking arbitrary context, specified by python function. I guess you can see, how difficult will be imap syntax for that case.

Sorry for my stubborness. It's because I consider myself fast typist and I'm writing code pretty fast using UltiSnips + expand actions and autotrigger, so disabling autotrigger sounds like step backward for me.

BTW, what are you using such complicated macros with good amout of insertions for? I think, when we need to insert amount of text, we use snippets for it, not macros. Can you give realworld example, please?

[bohrshaw]

@seletskiy In my imap example, I just remap <Space> to the snippet trigger key in carefully defined situations, which is not auto-trigger at all. And in your example, it seems auto-trigger could sometimes do unintended triggering. Anyway, trigger-as-you-command manual-trigger is just one key away.

I see auto-trigger as a turbo-mode(fast and relatively expensive) which IMO should have the chance to be turned off.

[seletskiy]

@BohrShaw: Nope. Autotrigger can be and should be used in carefully defined situations. Given example above snippet definition goes like that:

snippet "}(.)" "else" "is_if_bracket(snip.buffer, snip.line, snip.column-1)" rebA
} else {
    `!p snip.rv = match.group(1)`$1
}
endsnippet

As you can see, snippet will be expanded only when user is typing char after
closing brace which is (1) at the beginning of the line (flag b); (2) related
to if statement (is_if_bracket python function return true)

So, it will not be triggered in the following situations (user is typing a):

for {
    // …
}a

{
    // …
}a

if {
    // …
} else {
    // …
}a

func ifBlah() {
    // …
}a

Autotrigger is the turbo-mode indeed, and if you have good set of
autotriggering rules, you will type single keys and code will appears like
magic. See first GIF in the thread. If you can write code faster that this,
I'll glad to see (no offense/negative, really curious).

In that case that excessive Tab makes the
difference. You can consider another example of writing SQL queries, where
syntax is pretty simple and context is trivial, so you can write complex
queries just by typing single keys, like a for ALTER.

To summarize the thread (@SirVer):

• autotrigger has performance hit only in neovim, which is, probably, has other
  issues with autocommands;
• autotrigger has insignificant performance hit in vanilla vim (0.007 vs 0.011
  in the timing above), so there is no need to disable it by default.
• autotrigger can be disabled by au! UltiSnips_AutoTrigger in .vimrc, so
  there is no need of adding option in UltiSnips.

[bohrshaw]

autotrigger has performance hit only in neovim, which is, probably, has other
issues with autocommands;

That's regretfully a pay in Neovim's plugin re-architecture. It's not related to auto-commands, but the plugin layer providing commands like :py, :pydo, etc. IMO, at least for now, _we_ adapting is the way to go.

autotrigger can be disabled by `au! UltiSnips_AutoTrigger`` in .vimrc, so
there is no need of adding option in UltiSnips.

There's a difference between "supported disabling" vs "a user hacker". And the initial aim of this issue is to figure out if auto-trigger could be optional, not how to disable it.

[seletskiy]

I know little about nvim. Do you know, is there easy way of tracking
changes without that performance hit in neovim? If so, I will be glad to
see how it can be done, and, probably implement it.

On the main topic let's wait @SirVer's final judgement. I made my point
pretty clear.
On Oct 26, 2015 7:49 PM, "Bohr Shaw" [email protected] wrote:

autotrigger has performance hit only in neovim, which is, probably, has
other
issues with autocommands;

That's regretfully a pay in Neovim's plugin re-architecture. It's not
related to auto-commands, but the plugin layer providing commands like :py,
:pydo, etc. IMO, at least for now, _we_ adapting is the way to go.

autotrigger can be disabled by au! UltiSnips_AutoTrigger` in .vimrc, so
there is no need of adding option in UltiSnips.

There's a difference between "supported disabling" vs "a user hacker". And
the initial aim of this issue is to figure out if auto-trigger could be
optional, not how to disable it.

—
Reply to this email directly or view it on GitHub
https://github.com/SirVer/ultisnips/issues/593#issuecomment-151138929.

[bohrshaw]

It's probably not viable as long as the trigger-pattern-matching logic is implemented in python.

[bohrshaw]

@SirVer Besides the performance's concern, I don't like to pay for what I don't use or possibly use periodically. A user's number of plugins would not scale if more plugins comes with a overburden. Compared to start-up performance, the after-start session is actually more important to keep it as lean as possible. Admittedly, you have more to think about.

[justinmk]

Consider opening a Neovim issue (at least for tracking) if there is a serious performance issue.

[SirVer]

@BohrShaw I agree with your statement that you should only pay for what you use if possible. However, Stanislav showed that the timings are not bad on vanilla Vim and NeoVim is not supported: Their change in the TUI and the flaky way of feeding keys into it makes it impossible to test it as I do on vanilla Vim, even after spending considerable time trying to get it to work. So I gave up on testing on NeoVim for now, which means it is not officially supported.

If you want to use UltiSnips with it, I suggest using what @seletskiy suggested earlier and simply disable the autocommand - that is not hacky in the least, it is a very sensible way of doing feature selection.

@justinmk I already did - at least a suggested API to fix the amount of work UltiSnips has to do. It has been closed for not fitting the current project focus: https://github.com/neovim/neovim/issues/174. Right now, I care very little, so I did not reopen it. I find the NeoVim project not focusing on the issues I care about, so I am not following its development anymore. I might look into supporting NeoVim again once it reaches a release.

[justinmk]

@SirVer You may be interested in the recently-merged https://github.com/neovim/neovim/pull/3413 which began work on refactoring Vim states to a finite automaton. Not sure if that precisely meets https://github.com/neovim/neovim/issues/174 but would welcome your comments.

Their change in the TUI and the flaky way of feeding keys into it makes it impossible to test it as I do on vanilla Vim,

"flaky" is a bit imprecise: we handle \x1b differently, that's it. BTW, instead of writing tmux tests you could choose to use the API, which I am guessing is what a test suite for swiboe would do :)

[SirVer]

@justinmk I do not quite understand what the K_EVENT is and as said until NeoVim settles on a stable release I will not try to keep up.

And I do use the API - unfortunately I do not get any feedback about NeoVim being idle, so I do not know when I can send the next keys. I tried slowing down the input to a trickle, but the test are still too flaky to be useful.

[justinmk]

@SirVer if timing was the issue, again https://github.com/neovim/neovim/pull/3413 may have fixed it, because Neovim now blocks async events during operator-pending (https://github.com/neovim/neovim/issues/3382). We are 3 days from 0.1 release, maybe you could run your test suite against current master...

[SirVer]

@justinmk It fails right now.

[timfeirg]

I tried adding au! UltiSnips_AutoTrigger to my .nvimrc, but vim and neovim both reports E216: No such group or event: UltiSnips_AutoTrigger on start up, am I missing anything here?

[lacygoill]

@timfeirg When your .nvimrc is sourcd, UltiSnips hasn't installed its autocmds yet. You must delay their removal until NeoVim has fully started. Try this:

augroup ultisnips_no_auto_expansion
    au!
    au VimEnter * au! UltiSnips_AutoTrigger
augroup END