Created attachment 2357 [details] The patch. The new message is more clear for the fact that you can combine the regex shortcut with other operators and expressions, but only when they come _before_. Translation suggestions: de.po: msgid "" "all filtering expressions are allowed, but cannot be followed by logical " "operators with the expressions above" msgstr "" "Alle Filterausdrücke sind erlaubt, aber es konnen keine logischen Operatoren " "mit obigen Ausdrücken folgen" fr.po: msgstr "" "Toutes les conditions de filtrage sont utilisables, mais ne peuvent être " "suivi des expressions ci-dessus par des opérateurs logiques." es.po: msgstr "" "se permiten todas las expresiones de filtrado, pero no pueden ir seguidas de " "operadores lógicos con las expresiones anteriores" (German is my native language, Spanish got verfied by a South American native speaker.)
I'm afraid I don't understand the new sentence in English, and even not in French :-) (not counting a grammar error). I let Paul state for the English one, and will update the French translation accordingly. Thanks for your efforts on clarifying non-trivial situations!
The current English used seems hard to understand, but perhaps this is because the concept is hard to understand also. Your suggestion about 'cannot be followed' is wrong, though. What the wording is trying to express is that, although any filtering expressions can be used, they cannot be used at the same time as the shortcut versions listed in the Extended Search information window. For example, the following fail s "[Users] " & colorlabel 1 colorlabel 1 & s "[Users] " but these work: subject matchcase "[Users] " & colorlabel 1 colorlabel 1 & subject matchcase "[Users] "
Oh, so the message text refers to the non-abbreviated expressions in combination with the whole set of shortcuts? I only thought it releates to regular expressions. We need an empty line to separate the Sentence from the regex help line. I see that this probably was intended in the data structure, but does not work. I'll attach another patch. Brain log mainly about motivating additional clarifications about syntax and error behaviour of the quick search: I thought about da "2023-10-20" & #s PA.CH compared to #s PA.CH & da "2023-10-20" But now I see they both seem to work. (Btw: I needed a moment again to figure out that I need to write "#s" and not "# s" or "s #". We need examples.) I probably was confused by the error handling in the quick search: A broken search condition results in all messages being listed instead of none. I need to guess that my quick search syntax is wrong. Guessing at syntax is very hard with that. I am also not sure if sometimes just the existing result is not changed, even if the expression would not match. For example, I fail to figure out how I would match Subject: Ein Text mit "Anführungszeichen" with an expression including the quotes and spaces. s "mit \"Anführ" seems to be bad syntax (I get all 6368 messages in my inbox listed). s \"Anführ seems to be correct, though. Also, s "mit "Anführ" seems to work, too. But I guess it only matches on "mit ", not the following Word. The parser should throw an error that not all input was consumed. #s "Anführ is broken (6368 "matches"). #s \"Anführ seems ok. #s "Text mit.*Anführ" also does the job, while #s Text mit.*Anführ does not. This matches all subjects with "Text" in them. So the regex is also hard-split on spaces. subject regexp "mit \"Anführ" does the trick but #s "mit \"Anführ" does not. That baffles me as a user. I'd expect this to simply expand to the former. That this is not the case, is this really intentional or just an artifact of the parser implementation?
Created attachment 2364 [details] new patch rephrasing the help text and adding crucial separation