I'd expect that setting main.text.me different to main.text.them in a theme would result in two different colors.
I am setting main.text.me=white and main.text.them=blue but I always get blue.
It's not critical or anything I just thought somebody should know.
profanity -vThis is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Build information:
XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Disabled
PGP support: Disabled
OMEMO support: Disabled
C plugins: Enabled
Python plugins: Enabled (3.7.9)
GTK icons: Enabled
Must be a problem with your theme.
You can check your colors with /theme properties.

main.text=white
main.text.me=cyan
main.text.them=red
My problem was that /theme properties was correct!
This seems to fix the issue for me.
```diff --git a/src/ui/window.c b/src/ui/window.c
index 687af3b2..663b49b5 100644
--- a/src/ui/window.c
+++ b/src/ui/window.c
@@ -1215,7 +1215,7 @@ win_print_outgoing(ProfWin* window, const char* show_char, const char* const id,
_win_correct(window, message, id, replace_id, myjid);
} else {
//TODO my jid
- _win_printf(window, show_char, 0, timestamp, 0, THEME_TEXT_THEM, "me", myjid, id, "%s", message);
+ _win_printf(window, show_char, 0, timestamp, 0, THEME_TEXT_ME, "me", myjid, id, "%s", message);
}
inp_nonblocking(TRUE);
My problem was that /theme properties was correct!
What do you mean?
I mean that /theme properties correctly resolved the colors fot main.text.me and main.text.them.
However all text in the chat appeared as main.text.them.
@aba-hollerer but in my screenshot it looks correct, doesn't it?
Can you provide your theme file and/or screenshot?
I used the following testing theme:
[colours]
main.text=white
main.text.me=cyan
main.text.them=red
This resolved as follows:

But:

However I don't really see the point in all of this since I already posted the patch...
@aba-hollerer are you sending from two different instances here?
Then, I'm able to reproduce it like (in a MUC):

(@jubalh is this expected?)
However I don't really see the point in all of this since I already posted the patch...
I think we're just trying to understand what this solves :)
@wstrm: No this was on the same instance.
With the patch applied:

However I don't really see the point in all of this since I already posted the patch...
Your patch looks right to me on first glance. The point is to verify the root cause of this. Is it a misunderstanding? Is it an error that you found and solved? Is it another error and your solution is only covering it up?
As stated above we cannot reproduce this issue on our side (both @wstrm and me), which is suspicious don't you agree?
Like you saw in the code there are many cases. I also think that it is possible that you send with another client/instance and thus carbons are used.
So I dug a little further in src/ui/window.c. The problem seems not to be present for MUC:
In win_print_outgoing_muc_msg:
_win_printf(window, show_char, 0, timestamp, 0, THEME_TEXT_ME, me, me, id, "%s", message);
But in win_print_outging:
_win_printf(window, show_char, 0, timestamp, 0, THEME_TEXT_THEM, "me", myjid, id, "%s", message)
I still don't see why I couldn't reproduce it.
But I think you are right. The mistake seems to be introduced in https://github.com/profanity-im/profanity/commit/b6b7dd5ad497a71e250b8b3cef0bb987314b141d
I have /receipts set to on. Thus win_print_outgoing() isn't used.
Thanks for your investigations @aba-hollerer !
Thank you for maintaining such an awesome piece of software:)
Most helpful comment
Thank you for maintaining such an awesome piece of software:)