feat/tone-tags #26

					
				@ -32,6 +32,14 @@ async fn on_room_message(event: OriginalSyncRoomMessageEvent, room: Room, client

				    let message = text_content.body.trim();

				    message.trim().lines().map(|line| {

				        if let Some(tag) = line.split(" ").last().unwrap_or("").strip_prefix("/") {

				            if let Err(e) = reply_tag(room, event, client, tag).await {

				                tracing::error!("{e}");

				            }

				        };

				    });

ich empfehle gleich message.split_whitespace() zu nehmen. Das ist robuster, falls jemand mehr als ein space oder tabs benutzt.

Ausserdem:

funktioniert await nicht in normalen loops, wenn du willst, kann ich das naeher erlaeutern
wenn du nur .map machst, nutzt er den iterator nicht. Die iterator combinators sollten immer als letzte Operation
- collect haben wenn du output von der loop haben willst
- for_each haben, wenn du einfach fuer jedes item irgendwas ausfuehren willst

In dem Fall hier sollte es eher sein:

    for maybe_tone_tag in message
        .split_whitespace()
        .filter_map(|word| word.strip_prefix("/"))
    {
        if let Err(e) = commands::reply_tag(&room, &event, &client, maybe_tone_tag).await {
            tracing::error!("{e}");
        }
    }

bzw wenn du fancy sein willst sogar

    for maybe_tone_tag in message
        .split_whitespace()
        .filter_map(|word| word.strip_prefix("/"))
    {
        commands::reply_tag(&room, &event, &client, maybe_tone_tag)
            .await
            .inspect_err(|err| {
                tracing::error!("{err}");
            });
    }

ich empfehle gleich `message.split_whitespace()` zu nehmen. Das ist robuster, falls jemand mehr als ein space oder tabs benutzt. Ausserdem: - funktioniert `await` nicht in normalen loops, wenn du willst, kann ich das naeher erlaeutern - wenn du nur `.map` machst, nutzt er den iterator nicht. Die iterator combinators sollten immer als letzte Operation - `collect` haben wenn du output von der loop haben willst - `for_each` haben, wenn du einfach fuer jedes item irgendwas ausfuehren willst In dem Fall hier sollte es eher sein: ```rs for maybe_tone_tag in message .split_whitespace() .filter_map(|word| word.strip_prefix("/")) { if let Err(e) = commands::reply_tag(&room, &event, &client, maybe_tone_tag).await { tracing::error!("{e}"); } } ``` bzw wenn du fancy sein willst sogar ```rs for maybe_tone_tag in message .split_whitespace() .filter_map(|word| word.strip_prefix("/")) { commands::reply_tag(&room, &event, &client, maybe_tone_tag) .await .inspect_err(|err| { tracing::error!("{err}"); }); } ```

aviac marked this conversation as resolved

lorax added 1 commit

2026-02-01 11:29:50 +00:00

fix(soko-command-bot): Fix stuff 3d8fb683bf

lorax commented

2026-02-01 11:32:45 +00:00

Ist so besser? Dass es sich nur das letzte Wort anschaut, ist so gewollt, ausßer du denkst, das ist nicht gut. Aber ich wollte vermeiden, dass z.B. Linux-Dateipfade immer als tag identifiziert werden (/etc oder so).

Das mit .await in loops würde mich atatsächlich interessieren ^^'

Ist so besser? Dass es sich nur das letzte Wort anschaut, ist so gewollt, ausßer du denkst, das ist nicht gut. Aber ich wollte vermeiden, dass z.B. Linux-Dateipfade immer als tag identifiziert werden (`/etc` oder so). Das mit `.await` in loops würde mich atatsächlich interessieren ^^'

aviac requested changes

2026-02-01 11:43:30 +00:00

Dismissed

bots/soko-command-bot/src/commands.rs Outdated

					
				@ -319,0 +402,20 @@

				        "s" => "sarcastic / sarcastically",

				        "sarc" => "sarcastic / sarcastically",

				        "sbh" => "somebody here",

				        "sbtw" => "subtweeting",

				        "srs" => "serious",

				        "st" => "statement (see also: /naq)",

				        "state" => "statement (see also: /naq)",

				        "sx" => "sexual intent",

				        "x" => "sexual intent",

				        "t" => "teasing",

				        "tan" => "tangent",

				        "th" => "threat",

				        "tic" => "tic, for when something typed out was unintentional due to being a tic",

				        "ts" => "to self",

				        "u" => "upset",

				        "unin" => "unintentional",

				        "unre" => "unrelated",

				        "vu" => "very upset",

				        "w" => "warm / warmth",

				        _ => "Unable to decode tone tag :/",

Ich glaube ich wuerde hier dann einfach nichts machen in dem case und early returnen wenn es nicht matcht mit

return Ok(());

Dann hast du auch das "Problem" mit den Dateipfaden nicht mehr weil du wirklich nur auf die fest definierten tone tags matchst.

Ich glaube ich wuerde hier dann einfach nichts machen in dem case und early returnen wenn es nicht matcht mit ```rs return Ok(()); ``` Dann hast du auch das "Problem" mit den Dateipfaden nicht mehr weil du wirklich nur auf die fest definierten tone tags matchst.

bots/soko-command-bot/src/main.rs

					
				@ -32,6 +32,21 @@ async fn on_room_message(event: OriginalSyncRoomMessageEvent, room: Room, client

				    let message = text_content.body.trim();

				    for line in message.lines() {

				        if let Some(token) = line

				            .split_whitespace()

				            .last()

				            .unwrap_or("")

				            .strip_prefix("/")

				        {

				            let _ = commands::reply_tag(room.clone(), &event, token)

				                .await

Await geht in loops nicht weil es nicht wirklich gut definiert ist, wie das funktionieren soll. Also rust kann dann nicht wissen, was du haben willst:

jedes future nacheinander abwarten
alle parallel laufen lassen ... dann koennen die potenziell in anderer Reihenfolge wieder fertig werden als die Startreihenfolge war

deswegen gibt's dafuer die "Stream" Abstraktion, die quasi ein async iterator ist. Die ist aber nicht im std drin, siehe hier fuer mehr

Await geht in loops nicht weil es nicht wirklich gut definiert ist, wie das funktionieren soll. Also rust kann dann nicht wissen, was du haben willst: - jedes future nacheinander abwarten - alle parallel laufen lassen ... dann koennen die potenziell in anderer Reihenfolge wieder fertig werden als die Startreihenfolge war deswegen gibt's dafuer die "Stream" Abstraktion, die quasi ein async iterator ist. Die ist aber nicht im std drin, siehe [hier] fuer mehr [hier]: https://docs.rs/futures/latest/futures/prelude/trait.Stream.html

aviac marked this conversation as resolved

lorax added 1 commit

2026-02-01 11:47:18 +00:00

fix(soko-command-bot): Streamline response to tts 7f81652e79

aviac approved these changes

2026-02-01 11:50:51 +00:00

aviac left a comment

LGTM!

❤️ 1

lorax merged commit 7cb53ce61f into main

2026-02-01 11:52:34 +00:00

lorax deleted branch feat/tone-tags