feat: add the ability to reply with any filetype

[nushea]

Description

Whenever I talk with people and they ask me to send them a file or i want to reply with an image to something they say I currently have to reply with an empty message and then the image/file.

This fix would allow anyone to reply with any file or a sticker to an event.

Also while you can send multiple files in one burst or a file and text, only the topmost item gets the reply event so it doesn't show as many reply icon visuals as there are events, with the reply working as before for text+file, with only the text having the reply tag as it is always the topmost item.

Additionally the older flow where you couldn't reply with images/files has confused all of the people that i have on-boarded or that were new to the platform

Example of how this feature could be used

Fixes #2659
(accidentally closed #2706 by renaming the branch to give my local branches proper names - without realizing it automatically closes them on github/cinny)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[Sollace]

Found a bug!
If you add an attachment and type a message, both the message and the attachment generate a reply.

Ideally if there's message text the reply should only be applied to that.

[nushea]

Found a bug! If you add an attachment and type a message, both the message and the attachment generate a reply.

Ideally if there's message text the reply should only be applied to that.

the intended behavior is for it to only apply to the topmost item (ie the message), but the pr is rather old now, maybe something broke in a later version if you have merged it to it? or honestly the implementation is a bit hacky because the entire message sending flow is quite hacky too, so if the message sends fast enough (kinda impossible tbh in my exp) it could be doing it so fast it clears the editor before the file sending has a chance to review it, i could update it to work better if this is reproduceable

[Sollace]

maybe something broke in a later version if you have merged it to it

Dunno. That might be the case but I also don't remember exactly when I merged it to my branch. I don't think I've pulled since this was last reviewed though.

[nushea]

maybe something broke in a later version if you have merged it to it

Dunno. That might be the case but I also don't remember exactly when I merged it to my branch. I don't think I've pulled since this was last viewed though.

oh sorry i just realized that this was still using an older implementation of it, the issue is that cinny sends files and text in parallel so there can be a race condition where the editor gets cleared out before you get the chance to send the files, i have made a one line change to fix this by literally beating out the clear by any means possible, honestly the whole message sending flow could use changing but for this one option it might not be worth it

also there is another way to make it consistent but that would require awaiting the completion of creating the file contents which could make sending them a bit slower

Could you please update it on your fork (or move the plaintext function in the /src/app/features/room/RoomInput.tsx → handleSendUpload function to have const plaintext = toPlainText(editor.children, isMarkdown).trim(); as the first item ) and then tell me if the issue persists?

[Sollace]

maybe something broke in a later version if you have merged it to it

Dunno. That might be the case but I also don't remember exactly when I merged it to my branch. I don't think I've pulled since this was last viewed though.

oh sorry i just realized that this was still using an older implementation of it, the issue is that cinny sends files and text in parallel so there can be a race condition where the editor gets cleared out before you get the chance to send the files, i have made a one line change to fix this by literally beating out the clear by any means possible, honestly the whole message sending flow could use changing but for this one option it might not be worth it

also there is another way to make it consistent but that would require awaiting the completion of creating the file contents which could make sending them a bit slower

Could you please update it on your fork (or move the plaintext function in the /src/app/features/room/RoomInput.tsx → handleSendUpload function to have const plaintext = toPlainText(editor.children, isMarkdown).trim(); as the first item ) and then tell me if the issue persists?

Alright, pulled your branch and it looks to be good now!

Tested also after merging to my main branch and that has definitely solved the issue.

honestly the whole message sending flow could use changing but for this one option it might not be worth it

Yeah by the sounds of it, that would probably be a good idea. Maybe for a future PR though.

Thanks for the speedy fix!