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.

[eblot]

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

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

[cboos]

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

[cboos]

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.

[eblot]

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 does not change for existing users.

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

[eblot]

s/does/do/

[cboos]

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.

[eblot]

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

[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.

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 ':'

[cboos]

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.

[eblot]

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.