mirror of
https://github.com/dabeani/meshcoreterm.git
synced 2026-11-03 11:22:19 +01:00
Some usernames are not rendered correctly: Just as <-->, and then "username: " followed behind in the normal text view.
#131
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/meshcore#131
Reference in new issue
Block a user
Describe the bug
In public channels (have not communicated by another means with the affected users, so I could not test other chats than public channels), the user names of some users are not displayed as they should, but just as
<-->, followed by the username in the part of the normal text:Normally, in Channels, the display is formed as follows:
<username>TextBut for the cases I report here, the display is
<-->username: Text.It also affects the "reply"-function, if I hit "reply", I would reply to user "--".
Photographs:
(By the way, what does the colour coding in the chat view mean?)
Which device are you using
LilyGO T-Deck Plus
Which Firmware are you using
v0.9.10
v0.9.11
v0.9.12
Regards!
It is not (specifically) related to the
@, I now have a user without@in the username where the same happens. I have updated the original issue description accordingly.Hier is another example photograph where the issue is clearly visible (see last message).
MC Term version 0.9.12 on LilyGo T-Deck Plus.
Regards!
Still present in v0.9.12.3. And it seems that also the scope of the sent message also is added behind the sending username overflown into the message text.
I currently received a message like:
<-->?Silota ??: @[User ?] erkläre mal was dat bringt und wie dat geht(Where each
?probably is some non-renderable unicode character and?Silota ??a user name of the probably sending user.)Fixed in v0.9.14
Chat no longer shows
<-->as the sender. A region name at the start of a channel message is not used as the nick, and a sender name of 24-31 characters (allowed by the 32-byte node-name limit) is now parsed correctly too — previously it silently fell back to--and left the rawName: textprefix stuck in the message body instead of showing it as the nick.Cannot easily test, so closing without testing.
Regards!