行内主题搜索和链接，例如 Roam 式括号链接

功能
1

I think it’s time Discourse had a faster way to create links to other topics on a given forum. Obviously there is the existing link button and shortcut in the composer, and if you’re really brilliant and happen to know the exact URL of a topic you can even do it without using the link dialog. But there are other apps showing that there can be a better, faster, easier way: invoking a search-and-link dialog in-line.

There is already precedent for this in Discourse with the @ link/search behavior for profiles, as well as # link/search behavior for hashtags. So I’m simply suggesting that search-and-link for topics be added. This would take a very minimal approach, quite like the @ user search, with a quick pop-up in-line topic search based on text you type in the composer, and would not have any fields for Title or any other controls. It would work exactly like @ search except for links. You would use the keyboard to confirm the link, and the first option would be auto-highlighted.

One recently popularized syntax for this is “bracket links”, i.e. [[link-to-topic]]. You type [[ and a search of topic titles is invoked, just like the user or hashtag searches. Another common approach is a / slash menu, though this is usually used for multiple functions. However it is invoked, it would make it super fast and easy to create links between topics, which I personally view as a good thing as it encourages people to reference other existing and related content.

The main issue I see with this particular syntax is it’s different than the currently supported wiki syntax, but also similar. However wiki link syntax is actually used in systems that also support double bracket [[ ]] syntax, but specifically for links that need custom text. So one option would be to use that same distinction, double brackets for a link to a topic that uses the topic title as the link text, or a traditional wiki link for a custom title. Another would be to change link syntax overall, which I doubt is appealing. A 3rd option would be to pick some other in-line link syntax, i.e. a different set of characters that invoke the link search.

I don’t really care exactly how it’s implemented, I just want to be able to search-and-link in-line! I think it would be a great addition to Discourse’s already excellent composer and general convenience features. :slight_smile:

That said, I realize the existing Composer functions are quite good and this is only a convenience feature, arguably for a certain subset of users. It’s definitely a low priority even if there is agreement it would be useful.

6 个赞
2

Something similar exists when you select and move postings to a new/existing topic. Frankly speaking, it’s a PITA in its current form:

  • search takes long time
  • even if you know the topic title and type it in exactly as it is written (correct capitalization etc), the search does not find the topic you want
  • the search finds it, you select it, and then the search goes on before you even have the chance to confirm your selection. Your selection is gone, the search doesn’t even list your selected topic any more

My experience is just the opposite of that, see above.
I’m faster in finding the right topic whem I’m using the standard search function.

1 个赞
3

Hi Oshyan, :slightly_smiling_face:

I really like the idea but…

Topic title is not unique so now when you search a topic you have other additional informations such as tags, categories to help recognize it more but inline might be too crowded and sometimes too many topic match your search to filter it inline.

Other thing:
When you use this panel to insert link you have to confirm your choice with a button click which is super useful I think.

Screenshot_20210815_093116_com.android.chrome
Screenshot_20210815_093116_com.android.chrome1080×2240 168 KB

In inline if you missed the correct topic you have to delete too much and maybe there will be more broken format links than now.

Maybe there is a good way to make it simple and fast but now I think the panel solution is faster and more user friendly.

1 个赞
4

This all sounds like a result of failures of the UI/UX or search functions, not a problem with the idea of in-line linking itself. If you haven’t already, I’d suggest you open a topic to discuss improvements/fixes to the existing “move posts/merge” behavior, given the experiences you describe. But assuming those kinds of problems didn’t occur in the context of my proposed linking approach, would you then find it useful?

Why are you assuming that the in-line search would work any differently from the toolbar-based search? As far as the search-and-display behavior, it should work exactly the same and so would have the same level of ease and utility in terms of finding and selecting the right topic. My preference would be that it differentiate from the existing linking dialog and focus on speed and ease of use, working very similarly to the existing @ search that pops up a little contextual results list. The results list could look exactly like the one on the link dialog, but I don’t want a topic title field, an OK/cancel button, etc. There is already a shortcut that brings that up.

I really don’t know why there would be more broken links. You still need to hit Enter to confirm the topic you selected from the search.

Well, it’s definitely not “faster”. It may be more user friendly, sure, but my suggestion is not to replace the existing toolbar linking, just to add a faster way to link for more experienced users.

I suppose Ctrl-K (shortcut) is a fine alternative and already exists, of course. I just like the ability to use in-line syntax to trigger useful things, and it’s something Discourse already embraces with @ and # . Both of those could also just be accessible with keyboard shortcuts or manual typing without search, but of course there is added value in how they work now. I’m proposing that linking may gain similar value with this approach.

2 个赞
5

Ah ok I understand thanks for the clarification!
This would be an advanced feature and keep the original search panel.
Seems to a good idea for me. :slightly_smiling_face:

1 个赞
8

Just for clear context, what we have today is:

CTRLALTf
search for thing
DOWN
a

For example: In-line topic search-and-linking, e.g. Roam-like bracket links

The trouble is that is is extremely hard to teach about it, but offers (arguably) a larger feature set than the [[ proposal.

5 个赞
9

Oh, that’s very interesting and good to know! However I do think there is a valuable difference between action-from-in-line-syntax and action-from-keyboard-command. Discoverability is one, speed is another.

It’s true that once you learn it, it’s reasonably quick to use that sequence, but having just tried it a bunch of times to test, it definitely feels slower and less smooth than my experience in the (growing number of) apps that support [[ ]] bracket linking. Perhaps this is partly because it involves a shift of attention/gaze, in addition to the novel and slightly awkward keyboard shortcut. The latter may be partially overcome in time (though my basic hand geometry sees some limits to that potential), but the attention shift is always going to have a cost during composing a message.

It’s actually interesting to me that you had desire enough for fast linking to create this somewhat unusual keyboard shortcut sequence (no doubt because many others were used). That suggests a bit to me that you might see some value in the in-line linking idea in general… But I do get the impression there isn’t much support for my suggestion for now. Even so, I’m curious to know at least whether there are any clear blockers to it, e.g. “We use brackets for something else”, “we can’t add another in-line handler or it will slow down all database queries by 30%” or whatever. :grinning_face_with_smiling_eyes:

Anyway, I hope this has at least piqued someone’s interest. I’d still love to have this available, and I imagine once other users had a chance to try it, they might also love it (any Roam users here at all? Obsidian? Logseq?). But at the least I hope I’ve piqued some interest in the idea of in-line search-and-link, and maybe something will crystallize around that in the future. :pray:

1 个赞
10

I see a [[ magic search as workable in a theme component today.

Only caveat is that the completion would strip [[ and replace with a link, not sure how else this could work. This makes ]] kind of pointless though

Keep in mind keeping auto complete open beyond a space boundary may be somewhat confusing

2 个赞
11

That’s good to know! As a non-programmer I don’t really know just how much is possible in theme components (a lot it seems, which is one of the many things I love about Discourse). So that’s pretty cool.

It’s true that in other software the [[ is retained and maintains some value even after the link is added. Or rather I should say, the [[ search doesn’t auto-fill a traditional link, but a specialized internal reference. Because multiple applications support that reference format, it’s portable in a variant of Markdown, so that’s pretty handy.

But anyway, in the case of Discourse [[ is just a familiar in-line shortcut, that happens to fortunately be unlikely to be triggered accidentally. I’d be happy with any other such text-based way to invoke in-line search that met similar criteria, but despite the differences in how it would work in Discourse vs. e.g. Roam, I do see some value in at least having the syntax be the same. Like I said, it’s something of a growing de facto standard. :thinking:

The other thing that occurs to me is that Discourse already has its own equivalent of internal links that get rendered in special ways: it’s how quoting works! So “post:10, topic:200454” will of course link to your reply to me here. Since this link function is intended to be specifically to internal topics, it could just use that and automatically display it as a link to the topic at render time. I can’t decide whether this is more in keeping with how Discourse does things, or less… :grinning_face_with_smiling_eyes:

On the one hand there is already this way of linking, this would just be a different way of invoking the link search-and-selection, and it is very similar to existing @ and # searches as I’ve mentioned. On the other hand it departs from existing linking behavior invoked by Ctrl+K, the toolbar, and other shortcuts. I think, though, that the “post:10” type of link is more similar to the [[ link concept concept as used in other apps, so I’d lean slightly that way… if I had any weight in the matter. :wink: I know of course that this is more theme component territory anyway, so perhaps I do! Maybe you can just weigh-in on whether “post:10” style linking could be done from a pop-up search in a theme component?

12

I just tried out Roam for context.

@codinghorror has mentioned a few times in the past how he is very concerned about how ineffective an inline search can be when you use the composer, though I guess that in the context of documentation and specific categories where stuff is scoped tighter is may be useful.

We had discussions in the past about introducing #784 type syntax which rings very similar to this discussion.

The way roam works:

  1. You type [[
  2. It magics in ]] and places cursor inside.
  3. As you type inside the [[ ]] it performs an auto completing search. Eg:

image
image783×281 14.2 KB

  1. When you finally decide on the link it uses full title eg: [[August 13th, 2021]]

  2. It handles renames of original document automatically updating markup in linking documents.

Anything similar to this behavior would require a pretty extensive plugin to Discourse, hooking into spots where topics are renamed, markdown engine and more. I would put this in the multiple weeks of complex work bucket.

Currently we have:

4 个赞
13

For an interesting implementation to note, I’d recommend checking out https://obsidian.md. They use this syntax in Markdown files and it seems it’s similar to the spec @sam described.

1 个赞
14

OK, so here’s where me using Roam as an example starts to break down if taken too literally. :grinning_face_with_smiling_eyes: I actually stopped using Roam quite some time ago, partly because its in-line search is completely awful. Obsidian is a better example and it’s what I use full-time now, but it requires a download to try and Roam (or Logseq) do not.

Before I go any further, thank you @sam for engaging so much with this idea, which I realize may be a bit out of left field. And especially for giving me a ballpark of the work you think it might take, at least in the way that you’ve outlined it working.

That said, I want to stress that my suggestion is inspired by Roam and similar apps that use this syntax, but I am not interested in trying to fully replicate everything about how it works.

  • It doesn’t need to auto-complete the bracket because the bracket will not be kept in the resulting markdown (in Roam it does keep it, same in Obsidian)
  • Discourse search, as exemplified by Ctrl-K link search, or Ctrl-Alt-F, is better than Roam and, if instantiated in-line, would probably allow me to find a topic of interest in a reasonably short amount of time (i.e. if you think search is useful at all, then it would meet the need described here as-is)
  • Link would use full title, just as if you copied/pasted a link to a Discourse topic in to that same forum in a message
  • Renaming would be handled however Discourse already handles that for internal links

So, to sum up, Roam is just an example to demonstrate the concept and part of the user experience. What I am really suggesting is:

  • Some set of uncommon but quickly typed characters that can trigger an in-line topic search
  • In-line topic search with Enter to select first result automatically
  • Regular Discourse link handling in all other respects
  • Implementation in whatever way would be most in keeping with the Discourse approach to things

The rest of what I’ve said is just musings on what might make the most sense or possible approaches to the problem.

So with all that in mind, does that change the estimate of work required? If not, what exactly about the feature request is making it so much more complicated than e.g. Ctrl-Alt-F + A? I ask because that might help me understand if I can narrow the scope of the request to make costs reasonable, or if it’s just not worth the time needed.

Thanks again!

4 个赞
15

For me, the less compatible Discourse is with regular markdown, the harder some other things would become, like moving content between Discourse and other things that use markdown. (My sites and documentation generally use markdown or MDX.)

If some kind of feature like this gets added, an alternate idea for implementation would be to use a system similar to Confluence or Notion where the / (slash) character opens up a menu.

Here’s Confluence:

Confluence slash commands
Confluence slash commands641×705 37.2 KB

Here’s Notion:

Notion slash commands

If a similar feature were in Discourse, a slash could open up a menu which would include “Link” as an option. If “Link” is selected, then the user could do a search for other posts and a normal markdown link would be inserted in the editor.

I’m not requesting the feature but am just mentioning an alternate idea for implementation that wouldn’t make the raw content diverge further from regular markdown. :slight_smile:

3 个赞
16

If you keep stuff within the existing structures then a theme component can work just fine and the amount of work is not enormous. The [[ is actually handy implementation wise cause it gives you a nice anchor of where to stop with auto complete.

A full workflow example could be:

  1. User types: [[
  2. Composer fills in ]], cursor is in between the brackets.
  3. User types search term eg: [[in-line topic]]
  4. As user is typing search is performed and results rendered in a autocomplete like @mentions
  5. Hit up/down/enter to select.
  6. Once selected [[in-line topic]] is replaced with https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454
  7. If user just moves cursor beyond ]] autocomplete closes and a [[in-line topic]] would just stay in the markdown

Overall building something like this is totally feasible in a theme component , does not amend any server side stuff and would be pretty straight forward to build. I would say an expert could swing something in a day or two, an intermediate would probably take a week or so.

5 个赞
17

Yeah, slash menus are definitely an interesting and cool approach that I like and use in a lot of apps. I think it didn’t occur to me as the way to implement what I wanted in this case because that approach implies a whole set of functionality to be invoked. In other words I think it would be weird/unexpected, for those used to slash menus, for one to only invoke a link search. And while having a lot of other functions on a / menu would certainly be something I’m in favor of, it sounds like a notably bigger feature request to me.

Fantastic, thank you for thinking this through and giving me some idea of the complexity and dev time! That is extremely helpful. I will have to think about whether I can put some of my own money toward it, as I have some other perhaps more important requests I probably need to fund for development. And now that I know more about the keyboard shortcuts this one is more a convenience than necessity anyway.

2 个赞
18

如果通过 kbd 键添加链接到选定文本时支持“创建命名链接”，那将更有趣。我希望此操作的结果是 [选定文本](链接)。

不幸的是，它似乎没有添加到撤销缓冲区中。

2 个赞
19

可以从以下两个网站获得关于/和[[ ]]输入（工作）流程的其他优秀示例，从中获得灵感：

和

3 个赞
20

这个个人知识管理系统+论坛的概念确实具有前瞻性，并且潜力巨大。它并非“全新”（例如，参见 2003 年的“Bliki”），但它不必是全新的。背景是新的，因此这个想法也是新的。PKM（个人知识管理）市场正在快速增长，因为每个人都想要某种类似您描述但又不存在的东西。话虽如此，我认为维基链接并不是正确的解决方案；应该将 Discourse 内置的“链接到高亮”功能（作为当前引用功能的改进/变体）集成进来。“分享”按钮会在您高亮帖子内的文本时弹出，除了提供 URL 外，还应提供一个选项，用于在论坛内使用引用创建新主题（后一个功能隐藏在三个点击之后，并且工作不正常）。但我可以看到创建指向尚不存在的主题的维基链接可能很有用，一旦有人点击并创建它，这些链接就会变成维基帖子。

我认为您的“Garden”是一个绝佳的概念验证，并且很大程度上受限于它是从 Discourse 拼凑而成的（您认为它作为 wiki、zettelkasten 或 Circle/Notion 实例会更好吗？）。如果帖子质量没有得到严格控制，共享 PKM 很容易崩溃：深奥但无用 的内容可能会根深蒂固，而又无法在点击之前辨别内容质量。论坛比传统的 PKM 更能处理开放式的协作知识生产。这里有一个有趣的中间示例：LessWrong 有一个“社区博客”系统，它实际上是 Reddit 的一个分支，并且对他们的目的非常有效。它使他们能够摆脱要求贡献者从一开始就擅长自己所做的事情的挑战；用户贡献（帖子和类似播放列表的帖子集合）不是规范的（与 wiki 上通常每个主题只有一个文章形成对比）。

3 个赞
21

有些方面会更好，但有些方面会明显更糟。为了我的目的，我确实在一些重要方面受到Discourse的限制，但我认为其中一个主要限制仅仅是导航，这似乎很容易解决，如果有意愿和开发资源的话。我有一个想法，我将很快（带着一些资金）提出，希望能有所帮助。

我还认为，尤其是在知识生成环境中，将“版主”概念扩展为更像“策展人”的想法是有价值的。个人知识生成结合了生成者和策展人的角色/活动。但集体知识生成可能需要——或者至少会极大地受益于——值得信赖的人，他们的角色或部分关注点是引用、推广、组织、润色以及其他方式来呈现他人生成的内容、想法等，并使其更容易被能够从中受益的人获取。理论上，Discourse中的维基功能可以成为解决方案的一部分，但这需要进行一些调整。

在协作知识生成、“数字园艺”等方面也有许多有趣的想法。目标是最终形成代表集体视角和理解的单一文档吗？还是同时呈现多种视角？或者两者的某种结合。我可以看到许多处理这些问题和其他问题的可能方法。

最终的挑战是，CDCK可能对Discourse的这些用途不感兴趣（我能理解，它们的效用以及潜在收入在目前来说更加初级和不确定）。与此同时，很少有（甚至没有）其他专注于知识生成的平台，例如维基百科/MediaWiki，能够很好地处理对话、讨论方面，特别是两者之间的互动。在一个完美的世界里，长期的优质讨论可以轻松、流畅地逐步增加提炼出的知识、想法、视角，同时保持归属，并允许输出格式良好、一致的“文档”/人工制品，这些文档/人工制品实际上会让人乐于阅读。维基百科再次是当前有效模式的一个很好的例子，但它非常不完美，需要新的工具和方法来超越仅仅记录知识，而是真正生成见解，探索新想法等。

Discourse现在可以用于这些事情，有些方面比其他方面更容易。但可以做到，它拥有大部分所需的功能……

4 个赞