Obsidian / Tokenz

Use your favourite icons, special characters and frequently used snippets with ease!
You can insert them to your document using short code mappings:

Built-in short code maps:
- emojis, like :smile: 🙂 or :wink: 😉 (1800+ installed by default),
  and the classic, good old
- smileys, like :-) 🙂, 8-D 😎 (installed by default)
User defined short code maps. You can use any format you’d like: /prog-50 ▋, .success 🏆, !movie 🎥 For further explanation and a short configuration guide see 2. User defined code maps .

Demo video showing the features:

Configuration

1. Installation

1.1 From Obsidian’s Community plugin collection

Suggested method, the easiest way to install:

Open settings (Gear icon)
Click Options / Community plugins / Community plugins, Browse… button
Search for “Tokenz”
Install and Enable
Start typing some pre-installed token, e.g. :)
1.2 From sources

It’s also possible to install it manually:
Get the sources: git clone https://github.com/ferenk/obsidian-tokenz
Init the sources folder: cd obsidian-tokenz; npm install
Build the plugin: npm run build
Create a folder in your Obsidian wallet: mkdir <your wallet's path>/.obsidian/plugins/tokenz
Copy the plugin’s files main.js, manifest.json, styles.css into the folder just created
Restart Obsidian and enable the “Tokenz” plugin
Start typing :)

2. User defined code maps

It’s easy to define your own code maps. You can choose any format for your short codes (tokens). But you can also mix different formats (see 4.).

Choose a name for your code map, e.g my code map
Create a folder named data in <Your wallet’s path>/.obsidian/plugins/tokenz
Create an index file of the code maps in the data folder just created. It’s name must be maps.lst.
Example data/maps.lst:
```
my_code_map.json
```
Create your own code map file. Its structure is very simple, for example here are are the codes for our sample paragraph
(it also demonstrates the mixed usage of different token formats)
Example my_code_map.json to enter the sample lines
```
{
    "/prog-20":         "▎",
    "/prog-50":         "▋",
    "/prog-80":         "▉",
    ".success":        "🏆",
    ".idea":           "💡",
    "|tv_episode|":    "📺",
    "!movie":          "🎥"
}
```

And now you can insert these symbols to your document this way:

Format	Short code example	Result
IRC style	`/prog-20 20%, /prog-50 /prog-90 90%`	=> ▎ 20%, ▋ 50%, █ 90%
CSS class	`.idea, .success`	=> 💡, 🏆
Any “crazy” style	`\|tv_episode\|`	=> 📺

3. Settings

Highlighting

Token text highlighting is enabled for all kind of code blocks by default, but you can enable/disable any sets of block names with rulesets. The format of these rulesets is:
{+|-}<block name pattern>, ...

The rules are separated by commas and the rules are applied in the order of appearance. You can use the wildcard character * to match any character sequence (even “”) and the ? character to match any single character. Some examples:

+*: Enable highlighting for all block names
-?*: Disable highlighting for named blocks but still enable it for unnamed blocks (?* ensures that the length of the name is at least 1)
-*, +html: Enable html block highlighting, all others are disabled
-*, +*js*: Enable highlighting for all block names containing “js” (e.g ‘dataviewjs’ blocks), all others are disabled

And a final example with an explanation of how it is applied:

-*, +*js*, +javascript, -*json*

( +* ) (Hidden rule)
This is the default starting state, every evaluation starts with this. It enables highlighting for all block names.
This is a practical starting state for negative rules.
-*

You can start with this rule to have the opposite starting state. Now all block names are disabled, even the empty ones (use -?* to keep them enabled).
This is ideal for positive rules.
+*js*

This rule re-enables highlighting for all block names containing “js”
+javascript

Enable “javascript”, too
-*json*

This rule disables highlighting for all block names containing “json”

So as the result of this ruleset, the empty block name will be disabled, "js" and "dataviewjs" (for example) will be enabled, "javascript" will be enabled, too. But "json" will be disabled.

Note that the order of the rules matter. Rule 4 has to appear later than rule 2, because *json* is more specific than *js*. So the rule containing “js” would erase the effect of a previously applied rule containing “json”.