profanity icon indicating copy to clipboard operation
profanity copied to clipboard

Double quote in contact name breaks auto-complete

Open haansn08 opened this issue 2 years ago • 6 comments

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

haansn08 avatar May 04 '23 11:05 haansn08

Not sure what to do against this.

jubalh avatar May 04 '23 11:05 jubalh

Not sure what to do against this.

escape the char?

sjaeckel avatar May 04 '23 11:05 sjaeckel

At which point?

jubalh avatar May 04 '23 12:05 jubalh

At which point?

yes :laughing:

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?

sjaeckel avatar May 04 '23 12:05 sjaeckel

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?

jubalh avatar May 04 '23 13:05 jubalh

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)

sjaeckel avatar May 04 '23 13:05 sjaeckel