Draft for partial file ignoring with tags.

[ewoolsey]

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.

[ewoolsey]

#158

[zoni]

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.

[ewoolsey]

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. 

[ewoolsey]

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.

[epsilonhalbe]

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 ;-)

[ewoolsey]

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.

[ewoolsey]

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

[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.

[ewoolsey]

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.