How to fix erb tag in Atom from requiring a space to tab-complete?
@Rockster160 asked this on stackoverflow:
Up until about 2 versions of Atom ago, doing
h={tab}would autocomplete intoh<%= %>. Obviously this still happens now, however for some reason it is required that the "=" be after a space. Example:
hello={tab}Does NOT autocomplete to
hello<%= %>Which is the desired syntax. Instead, you have to do
hello ={tab}=>hello <%= %>and then click/arrow over and delete the space. This is very annoying. I've gone into the Snippets assuming this was just a typo and the "=" was accidentally prepended by a space... However as far as I can tell the Snippet is written correctly and this is just a bug? Does anybody know of a way to fix this?
For clarification, most of the other snippets have no issue working up against any character. It seems to only be
={tab}/-{tab}.
Any ideas why that is the case and how it can be fixed? Would be very much appreciated!
Thanks for posting this up here, @wdspkr! I would love to see this get fixed. You never realize how much you use something until it is gone. Haha.
This doesn't seem to be an issue in the current version:

Just updated and tried it. It works for letters now, but not other characters.
Try wrapping it in quotes, a common use for dynamic HTML classes. "={tab}" does not work, while " ={tab}" does.
More importantly (for me at last) is that it works after the closing > in a case like this:
<b>={tab}</b> expands to <b><%= some_var %></b>
Which it does not right now. :disappointed:
Provided a fix in 5ca3b9cff0ac6e4be3389b40a98f8b076f85f274
The fix is only for ERB blocks after > and ". Let me know if there are other cases that should be there. It doesn't seem like snippets can take wildcards or regex as a prefix/trigger, or at least I don't know how to do it - that would be the way to make a general solution.
FWIW, after a bit more digging, I see that the rails-snippets package contains a very handy Shift-Command-'.' (Technically Command-'>') to insert and toggle through ERB tags, which works regardless of preceding character and is another alternative to consider.
That's awesome, @mamenama! However, still has an underlying/residing issue.
First off, your solution doesn't work in this very common situation: <(div/a/whatever) (class/href/whatever)="">={tab} as well as a few other similar situations. (Including being in the middle of other snippets, but that's an awkward workaround.)
I wound up creating a bunch of custom snippets that alter the behaviors of these situations in order to get a bunch of these to work. I'm happy to post them if others are interested, but they are quite hacky. :P
Ugh, yeah. This seems to stem from the snippets package not playing nice with symbol prefixes, which I am at a loss how to fix - requires delving into the snippets package code rather than just the ruby grammar.
Changing the = and - to something alphabetical (e.g. erband erbe) seems to fix the problem even in the case you mention. However, I'll leave it to folks more in the know to make that call (I'm not sure what the 'standards' are for changing things that break previous snippets. I suppose you can just add them as alternative synonyms but that 'seems messy'). You can also just add the alphabet-named ones as custom snippets in your own snippets file.
It looks like this same issue has been brought up in the snippets forum as atom/snippets#151
Like you and that other issue mentioned, it seems to be caused only if there are multiple special characters lined up. So what I did is create snippets that actually include the special characters. (">={tab}, ="">={tab}, etc....) I actually made 7 extra snippets (+ 2 overrides to stop tag snippets from having second arguments) in order to account for all of the cases.
After some wrangling and loss of sleep, this seems to be deep down an issue with the way snippets work - they are not supposed to auto-complete items if they are part of a word. There just so happens to be a bug in cursor.wordRegExp that defines word boundaries between stretches of word characters and stretches of symbol characters, hence h= works but >= does not.
However, there is work going on in atom/atom#8906 to fix word boundary definitions in cursor.wordRegExp w.r.t. special characters that will likely result in breaking the h= rather than fixing the >= case (in order to be consistent with other snippet behavior). If this is undesirable, then the snippets code needs to be patched to handle this kind of case.
The 'easy' fix is to add the special-case snippets as separate cases or use rails-snippets. But that covers up the underlying issue and, frankly, is just too easy. :wink:
Good man going through all that work. I came to the same conclusion with a lot less work (and, likewise, a lot less confidence or ground to back it up). I'm interested to see how they fix it, but until then, let's get patchy! :D
Same issues here works for letters, not let's say $$.