added a simple implementation of send_message method #20

Closed

Jadid-Alam wants to merge 1 commit from send-message into master

Jadid-Alam commented

2026-02-23 08:30:22 +01:00

(Migrated from github.com)

No description provided.

flaxeneel2 (Migrated from github.com) reviewed

2026-02-23 08:30:22 +01:00

rayyan-parkar (Migrated from github.com) reviewed

2026-02-23 08:30:22 +01:00

rayyan-parkar commented

2026-02-23 14:30:12 +01:00

(Migrated from github.com)

I have a nitpick with your comments, can you make them consistent with how me and @flaxeneel2 have done them in the latest comment. The way we did it is by following rustdoc function comments, the syntax is just md, so it should be fairly easy to implement.
The main thing is that you should probably request review again when you complete it rather than trying to PR incomplete code because it's not hooked up to the front-end either so we can't test your code either

I have a nitpick with your comments, can you make them consistent with how me and @flaxeneel2 have done them in the latest comment. The way we did it is by following rustdoc function comments, the syntax is just md, so it should be fairly easy to implement. The main thing is that you should probably request review again when you complete it rather than trying to PR incomplete code because it's not hooked up to the front-end either so we can't test your code either

flaxeneel2 commented

2026-02-23 19:05:23 +01:00

(Migrated from github.com)

Ideally, send message should not be going into the client_events.rs file, because, while its an event, client_events.rs is meant more for the events that the client will be listening to (e.g. listening for incoming messages and emitting them to the frontend). For direct client calls you can use user.rs, it is a file we will soon be refactoring though, since its kind of a mess right now (splitting it into seperate files), but for now it would be preferred if you can put the send code there instead.

I understand you have mentioned that this is a simple implementation of plaintext messages, but you might want to look into the markdown feature flag of the matrix rust sdk crate, to allow the user to send markdown formatted messages.

It might also be worth looking into RoomMessageEventContent::text_html which lets you give both body and formatted body. We will be using this for custom emojis/sticker packs (from the limited research ive done in it).

This PR can be accepted once the feature is fully implemented, with functioning send message of markdown type at the very least.

This feature would also need testing. Were you able to test this code? If so, then what were your testing methods? you dont need to do some fancy test cases, since testing is another thing i need to set up for others to use, but, it would be preferred if you could go through and do a full test by sending a few different kind of messages manually. easiest way to do that would be turning it into a tauri command and calling it through the frontend, since that way you are testing what the frontend's experience would be like of using your code.

Ideally, send message should not be going into the `client_events.rs` file, because, while its an event, `client_events.rs` is meant more for the events that the client will be listening to (e.g. listening for incoming messages and emitting them to the frontend). For direct client calls you can use `user.rs`, it is a file we will soon be refactoring though, since its kind of a mess right now (splitting it into seperate files), but for now it would be preferred if you can put the send code there instead. I understand you have mentioned that this is a simple implementation of plaintext messages, but you might want to look into the `markdown` feature flag of the matrix rust sdk crate, to allow the user to send markdown formatted messages. It might also be worth looking into [RoomMessageEventContent::text_html](https://docs.rs/matrix-sdk/latest/matrix_sdk/ruma/events/room/message/struct.RoomMessageEventContent.html#method.text_html) which lets you give both body and formatted body. We will be using this for custom emojis/sticker packs (from the limited research ive done in it). This PR can be accepted once the feature is fully implemented, with functioning send message of markdown type at the very least. This feature would also need testing. Were you able to test this code? If so, then what were your testing methods? you dont need to do some fancy test cases, since testing is another thing i need to set up for others to use, but, it would be preferred if you could go through and do a full test by sending a few different kind of messages manually. easiest way to do that would be turning it into a tauri command and calling it through the frontend, since that way you are testing what the frontend's experience would be like of using your code.