Would it be possible to toggle-off the new browser tendency to add operators and quotes?

Anki Help
1

I loved the 2.1.34 update to the tag system – that overhaul is one of the most welcome and best changes that Anki has implemented in my three years of using it. But I could not stick with that version, and very grumpily downgrade to 2.1.33 before too long. My reason for downgrading was that I cannot stand the tweaks to the browser that automatically set every term into quotes and automatically add superfluous operators to my searches.

I usually am not a complainer at all. But the browser search change… I just cannot stand it! It slows me down by adding unnecessary keystrokes every time I edit a search, it clutters up the looks of my searches by obfuscating the critical information behind superfluous operators and quotation marks, it leads to random unhelpful error messages that interrupt my work, and for the life of me I cannot understand what value it is supposed to be adding. Could it please be possible, either in a future release or in an add-on, to toggle or disable this feature in browser?

For an example of what I mean, please compare the following two searches:

  • w:Dickens -cities -twist -copperfield -expectations added:10 flag:1

  • “w:Dickens” AND -“cities” AND -“twist” AND -“copperfield” AND -“expectations” AND “added:10” AND “flag:1”

This is somewhat of an exaggeration of the complexity of my usual searches, but not a particularly reckless one. And which of these two searches does a better job at succinctly and accurately conveying the information sought? In my view, the old search does a far, far better job. This is because the length of the new search in this example is more than 50% greater than the length of the old one, yet all that added length is spent on ANDs and ""s that are nothing more than superfluous visual clutter that the eye must navigate before it can parse the actually useful information out of the search.

I also find the old search much more wieldy when it comes to editing the search. Say I wish to change the search from flag:1 to flag:2 – the old browser would let me accomplish this with two keystrokes (backspace, 2). Whereas the new browser requires four keystrokes (backspace backspace 2 "). Or say I wish to stop excluding results for Great Expectations – the old browser would let me accomplish this with two keystrokes (doubleclick “expectations” then hit backspace backspace). But the new browser requires six or so (doubleclick “expectations” then hit backspace backspace backspace delete then delete either the preceding AND or the following AND). A minor inconvenience, but still an inconvenience.

Finally, the new browser is prone to displaying error messages if a user does not perfectly match the syntax of the new search that was created. For example, if I forgot to re-add the trailing quotation mark at the end of “flag:2” in my previous example, Anki would return an error and interrupt my work. Or, if I delete the term -“expectations” but forget to delete the useless AND that was automatically inserted into the search, the search would read, “…AND -“copperfield” AND AND “added:10”…” returning an error and interrupting my work. And these errors crop up as a result of me failing to comply with syntax that Anki automatically added, that I do not want, and that does not help me. Anki basically invites these errors by adding the superfluous operators and quotes!

Please revert this change, make it toggleable, or point me in the direction of somebody I can talk to about hiring to make an add-on to fix this.

Thank you very much for listening to my (hopefully not too impolite) rant.

11 Likes
2

Agreed. I think maybe we can add something like implicit AND?
If there is no OR between two Terms, then the logical operator between them is taken as an AND. So we can remove all AND and only keep “” and OR.

e.g.
"a" AND "b" AND "c" AND ("d" OR "e")
become
"a" "b" "c" ("d" OR "e")

3

The aim was to make it clearer to the user that spaces are separating search terms, and that quotes can be used to denote a single term. I think it does better express how the search will be interpreted, but it has had a negative effect on the ability to quickly make adjustments to an existing search, and a number of users have expressed similar sentiments to yours.

Keeping it as an option and defaulting to the current behaviour would make sure that new users are exposed to how the search parser works, but then they might struggle to find the button to turn it off, and I have the feeling that’s not the best way forward.

@Rumo I’m inclined to call my suggestion a failed experiment, and partially walk this back - maybe we could remove the explicit joiners and only quote when necessary. What do you think?

4 Likes
4

I tend to agree regarding the ANDs. They are only really useful to new users who may not know what the default joiner is.
However, I rather like the double quotes: They allow you to expand a search term to multiple words afterwards without having to jump back and forth to wrap it in quotes. They also clear up the occasional ambiguity with prepended minuses.

I had thought about automatically stripping extraneous ANDs at the time (shouldn’t be a problem codewise) but didn’t want to try to guess the user’s intention in the end.

1 Like
5

Quoutes also can be very annoying. The size of a font is rather small and it’s not that simple to undestand what is the symbol between quotes if you are not familia with a foreign writengs (“책” or “年” for example)

2 Likes
6

Quotes mean that if you backspace a few characters to make a minor adjustment to the search, you have to type the end quote again, which some people find inconvenient. Maybe we should make it an option and default it to off?

3 Likes
7

My suggestion would be to keep the previous version, but add a button for “verbose” search that would change to the new style and change the button to “simple” (which would change it back)

1 Like
8

I don’t feel so strongly about the quotes that I’d want an option for it. Having a single format for all users is more important to me.
If the like count is any indicator, many users agree with the OP, so Damien’s initial suggestion sounds reasonable to me. I would only argue to keep the quotes for negated terms because I expect many users to misinterpret them otherwise.
Here’s a fun game: Where would the quotes go? :wink:

 -  --  -spam  --spam
1 Like
9

I also find backquotes really inconvenient.

Usually I type the first letter of a word or group of words, check what appears and type more if there is too much card. I can’t easily do that anymore.
One solution would be not to move the cursor, to ensure that the cursor remains at the same place than where it was when we clicked. If there is a way in QT to get the cursor position and to set it again, I believe doing the remaining of the computation in rust should be relatively easy (i.e. I would accept to do it)

adding “AND” is also a problem because now I must decide in advance whether I’ll need to group multiple words together. I can’t just decide to add quote later quickly if needed. But it occurs less often

10

If you look at the OP’s example, more than half of the terms are negated, so I suspect quoting the negated terms would not adequately solve the OP’s problem :slight_smile: Could we limit the quoting to cases where it’s necessary or more ambiguous, like double hypens?

11

@ArthurMilchior, preserving the cursor position sounds useful but is not possible with the current implementation. The search text gets parsed to an AST and then that AST is written to a string, there is no link between the two strings and their characters.

@dae, I only speak as a user here, so if the majority wants the quotes to be gone, that’s what Anki should go with. Please don’t compromise if I’m the only one with this view. :slight_smile:

12

@rumo
If you can have the information “the cursor is at position P”, then you can just add an extra letter at position P that can totally be represented in your AST. Then you can recreate the result string and put the cursor at the correct position.

Two cases must be considered. Either the cursor touches a word letter, in which case the cursor letter is considered a part of this word, and it’s easy.

Or the cursor is between words, in which case it should be an extra token and it’s not harder.

The only question here is really to know whether the cursor position can be get and set

13

I’m pretty sure it’s not possible without a lot of rewriting or complicating the code because when adding the detailed search errors, I had to abandon the idea of doing something similar: I wanted to indicate the position of the unexpected character.
I’d love to be profed wrong but I don’t think it’s worth the trouble.
As for the cursor position in Qt, it seems to be available: QLineEdit Class | Qt Widgets 5.15.3.