[Poll] RemNote Library Tag Handling

[hannesfrank]

Problem

In v1.2.1 the pasting syntax of RemNote got reworked a bit which broke most demos.

Pre v1.2.1 when resolving a tag it would check if you have any rem with that name and use it. This way I could include a Tags section in a scroll with a list of hopefully unique tags and the Demo section could use them directly.

This does not work in v1.2.1 any more since pasted tags are resolved to top-level rem. This means a scroll can not be made self contained anymore.

How to handle it?

Here are some possible ways to handle the Demo section each with pros and cons (mostly cons since the old way was pretty flexible).

1. Use top level rem as tags.
   • The simplest solution. Tags section could be a list of references to these top level rem.
   • Con: The scroll is not self contained, i.e. deleting leaves the tags in your KB. Can also be a good thing:
   • Pro: Tags are still there if you want to use a similar functionality later.
   • Con: You can not use hierarchical search to look up the correct tags of a scroll.
   • Con: Creates a bunch of #Stubs.
2. Use the full path to the tags (#[[Custom CSS/Scroll/Tags/tagname]]), basically recreating the current self contained scrolls.
   • Con: Users would be required to paste the Scroll at the root of Custom CSS which is one more source of errors.
     • If I ever implement an API this would not be a concern.
   • Con: This does not work in one paste ATM, but theoretically RemNote’s pasting routine could be modified to first create all rem and then apply the tags.
3. Use an external tag list/archive
   
   
   • Basically an extension of full path tags that would currently work.
   • Pro: Have one location to list all tags.
   • Con: No nice formatting.
   • Con: Creates a bunch of #Stubs.
   • Con: Scroll names can clash. I intended to identify Scrolls with a unique id e.g. com.github.user.repo. I guess the size of the Libray does not justify that though. Also the tags themselves can clash without some extra config/CSS postprocessing.
4. Drop the Demo (maybe 2 step install)
   • Users paste only paste CSS code and some tags, then maybe optionally a Demo using using full path as outlined in 2 or 3 provided those are viable.
   • Con: No direct Demo to play with.
5. Import JSON
   • Con: Harder to install: requires download and Import.
   • Con: It’s not documented yet how to create the correct JSON format yet.
6. Drop the library and use other means of sharing
   • RemNote document snapshots: Very easy sharing for lay users. Very easy import (just click the +). No version control, no auto update/update notification possible, not discoverable/searchable.
   • CSS Snippets on Github: Is version controlled and somewhat discoverable, watching repo can notify for updates (but notifies for all commits, not just installed), no nice way to install.
7. Tutorials
   • In case of 4. provide make gifs/youtube videos demonstrating the scroll.
   • Con: High effort: Someone has to record gifs/youtube videos.
   • Pro: Explains complex stuff better than a small demo.
   • Con: Can’t see and play around in own knowledge base.

• Top-level Tags
• Full Path Tags (requires devs to implement it)
• Tag List
• No Demo
• JSON
• RemNote snapshots
• Snippets on Github
• Tutorials

[UMNiK]

How about making the tags unambiguously “special”, e.g. by prefixing them with a string of garbage like @_` or something, so people can play around with the demo and then rename the tag to be more convenient if they like it or delete it if they don’t?

@Martin Any hint as to what may be best for the (hopefully) upcoming native custom css manager?

[hannesfrank]

The problem is not ambiguity, but where the styling tags are stored. Unlike as in Roam when using a tag in RemNote it has to be created first and it persists even after the tag is not used anymore. Like if I use add #[[@_super special tag]] it creates this top level rem and after deleting the scroll it still clutters your KB.

I mean starting them with the same prefix at least provides some way of finding them all if they were top level rem, but I still would feel better if they were somehow scoped and you don’t need to worry about cluttering your knowledge base when trying things out because you know you can clean them up 100% easily.

[UMNiK]

Sure, that was my point - the prefix makes it easy to find them again and clean in bulk if needed (if there are ever official ways to add new power-ups through a menu).

Regarding the main vote: what about adopting shared documents with a link to a (unique) repository and a (standard) tutorial for manual updating as the main way to share? At the moment your library seems like the only place where snippets are sometimes updated (for themes it’s a bit better), most people just post them as a code block, so I’ve taken to manually adding links to their posts on the same level as the codeblock. At least this way there is an implicit obligation to add a link to a permanent location (I’m not sure whether people are too afraid to ask you to host their stuff on the library, or what). The updates would have to be checked manually, but at least people would know where to check and the barrier to entry would be eliminated.