Overall I think this is a workable idea, however my most atomic units are usually latex equations.

3 Likes

Perhaps we are firmly in plugin territory on this, which allows us to extend the core app principles :smile:

I don’t think we need to abandon filenames as links inside the source markdown for portability. What I proposed in my feature request is that Obsidian uses a different “display name”. I am hoping the future WYSIWYG editor and other components (search, graph, etc.) can create useful abstractions for note titles.

Great idea - I updated my feature request.

6 Likes

I had some thoughts about that subject. I don’t really understand programming, so forgive me if I point out s.t. what is already described. But maybe I can add an Idea :wink:

The idea of having a textsection/block referenced via the filename (hope I understood that right), seems viable but I think it has the disadvantage for things to get quite chaotic (they will always pop up when searching for notes, you have these “random files” which gain meaning just by they are linking to other notes)

I like the idea of obsidian working just with plain text and that adding a feature, which ads ID’s to every text line just doesn’t seem to work with this sort of file.

As far as I understand when creating a markdown header, there is an ID created which can be linked to. (And this is used already). So, it’s seems to me, that it is already possible to create an ID to a certain text part within a markdown file. But in the current state of Obsidian it can’t be used conveniently for the referencing purpose.

  • When changing a header in an original file, files that linked to this header doesn’t get updated in the way it works, when changing the filename of a note. But maybe it isn’t that hard to implement in the software, to update all files when a header is changed.

  • As for now, the whole “path” is displayed when referencing to a header. So, it would be necessary to have an option to just have the referencing header to be shown or it can’t be read properly.

  • When creating a header, the appropriate formatting is added to this. I think to be more broadly excepted, a form of header with no formatting would help.

I think of a kind of “special referencing header” (maybe invoked with its own command).

  • it creates an ID for referencing a text at the points where you need it (instead of creating ID’s for everything).
  • it hides the formatting so it looks an behaves like usual text
  • It would update when being changed
  • it would prevent the accumulation of “referencing notes”, and it would be still possible to create a note file of its own when needed
  • in another application it would show of as “plain text” to be read

This would seem really powerful to me, without having to give up the plain text tenet. Can s.t. like this work?

1 Like

Hi @ryanjamurphy,

Tada. You can now reference and embed that block anywhere. It doesn’t matter that the linked note contains no text. Its own Backlinks will lead you back to the original note. Edits to the link will rewrite the note title and other backlinks. Magic!

I’m experimenting with this now, but on my end it does not seem that editing the link changes the note title and other links - instead a new note with a different title is created. Am I doing something wrong?

On a more general note, this solution could work in a pinch, but the limitations are just too great and things quickly get really ugly in the File Explorer as well. I do think having blocks as separate notes is fine - it actually makes sense in a way - but agree with others above that there should be a way to display the note content as the link without it being the actual title/file name.

A good workflow for this could be a hotkey that takes a “block” (sentence/paragraph or whatever, really) and prompts you for a shorter note title/file name or creates one automatically (could be the zettelkasten time stamp), ideally this would be a setting since preferences may vary here. Then it would create a new note with the selected content and title and replace the original content with a link to the new note, that actually displays the original paragraph, if that makes sense.

It would also have to be searchable when creating links, so some extra title tag seems to me to be a reasonable solution. Just my three cents. :sweat_smile:

2 Likes

@FriSti I couldn’t say for sure, either way, but my instinct is that the kinds of generated IDs you’re describing wouldn’t be simpler than the text they’re standing in for. The only way to get a simpler ID for a given line in a given file would be to generate it, and then you’re either appending that generated ID to the plain text somehow or maintaining a separate index data file in your Obsidian vault somehow. The latter is likely the direction a successful block referencing plugin will take, once externally-developed plugins are possible.

@Hitchhiker90 Sorry, good point. I hadn’t thought of two-way editing in my “solution.” I wouldn’t expect the filename to change when you changed the [[reference link]]. It’s possible, though, that an embed would work? These are of the form ![[reference link]] (note the preceding exclamation point). I haven’t tested this myself.

1 Like

@ryanjamurphy Thanks for the clarification. It’s impossible to change the file name this way, even with embedding.

Embedding does work but the embedded bit really stands out, so it could be useful in some cases, I guess, but it does have a different feel to it.

Anyway, maybe it’s best to wait and hope for a plugin.

Ah, there are some CSS themes that clean up the look of embedded blocks.

But yes, there are definitely use cases that would benefit from a specialized plugin.

1 Like

Actually every text line has a number (even if hidden), so surely,if it were parsed, this could be used. Line instead of block should be okay.

2 Likes

My thoughts on that in another forum topic: Block reference

1 Like

huh! :thinking: Interesting approach! I think for those of use using a strict folder structure, there would be a hassle of finding a place to put these newly made files, but it sounds interesting. Though For longer strings of text, as you mentioned, there is the limitation imposed by the OS (for windows it’s 255), and the use of most special characters is out of the question. But I think it will do. At least the price of using a Database is probably too high of a price for having something more convenient.

1 Like

The problem with referencing a line number is that as soon as you add a line anywhere above it, the whole thing falls apart.

I’ve been entertaining the idea of plain text block referencing for a while now, and I believe that some ID has to be added to the referenced line. Maybe just a few characters.

1 Like

I think in theory it could be done by tracking, in the same way that Obsidian tracks and adjusts for name changes.

@macedotavares @Dor Indeed, I think the best plugins for this will do both instantiate a block reference with a few characters and then cache and track that instantiation.

If I were to make such a plugin, I would use something like ((double parentheses)) to declare a statement reference. The statement itself can then be the identifier. (This assumes such statements would be unique, which I think is safe.)

Adding a couple thoughts. I think we could get most of the way there with Aliases if there were a way to embed a Page or Header without actually displaying the page title or header (e.g. embed contents only) and to display the contents in-line instead of inside a box.

Example:

  • Make a file called BlockTest.md
  • Type this out: [[blockRef123abc|Content I want to embed.]]
  • This would create a file called ‘blockRef123abc.md’ linked to a line of text “Content I want to embed.”
  • Now I can manually add the text “Content I want to embed.” to the file ‘blockRef123abc.md’.
  • Finally, I can embed this in another file with ![[blockRef123abc]]

The remaining problems are that the whole thing is in a box and that there’s a big “blockRef123abc” title above it.That should just be a display thing. Remove the title and display the content in-line with the rest of the note. We might even be able to do this with custom css? I’m not sure.

Now let’s modify this a bit:

  • Keep your BlockTest.md file, but also make BlockTest_BlockRef.md
  • Open BlockTest_BlockRef.md and type the following:
# blockRef123abc
Content I want to embed.
  • Now, in another file, type: [[BlockTest_BlockRef.md#blockRef123abc|Content I want to embed.]]

This works almost the same way as the first example with the same problems, except that, instead of creating a new markdown file for every single block you want to reference, you’re creating one additional file for each file that contains blocks you want to reference. The number of block reference files are, at most, going to equal the number of non-reference files in your vault instead of the total number of “blocks” that you want to reference.

Having gone through all that, I think a specialized syntax for creating a block is probably simpler (e.g. [[%abc123|Content I want to embed.]]. Though you’d probably need a way to generate a unique ID - at least unique per page, since you would probably do something like ![[BlockTest%abc123]] to embed it

The other problem I see is that any of these solutions would make the text pretty messy and difficult to read in edit mode.

We are able to do such thing by CSS. Many examples in the current CSS library.

I don’t like ‘problem(s)’ :wink:

I’ll be quoting a few posts from Block reference to summarize best practices found in that thread (which is a bit long).

Using H6 headers as blocks (albeit that can be a bit resource-intensive from what I recall).

1 Like

Block-level references for mathematical proofs:

Using header-level embeds:

Using CSS to make embeds inline: