Hidden Section Titles

Feature requests
#1

Hidden headings could be a great way for people to introduce block style identifiers to their markdown.

A hidden heading would not show in the Preview, and would allow block level referencing without adding visual clutter where a heading would otherwise not make sense.

So many people migrating to Obsidian want better block/section embedding options. This is one way to help them without diverging from markdown principles.

Approach Suggestion:

There are multiple heading styles in markdown to take advantage of. Obsidian could commit to the ## Section Atx-style for normal headings and use the underline style to render those headings as hidden.

Hidden section title of a block that will be embedded somewhere
------
Content of the interesting block

By default, the hidden heading should also be hidden wherever the content is embedded. So both Preview of the source content and embedded content would simply be

Content of the interesting block

Alternatively, maybe Obsidian could introduce a 7th heading level so that

####### These headings would be hidden but still embed referencable

Designating a specific type of heading to be hidden wouldn’t compromise the markdown integrity of our content either. Should we migrate, the heading would simply become visible and parse friendly if the future app environment provided similar rendering options.

As an additional way to manage embedded sections gracefully, this is related to

12 Likes
How to embed a section but skip the first row/heading
Organising The Bible in Obsidian
#2

HTML comments are already allowed and invisible in Markdown - for example:

<!-- REFERENCES SECTION -->

Some programmers’ text editors make use of this feature to allow the programmer to create ‘bookmarks’ that are automatically picked up by the app. Usually, this means using some extra characters to indicate that this is a ‘special’ comment, that should be picked up as a bookmark. For example, using the hash character as the first character in the comment might signal it as a bookmark:

<!-- # BOOKMARKED SECTION -->

These ‘bookmarks’ could then be picked up by a spacial panel, or via a plugin. Is that what you had in mind?

4 Likes
#3

That’s such a great feature to point out! But special panels and external plugins are not what I have in mind here. There are thousands of potential users coming from Roam. Many of them are resistant to migrating because Obsidian’s Section Embedding pales in comparison to the block level embedding available in Roam.

What I’m suggesting is a possible way to satisfy most of their needs within a markdown framework that’s also compatible with the approach that the Obsidian developers have already taken.

I am, however, into your suggestion of using HTML comments. Being that it’s already allowed and invisible in Markdown, it’s a fantastic idea and has so much potential! Combining it with your suggestion of using special characters, It could be used to make Obsidian better in numerous exciting ways!

It seems like a perfect integration tool to facilitate many plugin ideas that are brewing.

There are also several Plugin Idea threads that introduce UID management to emulate block style embedding. They tend to rely on solutions that deviate from the self-contained markdown philosophy. And I think some of them are really great ideas. I’m eager to use them if they are created.

#4

How does hiding a header turn text into a Roam-type block? From what I understand of the Roam system, is that ever line is a bullet is a block. In Obs text under a heading may consist of more than 1 sentence, therefore of more than 1 line.

#5

Well it’s up to you as the user to choose how much text you want in this referenced section. That’s a good thing.

I’m not claiming that it turns it into a Roam-type block. Try not to box yourself into thinking that we have to do the exact same thing as Roam to get most of our needs met.

This is just a suggestion that brings us closer to the embedding utility that many users want while staying in the markdown framework.

1 Like
#6

But if it is not what I suggested, then what is the point of suppressing a header?

If that header is just above 1 sentence, then @ryanjamurphy’s suggestion of surrounding that sentence with double square brackets is a simpler solution. Or am I misunderstanding your solution?

Edit: I just saw your link to @benperkins’s workaround with the 6 # in the #general channel. Is that what you mean?

#7

I just discovered the suggestion by @benperkins myself. Yes, it sacrifices one of our heading levels, but it provides a great proof of concept for the idea.

How embeds are shown depends on your CSS. Some of us see the section title in addition to the content in every embed. The option of a hidden section title is one way to give you a choice on how it presents.

@ryanjamurphy’s suggestion is very cool and definitely has utility. But it’s impossible to include any rich content. Latex or Mermaid, no way. Most symbols are out of the question. And for those of us that like using directory structures, it creates such a mess of file clutter. Also you lose title referencing which really simplifies organizing content for some people like me. But there’s an entire thread dedicated to that technique. It doesn’t need to be repeated here.

People organize their their thoughts differently and having various options is a good thing when making an organizational tool.

Having a custom reference is a nice functional middle ground between hidden UIDs, section titles, and associative naming. I like the approach the developers are exploring for embedded sections. It just needs some polish.

#8

?
The issue is that exRoamers have identified block linking as the missing feature.
But it isn’t. Block links in Roam are part and parcel of its foundation as an outliner working through a database. That encourages a particular workflow. And you can’t duplicate outliner advantages with documents - they have very different advantages, like better data security. In many ways the nifty feature in Roam is its document view hiding the outliner base.

Block links are fine. Setext headers may be an option. But they won’t duplicate the Roam experience. Outliners are faster for some types of notetaking and organisation.

2 Likes
#9

Personally, I need a good documentation tool that handles transclusion elegantly and can produce exports that will format well for publication. It seems like Obsidian has the potential to be exactly that.

Though Roam does both outlining and transclusion, which is probably the reason for so much crossover in discussions, the outliner workflow is a different discussion than creating an elegant transclusion workflow. Or, I at least hope to keep that differentiation in this thread.

I really just want Obsidian to get transclusion dialed in and I believe it’s entirely possible to do it well, even within the limiting framework of markdown.

#10

Transclusion should be possible, but is easier in a database.

#11

Just a quick note: if you’re using sentence-level blocks, you don’t need to create a file for it to work. [[You can just link a sentence like this]], and then you’ll be able to use the exact phrasing/transclude it elsewhere.

But yes, your other concerns are the drawbacks of this technique. No mermaid in file names ;<

Requirements for supporting keywords in some way
#12

Linking a sentence like this

WILL create a new file with that title, won’t it? I mean, isn’t that what wikilinks are all about?

#13

I don’t know @ryanjamurphy, I don’t think you should be pushing this method so hard. Users are going to lose their work if they rely on it. It’s neat that it sort of works but it’s a rather precarious trick to place much faith on.

It’s just too easy for the blocks to fall out of sync. Any inline editing breaks the connection. And technically, not having to create a file is true? But creating a file is a necessary extra diligence if you ever want to change anything in the block and keep all instances in sync.

Clearly people are interested in your technique. So it really should exist as a proof of concept demonstration and be filed as a highly desired feature request. Your technique should be turned into an actual feature with a dedicated symbol or maybe triple brackets. That way Obsidian could manage it in a robust manner.

@Klaas, No @ryanjamurphy is correct. You can create as many links like that as you want and a file won’t be created. But if you you Ctrl-click the link, the file will then be created. Try it out. It is pretty cool.

1 Like
#14

Many thanks for that, @goodsignal. I tried it, and it’s pretty cool like you say.

There are 2 flaws;

  • clicking a block referencing link that creates a file is of no use to me; YMMV
  • if [[some sentence]] is altered, the linked to part does not update. Or is there a way, a shortcut perhaps, to achieve an update too?
#15

@goodsignal Good point re: changes to the sentence not auto-updating. I don’t edit these blocks after I create them. Indeed, if the devs are interested in making this less of a workaround and more of a feature, I’d advocate for a different syntax and auto-updating too.

@Klaas Aye, that’s the problem goodsignal was describing.

2 Likes
#16

+1

This is one of the top feature requests for me, as it would eliminate a mundane part of my workflow:

  1. Take reference notes, include “Summary” section with my own words and views in a single paragraph
  2. Create “Aggregator” notes, with include transcluded links to relevant reference notes - essentially creating the rough draft of a publication.
  3. Add text where necessary to clean this up - a introduction, transitions, etc, amongst the various transcluded links.
  4. Copy “preview” document of the “Aggregator” note into another file, remove “Summary” heading that repeats throughout, publish.

It would be nice to eliminate that 4th step.

3 Likes