Enable quickjump in the Search preference panel

[anonymous]

If you in the search box write a name that is interpreted as a WikiPage ie in camelcase you dont get search results instead you get the wikipage.

To try it out search for ex AfdBfd. In the search box in the right top corner.

[Emmanuel Blot]

This is not a bug, this is a feature ;-)

Add a ! before the searched word: !AfdBfd. See TracSearch#DisablingQuickjumps

[Christian Boos]

Yes, and besisdes this has been discussed before: see #1269 and #2532.

We thought about not jumping to a page known to be missing, but some people are using that behavior as a shortcut to create new pages…

[anonymous]

I would say that this is viewed as a bug for somebody that doesnt know that it is intended. And it is not really intuitive to know how you should do to disable it.

I would say that if you want to do quickjump you should do something active and not the other way around. As you now disable quick jumps, this could instead be used to enable them.

If the current behavior isnt changing. Somehow information that one did a quickjump and how to disable it should be showed for the user. For example a red box on top when you have done a quickjump that explains what happened.

In any case I think that if it is kept as it is know, this bug will reappear many times….

Best regards,

T

[Christian Boos]

Well, as we now have fancy preference panels, we could think about making that a user preference:

• new users won't have the quickjump active, so they don't risk to get confused
• advanced users will keep having that behavior, which they rely on for daily work…

… and you make the transition from new user to advanced user by reading the documentation displayed next to the Enable Quickjump checkbox in the Search preference panel.

[Emmanuel Blot]

Replying to cboos:

Well, as we now have fancy preference panels, we could think about making that a user preference:

Why not, although it will require a DB table update (session) so that the default settings do not change for existing users.

BTW, I really think we should stop adding features for 0.11 …

[Emmanuel Blot]

s/does/do/

[Christian Boos]

Replying to eblot:

BTW, I really think we should stop adding features for 0.11 …

Well, this one (and a lot of other minor stuff currently scheduled for 0.11) will not prevent 0.11 to be released. I only used that milestone as a rough estimate/wish. But probably 1.0 would be more appropriate in those cases, yes.

(which doesn't mean it couldn't be done earlier of course, e.g. if someone contributes a patch!)

[Waldemar Kornewald <wkornewald>]

with this patch you have to prepend a search with '!' in order to do the quickjump. otherwise you do a normal search

[Waldemar Kornewald <wkornewald>]

Our developers have problems with the default behavior. They didn't know how to disable this function and so they were unable to find a bug by entering a CamelCase function name. This was really annoying. I think that quickjump should always be explicit. With my patch you can enter "WikiWord" and you get to the respective wiki page. If you just enter "WikiWord" the search results still suggest to do a quickjump.

[Emmanuel Blot]

The proposed syntax reverts the convention of "!" which is to disable wikification. In this case, "!" would indicate to use the wiki format. This is inconsistent with Trac.

Moreover, I'd like to keep the syntax as it is as Trac-aware people are used to this syntax and use it a lot. It does not mean that disabling quick jumps is not an option, but I think we need something easier to use: why not a checkbox close to the search field (the checkbox status being stored along with the user preferences)?

[Waldemar Kornewald <wkornewald>]

A checkbox takes up quite a bit of space and IMHO doesn't work very well because when you've only used quickjump once you have to disable it, again, with the next search. You can't even disable quickjump immediately.

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

[Waldemar Kornewald <wkornewald>]

in order to not introduce inconsistencies I changed the code to use ':' for executing a quickjump

[Emmanuel Blot]

Replying to Waldemar Kornewald <wkornewald>:

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

Sounds a bit "geeky" to add escape characters to perform (or not) a feature. Still, wiki is on everywhere, but would be off by default in the search box: in one case wiki is disabled with an escape char, in the other case it is enable with another escape char.

Another solution would be to replace the search button w/ two small buttons, one for search, the other for quickjump.

[Waldemar Kornewald <wkornewald>]

Replying to eblot:

Replying to Waldemar Kornewald <wkornewald>:

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

Sounds a bit "geeky" to add escape characters to perform (or not) a feature. Still, wiki is on everywhere, but would be off by default in the search box: in one case wiki is disabled with an escape char, in the other case it is enable with another escape char.

Is '!' better in this regard? :)

Well, at least it makes sense to have the wiki disabled in the search box, by default. You're not writing an article there. ;)

Another solution would be to replace the search button w/ two small buttons, one for search, the other for quickjump.

Hmm, that would work, too, but then you have to use the mouse to click on "Quickjump". Since this is a power-user feature you'd decrease its efficiency for those who appreciate the feature the most, so I doubt that this alone will solve the problem.

I think that only these two solutions are good enough:

• it's a power-user feature, so let power-users learn that they can use ':'
• allow for using ':', but also add a quickjump button for those who don't know ':'

[Christian Boos]

Well, I'd rather see a search panel preference used for this, rather than to clutter the interface and/or the search syntax.

[Waldemar Kornewald <wkornewald>]

Aren't preference panels cluttering the UI, too? Will everything where no agreement can be found get a new entry in the preferences panel? Why can't things just work and those who need quick-access features can learn a new function? I mean, this function is still available for everyone because it shows up in the search results, anyway. It's just about saving exactly one mouse click for the experts.

[Emmanuel Blot]

Replying to Waldemar Kornewald <wkornewald>:

It's just about saving exactly one mouse click for the experts.

It is also about usability: in my team, we use the the search box 9 time out of 10 for quick jumping, not for searching. So yes, "one mouse click" does matter, a lot. I still do not like the ':' thing, but I guess Matt would recommend us to move this discussion to Trac-Dev, so let's discuss this point in Trac-Dev ML.

[Christian Boos]

Milestone 1.0 deleted

[Ryan J Ollos]

Replying to anonymous:

If the current behavior isnt changing. Somehow information that one did a quickjump and how to disable it should be showed for the user. For example a red box on top when you have done a quickjump that explains what happened.

This is an interesting idea. In a notice box, along with the message about the quickjump, we could display a link to the search results. We can also display a message about disabling quickjump through the preferences panel, though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

[anonymous]

+1 for changing something. E.g. show both the search results and the form to create a new page.

[Ryan J Ollos]

Replying to Ryan J Ollos:

This is an interesting idea. In a notice box, along with the message about the quickjump, we could display a link to the search results. We can also display a message about disabling quickjump through the preferences panel, though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

I propose to add a message like the following:

close You arrived here through the quick-jump search feature. To instead search for the term WikiStart, click here.

If we get more requests we can add the preference, but it's always best to avoid the additional complexity if possible.

Initial cut at implementation in log:rjollos.git:t4309, but I'll review again and add tests.

[Jun Omae]

The here word without context is a general word. I would like to avoid extraction because it's difficult to translate such a word which is used in another extracted text.

[Jun Omae]

We could use tag(Markup(_("..."))) and escape() but not elegant.

trac/search/web_ui.py

@@ -22 +22 @@
 from trac.perm import IPermissionRequestor
 from trac.search.api import ISearchSource
 from trac.util.datefmt import format_datetime, user_time
-from trac.util.html import find_element, tag
+from trac.util.html import Markup, escape, find_element, tag
 from trac.util.presentation import Paginator
 from trac.util.text import quote_query_string
-from trac.util.translation import _, tag_
+from trac.util.translation import _
 from trac.web.api import IRequestHandler
 from trac.web.chrome import (INavigationContributor, ITemplateProvider,
                              add_link, add_notice, add_stylesheet,
@@ -180 +180 @@
                 return {'href': quickjump_href, 'name': tag.em(name),
                         'description': description}
             else:
-                help_link = tag.a(_("quick-jump"),
-                                    href=req.href.wiki('TracSearch') +
-                                         '#Quicksearches')
-                search_link = tag.a(_("here"),
-                                    href=req.href.search(q=kwd,
-                                                         noquickjump=True))
-                add_notice(req,
-                    tag_("You arrived here through the %(help_link)s search "
-                         "feature. To instead search for the term %(term)s, "
-                         "click %(search_link)s.", help_link=help_link,
-                         term=tag.b(kwd), search_link=search_link))
+                help_url = req.href.wiki('TracSearch') + '#Quicksearches'
+                search_url = req.href.search(q=kwd, noquickjump=1)
+                add_notice(req, tag(Markup(_(
+                    'You arrived here through the <a href="%(help_url)s">'
+                    'quick-jump</a> search feature. To instead search for the '
+                    'term <strong>%(term)s</strong>, click <a '
+                    'href="%(search_url)s">here</a>.',
+                    help_url=escape(help_url), term=escape(kwd),
+                    search_url=escape(search_url)))))
                 req.redirect(quickjump_href)
 
     def _get_search_terms(self, query):

If Genshi i18n translation format could be used in *.py, we could make it simple like this:

You arrived here through the [1:quick-jump] search feature. ..., click [2:here].

[Ryan J Ollos]

I considered whether the sentence could be reworded, but any solution that looks like the comment:22 changes will break the sentence to multiple fragments.

Unrelated, I considered only adding the notice when the term length is ≥ [search] min_query_length, but that seems like too much complication.

log:rjollos.git:t4309.1 adds a test for the comment:25 changes.

[Ryan J Ollos]

Committed to trunk in [14830].

[anonymous]

I have just upgraded from 1.0.8 to 1.2.2, and find the "you arrived here…" notice at the top of each page to be useless and annoying/distracting, since I use the quick-search feature very often.

what happened to the idea from comment:19 ?

… though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

I would like that feature very much; or else I would like to disable this annoying new banner. I've been using Trac for 11+ years and needless to say this is not helpful / not necessary for experienced users.

[jeremy.j.dunn@…]

sorry, previous anonymous comment by me. I would like to receive notifications of comments to this ticket.

[Ryan J Ollos]

Please ask on MailingList if you'd like help on creating a plugin to remove the notification.