oshyan
2021 年8 月 15 日 04:27
1
我认为，Discourse 是时候提供一种更快捷的方式来创建指向特定论坛中其他主题的链接了。显然，目前编辑器中已有链接按钮和快捷键，如果您足够聪明且恰好知道某个主题的精确 URL，甚至可以不使用链接对话框直接操作。但其他一些应用已经表明，存在一种更好、更快、更简便的方式：在行内调用“搜索并链接”对话框。
Discourse 中其实已有先例，例如用于个人资料的 @ 链接/搜索行为，以及用于标签的 # 链接/搜索行为。因此，我仅建议增加针对主题 的“搜索并链接”功能。这将采用非常简洁的方式，类似于 @ 用户搜索：在您于编辑器中输入 文本时，快速弹出一个行内主题搜索框，且不包含 标题字段或其他任何控件。其运作方式将与 @ 搜索完全一致，只是用于创建链接。您可使用键盘确认链接，且第一个选项会自动高亮。
近期流行的一种语法是“方括号链接”，即 [[link-to-topic]]。您只需输入 [[，便会像用户或标签搜索一样触发主题标题的搜索。另一种常见方式是斜杠菜单（/ slash menu），不过它通常用于多种功能。无论采用何种调用方式，这都将使主题间的链接创建变得极其快速便捷。我个人认为这是一件好事，因为它能鼓励人们引用其他现有且相关的内容。
我认为该语法的主要问题在于，它既不同于当前支持的 Wiki 语法，又与之相似。然而，Wiki 链接语法实际上也存在于同样支持双括号 [专门用于需要自定义文本的链接 。因此，一种方案是沿用这一区分：使用双括号创建以主题标题作为链接文本的主题链接，而使用传统 Wiki 链接语法来创建自定义标题的链接。另一种方案是整体更改链接语法，但我怀疑这不太有吸引力。第三种方案则是选择其他行内链接语法，即使用另一组字符来触发链接搜索。
我并不太在意具体如何实现，我只希望能实现行内的“搜索并链接”！我认为这将是对 Discourse 原本就已出色的编辑器及通用便捷功能的一大补充。
话虽如此，我也意识到现有的编辑器功能已经相当完善，而这项功能仅属于便捷特性，或许仅适用于部分用户。即便大家一致认为它很有用，其优先级也肯定较低。
6 个赞
tmomas
2021 年8 月 15 日 07:19
2
oshyan:
我只是希望能够进行行内搜索并链接！
当你选择帖子并将其移动到新主题或现有主题时，已有类似的功能。坦率地说，其当前形式非常令人头疼：
搜索耗时很长
即使你知道主题标题并完全按照原文输入（包括正确的大小写等），搜索也找不到你想要的主题
搜索找到了该主题，你选中它后，搜索仍在继续，甚至来不及让你确认选择。你的选择已消失，搜索结果中甚至不再列出你选中的主题
oshyan:
这将使在主题之间创建链接变得超级快速和简单
我的体验恰恰相反，详见上文。正确 的主题。
1 个赞
Don
2021 年8 月 15 日 07:44
3
你好 Oshyan，
我很喜欢这个想法，但是……
话题标题并不唯一，所以当你搜索话题时，现在会有标签、分类等额外信息来帮助识别。不过，内联方式可能会显得过于拥挤，而且有时搜索匹配的话题太多，难以在内联中有效筛选。
还有一点：
在内联方式中，如果你错过了正确的话题，就需要删除太多内容，而且可能会出现比现在更多的格式错误的链接。
也许有一种更好的方法可以让它既简单又快速，但目前我认为面板方案更快，也更用户友好。
1 个赞
oshyan
2021 年8 月 15 日 15:37
4
这一切听起来都是 UI/UX 或搜索功能失效的结果，而非内联链接这一概念本身的问题。如果你尚未提出，我建议开一个主题来讨论如何改进/修复现有的“移动帖子/合并”行为，鉴于你所描述的体验。但假设在 proposed 链接方法的上下文中不会出现这类问题，那么你会觉得它有用 吗？
你为何假设内联搜索的工作方式会与基于工具栏的搜索不同？就搜索与显示行为而言，它应完全一样 地工作，因此在查找和选择正确主题的便捷性与实用性方面也应保持一致。我倾向于让它区别于现有的链接对话框，专注于速度与易用性，工作方式非常类似于现有的 @ 搜索（弹出一个小上下文结果列表）。结果列表的外观可以与链接对话框中的完全相同，但我不 想要主题标题字段、确定/取消按钮等。已有快捷键可以调出该对话框。
我真不明白为何会出现更多格式错误的链接。你仍然需要按 Enter 键来确认从搜索结果中选中的主题。
嗯，它肯定算不上“更快”。它或许更用户友好，没错，但我的建议并非要取代 现有的工具栏链接功能，而是为更经验丰富的用户增加 一种更快的链接方式。
当然，Ctrl-K（快捷键）是一个不错的替代方案，而且已经存在。我只是喜欢利用内联语法来触发有用功能的能力，而 Discourse 已经 通过 @ 和 # 体现了这一点。这两者本也可以通过键盘快捷键或手动输入（无需搜索）来访问，但显然它们当前的工作方式带来了额外价值。我提议，通过这种方式，链接功能也能获得类似的增值。
2 个赞
Don
2021 年8 月 15 日 15:54
5
啊，好的，我明白了，谢谢你的澄清！高级 功能，同时保留原有的搜索面板。
1 个赞
sam
2021 年8 月 17 日 01:49
8
为了明确上下文，我们目前拥有的是：
CTRL ALT f DOWN a
例如：In-line topic search-and-linking, e.g. Roam-like bracket links
问题在于，这种方法极难教学，但它（可以说）提供了比 [[ 提案更丰富的功能集。
5 个赞
oshyan
2021 年8 月 17 日 02:13
9
哦，这非常有趣，而且很有参考价值！不过，我认为“行内语法操作”和“键盘命令操作”之间确实存在一个重要的区别。可发现性是一个方面，速度则是另一个方面。
诚然，一旦你掌握了它，使用这个序列确实还算快捷。但刚才我为了测试反复尝试了几次，感觉它确实比我在（越来越多的）支持 [
有趣的是，你竟然为了快速链接而设计了这样一套不太寻常的键盘快捷键序列（毫无疑问是因为很多人都在使用）。这在一定程度上表明，你可能也认为行内链接这个想法本身是有价值的……不过，我确实感觉目前对我的建议支持并不多。即便如此，我仍然好奇是否存在一些明确的阻碍因素，例如“我们已将括号用于其他用途”、“我们无法添加另一个行内处理器，否则会使所有数据库查询速度降低 30%"之类的。
无论如何，我希望这番话至少能引起某些人的兴趣。我仍然很希望这个功能能够上线，而且我想，一旦其他用户有机会尝试，他们可能也会爱上它（这里有任何 Roam、Obsidian 或 Logseq 的用户吗？）。但最起码，我希望我能在“行内搜索并链接”这个概念上激起一些兴趣，也许未来会围绕这一点形成一些具体的成果。
1 个赞
sam
2021 年8 月 17 日 03:31
10
我认为在主题组件中实现 [[ 魔法搜索是可行的。
唯一的限制是，自动补全会移除 [[ 并将其替换为链接，我不确定还有其他方式如何实现这一点。这使得 ]] 显得有些多余。
请注意，在空格边界之外保持自动补全打开可能会造成一定的困惑。
2 个赞
oshyan
2021 年8 月 17 日 04:13
11
这很有帮助！作为一名非程序员，我其实不太清楚主题组件中究竟能实现多少功能（看起来非常多，这也是我喜爱 Discourse 的原因之一）。所以这确实很酷。
确实，在其他软件中，[[ 符号会被保留，并且在添加链接后仍保留其部分价值。或者更准确地说，[[ 搜索不会自动填充为传统链接，而是生成一种专用的内部引用。由于多个应用程序都支持这种引用格式，因此它在一种 Markdown 变体中具有可移植性，这非常实用。
不过话说回来，在 Discourse 中，[[ 仅仅是一个熟悉的行内快捷方式，而且幸运的是，它不太可能被意外触发。只要存在其他类似的基于文本的方式来调用行内搜索，并且满足类似的准则，我也很乐意接受。尽管 Discourse 与 Roam 等工具在实现方式上存在差异，但我认为至少保持语法一致是有价值的。正如我之前所说，这正在成为一种事实上的标准。
另外我想到的一点是，Discourse 本身 就已经拥有其等效的内部链接功能，并以特殊方式渲染：这就是引用功能！例如，“post:10, topic:200454”自然会链接到你在这里对我的回复。由于此链接功能专门用于内部主题，因此可以 直接利用它，并在渲染时自动将其显示为指向该主题的链接。我无法确定这是否更符合 Discourse 的做法，还是不太符合……
一方面，Discourse 已经存在这种链接方式，这只不过是一种调用链接搜索和选择的不同方式，而且正如我之前提到的，它与现有的 @ 和 # 搜索非常相似。另一方面，它与通过 Ctrl+K、工具栏和其他快捷方式调用的现有链接行为有所不同。不过，我认为“post:10”类型的链接与其他应用中使用的 [[ 链接概念更为相似，因此我略微倾向于这种方向……如果我有发言权的话。
sam
2021 年8 月 17 日 06:50
12
我刚刚试用了 Roam 来了解其上下文功能。
@codinghorror 过去曾多次提到，他非常担心在使用编辑器时，行内搜索可能效率低下。不过我想，在文档和范围更明确的特定类别中，这种功能或许会有用。
我们过去曾讨论过引入类似 #784 的语法，这与当前的讨论非常相似。
Roam 的工作方式如下：
输入 [[
系统会自动补全 ]] 并将光标置于其中。
在 [[ ]] 内输入时，会自动执行搜索补全。例如：
当你最终确定链接时，它会使用完整标题，例如：[[August 13th, 2021]]
它会自动处理原文档的重命名，并更新链接文档中的标记。
要实现类似的行为，需要为 Discourse 开发一个相当复杂的插件，涉及主题重命名、Markdown 引擎等多个环节。我认为这需要数周时间的复杂开发工作。
目前我们有：
4 个赞
justin
2021 年8 月 17 日 15:27
13
有一个值得关注的有趣实现，我推荐查看 https://obsidian.md 。他们在 Markdown 文件中使用了这种语法，看起来与 @sam 描述的规范相似。
1 个赞
oshyan
2021 年8 月 17 日 15:41
14
好的，如果过于字面地理解，我拿 Roam 作为例子的部分就开始不太适用了。
在继续之前，首先要感谢 @sam 如此积极地参与这个想法的讨论，我意识到这可能有点异想天开。特别感谢你给出了关于这项工作量的大致估算，至少是按照你描述的实现方式。
话虽如此，我想强调的是，我的建议只是受 Roam 及类似使用此语法的应用的启发 ，但我并不打算完全复制它们的所有工作机制。
不需要自动补全括号，因为生成的 Markdown 中不会保留括号（Roam 和 Obsidian 都会保留括号）。
Discourse 的搜索功能（以 Ctrl-K 链接搜索或 Ctrl-Alt-F 为例）优于 Roam，如果将其实现在行内，应该能让我在合理的时间内找到感兴趣的主题（也就是说，如果你认为搜索有任何 用处，那么按目前描述的功能就已经能满足需求了）。
链接将使用完整标题，就像你在该论坛的消息中复制/粘贴了一个 Discourse 主题链接一样。
重命名将由 Discourse 现有的内部链接处理方式来处理。
因此，总结一下：Roam 仅仅是一个用来演示概念和部分用户体验的例子。我真正建议的是：
一组不常见但输入快捷的字符，用于触发行内主题搜索
行内主题搜索，按 Enter 键自动选择第一个结果
在其他所有方面遵循 Discourse 常规的链接处理机制
以符合 Discourse 一贯风格的方式实现
我所说的其他内容，只是关于什么最合理或可能解决该问题的思路。
考虑到以上所有情况，这是否会改变对所需工作量的估算？如果没有，那么具体是功能请求中的哪一点让它比例如“Ctrl-Alt-F + A”复杂得多？我问这个是因为，这或许能帮我理解是否可以通过缩小请求范围来使成本合理化，或者这是否根本不值得投入所需的时间。
再次感谢！
4 个赞
j127
2021 年8 月 17 日 19:02
15
对我来说，Discourse 与常规 Markdown 的兼容性越低，其他一些事情就会变得越困难，比如在 Discourse 与其他使用 Markdown 的工具之间迁移内容。（我的网站和文档通常使用 Markdown 或 MDX 。）
如果最终要添加此类功能，一个替代的实现思路是采用类似 Confluence 或 Notion 的系统，即通过 /（斜杠）字符打开菜单。
以下是 Confluence 的示例：
以下是 Notion 的示例：
如果 Discourse 也加入类似功能，输入斜杠即可打开菜单，其中包含“链接”选项。选择“链接”后，用户可以搜索其他帖子，编辑器中将插入一个标准的 Markdown 链接。
我并非在请求该功能，只是提出一种替代的实现思路，以避免 raw 内容与常规 Markdown 进一步偏离。
3 个赞
sam
2021 年8 月 18 日 00:01
16
oshyan:
考虑到所有这些，这是否会改变所需工作量的估算？
如果您将内容保留在现有结构内，主题组件完全可以正常工作，且所需工作量并不大。[[ 在实现上其实很方便，因为它为您提供了自动完成停止位置的清晰锚点。
一个完整的工作流程示例如下：
用户输入：[[
编辑器自动补全 ]]，光标位于两个括号之间。
用户输入搜索词，例如：[[in-line topic]]
用户输入时执行搜索，结果以类似 @提及 的自动完成形式呈现。
按上/下箭头或回车键进行选择。
选中后，[[in-line topic]] 将被替换为 https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454
如果用户只是将光标移至 ]] 之外，自动完成将关闭，[[in-line topic]] 将保留在 Markdown 中。
总体而言，在主题组件中构建此类功能完全可行，无需修改任何服务器端内容，且构建过程相当直接。我认为专家可以在一两天内完成，中级开发者大概需要一周左右。
5 个赞
oshyan
2021 年8 月 19 日 03:50
17
是的，斜杠菜单确实是一种有趣且酷的方法，我在很多应用中都很喜欢并使用它。我觉得自己之前没考虑到这种方式来实现我想要的功能，是因为这种方法意味着需要调用一整套功能。换句话说，对于那些习惯使用斜杠菜单的用户来说，如果 / 菜单仅用于调用链接搜索，可能会显得奇怪或出乎意料。虽然 / 菜单包含许多其他功能确实是我支持的方向，但这听起来像是一个规模明显更大的功能请求。
太棒了，感谢您仔细思考并向我说明复杂度和开发时间！这非常有帮助。我需要再考虑一下是否能自掏腰包支持开发，因为我还有其他可能更重要的功能请求需要优先资助。而且，既然我现在更了解快捷键了，这个功能对我来说更多是便利性需求，而非必要性需求。
2 个赞
thoka
2022 年1 月 29 日 08:41
18
如果通过 kbd 键添加链接到选定文本时支持“创建命名链接”，那将更有趣。我希望此操作的结果是 [选定文本](链接)。
不幸的是，它似乎没有添加到撤销缓冲区中。
2 个赞
可以从以下两个网站获得关于/和[[ ]]输入（工作）流程的其他优秀示例，从中获得灵感：
A modern team knowledge base for your internal documentation, product specs, support answers, meeting notes, onboarding, & more…
和
3 个赞
seong
2022 年6 月 22 日 04:09
20
这个个人知识管理系统+论坛的概念确实具有前瞻性，并且潜力巨大。它并非“全新”（例如，参见 2003 年的“Bliki ”），但它不必是全新的。背景是新的，因此这个想法也是新的。PKM（个人知识管理）市场正在快速增长，因为每个人都想要某种类似您描述但又不存在的东西。话虽如此，我认为维基链接并不是正确的解决方案；应该将 Discourse 内置的“链接到高亮”功能（作为当前引用功能的改进/变体）集成进来。“分享”按钮会在您高亮帖子内的文本时弹出，除了提供 URL 外，还应提供一个选项，用于在论坛内使用引用创建新主题（后一个功能隐藏在三个点击之后，并且工作不正常）。但我可以看到创建指向尚不存在的主题的维基链接可能很有用，一旦有人点击并创建它，这些链接就会变成维基帖子。
我认为您的“Garden ”是一个绝佳的概念验证，并且很大程度上受限于它是从 Discourse 拼凑而成的（您认为它作为 wiki、zettelkasten 或 Circle/Notion 实例会更好吗？）。如果帖子质量没有得到严格控制，共享 PKM 很容易崩溃：深奥但无用 的内容可能会根深蒂固，而又无法在点击之前辨别内容质量。论坛比传统的 PKM 更能处理开放式的协作知识生产。这里有一个有趣的中间示例：LessWrong 有一个“社区博客”系统，它实际上是 Reddit 的一个分支，并且对他们的目的非常有效。它使他们能够摆脱要求贡献者从一开始就擅长自己所做的事情的挑战；用户贡献（帖子和类似播放列表的帖子集合）不是规范的 （与 wiki 上通常每个主题只有一个文章形成对比）。
3 个赞
oshyan
2022 年8 月 9 日 20:10
21
有些方面会更好，但有些方面会明显更糟。为了我的目的，我确实在一些重要方面受到Discourse的限制，但我认为其中一个主要限制仅仅是导航，这似乎很容易解决，如果 有意愿和开发资源的话。我有一个想法，我将很快（带着一些资金）提出，希望能有所帮助。
我还认为，尤其是在知识生成环境中，将“版主”概念扩展为更像“策展人”的想法是有价值的。个人知识生成结合了生成者和策展人的角色/活动。但集体知识生成可能需要——或者至少会极大地受益于——值得信赖的人，他们的角色或部分关注点是引用、推广、组织、润色以及其他方式来呈现他人生成的内容、想法等，并使其更容易被能够从中受益的人获取。理论上，Discourse中的维基功能可以成为解决方案的一部分，但这需要进行一些调整。
在协作知识生成、“数字园艺”等方面也有许多有趣的想法。目标是最终形成代表集体视角和理解的单一文档吗？还是同时呈现多种视角？或者两者的某种结合。我可以看到许多处理这些问题和其他问题的可能方法。
最终的挑战是，CDCK可能对Discourse的这些用途不感兴趣（我能理解，它们的效用以及潜在收入在目前来说更加初级和不确定）。与此同时，很少有（甚至没有）其他专注于知识生成的平台，例如维基百科/MediaWiki，能够很好地处理对话、讨论方面，特别是两者之间的互动。在一个完美的世界里，长期的优质讨论可以轻松、流畅地逐步增加提炼出的知识、想法、视角，同时保持归属，并允许输出格式良好、一致的“文档”/人工制品，这些文档/人工制品实际上会让人乐于阅读。维基百科再次是当前有效模式的一个很好的例子，但它非常不完美，需要新的工具和方法来超越仅仅记录知识 ，而是真正生成见解 ，探索新想法等。
Discourse现在可以用于这些事情，有些方面比其他方面更容易。但可以 做到，它拥有大部分所需的功能……
4 个赞
当然，我知道这更多属于主题组件的范畴，所以也许我确实有发言权！也许你可以就“post:10”风格的链接是否可以通过主题组件中的弹出搜索来实现发表一下看法？
