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

Eugene Arshinov earshinov at xxxxx
Tue Nov 16 16:06:59 UTC 2010


On Tue, 16 Nov 2010 19:01:41 +0300%
Eugene Arshinov <earshinov at gmail.com> wrote:

> On Tue, 16 Nov 2010 15:12:32 +0000%
> Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> 
> > On Sat, 13 Nov 2010 12:44:03 +0300
> > Eugene Arshinov <earshinov at gmail.com> wrote:
> > 
> > > > > > 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.
> > 
> > Applied, thanks.
> > 
> > BTW your implementation of editor_insert_snippet was probably
> > buggy. I restored the use of read_indent and -1 for
> > newline_indent_size. Otherwise multiple cursor positions with
> > tabs+spaces mode probably wouldn't work.
> > 
> 
> Ah, OK.  Seems that I investigated that argument not thorough enough.
> 
> > > > > > > > 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).
> > 
> > Why would <lia> be kept? That should be removed, otherwise <table>
> > would result in <table><table>...</table>
> > 
> > If that is done, <lia> would be 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?
> > 
> > I don't think it's a problem.
> > 
> 
> Yes, removing the tag is a good idea, especially if we account that
> it's how "ordinary" snippets work now.  I had an idea that for
> snippets for the plugin snippet body should contain only the part
> that's inserted (i.e., shouldn't contain the first open tag) because
> it easily allows to save attributes user may have specified in the
> open tag that gets autocompleted.  If we remove this tag, we'll have
> to copy the attributes to the first tag within snippet body, but I
> think it's easy to implement.
> 

…easy to implement if we don't consider the case when the first tag
already contains attributes, especially when names of those attributes
match the ones of the attributes user entered in the autocompleted tag…

> Best regards,
> Eugene.



More information about the Users mailing list