zulip/static/js/markdown.js

490 lines
18 KiB
JavaScript
Raw Normal View History

import {isValid} from "date-fns";
import katex from "katex";
import _ from "lodash";
import * as emoji from "../shared/js/emoji";
import * as fenced_code from "../shared/js/fenced_code";
import marked from "../third/marked/lib/marked";
import * as blueslip from "./blueslip";
import * as linkifiers from "./linkifiers";
import * as message_store from "./message_store";
// This contains zulip's frontend Markdown implementation; see
// docs/subsystems/markdown.md for docs on our Markdown syntax. The other
// main piece in rendering Markdown client-side is
// static/third/marked/lib/marked.js, which we have significantly
// modified from the original implementation.
// Docs: https://zulip.readthedocs.io/en/latest/subsystems/markdown.html
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
// This should be initialized with a struct
// similar to markdown_config.get_helpers().
// See the call to markdown.initialize() in ui_init
// for example usage.
let helpers;
// Regexes that match some of our common backend-only Markdown syntax
const backend_only_markdown_re = [
// Inline image previews, check for contiguous chars ending in image suffix
// To keep the below regexes simple, split them out for the end-of-message case
/\S*(?:\.bmp|\.gif|\.jpg|\.jpeg|\.png|\.webp)\)?\s+/m,
/\S*(?:\.bmp|\.gif|\.jpg|\.jpeg|\.png|\.webp)\)?$/m,
// Twitter and youtube links are given previews
/\S*(?:twitter|youtube).com\/\S*/,
];
export function translate_emoticons_to_names(text) {
// Translates emoticons in a string to their colon syntax.
let translated = text;
let replacement_text;
const terminal_symbols = ",.;?!()[] \"'\n\t"; // From composebox_typeahead
const symbols_except_space = terminal_symbols.replace(" ", "");
const emoticon_replacer = function (match, g1, offset, str) {
const prev_char = str[offset - 1];
const next_char = str[offset + match.length];
const symbol_at_start = terminal_symbols.includes(prev_char);
const symbol_at_end = terminal_symbols.includes(next_char);
const non_space_at_start = symbols_except_space.includes(prev_char);
const non_space_at_end = symbols_except_space.includes(next_char);
const valid_start = symbol_at_start || offset === 0;
const valid_end = symbol_at_end || offset === str.length - match.length;
if (non_space_at_start && non_space_at_end) {
// Hello!:)?
return match;
}
if (valid_start && valid_end) {
return replacement_text;
}
return match;
};
for (const translation of emoji.get_emoticon_translations()) {
// We can't pass replacement_text directly into
// emoticon_replacer, because emoticon_replacer is
// a callback for `replace()`. Instead we just mutate
// the `replacement_text` that the function closes on.
replacement_text = translation.replacement_text;
translated = translated.replace(translation.regex, emoticon_replacer);
}
return translated;
}
export function contains_backend_only_syntax(content) {
// Try to guess whether or not a message contains syntax that only the
// backend Markdown processor can correctly handle.
// If it doesn't, we can immediately render it client-side for local echo.
const markedup = backend_only_markdown_re.find((re) => re.test(content));
// If a linkifier doesn't start with some specified characters
// then don't render it locally. It is workaround for the fact that
// javascript regex doesn't support lookbehind.
const linkifier_list = linkifiers.linkifier_list;
const false_linkifier_match = linkifier_list.find((re) => {
const pattern = /[^\s"'(,:<]/.source + re.pattern.source + /(?!\w)/.source;
const regex = new RegExp(pattern);
return regex.test(content);
});
return markedup !== undefined || false_linkifier_match !== undefined;
}
export function apply_markdown(message) {
message_store.init_booleans(message);
const options = {
userMentionHandler(mention, silently) {
if (mention === "all" || mention === "everyone" || mention === "stream") {
let classes;
let display_text;
if (silently) {
classes = "user-mention silent";
display_text = mention;
} else {
message.mentioned = true;
display_text = "@" + mention;
classes = "user-mention";
}
return `<span class="${classes}" data-user-id="*">${_.escape(display_text)}</span>`;
}
let full_name;
let user_id;
const id_regex = /^(.+)?\|(\d+)$/; // For @**user|id** and @**|id** syntax
const match = id_regex.exec(mention);
if (match) {
/*
If we have two users named Alice, we want
users to provide mentions like this:
alice|42
alice|99
The autocomplete feature will help users
send correct mentions for duplicate names,
but we also have to consider the possibility
that the user will hand-type something
incorrectly, in which case we'll fall
through to the other code (which may be a
misfeature).
*/
full_name = match[1];
user_id = Number.parseInt(match[2], 10);
if (full_name === undefined) {
// For @**|id** syntax
if (!helpers.is_valid_user_id(user_id)) {
// silently ignore invalid user id.
user_id = undefined;
} else {
full_name = helpers.get_actual_name_from_user_id(user_id);
}
} else {
// For @**user|id** syntax
if (!helpers.is_valid_full_name_and_user_id(full_name, user_id)) {
user_id = undefined;
full_name = undefined;
}
}
}
if (user_id === undefined) {
// Handle normal syntax
full_name = mention;
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
user_id = helpers.get_user_id_from_name(full_name);
}
if (user_id === undefined) {
// This is nothing to be concerned about--the users
// are allowed to hand-type mentions and they may
// have had a typo in the name.
return undefined;
}
// HAPPY PATH! Note that we not only need to return the
// appropriate HTML snippet here; we also want to update
// flags on the message itself that get used by the message
// view code and possibly our filtering code.
// If I mention "@aLiCe sMITH", I still want "Alice Smith" to
// show in the pill.
let display_text = helpers.get_actual_name_from_user_id(user_id);
let classes;
if (silently) {
classes = "user-mention silent";
} else {
if (helpers.my_user_id() === user_id) {
message.mentioned = true;
message.mentioned_me_directly = true;
}
classes = "user-mention";
display_text = "@" + display_text;
}
return `<span class="${classes}" data-user-id="${_.escape(user_id)}">${_.escape(
display_text,
)}</span>`;
},
groupMentionHandler(name, silently) {
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
const group = helpers.get_user_group_from_name(name);
if (group !== undefined) {
let display_text;
let classes;
if (silently) {
display_text = group.name;
classes = "user-group-mention silent";
} else {
display_text = "@" + group.name;
classes = "user-group-mention";
if (helpers.is_member_of_user_group(group.id, helpers.my_user_id())) {
message.mentioned = true;
}
}
return `<span class="${classes}" data-user-group-id="${_.escape(
group.id,
)}">${_.escape(display_text)}</span>`;
}
return undefined;
},
silencedMentionHandler(quote) {
// Silence quoted mentions.
const user_mention_re = /<span[^>]*user-mention[^>]*data-user-id="(\d+|\*)"[^>]*>@/gm;
quote = quote.replace(user_mention_re, (match) => {
match = match.replace(/"user-mention"/g, '"user-mention silent"');
match = match.replace(/>@/g, ">");
return match;
});
// Silence quoted user group mentions.
const user_group_re =
/<span[^>]*user-group-mention[^>]*data-user-group-id="\d+"[^>]*>@/gm;
quote = quote.replace(user_group_re, (match) => {
match = match.replace(/"user-group-mention"/g, '"user-group-mention silent"');
match = match.replace(/>@/g, ">");
return match;
});
// In most cases, if you are being mentioned in the message you're quoting, you wouldn't
// mention yourself outside of the blockquote (and, above it). If that you do that, the
// following mentioned status is false; the backend rendering is authoritative and the
// only side effect is the lack red flash on immediately sending the message.
message.mentioned = false;
message.mentioned_me_directly = false;
return quote;
},
};
// Our Python-Markdown processor appends two \n\n to input
message.content = marked(message.raw_content + "\n\n", options).trim();
message.is_me_message = is_status_message(message.raw_content);
}
export function add_topic_links(message) {
if (message.type !== "stream") {
message.topic_links = [];
return;
}
const topic = message.topic;
const links = [];
const linkifier_list = linkifiers.linkifier_list;
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
for (const linkifier of linkifier_list) {
const pattern = linkifier.pattern;
const url = linkifier.url_format;
let match;
while ((match = pattern.exec(topic)) !== null) {
let link_url = url;
const matched_groups = match.slice(1);
let i = 0;
while (i < matched_groups.length) {
const matched_group = matched_groups[i];
const current_group = i + 1;
const back_ref = "\\" + current_group;
link_url = link_url.replace(back_ref, matched_group);
i += 1;
}
// We store the starting index as well, to sort the order of occurrence of the links
// in the topic, similar to the logic implemented in zerver/lib/markdown/__init__.py
links.push({url: link_url, text: match[0], index: topic.indexOf(match[0])});
}
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
}
// Also make raw URLs navigable
const url_re = /\b(https?:\/\/[^\s<]+[^\s"'),.:;<\]])/g; // Slightly modified from third/marked.js
const matches = topic.match(url_re);
if (matches) {
for (const match of matches) {
links.push({url: match, text: match, index: topic.indexOf(match)});
}
}
links.sort((a, b) => a.index - b.index);
for (const match of links) {
delete match.index;
}
message.topic_links = links;
}
export function is_status_message(raw_content) {
return raw_content.startsWith("/me ");
}
2019-01-16 10:11:30 +01:00
function make_emoji_span(codepoint, title, alt_text) {
return `<span aria-label="${_.escape(title)}" class="emoji emoji-${_.escape(
codepoint,
)}" role="img" title="${_.escape(title)}">${_.escape(alt_text)}</span>`;
2019-01-16 10:11:30 +01:00
}
function handleUnicodeEmoji(unicode_emoji) {
const codepoint = unicode_emoji.codePointAt(0).toString(16);
const emoji_name = emoji.get_emoji_name(codepoint);
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
if (emoji_name) {
const alt_text = ":" + emoji_name + ":";
const title = emoji_name.split("_").join(" ");
2019-01-16 10:11:30 +01:00
return make_emoji_span(codepoint, title, alt_text);
}
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
return unicode_emoji;
}
function handleEmoji(emoji_name) {
const alt_text = ":" + emoji_name + ":";
const title = emoji_name.split("_").join(" ");
// Zulip supports both standard/Unicode emoji, served by a
// spritesheet and custom realm-specific emoji (served by URL).
// We first check if this is a realm emoji, and if so, render it.
//
// Otherwise we'll look at Unicode emoji to render with an emoji
// span using the spritesheet; and if it isn't one of those
// either, we pass through the plain text syntax unmodified.
const emoji_url = emoji.get_realm_emoji_url(emoji_name);
if (emoji_url) {
return `<img alt="${_.escape(alt_text)}" class="emoji" src="${_.escape(
emoji_url,
)}" title="${_.escape(title)}">`;
}
const codepoint = emoji.get_emoji_codepoint(emoji_name);
if (codepoint) {
2019-01-16 10:11:30 +01:00
return make_emoji_span(codepoint, title, alt_text);
}
return alt_text;
}
function handleTimestamp(time) {
let timeobject;
if (Number.isNaN(Number(time))) {
timeobject = new Date(time); // not a Unix timestamp
} else {
// JavaScript dates are in milliseconds, Unix timestamps are in seconds
timeobject = new Date(time * 1000);
}
const escaped_time = _.escape(time);
if (!isValid(timeobject)) {
// Unsupported time format: rerender accordingly.
// We do not show an error on these formats in local echo because
// there is a chance that the server would interpret it successfully
// and if it does, the jumping from the error message to a rendered
// timestamp doesn't look good.
return `<span>${escaped_time}</span>`;
}
// Use html5 <time> tag for valid timestamps.
// render time without milliseconds.
const escaped_isotime = _.escape(timeobject.toISOString().split(".")[0] + "Z");
return `<time datetime="${escaped_isotime}">${escaped_time}</time>`;
}
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
function handleStream(stream_name) {
const stream = helpers.get_stream_by_name(stream_name);
if (stream === undefined) {
return undefined;
}
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
const href = helpers.stream_hash(stream.stream_id);
return `<a class="stream" data-stream-id="${_.escape(stream.stream_id)}" href="/${_.escape(
href,
)}">#${_.escape(stream.name)}</a>`;
}
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
function handleStreamTopic(stream_name, topic) {
const stream = helpers.get_stream_by_name(stream_name);
if (stream === undefined || !topic) {
return undefined;
}
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
const href = helpers.stream_topic_hash(stream.stream_id, topic);
const text = `#${stream.name} > ${topic}`;
return `<a class="stream-topic" data-stream-id="${_.escape(
stream.stream_id,
)}" href="/${_.escape(href)}">${_.escape(text)}</a>`;
}
function handleTex(tex, fullmatch) {
try {
return katex.renderToString(tex);
} catch (error) {
if (error.message.startsWith("KaTeX parse error")) {
// TeX syntax error
return `<span class="tex-error">${_.escape(fullmatch)}</span>`;
}
blueslip.error(error);
return undefined;
}
}
export function initialize(helper_config) {
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
helpers = helper_config;
function disable_markdown_regex(rules, name) {
rules[name] = {
exec() {
return false;
},
};
}
// Configure the marked Markdown parser for our usage
const r = new marked.Renderer();
// No <code> around our code blocks instead a codehilite <div> and disable
// class-specific highlighting.
r.code = (code) => fenced_code.wrap_code(code) + "\n\n";
// Prohibit empty links for some reason.
const old_link = r.link;
r.link = (href, title, text) => old_link.call(r, href, title, text.trim() ? text : href);
// Put a newline after a <br> in the generated HTML to match Markdown
r.br = function () {
return "<br>\n";
};
function preprocess_code_blocks(src) {
return fenced_code.process_fenced_code(src);
}
function preprocess_translate_emoticons(src) {
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
if (!helpers.should_translate_emoticons()) {
return src;
}
// In this scenario, the message has to be from the user, so the only
// requirement should be that they have the setting on.
return translate_emoticons_to_names(src);
}
// Disable headings
// We only keep the # Heading format.
disable_markdown_regex(marked.Lexer.rules.tables, "lheading");
// Disable __strong__ (keeping **strong**)
marked.InlineLexer.rules.zulip.strong = /^\*\*([\S\s]+?)\*\*(?!\*)/;
// Make sure <del> syntax matches the backend processor
marked.InlineLexer.rules.zulip.del = /^(?!<~)~~([^~]+)~~(?!~)/;
// Disable _emphasis_ (keeping *emphasis*)
// Text inside ** must start and end with a word character
// to prevent mis-parsing things like "char **x = (char **)y"
marked.InlineLexer.rules.zulip.em = /^\*(?!\s+)((?:\*\*|[\S\s])+?)(\S)\*(?!\*)/;
// Disable autolink as (a) it is not used in our backend and (b) it interferes with @mentions
disable_markdown_regex(marked.InlineLexer.rules.zulip, "autolink");
// Tell our fenced code preprocessor how to insert arbitrary
// HTML into the output. This generated HTML is safe to not escape
fenced_code.set_stash_func((html) => marked.stashHtml(html, true));
marked.setOptions({
gfm: true,
tables: true,
breaks: true,
pedantic: false,
sanitize: true,
smartLists: true,
smartypants: false,
zulip: true,
emojiHandler: handleEmoji,
unicodeEmojiHandler: handleUnicodeEmoji,
streamHandler: handleStream,
streamTopicHandler: handleStreamTopic,
texHandler: handleTex,
timestampHandler: handleTimestamp,
renderer: r,
preprocessors: [preprocess_code_blocks, preprocess_translate_emoticons],
});
}