[Patch] Ticket search by query with auto completion

[shesek]

I was inspired by ​YouTrack ticket search box and spent the last couple of hours hacking together something similar.

Its based on ​jQuery UI's autocomplete and uses the regular TracQuery syntax, but with auto complete for field names, operators and (multi) values. Its not as good-looking as YouTrac, but still, its really neat :-)

The way I implemented this is by making the regular search box a bit bigger, and my functionality is trigged when 'query:' is written. I thought it would be better than cluttering the interface with a separate search box.

I'm afraid I don't know how to create those cool egg files, so I just wrote it as a one .py file (it doesn't do much anyhow, just adds JavaScript/CSS/jQuery-UI and give JSON responses of field values). You can ​download it here, just place TicketQuerySearch.py and the TicketQuerySearch directory in the plugins folder.

That's about it. just write 'query:' in the top-right search box, and start writing a regular TracQuery. You can move around with the arrows and use tab, enter or the mouse to choose an item from the list.

Currently it supports:

• Auto completes the field name (either at the very beginning or after an '&').
• When a valid field name is typed/chosen, or when just one field name option is left in the suggestions, it start suggesting search operators. Those operators are also filtered as you type them.
• Once an operator is written, it suggests values.
• When a valid value is typed/chosen, it suggest you to add more values after a pipe (|).
• Also, in some contexts it lets you choose 'Another field…' and 'Another value…' which simply adds & or | to the query.

A couple more notes:

• I know some people would prefer this to be a plugin and not part of core, but I think it gives much better UX when searching for tickets.

It can completely replace the Custom Query page in most cases, making it much faster and easier to search. You can search using the keyboard alone, or by using some simple mouse clicks.

The current Custom Query interface is great and much more advanced than this, but for simple searches its an overkill - it takes too much clicks and time to make searches.

• I posted this ticket as soon as I got a working version, so it wasn't tested enough yet. I want to hear what you have to say about the idea in general, and what you think about the way I implemented this. I assume changes and fixes will be needed.

• I'm not quite sure if you would want to ship jQuery UI with Trac. I downloaded a version that includes only what's necessary for ​Autocomplete, and it weights around ~120KB (20KB for JavaScript and the rest is CSS&images). If needed, I can write a stand-alone Autocomplete functionality, but it probably won't be as good as jQuery-UI's.

• Most of the auto-complete is done on the client-side. When searching in values of some fields (like component), the client downloads a full list of possible values (only when required), searches them and caches them for the next time a search is needed on the same field.

As there aren't usually many values, I thought it would be better to download it once instead of hitting the server with a request every time the user types something.

• Support for custom fields is missing.

• Maybe the 'query:' prefix can be removed so it'll always be enabled? It does raise some questions (when the form is submitted, and the user typed 'status=new', did he mean to search for tickets with that status or just 'status=new' as plain string in the regular search?), but I think its all solvable.

[Remy Blank]

Looks interesting. I'll test it.

[shesek]

I'm updating the code every now and than, and I have updated it since you add the attachment, so please use the version from the link for testing

[Remy Blank]

I probably won't be testing it very soon, and we have had some external links vanish after some time. That's why I attached at least one version here.

[shesek]

A newer version with some small enhancements

[shesek]

Okay, attached the latest version. Hopefully I won't be making any more serious changes, everything seems to work fine now. Came out really cool :-)

[Christian Boos]

I'm eager to test it as well… Some preliminary comments:

The way I implemented this is by making the regular search box a bit bigger, and my functionality is trigged when 'query:' is written. I thought it would be better than cluttering the interface with a separate search box.

That's a welcome change. I increased regularly the size of the search box since 0.10, and I wanted to continue doing so for 0.13, so here is a good excuse ;-)

I'm afraid I don't know how to create those cool egg files … just place TicketQuerySearch.py and the TicketQuerySearch directory in the plugins folder.

That's fine for the initial prototype. If we agree on integrating that in core (and it seems promising enough for that), I would suggest that you start a clone.

That's about it. just write 'query:' in the top-right search box, and start writing a regular TracQuery. You can move around with the arrows and use tab, enter or the mouse to choose an item from the list.

Sounds great!

• I know some people would prefer this to be a plugin and not part of core, but I think it gives much better UX when searching for tickets.

Agreed.

The current Custom Query interface is great and much more advanced than this, but for simple searches its an overkill - it takes too much clicks and time to make searches.

Well, the Custom Query page could still benefit from some simple enhancements to make it much easier to use, like for example a "+" button at the right of a field for adding another alternative (saves you picking the field again).

• I'm not quite sure if you would want to ship jQuery UI with Trac.

I'd say let's go with the full jQuery UI. We would benefit from the datepicker and other components anyway, and it will provide a good baseline for plugin writers.

• Most of the auto-complete is done on the client-side […] As there aren't usually many values, I thought it would be better to download it once instead of hitting the server with a request every time the user types something.

Ok.

• Support for custom fields is missing.

Should be doable ;-)

• Maybe the 'query:' prefix can be removed so it'll always be enabled? It does raise some questions (when the form is submitted, and the user typed 'status=new', did he mean to search for tickets with that status or just 'status=new' as plain string in the regular search?), but I think its all solvable.

Yep, this is some polishing detail. As we already have the '/' shortcut to search for a path, we could use an initial '?' for starting an auto-completed query (hint: have autocompletion for paths as well, when entering '/' ;-) ).

Now my usual nit-picking: please have a look at our TracDev/CodingStyle. In particular, your search.js file has a mix of tabs and spaces and the lines are too long (put all the comments on a line of their own).

[Remy Blank]

I also have a few comments:

• I have had a need for jQuery UI before as well, so +1 for including it. It could also be useful for #1942.
• Could we generalize the concept to arbitrary quick-search providers? Maybe an IQuickSearchProvider defined in the search module, and providers for ticket queries, source paths, … This would probably allow keeping the XHR handler (and logic) in the search module, and only have the provider-specific code in the providers.

[shesek]

Replying to cboos:

• Support for custom fields is missing.

Should be doable ;-)

Uploading custom fields support in a couple of moments

• Maybe the 'query:' prefix can be removed so it'll always be enabled? It does raise some questions (when the form is submitted, and the user typed 'status=new', did he mean to search for tickets with that status or just 'status=new' as plain string in the regular search?), but I think its all solvable.

Yep, this is some polishing detail. As we already have the '/' shortcut to search for a path, we could use an initial '?' for starting an auto-completed query (hint: have autocompletion for paths as well, when entering '/' ;-) ).

An '?' prefix sounds good. I also thought about adding an 'new:' prefix that'll open the new ticket form, so you'd enter new:type=bug&priority=high and get the new ticket form with those arguments. What you think about that?

Now my usual nit-picking: please have a look at our TracDev/CodingStyle. In particular, your search.js file has a mix of tabs and spaces and the lines are too long (put all the comments on a line of their own).

Yeah, sorry about that - I'm usually writing with tabs and I started with the Javascript code, than started working on the python code and changed me editor settings to use spaces, so it came out all mixed. I'll read the CodingStyle and make sure its written according to it.

Replying to rblank:

Could we generalize the concept to arbitrary quick-search providers? Maybe an IQuickSearchProvider defined in the search module, and providers for ticket queries, source paths, … This would probably allow keeping the XHR handler (and logic) in the search module, and only have the provider-specific code in the providers.

Its definitely possible, but it'll require an XHR request for every character the user types. Currently the requests to the server are minimal, to keep it lightweight on the server. However, I do think that search box can be a chrome-like super search box that can do all things of cool things, and than this might be necessary. But another idea would be to provide an client-side API for giving suggestions, which will make it both extensible and won't take much server resources.

[shesek]

Added custom fields supprt

[shesek]

Any ideas as to what I could do with the 'owner', 'reporter' and 'keywords' fields? Would be nice to give them auto complete too, but I'm not quite sure how. An SELECT DISTINCT ... FROM ticket could work for 'owner'/'reporter', but its really not efficient. Extracting keywords from the ticket table is even worst. Any other ways?

[Christian Boos]

Well, at some point you need to extract the information from the database… but once you've done it, it's possible to cache it. Have a look at our CacheManager. In this specific case, I think the invalidation can be limited to the situations were new values are added, as values no longer valid will at worst return no results, which is OK.

[shesek]

attachment:TicketQuerySearch-0.3.zip​ - No more tabs and spaces mix, moved comments to separate lines and some small enhancements. Still not fully written to TracDev/CodingStyle. Do I really have to } else {?

Replying to cboos:

Well, at some point you need to extract the information from the database … Have a look at our CacheManager.

Well, obviously I will, but reading information from the enum table is much more efficient than scanning the entire ticket table, and for keywords, I'll also have to iterate over all the results, normalize each column to an array of keywords and merge everything together. I think it'll be quite an resource-intensive operation to do on a big ticket table.

I'll try to take a look at TracDev/CacheManager and implement it, but I'm not sure I know Trac/Python (I started with Python only when I started developing for Trac) well enough to invalidate it correctly. For the 'owner' field, for example, I'll have to check every time a ticket is created/updated if its a new owner that doesn't exists in the cache, which might . But I'll try.

How important is that for you to have auto-complete for author/reporter/keywords?

[Remy Blank]

The functionality is quite impressive! I would really like to find a way to generalize this system to other providers, without needing to send one request per character. Hopefully we can find a way.

A few comments about the functionality:

• The current implementation doesn't support OR clauses. I assume this would be quite simple to add.
• Would it be possible to add support for key repetitions? Currently, holding the "down" key only moves by a single entry (on Firefox 3.6.9).

And some advice about the code:

• You don't need to put parentheses around expressions in if statements.
• res == None should be written as res is None
• You can generate a 404 by raising ResourceNotFound, no need to build one yourself.
• The json module was introduced in 2.6 IIRC, and we need to support 2.5. There's a replacement in trac.util.presentation, called to_json().
• You should get the field names from TicketSystem.get_ticket_fields() instead of hardcoding them. This will also provide you with all the options for select fields, so you shouldn't need the hack to get them through the trac.ticket.model module.
• You should encode content as UTF-8 before passing it to req.write().
• You should raise RequestDone after req.write() to bypass the normal template processing.
• You will need to allow for translation of all "readable" text. See for example the query.js​ file and the _() JavaScript function.

So, some cleaning up is needed, but it's a very promising start!

[shesek]

Glad to hear that!

I'm working on it to implement your comments/advices, will upload a path shortly.

In regards to the XHR requests - maybe it'll be better to just load everything (including possible values) to begin with, and drop the need for XHR completely? I could set-up an separate Javascript file that'll set everything needed, and than tell the browser to cache it so it'll only be loaded once.

Basically, with a small number of values it could be smarter. If its expected to grow, it might be smarter to keep working with loading-on-demand. Any thoughts?

[shesek]

Attached attachment:TicketQuerySearch-0.4.zip​. rblank, thanks for the feedback!

Replying to rblank:

• The current implementation doesn't support OR clauses. I assume this would be quite simple to add.

Support for OR added

• Would it be possible to add support for key repetitions? Currently, holding the "down" key only moves by a single entry (on Firefox 3.6.9).

Will do that - shouldn't be too hard, but haven't done it yet.

And some advice about the code:

• You don't need to put parentheses around expressions in if statements.

Changed

• res == None should be written as res is None

Changed

• You can generate a 404 by raising ResourceNotFound, no need to build one yourself.

Great, much easier that way. Changed.

• The json module was introduced in 2.6 IIRC, and we need to support 2.5. There's a replacement in trac.util.presentation, called to_json().

Using to_json() instead

• You should get the field names from TicketSystem.get_ticket_fields() instead of hardcoding them. This will also provide you with all the options for select fields, so you shouldn't need the hack to get them through the trac.ticket.model module.

Changed. The field names aren't hardcoded anywhere now - not on the Python code and not on the JavaScript. The old way I did it feels kinda silly now :) I still don't know Trac API well enough to knew it exists.

• You should encode content as UTF-8 before passing it to req.write().

Added .encode('utf-8') on the return value of to_json()

• You should raise RequestDone after req.write() to bypass the normal template processing.

Added

• You will need to allow for translation of all "readable" text. See for example the query.js​ file and the _() JavaScript function.

Can't seem to find any __() function in query.js. Sure its the right file?

So, some cleaning up is needed, but it's a very promising start!

I changed pretty much everything you mentioned, other than using __() in my Javascript and Key repetitions. Can you please check I did it correctly?

Besides that, I should re-format it to match TracDev/CodingStyle (the last attachment has the spaces/tabs mixup again… haven't noticed it until after I uploaded, sorry), and I'll try to write something that allows other components to register callbacks to provide search suggestions.

What do you think about something like SearchProvider.registerCallback(foo), than foo() would get called with the searched term and a callback function to pass results to? Maybe it should also register a prefix that triggers it? Will there be global search providers that are always trigged, or its always trigged for a specific prefix only?

I also want to give it a small redesign to simplify it, as the code got a bit messy and complex. In the meanwhile, it would be great if more users could try it and give me some feedback on the current functionality/code, and their thoughts about how search provides should be implemented.

[Christian Boos]

Replying to shesek:

What do you think about something like SearchProvider.registerCallback(foo), than foo() would get called with the searched term and a callback function to pass results to? Maybe it should also register a prefix that triggers it? Will there be global search providers that are always trigged, or its always trigged for a specific prefix only?

I think that there are two levels here.

We could extend the resource system so that it provides a way to enumerate all the resources of a given realm (pushing the idea in ticket:9526#comment:2 a bit further).

e.g. IResourceManager.get_resource_completer(pattern) which given an input pattern would yield possible matches (actual matches and partial ones that need further completion, like folders, some results can be both, e.g. wiki pages that have sub-pages). But I have to look at the details of what you did for the query: too see how this could work in practice. There could be an option to specify "give me all matches at once".

Building on that, we can add a simple search provider extension for registering "quickjump" triggers: What are the initial input patterns which initiate a specific completion?

• BrowserModule.get_quicksearch_trigger(): yield ('/', partial(get_resource_completer('source:'))
• QueryModule.get_quicksearch_trigger('?', partial(get_resource_completer('query:'))

But this generic completion could have other use besides the search box:

• I would use it for the "page path" index (see TracDev/Proposals/AdvancedWikiOperations#BetterHierarchyNavigation)
• we could even imagine having smart auto-completion when typing <realm>:<TAB> in Wiki input fields :-)

[Carsten Klein <carsten.klein@…>]

when going for full jquery support, please consider reusing shared download sites provided by google et al.

that way, individual sites will not suffer that much due to jquery download every time a user clears his or her cache.

[Christian Boos]

Replying to Carsten Klein <carsten.klein@…>:

when going for full jquery support, please consider reusing shared download sites provided by google et al.

Sure, that should be an option - default empty, the help text could provide one or two of such links. Patch welcome if you'd like to help out, as you can set up that part already now for jquery.js itself :-)

[shesek]

OK. So I worked on it for last couple of hours and it got a complete redesign and some more functionality (wiki and source browser completion). Highlights:

Javascript side

Created some new objects/classes, and moved stuff around:

• QuickSearch object that's responsible for working with all the providers.
• SearchProvider class, each search provider is an instance of that class.
• Ticket-query related stuff are now at the TicketSearchProvider object, which uses SearchProvider.
• AjaxSearchProvider class that's responsible for pure-XHR suggesters. Extends SearchProvider.

Python side

• IQuickSearchProvider with register_quick_search and quick_search_suggestions
  • register_quick_search - registers search provider(s). this is used to automatically create AjaxSearchProvider instances on the client.
  • quick_search_suggestions - gets the suggestions type requested and the search string.
• QuickSearch component responsible for using IQuickSearchProvider components. Uses register_quick_search to pass an object to JavaScript telling it which AjaxSearchProvider is should register, and when suggestions are needed is 'asks' the components that were registered to handle it.

Functionality

• The ticket query suggester is now separate from the base quick search provider code. Some of its code was re-written and re-organized, but the functionality it pretty much the same.
  • Note that TicketQuickSearch doesn't use IQuickSearchProvider, as its mostly client-side.
• WikiQuickSearch component that uses IQuickSearchProvider to provide wiki page names suggestions. Triggered when 'wiki:' is written.
• SourceQuickSearch component that provides filename completion. Triggered when '/' is written. Currently only works with multiple repositories :(

Issues

• The XHR autocomplete isn't as optimized as it can be (delay & minLength parameters of autocomplete). I should find a way to do that while keeping the ticket completer update in live time.
• Not all of my code is formatted and uses the same naming convention as Trac. I'll do my best to fix all of that the next time I upload it.
• I couldn't get it to work with post requests because of token issues (even tho I submitted it), so it currently uses POST requests.
• I think that clicking a selection from the auto-complete should open it when there aren't multiple values to pick (like when completing wiki)
• My Python knowledge is still kinda limited, so I'd love it if someone could go over the code and tell me how to improve it.

I'm under the same nickname (shesek) at IRC. It might be more convenient to discuses it there?

Replying to Carsten Klein:

please consider reusing shared download sites provided by google et al.

That's possible, but it means Trac will be using the ​entire jQuer-UI code (around 200kb) and won't be able to ​specify which parts are needed. cboos said he wants to do it anyway, so it might not be an issue.

Replying to cboos:

But this generic completion could have other use besides the search box:

That version doesn't support that just yet, but its not far from there. I'll try to see how I can do that.

[shesek]

Generalized version, with wiki and source suggestions. See comment:19

[shesek]

About to upload a new version:

• Added autocomplete for the prefix as the default when no provider is handling the search text. (suggests 'query:', 'wiki:', etc)
• SourceQuickSearch renamed to VersionControlQuickSearch, and some functionality was added:
  • Added support for revision auto-complete. When writing '/repo/path/to/file@', the '@' at the end triggers it to display revisions with their description. Latest ones are displayed by default, and when you start writing a number it only displayed revisions that starts with it.
    • '/repo/@' can be used to display latest changes to a repository.
    • Should I display '@' as a suggestion? if so, when?
  • Added 'log:' which works pretty much as writing '/', but goes to the log viewer instead of the file source. Also support the '@' thingy.
• I implemented a smart caching mechanism I thought of, which should be used for cases like the Wiki completer. There is a maximum of 10 results, and if one searches for 'Foo' and only gets 5 results, when he types more characters ('FooA', 'FooXY') its known that every possible result for that was already returned for 'Foo', because 'Foo' returned less than the maximum results. So when limiting the last query even more, and I know I already have all the possible results of the last search, I'm filtering on the last results to get the results for the current search, instead of sending another XHR request. The search provider needs to set the 'cache' property to the number of maximum results to kick this into action.
• Added _() to JavaScript code
• Finally got rid of all the tabs/space mixup in JavaScript code. I missed some files the last time I made a cleanup.
• rblank, key repetitions seems to work here, under Chrome 6 and Firefox 3.6.10. Not quite sure what causes it not to work for you.

Todo/issues/questions:

• For quick search providers that are based solely on XHR, there's still room for improvement. Currently a request is made for every character typed (apart from cases my caching catches).
  • Add to server-side code headers to cache the JSON responses? If so, until when? It can be bad for stuff like VersionControlQuickSearch, as its very dynamic.
  • I still haven't fixed it to use delay/minLength when XHR requests are needed.
• VersionControlQuickSearch still lacks support for Trac enviroments without multi repository.
• The page that gets search terms doesn't seem to redirect '/repo/path/to/file@123' correctly. It works when used with 'source:' at the beginning, so it makes sense for it to work without it too. Is that a bug that should be fixed, or should I find a way to work around it?
• Still no support for owner/reporter/keywords in ticket query quick search.

[shesek]

As described at comment:20

[lkraav <leho@…>]

hi shesek, great work so far, any chance of you jumping on bitbucket, github, or one of their friends with this?

[Remy Blank]

As this has great potential to end up on trunk, and considering your development speed, I was going to suggest the same, working on a Trac clone.

shesek, are you familiar with Mercurial? I would suggest you clone from our ​BitBucket mirror, and start integrating your work in a named branch. This will allow me to easily follow your development, and suggest improvements, which you can then integrate back into your clone.

If you are not (yet :) familiar with Mercurial (and distributed development in general), I would suggest starting to read the ​Mercurial book.

[shesek]

I'm familiar (and working on a daily basis) with SVN, but not yet with Mercurial or Git. I can clone Trac and start working on it at BitBucket, but as my code is standalone and I'm not changing any Trac's code, I'm not sure its really needed - unless you want me to try merging it into core, but I'm not sure I should be the one to do that. Another option is to just open a separate non-clone repository and work there?

rblank / lkraav, any thoughts on the latest version? I really like how the version control quick search ('/' and 'log:') came out. Any improvement ideas/new search providers/bugs?

[Remy Blank]

If your goal is to integrate the functionality into core, then yes, you definitely are the one, and you should start working with a Trac clone and finding out where your functionality should be placed :) Don't worry, we're here to help.

OTOH, if your goal is to create a plugin, then a separate repository (possibly on trac-hacks) is a better option.

I won't have time to test your latest version in the next few days, but hopefully you will get some feedback from other interested parties.

[shesek]

Well, I think it should be part of core, but I didn't think you want people without deep knowledge of Trac to do that stuff. I can probably manage to add it to core and get it working, but not as good as you guys can.

That being said, I'll start merging it to core at BitBucket. What version should I clone?

[Remy Blank]

Just clone the whole repository, update to the branch "trunk", start a new branch and work from there:

hg clone ssh://hg@bitbucket.org/shesek/trac
cd trac
hg up trunk
hg branch ticket-9643

After that, start integrating your changes, and commit after every significant piece of work. When you are done, push back to BitBucket for everyone to see.

[shesek]

OK. so I cloned the Mercurial repository and I'm trying to add my changes to core, but I'm not really sure about a couple of things:

• I should create a new 'quicksearch' component, right? or should it be added to the 'search' component? or elsewhere?
• where do I implement my IQuickSearch? for wiki, for example, should I do that at wiki/web_ui.py? or somewhere as part of the quicksearch component?
• should I place my css/js under trac/quicksearch/htdocs and register it via get_htdocs_dirs, or under trac/htdocs and access it via common?
• should I add jQuery-UI in my component, so if its turned off it won't be added, or add it globally?

Also, if I have more questions (which I probably will), should I ask it here or at the trac-dev mailing list?

[shesek]

Well, never mind, for now I just did it as I thought would be the best (created a new 'quicksearch' component, placed all the static files in the common folder (trac/htdocs) and implemented the IQuickSearchSource interface in TicketModule, VersionControlUI and WikiModule). Everything works on my local Trac, you can see it here: ​http://bitbucket.org/shesek/trac/src/9a97403a08a5.

BTW, when I tried to push the changes back to BitBucket I got an 'push creates new remote branch ticket-9643. did you forget to merge?'. When I looked up that error, it seems like people suggest to just force it. is that okay, or I should've merged it?

[Christian Boos]

Replying to shesek:

BTW, when I tried to push the changes back to BitBucket I got an 'push creates new remote branch ticket-9643. did you forget to merge?'. When I looked up that error, it seems like people suggest to just force it. is that okay, or I should've merged it?

Use hg push --new-branch if your version supports it (don't remember exactly when it was introduced), otherwise, yes, '-f'.

Btw, did anyone notice the new "Copyright © 2010 Atlassian" on BitBucket? Interesting.

[shesek]

Okay, so - as far as I can tell, everything seems to work quite well.

Currently supports quick search for:

• TracQuery using query:. Auto completes field names, operators and values. Support custom fields and uses the Trac API to get the list of fields.
• Wiki pages using wiki:.
• Source browser when typing /. Auto completes folders/files, and when '@' is written at the end it also displays the latest revisions. Revision numbers are also filtered as you type. Support still missing for non-multi repositories. This should really be fixed.
• Changeset log using log:. Also supports '@'.
• When no search provider is found, it suggests them (query:, wiki:, etc).

For the source browser completion to work with /path/tp/file@<rev>, the code that handles the search string should redirect it to the right URL as it does when using source:.

Those are the ideas for improvement I currently have:

• Add support for milestone: searches
• Add support for diff: searches
• Make it possible to specify multiple revisions and ranges in log:
• Make XHR-based search providers more efficient using the 'delay' property, while keeping the query: searches updating in real time.
• Support owner/reporter/keywords autocomplete for query: searches. Still not quite sure about that one.
• When auto-completing query: queries and selecting items like 'priority' - maybe the operator should be '=' by default instead of letting the user pick between '=' and '!=' ?

I would really appreciate it if some more people would try it (with the ​code at BitBucket) and give me some feedback, so I could further improve it. Also, which of the features I mentioned above you think I should start with? I'm getting into a bit of a workload with clients, so I'll have to wait with some of those until I get some more spare time.

[Christian Boos]

Replying to shesek:

Okay, so - as far as I can tell, everything seems to work quite well.

… for you maybe ;-) I had to add:

setup.py

@@ -106 +106 @@
         trac.mimeview.silvercity = trac.mimeview.silvercity[SilverCity]
         trac.mimeview.txtl = trac.mimeview.txtl[Textile]
         trac.prefs = trac.prefs.web_ui
+        trac.quicksearch = trac.quicksearch.web_ui
         trac.search = trac.search.web_ui
         trac.ticket.admin = trac.ticket.admin
         trac.ticket.query = trac.ticket.query

in the entry_points before seeing the magic new feature ;-)

But I think this should rather be integrated in trac.search, simply.

• merge trac/quicksearch/api.py into trac/search/api.py
• move trac/quicksearch/web_ui.py to trac/search/web_api.py

Currently supports quick search for:

• TracQuery using query:. Auto completes field names, operators and values. Support custom fields and uses the Trac API to get the list of fields.

The query: support is awesome. It would be nice to find a way to show the full content of the query, as it very quickly overflows the search box.

• Wiki pages using wiki:.

Got an OperationalError: near "ILIKE": syntax error ⇒ use db.like() (gory details about like() vs. ilike() in #8519).

trac/wiki/web_ui.py

@@ -761 +761 @@
     def register_quicksearch(self):
         yield ('wiki', {'matcher':'wiki:', 'smartCache':10})
     def quicksearch_suggestions(self, req, name, search):
-        cursor = self.env.get_db_cnx().cursor() # to be changed at 0.13 to with?
-        cursor.execute("""SELECT w1.name, w1.author
-                       FROM wiki w1,
-                       (SELECT name,max(version) AS ver
-                       FROM wiki GROUP BY name) w2
-                       WHERE w1.version = w2.ver AND w1.name = w2.name
-                       AND w1.name ILIKE %s
-                       LIMIT 10""", [search+'%%'])
-        return [(name, '%s by %s' % (name, author)) for name,author in cursor]
- No newline at end of file
+        # cursor = self.env.get_db_cnx().cursor()
+        # Note: the above is even wrong for 0.12!!! one should always keep a handle on db
+        db = self.env.get_read_db()
+        cursor = db.cursor()
+        cursor.execute("""SELECT w1.name, w1.author FROM wiki w1,
+                            (SELECT name, max(version) AS ver
+                             FROM wiki GROUP BY name) w2
+                          WHERE w1.version = w2.ver AND w1.name = w2.name
+                            AND w1.name %s LIMIT 10""" % db.like(),
+                       (search + '%%',))
+        return [(name, '%s by %s' % (name, author)) for name, author in cursor]

Limiting the results at 10 matches is not a good idea I think, try for example with the Trac… pages, how would you figure out there's anything beyond TracFastCgi for example? Ideally we should perhaps only show the first 10 entries, but by going down, we should see the others (​scrollable results?).

• Source browser when typing /. Auto completes folders/files, and when '@' is written at the end it also displays the latest revisions. Revision numbers are also filtered as you type. Support still missing for non-multi repositories. This should really be fixed.

The directories could perhaps come first? And would be nice if they would be shown in bold and with a trailing '/'. For the interaction, it would be really nice to have TAB support (i.e. pressing the TAB key would cycle through the current results, like in Windows explorer).

• Changeset log using log:. Also supports '@'.

'@' support is great!

• When no search provider is found, it suggests them (query:, wiki:, etc).

What about using ? as an alias for query:. And showing a line of help text would be nice, e.g.

• / (search for a path)
• ? (search for tickets using criterions)
• wiki: (search for wiki page)
• log: (search for a path, see log)

And it would be great to have [A-Z] as a shortcut for Wiki auto-completion ;-)

For the source browser completion to work with /path/tp/file@<rev>, the code that handles the search string should redirect it to the right URL as it does when using source:.

source: itself is not supported? Maybe don't advertise it, but could be supported if typed explicitly.

---

Those are the ideas for improvement I currently have:

• Add support for milestone: searches

Sure :-)

• Add support for diff: searches

Not sure about this one, I'd rather focus on improving our Compare revisions… dialog and replace our custom suggest.js with yours (and deprecate suggest.js).

• Make it possible to specify multiple revisions and ranges in log:

Maybe overkill, but why not ;-)

• Make XHR-based search providers more efficient using the 'delay' property, while keeping the query: searches updating in real time.

• Support owner/reporter/keywords autocomplete for query: searches. Still not quite sure about that one.

That would be great, but a bit harder. And we'd need server side caching.

• When auto-completing query: queries and selecting items like 'priority' - maybe the operator should be '=' by default instead of letting the user pick between '=' and '!=' ?

Sounds good. Negation could be a possible secondary choice, as a first entry <field> is not…?

I would really appreciate it if some more people would try it (with the ​code at BitBucket)

Ouch, you based it on the 0.12-stable branch. If you agree with my move advice (quicksearch/… to search/…), would you please do that on top of the trunk branch?

Thanks for this great work, with this one, we can release 0.13 anytime :-)

[Christian Boos]

Ouch, you based it on the 0.12-stable branch.

Okay, actually not on 0.12-stable but on b34eeab9d12d, which is 3 months old…

[shesek]

Replying to cboos:

Replying to shesek:

I had to add … in the entry_points before seeing the magic new feature ;-)

Yeah, sorry - I did do it locally but forgot to commit it

But I think this should rather be integrated in trac.search, simply.

I'll do that. I thought it was better as a separate component so it could be easily turned off without disabling search completely… but okay.

The query: support is awesome. It would be nice to find a way to show the full content of the query, as it very quickly overflows the search box.

Yeah, it annoyed me too - but couldn't think of a solution for that. Any ideas? We could always make the search box even bigger.. :-)

Got an OperationalError: near "ILIKE": syntax error ⇒ use db.like() (gory details about like() vs. ilike() in #8519).

Will do.

Limiting the results at 10 matches is not a good idea I think, try for example with the Trac… pages, how would you figure out there's anything beyond TracFastCgi for example? Ideally we should perhaps only show the first 10 entries, but by going down, we should see the others (​scrollable results?).

I'm not sure its a good idea to always display everything, it might get pretty big, especially before the user starts typing something. Maybe we could make the limit higher (20-30?), use scrollable results and show '…' as the last result to let users know there are more results?

The directories could perhaps come first? And would be nice if they would be shown in bold and with a trailing '/'.

I'll get it to show directories first. Make it appear in bold is a bit more tricky and requires to extend the auto-complete functionality, but I have some ​experience with the auto-complete widget so it shouldn't be too hard.

For the interaction, it would be really nice to have TAB support (i.e. pressing the TAB key would cycle through the current results, like in Windows explorer).

I don't think so, TAB usually selects the current item in auto-complete boxes (as it does in regular <select>), so I think changing it behavior would cause confusion.

What about using ? as an alias for query:.

Sure, but the page that parses the search string should support that too. I'll try to implement it.

And showing a line of help text would be nice …

Was thinking about it too, but kinda forgot about it :) I'll add it.

And it would be great to have [A-Z] as a shortcut for Wiki auto-completion ;-)

Great idea! will do.

source: itself is not supported? Maybe don't advertise it, but could be supported if typed explicitly.

Will do.

---

• Support owner/reporter/keywords autocomplete for query: searches. Still not quite sure about that one.

That would be great, but a bit harder. And we'd need server side caching.

Yes, I know… I hope I'll manage to get it working with caching.

• When auto-completing query: queries and selecting items like 'priority' - maybe the operator should be '=' by default instead of letting the user pick between '=' and '!=' ?

Sounds good. Negation could be a possible secondary choice, as a first entry <field> is not…?

Exactly what I was thinking of. Should I do that for all fields, or just for those that are selected from a list and leave it as is for free text fields?

Ouch, you based it on the 0.12-stable branch. If you agree with my move advice (quicksearch/… to search/…), would you please do that on top of the trunk branch?

Hmm, I did write it on top of the trunk… maybe Mercurial is outdated?

Thanks for this great work, with this one, we can release 0.13 anytime :-)

Sure! I'm a happy user of Trac for quite some time, I'm glad I finally found some time to give something back.

Hopefully I'll have some time at Sunday to do everything. Can you also go over the code and give me some feedback, so I'll fix that too while at it?

One more question: I'm calling quicksearch_suggestions() ​only on components that registered themselves to the quicksearch name being requested (via register_quicksearch()). Should I, instead, call it on all the components, so every component has to check for himself if he wants to add search results to it from inside quicksearch_suggestions()? (I'm asking because that's the way it works with get_search_results()​ on ISearchSource, and I'm not quite sure if I should do the same)

[shesek <nadav+shesek@…>]

I ​fixed/implemented some of the bugs/suggestions from comment:31

[Christian Boos]

I tested the latest version a bit, and made some updates, please have a look at 9643-updates-93e3794ef656.patch​.

There are some "cosmetic" improvements to the code, to make it look more like the rest of our code base, but there's also some serious fixing of the TicketModule._process_field_values_request() method (the raise RequestDone would just get you to the except: that follows… well, assuming RequestDone was defined in the first place ;-) ). I didn't have time to look closer at the rest, but at least I wanted to share this part of the review. Shortly though, it still seems that the completion results could benefit from some polishing. I hope it's not a limitation of jQuery UI, but at least in our "home made" completion, we could insert arbitrary HTML, so it was easy to make some stuff stand out. In particular, I think we better need to separate the possible completion values from their labels.

Side note: it was a bit painful to work on the clone, since it's based on a version which doesn't have the .hgeol file and for some reason Mercurial eol extension keeps wanting to show some diffs as full file differences because of the different eols (well, yes, I work on Windows mainly). I wonder if a rebase on a recent trunk would improve the situation…

[Christian Boos]

reviewing the query: part of ​http://bitbucket.org/shesek/trac/changeset/93e3794ef656

[shesek <nadav+shesek@…>]

Thanks for the review!

Replying to cboos:

There are some "cosmetic" improvements to the code, to make it look more like the rest of our code base

Yeah, I'm a bit new to Python and don't know the syntax well enough just yet :)

but there's also some serious fixing of the TicketModule._process_field_values_request() method (the raise RequestDone would just get you to the except: that follows… well, assuming RequestDone was defined in the first place ;-) ).

That's odd, how come it even worked at all for me when I tried it?

Looking at it now… wanting to keep the field-lookup as a one liner (without a field=field[0] line) made me resort to some odd code indeed. BTW, is there no way to get a field by its name other than iterating over all the fields available and looking it up?

Shortly though, it still seems that the completion results could benefit from some polishing. I hope it's not a limitation of jQuery UI, but at least in our "home made" completion, we could insert arbitrary HTML, so it was easy to make some stuff stand out. In particular, I think we better need to separate the possible completion values from their labels.

Yes, it bugged me too. jQuery UI doesn't support any way to display the value and label separately in the auto-complete suggestions. However, the way jQuery-UI widgets are built make it quite easy to make modifications to it and add support for that.

I'll write a new widget (based on autocomplete) with support for:

1. A new 'hint' parameter in addition to 'value' and 'label'.

A third parameter is needed (instead of simply using value and label) because for some cases, like query:, 'value' contains the entire query, but 'label' would be just the part after the last '&'. Or for the source browser, the value would be the entire path, the label is the file/directory name and the hint could specify the type (directory/filename) and the revision.

Than, for example, when the user types query:priority=high&status and it suggests the '=' operator, the data for the auto-complete will look like that:

• value: query:priority=high&status= (as the value to be set in the input when its selected)
• label: status= (as the displayed value, when not set it'll default to the same as value)
• hint: Status is (displayed separately from the label)

This is similar to how it work in ​YouTrack - the current auto-complete string is displayed to the left, and a 'hint' is displayed to the right.

Does that solution sounds acceptable? If so, I'll start working on jQuery part and make some basic CSS for it - but I'm really awful at design, I could really use some help with that part.

2. allow to set arbitrary HTML as the hint/label
3. apply CSS styling to specific suggestion options (like making them bold)

Side note: it was a bit painful to work on the clone, since it's based on a version which doesn't have the .hgeol file and for some reason Mercurial eol extension keeps wanting to show some diffs as full file differences because of the different eols (well, yes, I work on Windows mainly). I wonder if a rebase on a recent trunk would improve the situation…

When I started working on it I did branch from trunk, but it still took a 3 months old version, so I'm not quite sure what I did wrong or how to fix it. Any idea?

As you already read the quicksearch.web_ui code, any comments as to the last question in comment:10? Does the current way it works seems right or I should change to how it works with ISearchSource?

[Christian Boos]

Replying to shesek <nadav+shesek@…>:

but there's also some serious fixing of the TicketModule._process_field_values_request() method

That's odd, how come it even worked at all for me when I tried it?

It "kind of" worked nevertheless, the data was sent, but Trac also produced an internal error, not pretty. And it caused a hang when pressing Search, IIRC.

BTW, is there no way to get a field by its name other than iterating over all the fields available and looking it up?

Watch #9648.

I'll write a new widget (based on autocomplete) with support for: …

Sounds good! 2. is perhaps not that important, in particular if it introduces complexity for variable height (pure speculation on my part, I don't know the internals), it's perhaps not needed as long as we manage to make it look good with 1. and 3.

Side note: it was a bit painful to work on the clone, since it's based on a version which doesn't have the .hgeol file and for some reason Mercurial eol extension keeps wanting to show some diffs as full file differences because of the different eols (well, yes, I work on Windows mainly). I wonder if a rebase on a recent trunk would improve the situation…

When I started working on it I did branch from trunk, but it still took a 3 months old version, so I'm not quite sure what I did wrong or how to fix it. Any idea?

I'm not sure what you did by then (I just checked hg clone http://bitbucket.org/edgewall/trac and after an hg update trunk I was on 7df160970d43 (r10198). To fix this, well, ​Mercurial:RebaseExtension ;-) After activating the extension, do: hg rebase -b ticket-9643 -d trunk (+ eventually --keep if you want to do a non-destructive rebase). Then push the new branch on BitBucket, with --new-branch if your hg push is recent enough, otherwise -f.

As you already read the quicksearch.web_ui code, any comments as to the last question in comment:10? Does the current way it works seems right or I should change to how it works with ISearchSource?

comment:14, rather? Well, sorry, didn't have the time yet to look in more depth, but it's not bad as it is.

[Remy Blank]

Replying to cboos:

To fix this, well, ​Mercurial:RebaseExtension ;-) After activating the extension, do: hg rebase -b ticket-9643 -d trunk (+ eventually --keep if you want to do a non-destructive rebase). Then push the new branch on BitBucket, with --new-branch if your hg push is recent enough, otherwise -f.

Rebasing in a published repository? Shesh…

You can also simply merge from the trunk branch after having pulled the latest changesets.

[Christian Boos]

Replying to rblank:

Replying to cboos:

To fix this, well, ​Mercurial:RebaseExtension ;-) After activating the extension, do: hg rebase -b ticket-9643 -d trunk (+ eventually --keep if you want to do a non-destructive rebase). Then push the new branch on BitBucket, with --new-branch if your hg push is recent enough, otherwise -f.

Rebasing in a published repository? Shesh…

There's no problem with this, really. You'll just get two branches on BitBucket, the original and the rebased one (or even locally, if you use --keep). The advantages is that the changes for adapting the code due to the merge are not apparent, you only get to see the changes related to the feature itself, which is what we want for a review.

[Remy Blank]

Rebasing is an advanced operation (and destructive, at that), so I wouldn't advocate using it if it can be avoided. It's also the reason why it's in an extension and not in core Mercurial.

While merging does introduce merge changesets (surprise!), it's a perfectly safe operation, simple to understand. It does make it a bit more difficult to see the "feature" changes (you have to pick them out of the log), but then again, what I'm interested in are the changes against SVN, which is a simple diff operation.

[Christian Boos]

Replying to rblank:

Rebasing is an advanced operation (and destructive, at that), so I wouldn't advocate using it if it can be avoided.

Ok, so I'll always advise people to use --keep, which makes it a non-destructive operation.

It does make it a bit more difficult to see the "feature" changes (you have to pick them out of the log), but then again, what I'm interested in are the changes against SVN, which is a simple diff operation.

Two views are interesting for me when I review the code:

1. the change wholesale, which indeed you can get via svn diff if you have a mixed checkout,
2. the sequence of changes as made by the author. For the latter, I much prefer a linear sequence of changes.

The complete, safe and clear rebase sequence would be:

$ hg clone http://bitbucket.org/shesek/trac#ticket-9643 ticket-9643
$ cd ticket-9643
$ hg pull http://bitbucket.org/edgewall/trac --update
$ hg branch ticket-9643-2
$ hg ci -m "Rebasing ticket-9643 at cboos' request ;-)"
$ hg rebase -b ticket-9643 -d ticket-9643-2 --keep
$ hg push --new-branch

Et voila, new rebased branch, nothing lost, what happened is quite clear ;-)

Note that without the explicit "hg ci", the new branch name ticket-9643-2 wouldn't have been kept by a rebase on trunk. That message can also be used to make a note about the changes that happened between two iterations of the topic branch, if any (no, I won't go into MQ yet ;-) ).

shesek, don't be put off by our discussions about the BitBucket workflow, as you're one of the first to get through this way, we also need Remy and me to agree on the ideal process that we can later document…

[Remy Blank]

Compare with merging:

$ hg clone http://bitbucket.org/shesek/trac#ticket-9643 ticket-9643
$ cd ticket-9643
$ hg pull http://bitbucket.org/edgewall/trac
$ hg merge trunk
$ hg ci -m "Merged."
$ hg push

Et voilà, still a single branch, but updated to current trunk. And no risk whatsoever, even if you forget a command option. Of course, you can do that in your working clone, in which case it reduces to pull, merge, commit, push, that is, the standard way of working with a DVCS.

There is no "ideal" process, only different ways of working. I just prefer using the simplest way that works, especially when working with people who are not familiar with DVCS. But please, please don't introduce even more complexity with MQ.

[Christian Boos]

Replying to rblank:

Compare with merging: … still a single branch … There is no "ideal" process, only different ways of working.

Exactly - so we have to advise people about the best way it works for us.

I just prefer using the simplest way that works, especially when working with people who are not familiar with DVCS.

If you're OK with reviewing branches that have seen plenty of merges, fine. But my personal preference however is to be able to review a linear sequence of changes.

Maybe to better see what I mean, please compare ​http://github.com/CuriousCurmudgeon/trac-batch-modify/commits/trunk (original) to ​http://github.com/CuriousCurmudgeon/trac-batch-modify/commits/ticket525-batchmodify (rebased). Ok, in this particular example it's even worse because in addition to the merges from origin/trunk he also cherry-picked some changes.

It would probably be simpler for our contributors to use merge rather than rebase, I agree, but "distributed" in DVCS is also (mainly?) about distributing the work load. If at a slightly higher cost for them, it makes life easier for us (a.k.a. the bottleneck guys), then it benefits everybody in the end: the review is faster, changes get integrated quicker, etc.

Do you imagine someone coming to the Mercurial list for example, saying: "hey, I've got some great stuff in my hg clone on bitbucket, have a look (oh, don't pay attention to the merges, I did that some time ago but it's been merged regularly since)." ;-) No, every feature there (and the same goes for lots of other projects using DVCS), is expected to come in a sequence of clean, small, changesets that apply cleanly on head. The kind of stuff you can only produce by using rebase or MQ.

If we wouldn't use the convenience of DVCS for doing this, we could just have opened up Subversion /sandbox a bit more and have plenty of branches there. Ok, a DVCS makes it a bit easier than Subversion as the merge changesets are identified as such (except for now in Trac; a few weeks ago, I started to work on #1492 before I got distracted by #9536, I should resume that effort).

Note that one thing I hope we can agree upon is that either rebase or merge operations should happen sparingly, only when really needed (e.g. to accommodate some big changes that happened in trunk, or just before integration).

But please, please don't introduce even more complexity with MQ.

Well, even if I find it hard to imagine working without, I'll try ;-)

Bottom line: Remy is fine with merges, I will frown upon seeing them but will nevertheless review the contributions, even if I'd prefer the convenience of rebased branches (optionally cleaned up with MQ) ;-)

[Remy Blank]

Replying to cboos:

Exactly - so we have to advise people about the best way it works for us.

That's not exactly my top priority. I try to advise people about one way it works at all.

We often hear of the high "entry barrier" for contributors. While one of my main concerns is code quality, so I wouldn't want to back down on TracDev/SubmittingPatches, I wouldn't want the VCS to be an additional entry barrier. I fear that requiring contributors to master rebase (let alone MQ) is an additional risk of scaring them away. So I'm fine that people who do master rebase to work with it (and I'm even ok with MQ in the meantime), but I won't request them.

Bottom line: Remy is fine with merges, I will frown upon seeing them but will nevertheless review the contributions, even if I'd prefer the convenience of rebased branches (optionally cleaned up with MQ) ;-)

Maybe we don't even want to require one or the other way? People who are familiar with one way should just use that, and people who haven't found their way yet will receive advice from someone who has, and will use that.

[Remy Blank]

Christian, I move this over to you, as you have done all the reviewing.

[lkraav <leho@…>]

how far away is this from landing in trunk? i think some of my upcoming stuff is significantly dependening on what final shape this functionality will take.

[shesek]

I'm sorry I kinda disappeared, I got recruited to the Army and was nearly never at home or near a computer for quite some time. I really want to move ahead with this and get it into the next release of Trac. Hopefully, I should have some spare time next week to continue the development.

I think I'll just clone again and manually re-apply my changes as it'll probably take me less time than figuring out that Mercurial stuff… I'll ask for some help on IRC to make sure I'm doing it right and not working on a 3 months old version again :-(

For now, I want to at least get it to a usable stage so it can be released, and I'll develop more features for later versions. Any chance you could give me a prioritized list of stuff to be implemented so I'll know where to begin? What's most important for you to get this into 0.13?

[Christian Boos]

Hello!

Same thing for us… integration of this patch somehow lingered. Let's revive this effort.

I'd say what's most urgent:

• get your work in a form that is easily reviewable (i.e. either GitHub or bitbucket, according to your DVCS preferences, see TracRepositories); continuing to work with .zip packages is not really efficient. See for example how Jun did it with #10016.
  • rebase what you did on current trunk
• a plan to integrate jQuery UI
• getting more review on the proposed interfaces

[psuter <petsuter@…>]

I wanted to test this cool feature, so I took ​shesek's code at Bitbucket and applied cboos' patch​ on top, rebased the whole thing to current trunk and put it in ​a new Bitbucket fork.

The feature looks really nice!

I had some minor issues with the '/' and 'log:' completion:

• When selecting the // (repository) suggestion it logs a ValueError: need more than 1 value to unpack on versioncontrol\web_ui\main.py line 54. (That line seems to have a commented out workaround already?)
• The '@' feature doesn't work (with mercurial repositories). versioncontrol\web_ui\main.py in quicksearch_suggestions calls repos.get_path_history() which raises NotImplementedError.
• Filenames with spaces break the 'log:' searches.

[psuter <petsuter@…>]

In that fork I now fixed those two corner cases (// (repository) and log:for filenames with spaces), integrated trac.quicksearch into trac.search (as suggested by comment:31), experimented with refactoring the API (e.g., to allow the ticket case to fit into the interface) and generally tried to adjust the code to fit the Trac style. (Although the last two points can probably still be improved. Suggestions welcome.)

(I opened #10245 so the jQuery UI integration can be planned separately.)

[Remy Blank]

Preparing for 1.0.

[Christian Boos]

Move feature requests to next-dev.

[Christian Boos]

well, once again… next-dev

[lkraav <leho@…>]

Replying to psuter <petsuter@…>:

I wanted to test this cool feature, so I took ​shesek's code at Bitbucket and applied cboos' patch​ on top, rebased the whole thing to current trunk and put it in ​a new Bitbucket fork.

The feature looks really nice!

Unfortunately the steam to get this merged seems to have been lost. Is @psuter's process above still the way to try this out? Does it still rebase without huge conflicts?

[Peter Suter]

Changes from comment:50 and 51 rebased on [11693]

[Peter Suter]

Yes, the changes still seem to apply with only minor conflicts. I attached a fully rebased and squashed patch.

[Christian Boos]

Maybe worth to have a look at #10303, as well.

[lkraav <leho@…>]

Might be helpful here ​http://engineering.twitter.com/2013/02/twitter-typeaheadjs-you-autocomplete-me.html

[Peter Suter]

Replying to lkraav <leho@…> in #11731:

TracLinks generation system overall could really use some kind of an automatic generation helper, "as you write" tooltip/autocomplete system.

Maybe the quick search system here could be generalized into that? I experimented a bit with a different library in ​th:WikiAutoCompletePlugin. (I haven't investigated if this is possible with jQuery UI autocomplete). So far I used no extension system. Maybe IWikiSyntaxProvider (and IWikiMacroProvider) should provide the completions?

[lkraav <leho@…>]

I'm currently successfully using ​https://github.com/yuku-t/jquery-textcomplete to autocomplete a hardcoded list of @mentions in ticket comment. Even though now that I look at it, typeahead.js is certainly still a viable choice.

Anyway, what could be the next step here? It'd be nice to have something however small in front of users, so next iterations could be more calibrated.

[lkraav <leho@…>]

Replying to psuter:

Maybe the quick search system here could be generalized into that? I experimented a bit with a different library in ​th:WikiAutoCompletePlugin. (I haven't investigated if this is possible with jQuery UI autocomplete). So far I used no extension system. Maybe IWikiSyntaxProvider (and IWikiMacroProvider) should provide the completions?

@psuter ​th:WikiAutoCompletePlugin screenshots looks mouth-watering good!

[Ryan J Ollos]

Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.