I find this macro quite useful, but it has some quirks (I think). First, I love how it takes img tags and makes them <img /> rather than <img></img>. When I apply it on a li-tag, and then hit enter, I get a nicely formated line break with a tab indentation <li> | </li>
but when I do the same on a h1 tag, the result becomes <h1> |</h1>
How, why, fix, please et cetera.
Andreas
On 25/09/2005, at 11.39, Andreas Wahlin wrote:
[...] but when I do the same on a h1 tag, the result becomes
<h1> |</h1>
This isn't the macro. The macro is just a regexp replace on the current word to <$1></$1>, though catching those tags w/o closing tag and using a condition in the replace string -- Michael Sheets has flirted with the thought of looking up the tag name and insert a customized snippet instead.
As for the extra indent and newline, this is done by having the HTML language grammar match a select set of open/close tag pairs (those which were part of the increase indent pattern) -- the rule is meta.tag.html, and it should be quite easy to add more tag names (or even make it a catch-all instead).
The rule assigns a special scope to the position between the two tags (meta.scope.between-tag-pair.html) and then the “Smart return/indent for tag pairs” snippet is set to insert the extra indent + newline, assigned return as key equivalent, and have the scope set to “meta.scope.between-tag-pair.html”.
So that's how this smart newline + indent is achieved for <tag></tag> pairs.
This isn't the macro. The macro is just a regexp replace on the current word to <$1></$1>, though catching those tags w/o closing tag and using a condition in the replace string -- Michael Sheets has flirted with the thought of looking up the tag name and insert a customized snippet instead.
I rather thought so, my opinion is that all inline tags (p, span etc) should NOT have this behaviour, while all block should. hehe, which, when I think about it, is probably true, since h1 isn't a block level element as far as I know :)
Andreas
On Sep 25, 2005, at 3:25 PM, Andreas Wahlin wrote:
This isn't the macro. The macro is just a regexp replace on the current word to <$1></$1>, though catching those tags w/o closing tag and using a condition in the replace string -- Michael Sheets has flirted with the thought of looking up the tag name and insert a customized snippet instead.
I rather thought so, my opinion is that all inline tags (p, span etc) should NOT have this behaviour, while all block should. hehe, which, when I think about it, is probably true, since h1 isn't a block level element as far as I know :)
It is. P is also a block level element. Anything that forces everything after it into the next line is a block level element. But, CSS can force anything to be anything. Haha ... i shall force all my span tags to behave like tables!!!!
-
Allan Odgaard -
Andreas Wahlin -
thomas Aylott