[Geany] The plugin - Re: Use snippets for HTML autocompletion?

[Eugene Arshinov]

On Fri, 12 Nov 2010 12:51:48 +0000%
Nick Treleaven <nick.treleaven at btinternet.com> wrote:

> On Thu, 11 Nov 2010 21:46:51 +0300
> Eugene Arshinov <earshinov at gmail.com> wrote:
> 
> > > > > I'm not sure these are necessary, particularly
> > > > > editor_get_snippets_for_file_type - I don't want to expose the
> > > > > snippet data structures unnecessarily. Perhaps
> > > > > editor_find_snippet(doc, snippet_name) instead?
> > > > > 
> > > > 
> > > > The reason why I decided to export a hash table is that it
> > > > allows a plugin to decide independently whether to account
> > > > "default" snippets or just use the ones specified directly for
> > > > the filetype (I must note that there is currently no separate
> > > > function to get the default snippets, and relying on the fact
> > > > that one can get it by passing "default" as filetype name is
> > > > really bad).  If we provide a function like
> > > > editor_find_snippet, we need to fix the behaviour in it or add
> > > > a boolean argument.  Now I think, the latter is the best
> > > > choice.  Your opinion?
> > > 
> > > Do plugins need to look up a default snippet?
> > 
> > Currently no.  And when such a plugin appears, we can always extend
> > the API.  It seems to be another reason to keep it simple and use
> > editor_find_snippet(doc, snippet_name).
> > 
> > > 
> > > Anyway perhaps editor_find_snippet(snippet_name, ft) is more
> > > flexible. Perhaps passing NULL for ft could lookup a default
> > > snippet, if that's necessary.
> > > 
> > 
> > Yes, I think it's a good alternative to additional function
> > argument.
> 
> Great, then we can still change snippet implementation if we decide to
> without breaking the API.
> 

I attach the updated patch.  It contains all the changes in Geany
necessary for the plugin, and a corresponding Changelog entry.  Seems
that I fixed all the issues we discussed.

> > > > > I'm not sure about having snippet names enclosed in <> angle
> > > > > brackets in snippets.conf, maybe.
> > > > > 
> > > > 
> > > > I explained it a bit in the documentation (geany.txt): "It
> > > > allows you to define snippets, which need not to be
> > > > automatically inserted, without any name clashes".
> > > 
> > > Ok, but I'm not keen on distributing <tag> snippets with Geany, it
> > > just seems ugly having some 'tag' snippets, some '<tag>'. I see
> > > the reason though.
> > > 
> > 
> > Ah, again I missed something.  If in the plugin I use 'tag', the
> > plugin will automatically support 'table' snippet included in Geany
> > since recently.  I think it's more important than preventing name
> > clashes, so it's probable worth changing to 'tag'.
> 
> Name clashes could be important though, in case the snippets are
> meant for JavaScript. One idea could be to check if the first char of
> the snippet body is '<'.
> 
> To do that, editor_find_snippet should return the snippet body.
> 

In [HTML] section I have a snippet

  lia=<li><a href="%cursor%">%cursor%</a></li>

It begins with a tag, so the plugin will insert it after I type <lia>
(it will result in <lia><li><a ...>...</a></li> which isn't useful).
Obviously I will never type <lia> intentionally, but still it isn't
nice.  As we decided that it's necessary for the plugin to catch up
Geany's snippets, we have only two options: to ignore this issue or to
think of a better check.  Currently I have no ideas, can you suggest
some?

Best regards,
Eugene.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geany.25.xmlsnippets_functions.r5380.patch
Type: text/x-patch
Size: 28549 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/users/attachments/20101113/a22bee0d/attachment.bin>