Double quote in contact name breaks auto-complete

[haansn08]

Double quotes in contact names (to indicate nicknames for example) like Max "plew" Mustermann are not escaped by auto-complete. For example /info Max<tab> would auto-complete to /info "Max "plew" Mustermann" and result in a

Invalid usage, see '/help info' for details.

Environment

• Give us the version and build information output generated by profanity -v

Profanity, version 0.13.1
Copyright (C) 2012 - 2019 James Booth <[email protected]>.
Copyright (C) 2019 - 2022 Michael Vetter <[email protected]>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.20.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.11.3)
GTK icons/clipboard: Disabled
GDK Pixbuf: Enabled

• Operating System/Distribution: Arch Linux profanity 1:0.13.1-4
• glib version:

glib2 2.76.2-1
glibc 2.37-3

[jubalh]

Not sure what to do against this.

[sjaeckel]

Not sure what to do against this.

escape the char?

[jubalh]

At which point?

[sjaeckel]

At which point?

yes 😆

It's a CLI, so it should behave like the CLI's we're all used to, i.e.:

• when user creates input to the CLI, this data must already be escaped
• when auto-completing, the "result" will already be escaped

Internally we still work with unescaped data, i.e. after reading a line, we must unescape the input and only then do further processing.

What do you think? Missing something?

[jubalh]

How do we know when the " is required by our command and when it is part of a name (etc)?

I think we have some commands where we already escape the " maybe. Need to check later.
But AFAIK it's not too easy to do this properly as a general thing?

[sjaeckel]

Well I guess that's part of the 'Missing something?' ... Maybe this will also lead to different usage behavior!? ...

This needs to be thoroughly thought through and checked, but IMO it must be fixed, even if it leads to different required usage behavior. (e.g. our users then have to escape some input which they didn't have to before)