Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
Welcome to the Intype forums diane.
Which ul snippet do you mean? There is one in the XHTML bundle, and to use it, your grammar must be set to XHTML. A paragraph snippet can be easily created, just do something like this in a new file in bundles\XHTML.itBundle\snippets:
{
content: '<p${1: class="${2}"}>${3:$SELECTED_TEXT}$0</p>'
title: '<p>'
scope: 'text.html.strict'
tab_trigger: 'p'
}
I’ve included mine as an attachment.
You can use the Textmate manual on snippets as a guide to creating new snippets. Variable names are different in Intype though. Remember to share great snippets! ;)
As far as the “is there anything in writing about the [...]” ... You can find an incomplete, not-up-to-date snippet guide in the following place:
C:\Program Files\Intype\doc\snippets.html
This assumes you let Intype install into the default installation directory.
I think I might write a simple script to update that HTML documentation…that ought to be fun (and recursively redundant!).
BrendonKoz: Yeah, I’m going to create Jasmine parser for Ruby, so we will be able to include actualized docs into release.
diane: Was the answer from idyllrain helpful? Have you set HTML or XHTML grammar before trying to test the snippet?
Haha.. I took too long to type my suggested solution and diane posted before me…
diane: I will admit, so far this has not been totally intuitive for me….
I concur. We’ll do some cleanup. I’d like to see the HTML bundle and the XHTML bundle merged together (like the current C and C++ bundle) since they share many common elements.
idyllrain: We’ll do some cleanup. I’d like to see the HTML bundle and the XHTML bundle merged together (like the current C and C++ bundle) since they share many common elements.
Yeah, I agree. There are a few others that could be merged.
I’m in the midst of rewriting the snippets of both bundles. I’ll look into the grammars after it.
And I’m rewriting the XML/XSL bundle grammar and snippet (I have questions doing it, I will soon start a new discussion about it).
I already wrote a DTD bundle and I’m planning to write an XPath and Xschema bundle. (Yeah I’m a kind of xml freak)
I also see a point where the XHTML grammar could/should extend the XML grammar.
But for all of that it would be great to have the bug fix release for the match/capture bug.
@daine: There’s also the Ctrl-W snippet “Wrap selection in open/close tag” that you can use as a shortcut to make any tag. Just hit Ctr-W, type ‘p’, [tab], then you’re on your way! This is a handy shortcut for those other tags that don’t have snippets, like li’s, dt’s, etc.
edit: This works in HTML and XHTML grammar
ccblaisdell: @daine: There’s also the Ctrl-W snippet “Wrap selection in open/close tag” that you can use as a shortcut to make any tag. Just hit Ctr-W, type ‘p’, [tab], then you’re on your way! This is a handy shortcut for those other tags that don’t have snippets, like li’s, dt’s, etc.
I refer you to this particular post. ;)
On the subject of missing tag snippets, is it a good idea to have all the tags represented in the snippets?
From a use ability point of view? Yeah, why not?
I don’t know about performance wise though – I guess it probably wouldn’t make much difference?
The snippets are compiled by Intype at first run or when we invoke “Reload bundles” i think. Huge amounts of snippets might degrade performance, although I haven’t tested this.
My concerns tho, aren’t about performance. Representing all language constructs in snippets will probably increase usability, but it might not be practical to have everything represented by snippets. Take the PHP language for instance, there are tons of pre-built functions; some are used fairly often, while others we’ve never used before (but this differs from web developer to web developer).
As bundle authors and maintainers, how do we draw the line on inclusion of something as a snippet?
I recommend that for programming languages, just include syntactic constructs as snippets. And for markup languages, to include all possible markup constructs. I am not entirely sure about my recommendation, I have arguments both for and against it… so I’ll put it up here for everyone to dissect and improve. :)
If you want to be picky about snippets, you’ll be treading very thin ice… For instance, just because we can doesn’t mean we should. Theoretically (and, truthfully) we, as HTML designers can produce really nice crap:
<b style="font-weight: normal; display:inline-block; color:#F00;
background: url('./images/something.jpg') #000 repeat-x top left;
height:120px; width:3em; text-transform:uppercase;">SuPeRmAn!</b>
There are things we can do and things we definitely shouldn’t do. With that being said, and still not really adding anything to this topic…
I really have no idea on the programming languages. I think the markup languages could be good to have everything…it’d be odd to have singular entities as a snippet though ( » « ©, etc…).
(nods) Precisely what I did back when I just learnt how to code webpages. Haha.
I think for entities we could just include the more commonly used ones, there’s simply too many of them to have snippets for each and every one of them. Although I believe that perhaps if insertion of HTML entities are done using plugins, it’ll keep everything cleaner. I don’t want to have huge multi-level menus under bundles.
I think a plugin for entities would be a good idea…it’d be like a character conversion plugin, so HEX, decimal, octal, ASCII, HTML-equivalents, (Unicode?,) and URL-encoded…I think that covers everything except multi-byte characters. That would be a useful plugin and could remove all the burden from the snippets, right?
Useful for web designers. :P
It’ll probably lessen the burden. We still need to get people to design snippets properly. For example, in the Ruby bundle, there is a snippet for “if … end” and another for “if … else … end”. These two snippets could just be combined into one. Actually, I believe that we shouldn’t even include the “else” clause in the snippet, as it doesn’t really take that much time to type it in the “if … end” block should we need it. Another example in the Ruby bundle are the “defd” and “defds” snippets.
I wish we had more opinions (I wish I had more time :() from programmers apart from WEB developers. I would hate to see Intype end up as the new version of HomeSite with SOME features for generic programming.
I would expect Intype to become as generic as possible with capabilities for extensions (whether that is Snippets, Grammars, Plugins or whatever).
It seems that almost everyone involved (community-wise) is a web developer!
Anyway I stop this here as it may sound as ranting which was not the original purpose. I just have the (bad) feeling that everything will turn into WEB-something and everyone not WEB-involved will have to migrate to another planet. (I am even getting off-topic now.. I think I should start a thread in off-topic with something related soon…)
Cheers (for now),
Nick
And Brendon was talking about a plugin, not a default feature of Intype. I don’t think there’s any danger that Intype will get too focused on web development; I’d like it to expand in all directions and I think it will, it’ll probably make life easier for hardcore C programmers as well as people who deal exclusively with HTML & CSS. It could even become an appreciated blogging tool among those that use something like Markdown or Textile to blog for example, if someone creates bundles or some general plugin for that stuff. And there could be a plugin for hex-editing and other more advanced things… There’s very few limits to what you can do with such a versatile base application.
1 to 21 of 21