Block reference

@Théry in the Obsidian CSS discord offered a little more refinement. I’m just copying it here because this is where people will find it. (I haven’t tested it yet)

For basic hiding of H6 in Preview:

.markdown-preview-view h6
{
  display: none;
}

Refining margins with the embedded text:

h6 + p { margin-top: 0; }
h6 + ul { margin-top: 0; }

Sources:

7 Likes

:grinning:
Using “quicker”, a third-party software, is close to the block reference function, which is not so convenient to use, but the effect is already good. Two-way link, synchronous modification can be as small as one letter.

https://getquicker.net/Sharedaction?code=1ac2f804-1444-4897-72e8-08d8309f8f6f

在用Obsidian 搜索需要被引内容后,
使用该动作几乎已经达到block reference(块 引用)的效果。
而且引用能支持到非常小的粒度。
同步、非同步修改也能做到。

我来补充一下对这个动作的使用需要注意的一些地方:
1、如果开始目录没选对,引文也可以引,但在软件内会看不到被引文功能所使用的文本。
2、每次打开不同库都要ctrl 重新设定一遍文件夹
3、按住ctrl键点击动作按钮,可以重新指定库目录

不知道开发者是否能看得到此贴。我尝试在qq上给开发者单独发过几次信息都没有任何响应。

块引用是非常重要的功能
见文:


上文是南开大学博士王树义对块引用粒度重要性的的描述,

简单而言小粒度的块引用可以大大的提升链接的效率和可能性,让之前所有做过的任何笔记到现在都可以轻松的产生链接,构建“第二大脑”,这个功能的意义还是很大的。而大粒度的块引用“双向链接”是是非常多的软件很久之前就已经具备的功能并没有什么独特性。目前Obsidian不借助quicker动作的话只能做到[[ ]] 盒子 [[ # ]]盒子内的小单元引用的级别。

如果把[[ ]]形容成一个 盒子 、那么[[ # ]]就是这个盒子里的小单元 、而(( ))块 就是更小的内容的载体。obsidian目前缺失块的功能,我见目前这个大贴中很大多国内外朋友都在想各种办法解决此缺陷,而且此大贴目前也成为了需求类的最大贴。

我想到了一更多从软件层面就解决块引用的思路,这是基于借助标签来实现块引用的办法,在标签的基础之上。标签只要能全局修改,它就和块引用 (block reference)功能其实就一样了。目前国内的 蚕子 也已经用quicker实现了标签同步修改的功能,如下连接:

https://getquicker.net/Sharedaction?code=75a8ce9b-4a2b-4a0d-b57b-08d83289803e

这个功能的粒度 已经非常独有,它所达到的引用的块是比Roam Research要细腻的Roam Research根本无法做到。而且可以对行文格式外观没有破坏,但是如此会带来一个困扰,原来的标签功能无法正常使用,还有它并不能达到真正的块引的快捷方便的效果。

https://www.getquicker.net/Sharedaction?code=1ac2f804-1444-4897-72e8-08d8309f8f6f
另外还有一个解决办法就是利用quicker软件扫描全部的.MD文件做全局对某符号的识别实现块引用。用[[☛]]符号配合一个内置的☛引文文件做回链,但这个方法会带来一个缺陷就是把图谱(思维导图)的关系破坏,大量的链接只链向一个点。所以目前全局修改标签的方法是最佳的块引用方法。

但这个“标签块引用”功能要更好的实现需要软件原生内置才行,所以我到此贴中把这个想法反馈给开发者,开发者完全运用 #标签 的理念来做块引用,只需要在软件内把 #标签 换成其它符号比如 ((双括号 即可,如此标签和块引互相就不会干扰,打出((命令后 可全文检索关键词来引用,和用搜索功能一样,用这个命令实现可以把软件变得非常易用,((命令可以在标签功能的基础上 加上1、源文可回链 2、可全局修改3、在图谱中关系可见

就是 使用(( 双括号符号后 输入需要的字符 会出现下拉框 供关联筛选 ,选中某需要 块引用的内容 后就变成了 标签(块)一样的功能,这个标签也具备1、源文可回链 2、可全局修改3、在图谱中关系可见。

最简单说
这个标签符号 (( 要具备 1、全局搜索功能 2、回链 3
全局修改功能 就做到任意粒度的块引用了,这种功能也具备独创性。

补充:
回需要回链的定位可以用在软件中在 (()) 已经被标签的内容符号后计上十六进制(或36进制更简短)数值就可以大量数据的快捷定位做顺序记号产生回链,比如这是.MD文件中的第10亿个块 就可以表示为 ((源被引的块内容))5f5e100 即可轻松对数据定位,它就可以是第十亿零一个数据 ((被引的块内容))3b9aca01的源,就可以轻松做成了回链,这个定位的数据可以在软件内单独建立一个储存文件实现识别或者用比较好的算法再软件内无需多余文件直接实现,十六、三十六进制数值有字符短软件无需高算力就能识别的优势。

另外((被引的块内容))3b9aca01的3b9aca01和(())都可以在软件的CCS文件定制为隐藏,这样文本格式就会最大程度的不被破坏。
如果不想破坏md的格式进行导出其它软件使用,可以设定一个去除编码导出的选项功能即可。

如果有md文件需要到其它软件用的用户,开发者完全可以把这种(()) 引用的功能设置一个开关,这样即方便了只用obsidian的大部分用户,也方便了md文件需要到别的地方再使用的用户。

附上进制在线转换网页,这种十六、三十六进制转换是非常微小的算力就能做到
https://tool.oschina.net/hexconvert/

1 Like

标签实现块引用的想法很好。由于标签前后都需要空格,中文一句话可以没有空格,但英文如何实现?

Please speak English on the forum. If you want, you can add a Chinese translation at the bottom of your posts.

10 Likes

I created a feature request that might be relevant for people who want/need block-level references. It’s not necessarily a replacement for blocks, but it might cover some use cases. It would be useful to be able to create links without having to remember which file or section has the content being referenced. If the links suggested at the moment of typing would include content, after selecting a suggestion, a link with the right location in the right file would be inserted, e.g. [[File##Header]].

In case you think that might be useful to you, please give it some love: Suggesting links based on content

Hi all,
This is a very good “discussion” going on…
I’d like to make some other suggestions reading all this:

  • The idea of the atomic note is for me (personally) a building stone of a good PKM-system.
    The remarks of @juvoni about Block Referencing and Block Transclusion (which are two very different things) were very insightful and got me thinking…
  • I tested some things and saw that when you drag a note from another vault into your current vault it creates a copy and references is with ![Block Description](Block Reference) in the current vault. I understand that this is linked to the “New link format” which is set to “Shortest path when possible” (correct me if I am wrong).
  • I also would like to add that I really like the idea of adhering to the MarkDown standards and the basic Obsidian Manifesto which is explained on the website.
    I do understand people who want to have Roam-like features. My honest meaning (which I also read in some remarks) is that the makers of Obsidian should stick to their basic ideas and not give in to make a Roam “clone”, which I don’t believe is going to happen seen what great suggestions come from the community.
    That being all said (sorry for the long intro):
  • Would it be and idea to explore the idea of storing metadata in an Atomic Note (Zettle) and do Transclusion of the metadata Zettle into the Zettle/Note you want?
    I need to do some testing here as I still don’t have a solution for Relative Path referencing which would keep your Vault easily transferable as we would adhere to the MarkDown standards. Again I don’t believe building proprietary stuff or Add-ons to achieve this will help the ecosystem in the long term. Obsidian is really great (and I mean that) but there is no one who can tell if some other even better system will emerge in the future (I doubt it but OK :wink: ). I also understand that some people “mix” different softwares to maintain their Second Brain. Not adhering to the MarkDown standard would be nefast for those people.
  • Another thing which I really like about Obsidian is the fact that you can freely edit your Zetlles in every outside system. I use this method a lot to add new block references when I am creating new research. This is something which Joplin does not allow at all so keep this great feature please!

Let’s try and find a good solutions which adheres to the MarkDown standard and keeps the Obsidian Manifesto alive. In my honest opinion the makers should try and keep that also in mind when opening the Obsidian platform for third-party add-ons. Not saying you should build an Apple ecosystem with very strict rules and kick out everybody and everything you don’t like. I would nevertheless not allow add-ons which violate the standards and start creating MarkDown files that are not usable in other environments without first having to convert them to ‘normal’ again.
Looking forward to see a good solution emerging for this issue!

3 Likes

From what the devs have said I understand they won’t go for block references. They have implemented links to headers (I personally use that a lot in combination with transclusions) and that’s it.

I am quite happy with their decision now that I have more experience with header links and transclusions.

1 Like

Hey @Klaas,
Thanks for mentioning this. I wasn’t aware of the new ‘developments’.
Would you comment mean you are ‘forced’ with the H6-approach you also mentioned in the discussion or can you link whatever header you want?

From DIscord →

Licat: “Officially the core app will stay at heading level references. Once plugins opens up it’ll be up to a plugin maker to implement block reference however they want with respect to syntax.”

How block reference is done in an app called liandi:
“Basically the way block references are done is that Markdown is parsed into a tree of blocks, and the app assigns an ID to each block, which is saved in the JSON. The original markdown file is then discarded and the JSON is the new source of truth.”

Silver: “I have heard potential plugin authors come up with solutions that do not require converting Markdown to JSON but instead add IDs inline, which may still play well with the other apps that understand markdown.”

@Silver
Good remark on the “other Apps that understand MarkDown”. Goes with my latter remarks on keeping the ecosystem of add-ons clear.
Letting add-ons transform MarkDown in a way that other MarkDown systems wouldn’t be able to ‘understand’ the files anymore is in my opinion the creation of proprietary format.
My opinion (personal meaning) is that such add-ons should not be ‘promoted’ in the Obsidian ecosystem or at least with serious caution warnings regarding portability and usability when working with different softwares.

3 Likes

Already sought out.
Works with every header.
Only remark:
You would need to know the name of the header ( :frowning: ).
Can’t we just display the available headers in the notes when #is typed in the [[ link?

@RikD: yes. So, you start with

  1. [[, get presented with a list of note titles,
  2. move your cursor to the one you want, but do NOT click on it,
  3. instead, type #, which will result in a list of all the headers in that note,
  4. when you have found your header, click on it.

Bonus: when you have followed these steps, you get an ugly looking ling like so
[[filename#headername]].

What you can do is after step 3 you can type | (= pipe character), then type a name for your link and it look like [[your chosen name]].

2 Likes

20 posts were split to a new topic: Link suggestion is not triggered when # is typed

Here’s a video from the Foam developer with some interesting ideas about block referencing in markdown

5 Likes

This looks very promising, hope Obsidian is considering how they might do this in the future too.

Effectively adding a UID isn’t it? Licat has said he’s not keen on that as a solution.
I think he anticipates someone addressing the issue when the API is out, possibly with a little database. As a plugin, users can choose to use it or not but the md remains intact. If someone produces a UID alternative, then they could choose that instead.

I think the option will come via a plugin.

2 Likes

That would be perfectly fine and welcome!

1 Like

I have seen Licat and/or Silver state explicitly that they will not implement block references, links to headers is as far as they’ll go.

1 Like

With the important caveat that it’s likely we’ll see multiple plugin options for block reference to suit everyone’s tastes!

Chant with me, everyone: API! :clap: API! :clap:

11 Likes