-
Notifications
You must be signed in to change notification settings - Fork 102
Feature request: Allow tab triggers to invoke commands #221
Comments
Closes #26 These snippets are really like "start me out with a template", they aren't intended to be used in the middle of an existing document. As such, it's very common to try expanding them in a new window, before setting the language to Ruby. There is no visual information that it's wrong in this case (ie missing syntax highlighting), so it just looks like SiB is broken. I could blame the user, but this is bad UX on my part, I should treat them like templates rather than snippets and just make them always available. The risk of collision is mitigated since the names are all likely to be unique. It would be really nice if, after expanding, we could set the language to Ruby, just in case the user did do this, we now know that the lang should be Ruby, so take care of that for them instead of requiring them to realize the highlighting is off, figure out why and figure out how to change it (eg a lot of users save the file because it has this same filetype inference behaviour and they don't realize they can just set it in the editor). This is the second time today I've wanted some behaviour like this, I opened an issue requesting the ability to do it at atom/snippets#221
Needs to be cleaned up, this was just to see if it is possible, which it is. I'm committing it on a branch to maybe prompt consideration in the snippets package. It seems like maybe the way to do this for real would be for the snippets package to emit an event for did-expand-snippet. Though I don't fully grasp how all the pieces fit together. For context, see: #25 atom/snippets#221
FWIW, I was able to hook into snippet expansion (a proof of concept) by observing the "snippets:expand" event and then checking if the scope matched and one of the cursors was just after the snippet I was interested in: https://github.com/JoshCheek/atom-seeing-is-believing/blob/fb62dcc243a34c9376d92e4d5b4c38eb8eb36b5a/lib/seeing-is-believing.coffee#L53-L64 This is just a proof of concept, but it illustrates that an evented approach could work well here (in terms of allowing extensibility and decoupling). Perhaps if the snippets emitted a 'did-expand-snippet' event, then other packages could register to be invoked after certain snippets got expanded? IDK, just musing :) |
This feels like a variant of the problem I described here. In TextMate, there are commands and there are snippets; and each can be invoked by a tab trigger or by a keystroke. In Atom, commands get invoked by keystroke and snippets get invoked by tab trigger. You can invoke a snippet by keystroke by inserting the snippet programmatically (or expanding it programmatically), but invoking a command by tab trigger is a harder problem. The solution feels like it ought to be to make tab triggers be something that Atom core understands, rather than just a concept invented by the snippets package. But that's a lot of work. Just thinking out loud here. |
JoshCheek/atom-seeing-is-believing#25 was opened against my package, thought I'd play around and see if I liked anything. However, it doesn't look like there is any way to do it.
Here are some ideas for what it might look like:
Take action other than expand/tabstop-cycle
With this approach, pressing tab the second time evaluates the file instead of expanding (ie the action to take becomes configurable and defaults to the current behaviour of expansion/tabstop cycling).
A second argument for this approach is that it might handle the decision to expand / tabstop-cycle better and not require the two keymap registration files with the comment to explain them.
Hook into snippet events
This one is probably easiest, it's the same behaviour as presently exists, but it lets the user set a callback.
The text was updated successfully, but these errors were encountered: