Open LosFarmosCTL opened 2 years ago
Agreed, we should remove shift+enter
functionality, while it sounded fine in theory, it has zero use.
The major issue with this functionality stems from #2844, while this issue has existed for a while, it was hardly ever noticed due to the fact that enter took priority over all in the old code, with the shift+enter
functionality, users believe they are unable to send messages, and said issue went from literally never being mentioned to happening to people daily.
up arrow, capslock, cv paste, ctrl+enter; there are multiple ways to spam in caps yet ppl complain about not being able to hold shift? :D
shift+enter
is expected to enter new line, twitch web chat works like this, same with popular apps like discord/telegram/slack/etc. It can be useful when you paste multi-row text and can read/redact it in original form before sending.
Would keep it and look for other solution to make shift-holders happy
shift+enter
is expected to enter new line, twitch web chat works like this, same with popular apps like discord/telegram/slack/etc.
Discord/telegram/slack all support multi-line messages, Twitch does not. I'm unsure why browser chat has this functionality.
It can be useful when you paste multi-row text and can read/redact it in original form before sending.
We had this functionality before custom hotkeys - cc random issue related to multi-line whispers #1123, but it did require hidden \n
's.
up arrow, capslock, cv paste, ctrl+enter; there are multiple ways to spam in caps yet ppl complain about not being able to hold shift? :D
The complaints I got were not about repeated spam but just random uppercase characters, there is no way to do that anymore without capslock (and capslock sucks and shouldnt exist)
I dont think that we should keep this behavior, it suggests that sending newlines is possible, while they are clearly not working. I guess webchat allowing it is probably just a browser thing, not sure if that can even be disabled by a website for multiline text fields?
I think the main issue here is that the focus works differently if the inputs are hidden or not.
Why would the window be differently focused when the input is hidden? Additionally even though the split is not in focus you can still type in the input. That makes even less sense.
So I think the correct solution here would be to focus the split directly.
Checklist
Describe your issue
This is somewhat of a regression from #2340, since before that change the SplitInput listened just for the enter key, ignoring modifiers other than Ctrl for keeping the message input.
There are 2 reasons why this should somehow be changed imo:
The second issue is fixable by just adding an additional Shift+Return keybinding, but it is definitely still unwanted behaviour.
Screenshots
No response
OS and Chatterino Version
Newest Dankerino Nightly, macOS 11.6