-
Notifications
You must be signed in to change notification settings - Fork 18
Message formatting #74
Comments
gTox does have a hidden text-formatting support. |
I think it's a pretty good idea! Even through it's true that "Markdown may be too complicated and unfamiliar to many users.", it's simple: those who deem it too complicated simply won't use it. Or won't use all of it. Having full support won't hurt. |
proposed by @antis81 in qTox/qTox#1432 (comment): Hm ... if we extend the idea to a real wiki-text parser (e.g. markdown like implemented in Github), that would actually become a useful feature. This would allow for sending also quick table and list mockups via chat-message. Idea: This way we could also provide a drop-down box to select a parser and prepend it to the chat message (if not given by hand). Tokens could be ( |
I like this idea. Perhaps full markdown support would be a bit excessive, but I would be fully willing to implement basic Skype-style formatting in Antox. I'd like to see a proposal to the STS with more details (which characters handle formatting, what they do, how to parse, etc). |
I'd be happy to add light markdown support to uTox.
|
I like that better than disguised autoaccepted filetransfers. Fails much more gracefully. |
I'll try to create a pull request with all specifications in nearest future. |
I would prefer to be able to send plaintext + "additional info" (like formated text). Of course toxcore would need a update ... I really don't want to directly hack it "somehow" into the normal send message.. (Like MSNPlus used to do it in the past.. sending html and every client without the addon got the shitty html) |
The idea is that markdown is quite readable in plain text in contrast to html. So there will be no problem for client without markdown support. Here you have some table:
And now here is same message in plain text:
Having ability to bold text or just paste |
true markdown is pretty readable, but the client still would need to detect "i am markdown". EDIT: or messages are default send in markdown... and sending clients escapes string for correct markdown rendering.. |
We could just add a new message type like TOX_MESSAGE_TYPE_MARKDOWN. |
Should the user explicitly specify whether she wants to use markdown in this case (by some "markdown" switch or |
@dvor always using markdown is a bad idea. Thing is, prefixing with Though, Now, if you don't like by default messages in your client being |
What does Skype do for /me in other languages? Translate it? A button will probably have to be used. |
Ridiculous. There are three use cases I can think of here, and none of them require prefixes.
Case 1:
Case 2:
Case 3:
|
@stal888 But not every message should be parsed as markdown. Code chunks may include characters that would be incorrectly and undesirably interpreted as markdown if there were nothing to distinguish plain messages from markdown messages. I definitely agree that typing a command should be avoided at all costs but there still needs to be something that tells clients whether or not a message is intended as markdown. |
Not every message should be markdown, having separate type for it seems best idea. So:
Are we good? |
Sounds good to me.
@GrayHatter said something about "lightweight" markdown for µTox - I take that it's because it would be hard to implement all of gh markdown? Are there some libs that clients could use for that, and that STS could perhaps point to? |
I am for gh markdown without html. |
Here is list of libraries https://github.com/markdown/markdown.github.com/wiki/Implementations |
This does not look right. Markdown is not the only markup language people use, so please don't hardcode it. Just having a “type” is much better. |
wrong repo mate |
Markdown? support
Summary:
It would be nice for clients to support some kind of messages formatting. I think that things like italic, bold,
strikethroughare used by some percentage of users and are quite important.If we will support italic/bold why not to go for full Markdown support?
code blocks
and lists would be also nice to have.Arguments for:
Arguments against:
@GrayHatter, @impyy, @tux3, @subliun
The text was updated successfully, but these errors were encountered: