Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double quote in contact name breaks auto-complete #1844

Open
haansn08 opened this issue May 4, 2023 · 6 comments
Open

Double quote in contact name breaks auto-complete #1844

haansn08 opened this issue May 4, 2023 · 6 comments

Comments

@haansn08
Copy link

haansn08 commented May 4, 2023

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 <boothj5web@gmail.com>.
Copyright (C) 2019 - 2022 Michael Vetter <jubalh@iodoru.org>.
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
Copy link
Member

jubalh commented May 4, 2023

Not sure what to do against this.

@sjaeckel
Copy link
Member

sjaeckel commented May 4, 2023

Not sure what to do against this.

escape the char?

@jubalh
Copy link
Member

jubalh commented May 4, 2023

At which point?

@sjaeckel
Copy link
Member

sjaeckel commented May 4, 2023

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
Copy link
Member

jubalh commented May 4, 2023

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
Copy link
Member

sjaeckel commented May 4, 2023

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants