obsidian-export icon indicating copy to clipboard operation
obsidian-export copied to clipboard

Draft for partial file ignoring with tags.

Open 0xForerunner opened this issue 2 years ago • 9 comments

I'm a DND dungeon master and often find myself wanting to hide only some information within a file. Here is an example of how it could look.

# Interesting Title

Here is some information I want to be exported.

%% BEGIN-EXPORT-IGNORE %%
Here is some information I want hidden.
%% END-EXPORT-IGNORE %%

Here is some other public info.

This is a draft PR. I'm just looking for a go-ahead from the maintainer so I can clean this up, add tests, and add the relevant flags to the cli.

0xForerunner avatar Aug 08 '23 05:08 0xForerunner

#158

0xForerunner avatar Aug 08 '23 05:08 0xForerunner

Aside from my commentary on #158, it should be possible to implement this entirely through postprocessors, as opposed to adding some form of preprocessing instead.

I probably have some examples of dropping sections of markdown based on encountered elements in the markdown event stream, if you need them.

zoni avatar Aug 09 '23 11:08 zoni

It is possible for the markdown part, but it’s much more work and quite a bit more error prone (I tried it and decided that it sucked haha). I think the concept of a preprocessor could be useful for others as well. To add to this, the preprocessor method also works on the yaml frontmatter. I don’t think it would work correctly using a post processor. There might be some crazy way you could hack that together but it would be awful. 

0xForerunner avatar Aug 09 '23 14:08 0xForerunner

As well, if you would like to support obsidian style comment removal, then that should be done as a preprocessor as well since the comments can span multiple markdown events. This would be quite cumbersome to do as a postprocessor.

0xForerunner avatar Aug 09 '23 18:08 0xForerunner

just my 2cents

I would go for something like

```no-hugo-export
secret content
```

using the existing markdown code fence syntax than introducing a new one

or

```spoiler
secret content
```

and working on the hugo side to hide those spoilers - I trust my players to not read them ;-)

epsilonhalbe avatar Sep 16 '23 22:09 epsilonhalbe

just my 2cents

I would go for something like

secret content

using the existing markdown code fence syntax than introducing a new one

or

secret content

and working on the hugo side to hide those spoilers - I trust my players to not read them ;-)

The triple back tick makes the content look different for me though, which I don't want. It should be completely invisible in obsidian read mode.

0xForerunner avatar Oct 05 '23 05:10 0xForerunner

@zoni any thoughts on accepting this using a preprocessor? I truly think this is the correct approach. (see my reasons above).

0xForerunner avatar Oct 05 '23 05:10 0xForerunner

I'm sorry, but unfortunately no, this does not feel like the right approach to me. I'm not convinced of the necessity or value of preprocessors in general, and for this specific use-case, it definitely does not feel like the right approach. There are many edge-cases that this will not work correctly with.

Consider for example the following Markdown, which might be written as help documentation as part of this PR:

# Ignoring sections

The following syntax block may be used to ignore content while exporting:

```
%% BEGIN-EXPORT-IGNORE %%
This is ignored
%% END-EXPORT-IGNORE %%
```

Your naive regex-based approach will omit this, leaving an empty code block which is incorrect behavior. Content within code blocks should be left as-is.

This is just a simple example, but there are more situations like this that will crop up when doing pure text-based processing, instead of building on top of the Markdown event structure.

zoni avatar Oct 06 '23 15:10 zoni

I'm sorry, but unfortunately no, this does not feel like the right approach to me. I'm not convinced of the necessity or value of preprocessors in general, and for this specific use-case, it definitely does not feel like the right approach. There are many edge-cases that this will not work correctly with.

Consider for example the following Markdown, which might be written as help documentation as part of this PR:

# Ignoring sections

The following syntax block may be used to ignore content while exporting:

%% BEGIN-EXPORT-IGNORE %% This is ignored %% END-EXPORT-IGNORE %%

Your naive regex-based approach will omit this, leaving an empty code block which is incorrect behavior. Content within code blocks should be left as-is.

This is just a simple example, but there are more situations like this that will crop up when doing pure text-based processing, instead of building on top of the Markdown event structure.

I'm not sure I understand your example? Of course it would omit that, that's the point is it not? There is no reason to not omit something just because it's inside a code block. There are many valid reasons why you might want to do that.

Anyhow if you disagree I understand, although I really do feel a preprocessor is the right call here. Feel free to give it a shot using the markdown events when you have some time and let me know if you think that solution is better. I did give that a go and found it to be quite overburdensome.

0xForerunner avatar Oct 06 '23 17:10 0xForerunner