Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Feature request: Allow tab triggers to invoke commands #221

Open
JoshCheek opened this issue Oct 28, 2016 · 2 comments
Open

Feature request: Allow tab triggers to invoke commands #221

JoshCheek opened this issue Oct 28, 2016 · 2 comments

Comments

@JoshCheek
Copy link

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).

'.source.ruby':
  'Add SiB annotation':
    'prefix': '#'
    'body': '# => '
  'Evaluate SiB annotation':
    'prefix': '# => '
    'action': 'seeing-is-believing:annotate-magic-comments'

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.

'.source.ruby':
  'Add SiB annotation':
    'prefix': '#'
    'body': '# => '
    'after-expand': 'seeing-is-believing:annotate-magic-comments'
JoshCheek added a commit to JoshCheek/atom-seeing-is-believing that referenced this issue Oct 28, 2016
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
JoshCheek added a commit to JoshCheek/atom-seeing-is-believing that referenced this issue Feb 4, 2017
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
@JoshCheek
Copy link
Author

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 :)

@savetheclocktower
Copy link
Contributor

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.

@savetheclocktower savetheclocktower changed the title Feature request: Allow custom behaviour Feature request: Allow tab triggers to invoke commands Oct 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants