Describe the bug
After a recent update that changed the behavior of the /usepmp command, it is no longer accepting profile IDs that contain characters other than A-Z, a-z, 0-9 and _ (underscore) - which includes the automatically-generated UUIDs when creating a persona through the settings menu (as they contain dashes), as well as certain mnemonics for members of plural systems (such as mine which also happens to contain a dash).
Reproduction
- Ensure per-message-profile support is enabled in the Experimental tab of the settings menu.
- Create a persona in the Personas tab in the settings menu - it'll automatically be assigned a UUID for its ID; you can either leave it as-is, or choose a different string of characters that happens to contain a non-whitespace non-alphanumeric character that isn't the underscore (
_). Give it a name, save it and copy the ID assigned to it.
- Attempt to run the
/usepmp command in a room, pasting in the ID that was assigned to the new persona as an argument.
- Having executed the command, attempt to send a message under the newly-assigned persona.
Expected behavior
The command should execute properly for any set of non-whitespace characters you can input as a persona ID in the Personas tab in the settings menu (at the very least but not limited to any printable non-whitespace ASCII characters), and the persona should be selected as the current PMP according to the specified criteria.
Platform and versions
1. OS: Arch Linux (KDE/Wayland/nvidia-580xx, linux-zen 6.19.6)
2. Browser: libcef (Sable 0.0.1/Electron)
3. Sable version: v1.13.0 (709a9a9)
4. Matrix homeserver: chat.blahaj.zone
Additional context
This seems to be caused by the regular expression that's being used to parse the command's payload, at 155ac64#diff-0e4172772c62327a8689d866202697fb752960019446deaee231bcedf5bc3079R55:
const USEPMP_REGEX = /^(\w+)\s*(-g)?(-o)?(-u)?\s*(\d+)?$/;
The \w+ token being used to parse the command payload is equivalent to [A-Za-z0-9_]+ and will make the regular expression not match anything that contains characters other than the aforementioned ones.
I consider this to be a regression as prior to this change, there were no issues running /usepmp with at least the default UUIDs generated by the Persona tab in settings, and at least one user was able to successfully use a colon in a persona ID without any issues.
Describe the bug
After a recent update that changed the behavior of the /usepmp command, it is no longer accepting profile IDs that contain characters other than A-Z, a-z, 0-9 and _ (underscore) - which includes the automatically-generated UUIDs when creating a persona through the settings menu (as they contain dashes), as well as certain mnemonics for members of plural systems (such as mine which also happens to contain a dash).
Reproduction
_). Give it a name, save it and copy the ID assigned to it./usepmpcommand in a room, pasting in the ID that was assigned to the new persona as an argument.Expected behavior
The command should execute properly for any set of non-whitespace characters you can input as a persona ID in the Personas tab in the settings menu (at the very least but not limited to any printable non-whitespace ASCII characters), and the persona should be selected as the current PMP according to the specified criteria.
Platform and versions
Additional context
This seems to be caused by the regular expression that's being used to parse the command's payload, at 155ac64#diff-0e4172772c62327a8689d866202697fb752960019446deaee231bcedf5bc3079R55:
The
\w+token being used to parse the command payload is equivalent to[A-Za-z0-9_]+and will make the regular expression not match anything that contains characters other than the aforementioned ones.I consider this to be a regression as prior to this change, there were no issues running
/usepmpwith at least the default UUIDs generated by the Persona tab in settings, and at least one user was able to successfully use a colon in a persona ID without any issues.