Breaking changes

[occivink]

Should fix #13 and #14. Ping @jjk96 @andreyorst

Regarding #14, you can now do:

# expand the last trigger before the cursor, on the same line
snippets-expand-trigger %{
    reg / "%opt{snippets_triggers_regex}"
    exec 'Ghs<ret><space>'
}
# expand the first trigger in the entire file
def com2 %{
snippets-expand-trigger %{
    reg / "%opt{snippets_triggers_regex}"
    exec '%s<ret>)<space>'
}

And a snippet trigger can now by anything instead of just alphanumeric. So /\* is now valid.

Heads up, if you have if and elif as triggers, you should now prepend \b to if so that it won't expand before elif.

[andreyorst]

Sorry, but I don't understand how expand snippets with keyboard shortcut after these changes. snippet-expand-trigger no longer automatic and requires manual selection of the trigger. Why it is so?

In c filetype, after writing for and executing snippets-expand-trigger I receive an error message:

Error: 1:1: 'snippets-expand-trigger' 2:6: 'eval' 3:79: 'eval' 18:608: 'eval' 1:1: 'try' 3:19: 'exec' no selections remaining

However after selecting for and executing command again, snippet expands.

[occivink]

It was to make it more flexible. You can now expand at a different location than just directly before the cursor, by using snippets-expand-trigger like I mentioned in the opening. If you want the previous behavior you can use snippets-expand-trigger 'exec b' although that will only work with triggers that can be selected with b (like it used to be). We can expose pre-made commands for these if necessary

[andreyorst]

Ah, I didn't got that snippets-expand-trigger accepts parameter. For some reason I was misguided by first comment that it is now an option and snippets-expand-trigger-internal is a command.

[andreyorst]

hm. Now it has kinda different problem:

This happens because I've used this:

define-command snippets-expand-or-jump -params 1 %{
    execute-keys <backspace>
    try %{
        snippets-expand-trigger %{
            reg / "%opt{snippets_triggers_regex}"
            exec 'Ghs<ret><space>'
        }
    } catch %{
        snippets-select-next-placeholders
    } catch %sh{
        case $1 in
            ret|tab)
                printf "%s\n" "execute-keys -with-hooks <$1>" ;;
            *)
                printf "%s\n" "execute-keys -with-hooks $1" ;;
        esac
    }
}

It checked if we can expand trigger before cursor, and if not tried to jump. If jump isn't available it executed the key it was called with.

Seems I can live with snippets-expand-trigger 'exec <a-b>' but indeed it leaves me with only WORD matching.

[occivink]

Yeah, that's because for recursively expands itself, since the current call to snippets-expand-trigger looks for a trigger from the cursor to the beginning of the line. If you want expansion to be anchored to the cursor position you can use:

snippets-expand-trigger %{
    reg / "%opt{snippets_triggers_regex}\z"
    # select the 6 previous character and abort if it doesn't end with a trigger
    # \z makes it so the trigger must be anchored to the cursor to be considered
    exec ';h6Hs<ret>'
}

[andreyorst]

Thanks, I'll try it and see if it has significant advantages over exec <a-b>.

[JJK96]

Maybe this snippet should be in the documentation

snippets-expand-trigger %{
    reg / "%opt{snippets_triggers_regex}\z"
    # select the 6 previous character and abort if it doesn't end with a trigger
    # \z makes it so the trigger must be anchored to the cursor to be considered
    exec ';h6Hs<ret>'
}

I just tested a bit with this pull and I ended up using this:

snippets-expand-trigger %{
    reg / "%opt{snippets_triggers_regex}\z"
    exec 'hGhs<ret>'
}