[TxMt] Nested snippets

[Allan Odgaard]

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”.