The Tab key is kept mapped to SparkupNext, even after all placeholder positions have been completed #22

Closed
nvie opened this Issue Oct 4, 2010 · 2 comments

Comments

Projects
None yet
2 participants

nvie commented Oct 4, 2010

The Tab key is overused by a few plugins I use to edit HTML (Supertab, Snipmate, ...). While I appreciate Sparkup to map the Tab key to cycle through all of the Sparkup placeholder positions, I would also appreciate if it put the original mapping of the Tab key back in place when the "filling" of the placeholders is completed. Instead, the Tab key is kept mapped to :call <SNR>68_SparkupNext() until eternity, effectively disabling my other plugins.

Can Sparkup "detect" that the last placeholder position is filled and then remap the Tab key to whatever mapping was active before Sparkup was triggered?

peterk commented Jan 6, 2012

Agree! Or provide an option to disable the tab key for cycling (e.g. only use ctrl-n).

@ghost

ghost commented Mar 2, 2015

First off, it seems that Sparkup no longer has Tab as the default caller of SparkupNext(), so that's a plus. However, there's more to it.

There are two ways you can fix this behavior: Disabling keybindings for Sparkup, or explicitly setting some mappings in your .vimrc file. I'll cover both.

Disabling Key Bindings

Sparkup won't bind anything to keys on its own if you add let g:sparkupMaps = 0 to your .vimrc file. All that will remain are insert-mode mappings that you can still call with <SID>Sparkup() and <SID>SparkupNext(). This will get Sparkup out of the way, but still allow you to use it. No guarantees that field jumping will work, however.

Custom Mappings

Sparkup has two mappings you can set: g:sparkupExecuteMapping and g:sparkupNextMapping. They accept the typical key abbreviations such as <C-n>, <Tab>, etc. (more details in the source)

As a side note, there's also g:sparkupMapsNormal, which allows mappings to be set in Normal mode instead of Insert mode.

Can Sparkup "detect" that the last placeholder position is filled and then remap the Tab key to whatever mapping was active before Sparkup was triggered?

The plugin code is pretty simple in that regard. All it really does is send the line to sparkup.py, return its output, and look for spots to jump to. It uses the basic search to find these fields, and there's not much opportunity to conditionally disable keybindings, since you need them between SparkupNext() calls. The only way I can see to fake this is to create a binding for a new function named SparkupDone() whose only job would be to reset the mapping. The problem is automating it. Sparkup's current design prevents context-aware field jumping, so the above tips are the best I can offer you. For Sparkup to support this, it'd need to be aware of how many jumpable fields there are and keep track of how many times SparkupNext() is called. It might be possible, but I wouldn't count on it.

ghost closed this Mar 2, 2015

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment