allowCommandsAtEnd setting is purely cosmetic with no use

[zneix]

Describe the bug I couldn't git blame the creator of this issue properly, but whoever made this, must've lost implementation of this setting in code and made this setting do literally nothing. I could fix this myself, but I am not really sure how should this work in the first place, so I am creating this issue to discuss it.

Screenshots https://cdn.zneix.eu/y4YYsaf.png

Chatterino version current master branch 2f5df3db

Operating system linux-5.10.2.arch1-1

[TranRed]

Yeah, seems like toggling that checkbox does nothing. can confirm on windows 10 and age-old commit 529f19a2d

I think it's in there forever, but I never used it. Maybe deleting it might also be a valid option?

[Mm2PL]

Cosmetic checkbox . Is there any consensus on if we're removing it or adding the functionality?

[zneix]

Cosmetic checkbox . Is there any consensus on if we're removing it or adding the functionality?

Guess we/I should look into how easy it actually is to add such thing and either make it do anything or just purge entirely since it does... JUST nothing

[Coldblackice]

This would be a pretty useful ability, particularly given the format/nature of Twitch comments. @zneix Are you still working on this?

[zneix]

This would be a pretty useful ability, particularly given the format/nature of Twitch comments. @zneix Are you still working on this?

I am infact not. Haven't started any progress towards "fixing" this because had other PRs to do and eventually moved on. I could try looking into it again and see if it's even possible to have this function properly. I personally also see the potential use for this and would like to eventually have this little feature in.

[talneoran]

If the functionality implementing this setting were to be added, it would need to somehow fit in with command placeholders. Currently a placeholder such as {1} matches the first word after the command trigger, but if the trigger can also be matched at the end it makes no sense to match words after the last word.

One possible way of dealing with this is completely ignoring placeholders in commands that matched at the end, which would need explanation in the wiki entry, but we could also avoid this by deciding to remove the setting.

[Coldblackice]

One possible way of dealing with this is completely ignoring placeholders in commands that matched at the end, which would need explanation in the wiki entry, but we could also avoid this by deciding to remove the setting.

This is a good idea, since when at the end, it's most likely not for expanding upon parameters. My personal use is to auto-expand certain username handles which don't always get picked up by the recent-users popup (since it only populates with usernames that have spoken in chat recently).

I suppose if there was a need it could be made to work by indexing the words in the message starting from the command itself being 0, words preceding the command indexing negative, words following the command indexing positive; if the command is EOL, the index is taken as an absolute value, so

/rule --> "Rules: {1+}"

User1: /rule paper eats rock --> "Rules: paper eats rock" User2: paper eats rock /rule --> "Rules: rock eats paper"

Not sure of a use case for that, but I'm also not a moderator. Another option is just having the {1+} loop back around to the start of the message, printing the rest of the words as if the command was at the beginning of the message to begin with.

But simplest and likely best logic is your idea to just disregard parameters if the command is EOL.

[Infinitay]

User2: paper eats rock /rule --> "Rules: rock eats paper"

I think this is unneeded. At least for specific option of also match the trigger at the end of the message. If this functionality is wanted I think it'd be better suited to either have another option or to replace the trigger at the end with also match the trigger at the end of the message in reverse. Like you say, I can't find an actual use case for having placeholders read and printed in reverse.

Is there something in particular stopping us from continuing as is and simply checking if there is a command at the end or not?

For example,

Command Trigger: /testend Command Function: {1+} | END.

Test: this is the /testend Output: this is the | END.

Test: /testend this is the Output: /testend this is the Of course there will be an unrecognized command message displayed instead because / will still be sent and therefore thought of another command