mirror of https://github.com/zulip/zulip.git
zcommands: Fully parse messages from the server.
Before this change, we would use **some** options relating to parsing messages, but not all of them. The reason for this was completely unintentional. It's mostly a moot point, since the server sends back pretty generic messages when you do something like invoke the "/dark" command, and the message would parse the same way whether or not the parser was looking for things like user mentions or stream links. In order to make this code predictable, I had to decide whether we do a completely vanilla parse or a full message parse. My decision now is mostly tactical. It's a trivial one-line change to just use all the options for message parsing, whereas it requires a major overhaul to allow a vanilla parse. I also predict that we will eventually want to parse these server responses as if they were messages. I doubt the zcommand responses would ever take advantage of it, but I could imagine things like nag messages wanting to use user mentions. Even if my predictions are wrong, my decisions here are pretty easy to reverse once we learn more. For the particular case of zcommands, it is puzzling to me why the server doesn't just send back HTML, but I don't want to open that can of worms yet, as that would technically be an API change. For now I am happy with the one-line fix.
This commit is contained in:
parent
06ba05b44d
commit
38a3d89a13
|
@ -567,6 +567,8 @@ export function apply_markdown(message) {
|
|||
|
||||
export function parse_non_message(raw_content) {
|
||||
// Occasionally we get markdown from the server that is not technically
|
||||
// a message, but we want to convert it to HTML.
|
||||
return marked(raw_content).trim();
|
||||
// a message, but we want to convert it to HTML. Note that we parse
|
||||
// raw_content exactly as if it were a Zulip message, so we will
|
||||
// handle things like mentions, stream links, and linkifiers.
|
||||
return parse({raw_content, helper_config: webapp_helpers}).content;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue