Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
Install: Just delete both the HTML.itBundle folder and XHTML.itBundle folder. Then just unzip this into your bundles folder.
Features:
So, please test and help me improve them! :) There is one other thing on my TODO list for the snippets, and that is to have correct snippet scoping. That means that you won’t be able to tab-trigger-activate the <base> snippet while you’re in the <body> tags for example. :)
These snippets listed below support wrapping selected text:
Abbreviation, Acronym, Address, Big Text, Blockquote, Body, Boldface Text, Caption, Citation, Code, Definition, Definition Description, Definition List, Definition Title, Deleted Text, Div, Dropdown List, Dropdown Option, Dropdown Option Group, Emphasis, Fieldset, Frameset, Heading, Hyperlink, Inserted Text, Italicized Text, Keyboard Text, Label, List Item, Mailto Link, Monospaced Text, Named Anchor, No Frames, No Script, Ordered List, Paragraph, Preformatted Text, Quotation, Sample Code, Small Text, Span, Strong Emphasis, Subscript, Superscript, Table, Table Body, Table Cell, Table Column Group, Table Footer, Table Header, Table Header Cell, Table Row, Text Direction, Textarea, Unordered List, Variable, Wrap Selection In Comment, Wrap Selection In Tag
Found bugs and squashed it.
This. Is. So. Great!
Also, I am an apple juice addict – how did you know?!
Thanks!!
dflock: Also, I am an apple juice addict – how did you know?!
Hahaha.. now that’s a nice coincidence! I’m addicted to apple juice too…
Great, but for the Wrap Selection In Tag, I would rather use something like
{
title: 'Wrap Selection In Tag'
key_equivalent: 'Ctrl+/'
scope: 'text.html'
content: '<${1:p}${2: id="${3:p}"}>${SELECTED_TEXT}</$1>$0'
}
Because otherwise I cannot easily put attribute in the tag.
Try selecting something and pressing Ctrl+/, then type the tag name (like “div”) but
now if you want to put an id on that div, you cannot press [SPACE]id=“myid”, otherwise it will go in the closing tag…
Another solution would be to change $1 at the end to only take the first ‘word’ (before the first space)
What do you think about this?
ok I found how to do the other solution, here it is:
{
title: 'Wrap Selection In Tag'
key_equivalent: 'Ctrl+/'
scope: 'text.html'
content: '<${1:p}>${SELECTED_TEXT}</${1/([^ ]+).*/$1/}>$0'
}
:) Thanks for the feedback!
I’ve integrated the alternative solution into the bundle. I changed the character class to (\w+) so that it’ll only match alphabets and numbers.
The attachment bundle has been updated as well.
You should also consider the ‘:’ character in the match if you want to handle namespace (like in <myns:mytag id=“1”>blabla</myns:mytag>)
Oops, forgot about that…
Great improvements idyll!
what about-
<br /> and space?
What about them?
If its concerning the space before the trailing slash, please read the W3C Recommendation on XHTML, particularly this ;)
idyllrain
He means ctrl+enter and shift+space shortcuts for <br /> tag and  
He does? I don’t know, what he says can mean both…
We’ve already discussed about the shift+space shortcut in this thread . On the ctrl+enter shortcut, do we really use it that often that it justifies a key equivalent shortcut? It’s not that hard to type br and then press tab.
i use br all the time…
maybe <br /> gets used a lot if all you do is write poems, lyrics or addresses in xhtml every day, but, other than that, its not semantically correct.
it is a common by-product of wysiwyg generated content, due to people pressing the shift+enter combination, and thats the way it should stay imho. the <br /> tag shouldn’t be used often enough to warrant its own shortcut, and, in providing one, we would only be promoting its use.
there are many alternatives for creating the visual linebreak effect, where it does not affect the semantics of the content. A few demonstrations:
<p>some text with</p>
<p style="margin-top: 0">some other text on a new line</p>
<pre>my freely line
breakable text or code</pre>
<p>
lorem ipsum...
<span style="display: block">read more</span>
</p>
My two (insert coin here).
prozente: The editor should only be a tool and it shouldn’t inhibit the coder from writing as he/she sees fit.
Yes. But we can’t have anything and everything. At one point, you’ll have to choose between correctness and convenience. On the <br /> issue, I’ve decided to follow current best practices in the web development field. I hope that the snippets I’ve designed are as close to this aim as possible while balancing the need for to cater to the majority.
Anyhow, the snippets are freely modifiable. If you use the <br /> tag all the time, then just go and assign a key_equivalent to it. I will only make commit changes that are due to my own oversight or if the majority of the users request it.
prozente: the reference you posted is for a draft of a new specification, that’s not one of the HTML or XHTML specifications.
Correct. I understand that we only code for today’s specifications, although I found the examples and explanations to quite cleary reflected, what in my opinion, is proper use of the <br /> tag. You may find this old article, on some of the changes we may be facing when XHTML2 comes out, quite relevant.
prozente: The method used in writing code isn’t the job of the code editor to decide if it’s right or wrong. The editor should only be a tool and it shouldn’t inhibit the coder from writing as he/she sees fit.
True, I see your point there. Indeed, it isn’t our job to dictate how one should code, or to assume one’s opinions on things like semantics, compliance and accessibilty. Although, one does need to take such things into consideration during development of the tool, to be convinced that the tool is taking the correct approach.
idyllrain: At one point, you’ll have to choose between correctness and convenience.
I like how you compare correctness and convenience. That is basically the point I was trying to convey. Do we need a shortcut because its convenient, or because it is correct?
1 to 20 of 20