Extension point interface so other plugins can provide completions

[Peter Suter]

I would like to allow other plugins to provide additional completions for their own realms, macros, etc.

For example MailArchivePlugin should be able to provide completions for mailarchive: links.

[Peter Suter]

(Another fun example could be the WikiExtrasPlugin.)

[Peter Suter]

(Also: @username mentions, see ​t:#11871)

[Ryan J Ollos]

Another use-case is TagsPlugin auto-completing tag names for TracLinks ([tag:).

[Peter Suter]

1. Refactor existing code​. Move list of strategies from Javascript to Python. Try to make everything more uniform, so we can reuse the same Javascript for all strategies.
2. Add extension point interface​.

Maybe there's a simpler / better / nicer / more flexible / more performant approach?

[Peter Suter]

For example MailArchivePlugin should be able to provide completions for mailarchive: links.

See #13352

[Peter Suter]

In 17030:

WikiAutoCompletePlugin: Move list of strategies to Python.
Prepare for extension point interface.
(see #13072)

[Ryan J Ollos]

Interface looks good. Maybe the interface name could be shortened to IWikiAutoCompleteProvider.

I haven't tried, so maybe this doesn't make sense, but I wonder if it would be more flexible to have replace and template regexes rather than replace_prefix, replace_suffix, ...

For TagsPlugin, I looked at supporting the "or" queries, like tag:"plugin macro" (TagsPlugin#tag:tagortagged:query). I'm not sure if that can or should be done.

[Ryan J Ollos]

In 17059:

TracTags 0.10dev: Add support for WikiAutoCompletePlugin

Refs #13072.

[Peter Suter]

Interface looks good. Maybe the interface name could be shortened to IWikiAutoCompleteProvider.

Thanks for reviewing. Sounds reasonable. Would you also shorten get_wiki_auto_complete_strategies, and to what?

I haven't tried, so maybe this doesn't make sense, but I wonder if it would be more flexible to have replace and template regexes rather than replace_prefix, replace_suffix, ...

Yes, I wondered exactly the same thing, but suspected it would get a bit confusing. If you can find a nice and clear way to do it, I'd be interested.

For TagsPlugin, I looked at supporting the "or" queries, like tag:"plugin macro" (TagsPlugin#tag:tagortagged:query). I'm not sure if that can or should be done.

Maybe something like this would work?

{
    'match': (
        r'\b(tag:|tagged:)' # tag: or tagged: query 
        r'("(?:\S* )*)?'    # Optional: Quotes allow multiple OR-tags
        r'(\S*)$'           # tag-prefix to complete
    ),
    'index': 3,
    'replace_prefix': '$1$2',
    # ...
}

[Ryan J Ollos]

Replying to Peter Suter:

Interface looks good. Maybe the interface name could be shortened to IWikiAutoCompleteProvider.

Thanks for reviewing. Sounds reasonable. Would you also shorten get_wiki_auto_complete_strategies, and to what?

That one seems okay to me. I would say to use get_strategies, but it's not specific enough to ensure it wouldn't collide with some other interface implemented on the same Component.

[Ryan J Ollos]

Replying to Peter Suter:

Maybe something like this would work?

{
    'match': (
        r'\b(tag:|tagged:)' # tag: or tagged: query 
        r'("(?:\S* )*)?'    # Optional: Quotes allow multiple OR-tags
        r'(\S*)$'           # tag-prefix to complete
    ),
    'index': 3,
    'replace_prefix': '$1$2',
    # ...
}

Works well. Thanks!

I noticed that some autocompletions add the closing characters. For example, { autocompletes to {1} when report 1 is selected. However, [wiki: autocompletes to [wiki:WikiStart when WikiStart is selected.

Should we always add the closing characters, resulting in [wiki:WikiStart]?

In the case of tag/tagged, it gets more complex because replace_end will depend on whether the term starts with a ".

[Ryan J Ollos]

In 17068:

TracTags 0.10dev: Suggest completions on OR queries

Patch by Pete Suter.

Refs #13072.

[Ryan J Ollos]

In 17077:

TracTags 0.10dev: Change required WikiAutoCompletePlugin version

Refs #13072.

[Ryan J Ollos]

Considering comment:8:ticket:13071, I changed the implementation to use IWikiSyntaxProvider. The changes assume the method get_wiki_auto_complete_strategies, even though it's not defined on the IWikiSyntaxProvider Interface.

• T13072_strategy_extension_interface.2.patch​ (rebased T13072_strategy_extension_interface.patch​)
• T13072_Use_IWikiSyntaxProvider.diff​
• T13072_TagsPlugin_IWikiSyntaxProvider.diff​

[Peter Suter]

The patches look good to me. (Assuming the method will get added to the interface in an upcoming version of Trac.)

I guess we could just start with this. The proposed changes to the interface:

• The replace and template regexes idea from comment:7
• The strategy, handler, priority idea from comment:8:ticket:13071

They could probably be added later in a backward-compatible way. (But if you want to try implementing these soon, it might be better to not commit the patches yet, so we don't need any backward-compatibility considerations at all.)

---

(In comment:2:ticket:13071 I also mentioned IWikiMacroProvider as a possible interface to extend for completions. This is also not urgent I think. The idea was to make macros more user-friendly. They could just provide a description​ more suited to this use-case, e.g. only listing parameters. Even better would be a context-sensitive per-macro-parameter help and suggestions for auto-completed parameter names and values. I'm not completely sure how to implement this though, and again I guess it can be done later in a backward compatible way. What do you think?)

[Ryan J Ollos]

#13665 closed as a duplicate. Need to revisit this eventually.

[Jun Omae]

I noticed cache option doesn't work while trying the patches in comment:14. It seems the issue is introduced in r17030.

wikiautocompleteplugin/wikiautocomplete/htdocs/js/wikiautocomplete.js

@@ -35 +35 @@
                 };
                 $.getJSON(wikiautocomplete.url + '/' + strategy.name, data)
                     .done(function(resp) {
-                        cache[strategy] = resp;
+                        cache[strategy.name] = resp;
                         invoke_callback(resp);
                     })
                     .fail(function() { callback([]) });

[Jun Omae]

I noticed jquery.textcomplete.js has an issue in strategies loop while trying the patches in comment:14 with custom strategy from plugin.

Original text is wrongly dropped if context function returns normalized text. As the result, the completion for processor will no longer work because custom strategy is added as first entry to strategies.

jquery.textcomplete.js

@@ -303 +303 @@
     _extractSearchQuery: function (text) {
       for (var i = 0; i < this.strategies.length; i++) {
         var strategy = this.strategies[i];
         var context = strategy.context(text);
         if (context || context === '') {
           var matchRegexp = $.isFunction(strategy.match) ? strategy.match(text) : strategy.match;
-          if (isString(context)) { text = context; }
-          var match = text.match(matchRegexp);
+          var normText = isString(context) ? context : text;
+          var match = normText.match(matchRegexp);
           if (match) { return [strategy, match[strategy.index], match]; }
         }
       }
       return []
     },
 

However, jquery.textcomplete.js is no longer maintained. See ​https://github.com/yuku/textcomplete/blob/jquery-v1.8.5/README.md.

[Jun Omae]

In 17990:

WikiAutoCompletePlugin: follow-up to r17030, fix cache option not working (refs #13072)