On May 21, 2005, at 2:04, Charilaos Skiadas wrote:
I find that I rarely make it through a multi-part snippet without doing something that breaks me out of snippet-tab-mode. Then I fill in the rest of the snippet template by navigating to the pieces in the usual way. Maybe I just have an unusually short attention span, or I am an exceptionally erratic typist, not sure.
I also cannot work with a snippet that has more than two tabs, and that's already too much :-)
Yeah, I also think for those 3+ argument snippets, it's often easier to collect the information first, and then say: make the proper boilerplate given this stuff I just collected for you! I've seen a few snippets with a non-linear flow through the snippet, that stuff throws me off ;)
To this end, I'd like to see Allan add the ability to create categories and subcategories of snippets that result in menus/ submenus if snippets. IMHO the snippets menu is useless for languages like Actionscript and OCaml because there are too many entries (screens of them)
OCaml turns out (after sorting) that this is completions for a lot of known functions for most objects, so here you'd never use the menu. But eventually I do plan to provide a way to structure these things into groups etc.
I think this is a great idea. The way things are, I'm afraid to add too many snippets so as not to overload the menu.
The important thing IMHO is to choose tab triggers in a way that makes them easy to remember, that way the menu really shouldn't be used. Often this means going with the full word of what to insert rather than some abbreviation, because the former is easy to remember (afterall, that's what the user wants to insert), where the latter is rather arbitrary (so only for stuff that's used a lot, should that be used, and since how to abbreviate is a personal preference, it probably makes sense to leave this to the user to do, when he starts to get confident with using snippets).
It also makes sense to try to use the same tab triggers accross languages, of course this does require some coordination, but going into a new language and being able to simply type function<tab> to get the proper way to define a function in that language would be a nice help :)
Btw, how much of a concern is the size of the bundle? Does adding a lot of snippets affect performance? If not, then I could try to add as many LaTeX commands as snippets as possible, or at least commands I think are likely to be often used.
After I started to load bundle items in a separate thread, I think the performance considurations are negligible (also, I'll probably switch to lazy loading using a cache of scope+activation per item in the future, so that I won't have to do any loading before the item is called upon).
So the main concern is perceived complexity.
Here's the one that annoys me the most: (and I've just now figured out how to fix it since I've been writing this email :-) )
[snip]
Now, I've modified my copy of itemize to be: \begin{itemize} \item ${0:premier item} \end{itemize}
Now things behave like I would like them to. I think I'll commit this new itemize, and fix up the other list making environments as well.
This sounds more appropriate to me too.
I've been bitten by that as well! :) I'm not entirely sure I want return to leave a snippet/placeholder -- when I do support nested snippets, it will work as expected even in the first form, so that might be the better workaround.
(btw, command-return is bound to <br /> in html. Do we really want that?)
No -- I've changed it to control-return now, which is consistant with control-space to make a tag pair. I've also added a control-return snippet for the source scope which inserts “\n”.