In the HMTL bundle, and in the XHTML bundle as well, there are snippets like this:
<h1>${1:`echo $TM_SELECTED_TEXT`}$0</h1>
activated via a tab trigger, "h1" in this case. I am completely missing the point here. Why is the echo command there? How can there possibly be a selected text when activating through a tab trigger? The way it is right now, if I type h1, press tab, type my heading, and press tab again, the heading is selected. Was that the intended behavior? If so, could someone give me an example of how this is usefull? I haven't played much with html, so I might just be missing something obvious here. If this is not the intended behavior, should we change all those snippets to simply <h1>${1:heading}</h1>$0, or <h1>$0</h1> ? Are these snippets redundant in the presence of Ctrl-space, and if so would it make sense to have them have a slightly richer outcome, like <h1 class"$1">... ?
Ok, enough questions for now, Haris
On 21-05-2005 22:28, Charilaos Skiadas wrote:
In the HMTL bundle, and in the XHTML bundle as well, there are snippets like this:
<h1>${1:`echo $TM_SELECTED_TEXT`}$0</h1>
activated via a tab trigger, "h1" in this case. I am completely missing the point here. Why is the echo command there? How can there possibly be a selected text when activating through a tab trigger?
There is of course always the menu you can use to activate the snippet, in which case it would work. Or through some other hotkey.
The way it is right now, if I type h1, press tab, type my heading, and press tab again, the heading is selected. Was that the intended behavior? If so, could someone give me an example of how this is usefull? I haven't played much with html, so I might just be missing something obvious here.
That's a bug with the tab-trigger placements. There has to be a seperator character between the end of ${1:...} and $0 (or $1 and $0).
If this is not the intended behavior, should we change all those snippets to simply <h1>${1:heading}</h1>$0, or <h1>$0</h1> ? Are these snippets redundant in the presence of Ctrl-space, and if so would it make sense to have them have a slightly richer outcome, like <h1 class"$1">... ?
Adding $0 to the end is not necessary. And I don't think the <h1>$0</h1> one has much value over the ctrl-space combo. So perhaps a bit richer might be useful. But I'm guessing this snippet is mostly aimed at the inexperienced developer or for wrapping a tag around some selected text later.
Speaking of which, would there be some way of wrapping a selected text in an arbitrary tag? I know I frequently run into that.
Jeroen.
On May 21, 2005, at 4:44 PM, Jeroen van der Ham wrote:
Speaking of which, would there be some way of wrapping a selected text in an arbitrary tag? I know I frequently run into that.
There's a "Wrap selection in tab" snippet in the HTML bundle, bound to shift-control-w. Is that what you mean? Right now it does the following:
<${1:p}>`printenv TM_SELECTED_TEXT|sed 's/$/\$/g'`</${1:p}>$0
I am wondering maybe it would be more helpful if it was:
<${1:p} $2>`printenv TM_SELECTED_TEXT|sed 's/$/\$/g'`</${1:p}>$0
so that people can add attributes to the tag.
Haris
On May 21, 2005, at 4:44 PM, Jeroen van der Ham wrote:
There is of course always the menu you can use to activate the snippet, in which case it would work. Or through some other hotkey.
Right, I keep forgetting there are people who like using menus and the mouse. :-) I just realized that a snippet could have both a key equivalent and a tab trigger. Maybe then it would make sense to also bind all those snippets to the same key equivalent, maybe in fact Ctrl-Shift-W, in addition to their tab triggers? This way the user can select the text, and then get to choose from a nice list of all the tags they might want to wrap that text around, or to chose to use a custom tag.
Unless the option of having both a key equivalent and a tab trigger for snippets was not the intended behavior/feature, but instead a bug.
Haris
On May 22, 2005, at 0:10, Charilaos Skiadas wrote:
I just realized that a snippet could have both a key equivalent and a tab trigger. Maybe then it would make sense to also bind all those snippets to the same key equivalent, maybe in fact Ctrl-Shift- W, in addition to their tab triggers?
I think that would degrade the current “Wrap selection in tag” snippet. Tags are generally 1-4 letters, so having to actually select the tag from a list would require more key presses than just entering the tag name (after doing ctrl-shift-W).
The thing about ${1:...}$0 is clearly a bug. The reason for putting the selection inside is probably because these were all made from the same copy, and then a user who does use one more than the others, could give it a key equivalent.
The actual necessity of these snippets is indeed questionable with the ctrl-space macro. Though some do seem to expect them, and it isn't more than a few days since someone complained that these were missing in his version ;)
As for changing the general “Wrap selection in tag” snippet to make room for an argument, I personally wouldn't like that. Although my production of HTML is more or less limited to what I put on my blog, and here I just need to wrap text in p, tt, b, code, pre, em etc. The only time I need an argument is for when I make links, and here I have the “Link using selection” (ctrl-shift-L). I should probably update it though (I initially did it when writing the documentation, which is why it assumes the current word is a page.html).
Personally I've always seen the default stuff more as a good starting point and inspiration than actually trying to cater to evrybodys needs. The idea with TM is that you setup the stuff how you prefer it, rather than adapt your working patterns to how it is setup by default. That's one of the reasons why I try to make this is easy as possible for the user to edit! :)
Maybe then it would make sense to also bind all those snippets to the same key equivalent, maybe in fact Ctrl-Shift-W, in addition to their tab triggers? This way the user can select the text, and then get to choose from a nice list of all the tags they might want to wrap that text around, or to chose to use a custom tag
As one data point, more often than not I write HTML text and then realize I have to style it a certain way. So the functionality you're talking about is pretty crucial to me. In fact, I've just written my own little macros to wrap text and have been staying away from tab trigger snippets. I didn't fully realize you could wrap text with snippets. Go figure.
best, Eric --- Eric Hsu, Assistant Professor of Mathematics San Francisco State University erichsu@math.sfsu.edu http://math.sfsu.edu/hsu
On May 21, 2005, at 5:45 PM, Allan Odgaard wrote:
On May 22, 2005, at 0:10, Charilaos Skiadas wrote:
I just realized that a snippet could have both a key equivalent and a tab trigger. Maybe then it would make sense to also bind all those snippets to the same key equivalent, maybe in fact Ctrl-Shift-W, in addition to their tab triggers?
I think that would degrade the current “Wrap selection in tag” snippet. Tags are generally 1-4 letters, so having to actually select the tag from a list would require more key presses than just entering the tag name (after doing ctrl-shift-W).
Good point. I'd rather have ctrl-shift-w work right away too.
The thing about ${1:...}$0 is clearly a bug. The reason for putting the selection inside is probably because these were all made from the same copy, and then a user who does use one more than the others, could give it a key equivalent.
The actual necessity of these snippets is indeed questionable with the ctrl-space macro. Though some do seem to expect them, and it isn't more than a few days since someone complained that these were missing in his version ;)
As for changing the general “Wrap selection in tag” snippet to make room for an argument, I personally wouldn't like that. Although my production of HTML is more or less limited to what I put on my blog, and here I just need to wrap text in p, tt, b, code, pre, em etc. The only time I need an argument is for when I make links, and here I have the “Link using selection” (ctrl-shift-L). I should probably update it though (I initially did it when writing the documentation, which is why it assumes the current word is a page.html).
Then how about two snippets, a "Wrap selection in tag", and a "wrap selection in tag with attributes"? Or perhaps an alternative to ctrl-space, which would allow you to enter an attribute too? I guess most of my html needs involve working on my homepage, and I find myself more often than not having to add an attribute to each tag, usually an id or a class. But I guess that's what the regular snippets are, if you customize them a bit, which as you say is more of a personal taste. Though I do personally think that a generic "tag with attribute" snippet/command would be useful. But I guess this does depend a lot on how one uses html.
Personally I've always seen the default stuff more as a good starting point and inspiration than actually trying to cater to evrybodys needs. The idea with TM is that you setup the stuff how you prefer it, rather than adapt your working patterns to how it is setup by default. That's one of the reasons why I try to make this is easy as possible for the user to edit! :)
And that's indeed what I love about it! It's the first editor I found extremely easy to customize to my needs. I must try to remember though, that my needs and workflow are different than other people's. It might be a good idea maybe to have a page on the wiki, where people can write tutorials on how they've accomplished various things with snippets. Having lots snippets available is pretty convenient, but for some users having an explanation of what the various pieces of a snippet do might be more helpful, especially when they involve shell commands. IIRC, Eric started a page on shell tricks, though I haven't seen it used much. Maybe a similar thing for snippets, to augment the segment in the help file? Just a thought, no idea if anyone would be interested in it.
Haris
-
Allan Odgaard -
Charilaos Skiadas -
Eric Hsu -
Jeroen van der Ham