commands: Do not try to escape quotes

[guludo]

Using re.sub(r'"(.*)"', r'"\\"\1\\""', cmdline) is wrong, as it would not work if we have multiple quoted fragments in the command line, for example: search subject:"foo bar" and date:"this month".

Furthermore, there are other places using split_commandstring() - doing the escaping in just one place does not sound very consistent.

Just let shlex do its job. It is possible to use single quotes when needed. Using the example above, we can simply do search subject:'"foo bar"' and date:'"this month"', which is what we would normally do when using notmuch from a shell.

[pazz]

I like this a lot and agree that we should just use the shlex tuff as is.
Let me just mention one use case that may be related, which has been annoying and may have led me to introduce this stuff. Perhaps you can find a nice solution:

I receive many mails with quoted name/mail pais like "Real Name" <[email protected]>. When editing such recipient in envelope mode, the quotes pop up unescaped in the prompt, so hitting enter would remove them and result in a non-RFC-conform header. Is there some convenient inverse escaping mechanism we shold call there?

[lucc]

Is the edit address prompt even the same as the command prompt? Only the latter needs to be split at semicolons so it might make sense to just not use shlex at all for address prompt (or subject prompts,etc).

[lucc]

I think we should (and do?) use email.utils.parseaddr() from the stdlib for to, from, etc prompts.

[pazz]

I agree. Have not checked if we do this consistently for these special prompts. Somehow I have a shortcut for `set To` using the normal prompt, which seems silly %) Quoting Lucas Hoffmann (2023-07-28 10:16:59)

…

I think we should (and do?) use email.utils.parseaddr() from the stdlib for to, from, etc prompts. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: <pazz/alot/pull/1622/ ***@***.***>