Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
—————————
Here’s my rationale for suggesting these features. I learned web development on big IDEs like Dreamweaver that have code completion, so I became dependent on quickly typing things like “pad[enter]”, which would output “padding: ;”. Sometimes instead of typing “pad” though I would type “pa” or “padd” or even “padding” before I hit enter, but the program would always insert the correct text. I still type like that sometimes in lighter text editors and so I cause a lot of backspacing. It would be great to set up snippets with several triggers so that I could type any one of my idiosyncratic shortcuts and always get what I want.
For the second feature, I just don’t like the snippet popup menu. Most of the time when I type “margin” in my css file I am going to use the shorthand where I define all 4 margin sides in one rule, but in the Intype popup menu for the trigger “margin”, the 4-way shorthand is number 4 in the list. If it was number 1 I could just hit enter immediately and get that one. Besides them being in the wrong order (to me), I also don’t like scanning that list for the item I want each time. I know that with time I will get used to this, but it would be really cool if it was configurable.
Take a look at my very old thread about this: Snippet Conventions
But well yeah, I’m for these suggestions mainly:
Augh! I looked and looked for an older thread about this but I couldn’t find one!
Multiple triggers per snippet would quickly solve that whole “should css triggers be shortened or will that make it too hard” debate. Just have a longhand trigger and a shorthand one. Easy for beginners, but powerful for advanced users.
I just wonder if this fits in with martincohen’s vision for Intype. I saw one thread where he said he didn’t want to autopair brackets and such things partially because it would require another parsing thread…
edit: Ha, that’s another one of your threads :)
:)
They’re going to investigate autopairing as far as I understand, yes it will require additional parsing threads but they haven’t dismissed it just because of that. This feature looks like it’s going to be scoped so that you can specify in which languages/scopes it will be active and also specify which characters should be autopaired in which scopes.
As for having multiple tab triggers per snippet, I think it’s also come up before and the developers either confirmed it or at least didn’t dismiss it, I don’t quite remember.
I must scour the forums again! I must find where the developers acknowledged this feature request!
I’ve become a little obsessive about this feature in the past 24 hours.
edit: Aha, here it is . Martin Cohen wants to add a tab_trigger_match property to the snippet syntax to match triggers with regexs. Cool!
Yeah, now I remember…
1 to 6 of 6