帖子编辑器中的Markdown语法高亮

将默认帖子编辑器 textarea 替换为 markdown 语法高亮是否很难?

或者我是在别处错过了这个选项?

您已经在管理员样式编辑器中为 css 精美地实现了这一点:

3 个赞

使用代码块不就能实现预览区域的语法高亮吗?

1 个赞

这是一个有趣的想法,目标是在文本区域(即撰写器的左侧)实现语法高亮,这样您就可以看到自己是否犯了 Markdown 语法错误。是的,代码块在预览中也能做到这一点,但您将看不到任何 Markdown 错误,例如。一些复杂的 Markdown 会更容易扫描,例如包含大量表格、上传、链接、标题的帖子。

不过,我不确定这是否容易实现。我们的管理员屏幕使用 ACE 编辑器,我认为我们无法将其直接拖放到帖子撰写器中。

4 个赞

是的,这正是我的用例。

它能直接反馈你的语法:你不必每隔几秒钟就看右侧窗格来检查你是否犯了简单的语法错误。

这会为那些不太擅长 Markdown(任何初学者)的人提供更多的结构。

当然,组合器窗口的右侧仍然有渲染的 HTML。

我看不出这有什么直接的缺点,尤其是如果这是一个选项的话。

附注:显然,甚至没有为代码块安装 Markdown 语法高亮器 :grin::

# Markdown 代码块的语法...

...不幸的是...

- 没有
- 高亮显示

**完全没有**!

编辑 2 小时后:已由 @pmusaraj 修复

4 个赞

哦,抓得好!看起来我们缺少一些 markdown highlighter 的样式。

2 个赞

使用一个全功能的编辑器来“仅仅”编辑 Markdown 是不是有点小题大做了?

依我看,使用一个 Markdown 的所见即所得(WYSIWYG)编辑器更符合 OP 的需求,例如 https://ui.toast.com/tui-editor、https://milkdown.dev/playground 等。

3 个赞

这两个看起来都很棒!

不过,我可以想象更简单的 Milkdown 可能更合适,因为编辑器如果能提供更“水下屏幕”[^wp] 的感觉也没关系,反正你右边有预览。

[^wp]:是的,我生动地记得 WordPerfect :older_man:

3 个赞

是的,ACE、TUI、Milkdown 中的任何一个都会带来很大的变化,它们都需要用 contenteditable 替换 textarea。当然值得尝试,但在核心层面这是一个大项目。

4 个赞

PR 已上线,修复了缺失的 markdown 高亮问题:UX: Update highlight.js styles by pmusaraj · Pull Request #23999 · discourse/discourse · GitHub

6 个赞

首先,我想说这是我真正希望核心功能支持的内容,但也有必要阐述其复杂性。

Discourse 核心直接使用许多 API 与 TEXTAREA 进行交互,例如 @提及、工具栏将内容插入 TEXTAREA、上传、剪切和粘贴图像等。

所有这些都没有被抽象化,并且假设它正在与 TEXTAREA 进行通信。直接在那里添加 contenteditable 将意味着它还需要正确且非常准确地模拟 TEXTAREA,这很可能会失败。我们需要大量工作来创建一个某种提供程序框架,以便我们可以替换其中的内容。

另请参阅:

Highlighter অবশ্যই এই দিকে একটি দুর্দান্ত প্রথম পদক্ষেপ কারণ আপনাকে দ্বিমুখী মার্কডাউন থেকে টেক্সট ম্যাপিং নিয়ে চিন্তা করতে হবে না।

可能存在一些忍者式技巧,您可以隐藏 TEXTAREA,然后在其上方渲染 contenteditable,并将事件传递给原始 TEXTAREA,但即使那样也需要重新实现 @提及 的定位。

9 个赞

我必须坦诚地说:现在我看到了Trello的编辑器,在编辑器方面,Discourse感觉有点像2000年代的产物:

我认为这类东西很重要。

注意:它仍然100%接受Markdown语法。

1 个赞

我个人不喜欢这样。它太杂乱了。我喜欢 Discourse 中的编辑器在视觉上很干净。我真正看到的只有文本,渲染出来的东西在旁边,这才是它应有的位置。

不过,回到语法高亮的主要问题,这也是我非常希望看到的。至少我希望 # 标题和 ## 副标题能以某种方式高亮显示。我无法告诉你我经常在较长的帖子中搜索,预览和编辑器不匹配时,找到相关的 # 标题需要多长时间。

对我来说,仅仅是在编辑器一侧将 # 标题设为粗体或某种特定颜色,就已经是一个巨大的改进了。

2 个赞

是这样的,不是吗?

这些编辑器是为开发者和编码人员设计的,对于普通用户来说非常令人困惑。

但事实就是如此,而且它太深入核心,无法更改。就像草稿问题一样 :wink:

总之——跑题了等等。

1 个赞

这有更接近实现的可能吗?

上下文:

1 个赞

我们已经开始在这方面工作了 @lindsey 会在我们进展时分享信息

9 个赞

听到这个消息真是太好了——使用 markdown 对我们的高级用户来说非常棒,但对于我们大多数不太高级的用户来说,学习曲线相当陡峭,这将大大提高我们社区的可访问性。

4 个赞

@lindsey,我不想催促你,但我想问一下你是否能够分享以下信息:

  1. 更改是否会包括互操作性/一个允许插件开发编辑器解决方案的框架。

  2. 同样地,你是否在考虑开发自己的富文本编辑器,例如作为插件。

  3. 你对第 1 点和/或第 2 点的预期时间表的大致了解。

我的背景是关于这个潜在项目的处理方法和时间表

我和 @Rohail_Altaf 正在尝试思考如何最好地处理这个问题,特别是时间表方面。不过,如果你在这个阶段无法分享,我完全理解。

5 个赞

安格斯您好 — 很抱歉这么晚才回复,我们一直在参加公司在东京举行的年度休养会!

我现在无法提供太多具体细节,因为我们仍在敲定实施细节。我认为我们将在未来几周内解决这个问题,至少足以回答这些问题,所以一旦我们了解更多信息,我会再与您联系。

6 个赞

Discourse 现已推出实验性所见即所得编辑器 :confetti_ball:

该基础架构还使我们能够长期应用 Markdown 语法高亮,如果我们选择这条路的话,但有了新的编辑器,它变得不那么必要了。

例如,新的编辑器现在允许你在输入代码时为其应用语法高亮!

5 个赞