Integration into Trac

[Peter Suter]

Ryan J Ollos asked:

I haven't spent much time looking at the source for this plugin, but was wondering if you have any thoughts about eventually integrating this into Trac. If the plugin get a good amount of testing through use on this site and the edge cases get worked out, do you have an opinion on whether it would be a good fit and how much effort might be required to move it to Trac?

I'm open to this. Let's discuss and track any progress in this ticket.

[Peter Suter]

One question is if we can integrate the ​jquery-textcomplete Javascript library? It's MIT licensed, but so is jQuery itself, so maybe that's not a problem.

It's committed as a "vendored dependency" (instead of "properly" declared as a dependency using some Javascript package manager), which distributions generally don't like. But Trac also does that for jQuery itself, so again maybe not a problem.

[Peter Suter]

One thing I always "planned" to do was to allow other plugins to provide their own completions. (#13072) This would probably make more sense if this plugin was integrated into Trac first. Also the code to provide the completions for tickets, wiki, etc. could then be moved to the respective realms / modules and use that same plugin mechanism.

Instead of adding a new extension point interface, it would then actually make sense to just add optional methods to the existing IWikiSyntaxProvider and IWikiMacroProvider interfaces and implementations. (Also an ​old idea).

[Peter Suter]

I'm not sure if a user preference / option to disable the functionality (temporarily or permanently) would be required before integrating the plugin into Trac. (#13073) Maybe not if it works well enough?

[Ryan J Ollos]

Replying to Peter Suter:

I'm not sure if a user preference / option to disable the functionality (temporarily or permanently) would be required before integrating the plugin into Trac. (#13073) Maybe not if it works well enough?

That's what I'm thinking. If it works well then it's unlikely users would expect to disable it. Worst case, we could add that if enough requests are received.

[figaro]

The current blue color rgb(110, 183, 219); is getting overbearing to users who are making edits to wiki pages a lot. It gives the appearance of dark areas flashing on your screen. Neither is this color used anywhere else in Trac.

The suggestion is therefore to use already existing colors, for example the same as for table class changes:

color: #663;
border: 1px solid;
border-color: #eea #dd9 #dd9 #eea;
background: #ffd;

[Peter Suter]

OK, I created #13075 for tweaking the colors.

[Ryan J Ollos]

​#9296 looks like a good complement to this ticket. I integrated the plugin, including the patch in #13072, in a branch: ​comment:5:ticket:9296. I plan to keep rebasing the branch to track changes in WikiAutoCompletePlugin.

Minor changes:

1. Use MilestoneCache to replace a query:

   @@ -358,10 +383,9 @@
            return [{'value': value} for value in completions]
   
        def _suggest_milestone(self, req):
   -        names = [row[0] for row in self.env.db_query(
   -                                "SELECT name FROM milestone ORDER BY name")]
   -        return [{'value': name} for name in names
   -                     if 'MILESTONE_VIEW' in req.perm('milestone', name)]
   +        return [{'value': name}
   +                for name in sorted(MilestoneCache(self.env).milestones)
   +                if 'MILESTONE_VIEW' in req.perm('milestone', name)]
   
        def _suggest_report(self, req):
            return [{'value': id, 'title': title}
   

2. Add export: to: wikiautocompleteplugin/trunk/wikiautocomplete/web_ui.py@17069:164#L163​.

[Peter Suter]

Nice.

The MilestoneCache and export: changes look good to me. Please feel free to commit any changes you feel are ready in general.

Some questions:

1) The order of the different strategies can sometimes be important. Some regex has to be matched before another one, or it'll never be considered. For example the wiki-page-anchor (WikiPage#anchor) regex in #13379 currently has to be tried before the ticket (#13071) regex. Maybe also {{{ blocks vs. {0} reports, and [ links vs. [[ macros. Maybe get_wiki_auto_complete_strategies could return strategy, handler, priority so the strategies can be sorted by priority. Or an OrderedExtensionsOption could be used so the user can reorder the strategies manually. Or maybe the regexes can be tweaked somehow to match unambiguously. Neither of these approaches seem great to me. What do you think?

2) How would you proceed with the IWikiAutoCompleteProvider interface in #13072? We could still go ahead with that, but that might just make it more difficult for e.g. TagsPlugin to be compatible with both the external WikiAutoCompletePlugin and the Trac-integrated version later. Or we could switch to IWikiSyntaxProvider already here. Or we drop the idea of plugins-extending-the-plugin entirely and wait for the Trac-integrated version for that. What would you prefer?

3) Have your tried the patch in #13256? It seems to me that should be applied before integrating into Trac.

[Ryan J Ollos]

In 17072:

WikiAutoCompletePlugin: Add autocomplete of export links

Refs #13071.

[Ryan J Ollos]

Replying to Peter Suter:

Nice.

The MilestoneCache and export: changes look good to me. Please feel free to commit any changes you feel are ready in general.

Some questions:

1) The order of the different strategies can sometimes be important. [...] Neither of these approaches seem great to me. What do you think?

I'm also unsure, but the problem sounds familiar. I will give it some thought.

2) How would you proceed with the IWikiAutoCompleteProvider interface in #13072? We could still go ahead with that, but that might just make it more difficult for e.g. TagsPlugin to be compatible with both the external WikiAutoCompletePlugin and the Trac-integrated version later. Or we could switch to IWikiSyntaxProvider already here. Or we drop the idea of plugins-extending-the-plugin entirely and wait for the Trac-integrated version for that. What would you prefer?

The compatibility is a good point. I like the idea of having WikiAutoCompletePlugin track the changes that are integrated into Trac. Switching to IWikiSyntaxProvider might be a good choice. Maybe it's worth seeing if we can add a method to the interface, replace the interface, or somehow fake it.

3) Have your tried the patch in #13256? It seems to me that should be applied before integrating into Trac.

I will test. Thanks!

[Ryan J Ollos]

In 17075:

WikiAutoCompletePlugin: Get milestone names from MilestoneCache

Refs #13071.

[Ryan J Ollos]

In 17076:

WikiAutoCompletePlugin 1.4dev: Bump version to 1.4dev

Refs #13071.