Command nodes

🙏 Thanks to Chuck for surfacing this excellent tip for all keyboard users out there doing incremental/bullet journaling and who find that command buttons just aren't their thing! For more stuff like this, join our community to share and learn about all things Tana 🫶

Goal

Use one keyboard shortcut to bring up a very specific set of commands.

Instructions

For this example, we're going to build one command that brings up a set of commands for a bullet journaling practice. People who practice bullet journalling (or BuJo) usually decide on a list of keys or "signifiers": bullet symbols that mean different things to the writer. Here's an example of things that might be in this list:

In Tana, we can assume each item in the list is a separate supertag.

Build the command

1. Decide on a prefix for your commands. In this example, we'll use "Bujo:".
2. For each of the signifiers
   1. Create a new command called Bujo: [signifier]
   2. Add the command Add tag, and insert the supertag definition to the parameter
3. Create a keyboard shortcut: Run Create keyboard shortcut in the command line, then record the shortcut you want to use. In this case, we're using Cmd/Ctrl+Shift+P. In the parameter Commands, write the words Bujo:.

Testing the command

To test it, use the keyboard shortcut Cmd/Ctrl+Shift+P

• This will insert the words Bujo: in the command line
• Type space to bring up all the options

That's it 🙌

🙏 Thanks to many community members but especially Ready and Navigator Dee for surfacing this tip in a recent conversation! For more stuff like this, join our community to share and learn about all things Tana 🫶

Goal

To move all nodes to a single place when they get tagged. This is useful if you want nodes of a certain type to live in a place that makes sense for breadcrumb navigation.

Instructions

For this example, we're going to build a command that moves all tagged nodes to the Library.

Build the command

1. Create a new command called Move to Library
   1. Add the command Move node
   2. In the parameter Move node target, pick the Library from the dropdown. There are other locations to choose from as well, and you can insert a reference to any node you want as the target
   3. Add parameter Remove references after moving node and give it your desired setting. Most would want it unchecked so it leaves a reference of the node in the original location
   4. Add parameter Move original node and check it. This ensures that even when you use the Add tag action on a reference, it moves the original node to the desired location and not the reference (which won't achieve the goal of this command)
2. Add the command to the config of the supertag in question. Go to AI and Commands > On added, and add a reference to the command here.

Testing the command

To test it, use the supertag on a node:

• If used on a node, it should immediately send the original to the specified location and leave a reference behind.
• If used on a reference, it should send the original - wherever it is - to the specified location.

That's it 🙌

Goal

Community member Jérémie asked: "I created a new supertag called #feedback to collect feedback from my team. They can easily add a comment and add the supertag. Is there a way to receive a notification when the tag has been added?"

Great question! Below was the solution that worked 👇 For more stuff like this, join our community to share and learn about all things Tana 🫶

Instructions

Build the command

1. Create a new command called Notify me
   1. Add the command Run a command line command
   2. In the parameter Commands, write Notify @[your tana account email]. Example: Notify @fei@tana.inc
2. Go to the supertag config you want to be notified on, to the section Trigger commands on events, and add a reference to the command to the On added section:

Testing

Test the command by adding the supertag. You should

1. get a notification that a notification has been sent, and
2. see a blue dot appear in your notifications. Clicking it shows you which node you were notified on.

🙌 That's it!

🙏 Thanks to Navigator Theo for sharing how to implement this "focus mode" idea on Related content sections! For more stuff like this, join our community to share and learn about all things Tana 🫶

Goal

You want to dial up your focus by hiding the Related content sections.

Instructions

Build the single-command toggle

See this example on how to build it. Build the first section called "In the schema", then come back here.

Configure visibility of related content

To configure the related content sections you want to toggle the visibility on, each section will need a node filter where the checked state of the is visible field determines whether they show up or not:

• Navigate to the Related content section in the configuration:
  • For supertags, Cmd/Ctrl+Shift click on the tag itself
  • For nodes, run the command Configure node
• For every related content section
  • Run the command Add contextual content on the related content nodes, and add >Node filter:: >is visible:: true (checked)

Testing

Test the command by running the Toggle visibility command on the node. It should make the related content sections appear/disappear.

Optionally, you can add the Toggle visibility command to the node as a button, and then use that instead.

🙌 That's it!

🙏 Credit goes to Ulises RJ and Navigator Theo for coming up with this elegant solution! Join our community to share and learn about all things Tana 🫶

Goal

You want to build one command that toggles the state of something, like a checkbox. The key that unlocks this is the obscure Run commands in parallel command, and this is an excellent use for it. The uses for a toggle are endless; this example will demonstrate how to build a visibility switch for command buttons.

Let's call it the single-command toggle.

Note: This is more like a proto-command, something that isn't useful on its own, but unlocks many creative uses.

Instructions

In the schema

1. Create a checkbox field called is visible.
   1. In the Hide field setting, choose Always
2. Create a command node for checking the is visible field:
   1. Name: visibility ON
   2. Add node filter: >NOT:: >is visible:: true (checked)
   3. Add command Set field values
   4. In parameter Fields to set: >is visible:: true (checked)
3. Make another command node that removes the field:
   1. Name: visibility OFF
   2. Add node filter: >is visible:: true (checked)
   3. Add command Remove fields
   4. In parameter Fields to remove: is visible (field definition)
4. Create a third command node for toggling between the two commands:
   1. Name: Toggle visibility
   2. Add command Run commands in parallel
   3. In the parameter Commands to run, add references to the two commands you created earlier
5. Test the command out:
   1. On any node, run the command Toggle visibility. It should add the is visible field to it, checked. Running it again should remove the field.

The commands are now ready to go.

Configure visibility of command buttons

To configure the commands you want to toggle the visibility on, each command will need a node filter where the checked state of the is visible field determines whether they show up or not:

• Create or find a node that has many command buttons you want to hide
• For every command, add the >Node filter:: >is visible:: true (checked)
• As you do this, the buttons should, one by one, disappear from the node.

Testing

Test the command again by running the Toggle visibility command on the node. It should make the buttons appear/disappear.

🙌 That's it!

Further ideas

• Bind a custom keyboard shortcut to Toggle visibility so you can easily toggle the visibility of buttons with the same keystrokes. See video above.
• Add the toggle command as a button: then you can toggle things with a mouse-click instead
• Use the same thing to toggle the visibility of related content sections

There is a command called Set view definition. It can set the Group, Sort and Display settings of a node view.

There is no good UX for this at the moment, so the instructions are not conventional nor friendly for beginners. But right now, this is one way of doing it:

• Mock up a node that will have sample child nodes representing the data you'll be applying this command on
• Then, create the exact view settings you want with Group, Sort and Display.
• Go Cmd/Ctrl+K > Debug Node on the parent node and look at Views for node:

• Clone the fields over to the command node so it looks like this:

When you run this command on a node, this should change the view settings according to your configuration.

Use Insert relative date command, here's an example:

The Autofill command can generate a new node title and description based on the URL.

To set up the command

• Create a new command node
• Add the Autofill fields command
• Add and check off Autofill title and Autofill description parameters to change both
• Add Model to use to control which model you prefer. If left empty, Tana will pick the one that returns the answer with best quality and consistency

To run the command

• Run the command on a URL node using the command line
• Put this command node in the Commands section of a supertag you use for URLs. Press the button to run the command.

While it isn't possible to tag things when you're sending things from Tana Capture, you can have Tana do some post-processing magic to convert written-out tags to real tags once they arrive the Inbox—no AI needed!

1. This method uses a simple Tana Paste command that you can run on the Inbox node, which targets all new children that have "#" in them.
2. Once you've created the command, you must add it to the On child added section of the Inbox node. You can find it by running the command Debug node on the title of the Inbox.

Here's Theo describing the command:

"All it does is paste the nodes that have # in them and that are not tagged, using Tana Paste.

Say we add this through Tana Capture:

buy milk #todo

The command will paste that exact text back in with Tana Paste, where ${name} is buy milk #todo and ${sys:content} are any child notes that are present. Using Tana Paste, #todo will be added as a tag.

Note: this creates a new node, so the created date will change, meaning you’ll lose the time that the node was captured through Tana Capture."

Set [field] command only works on field types Option, Instance, User and Checkbox.

Currently, the easiest and most foolproof way to do this is to not share it but instead build the supertag, with its fields and anything else necessary for the supertag to work, from the ground up in the new space.

That said, if you still want to move a supertag over that exists only in your private workspace, the main work is to ensure that there's nothing in the supertag that references something in your private workspace, otherwise it will appear as broken to others once it's moved.

It's like packaging up a zip file. You can't just zip up a bunch of shortcuts, you need the real files in there or the recipient will only see broken shortcuts.

You'll also have to remember to move over other things like field options, commands, and ensure that no saved view options contain elements from your workspace. Basically, you must ensure that nothing you're moving over from your workspace contains references from your workspace.

To bring all nodes (except system nodes) into the supertags, fields and commands you want to move, use the command "Bring referenced node here". Alternatively, you can move each necessary node separately too if you for example want the field definition to exist outside the supertag. But the key is that everything that is connected to what you're sending over gets sent over too, otherwise there will be missing pieces.

Yes, you can. Make a new command node, and use the command Insert Tana Paste with the following prompt:

- ${name} #note
  - Based on:: [[^${sys:nodeId}]]

The first line is the new node. It uses the name of the current node to inform the name of the new node by using the title expression ${name}. The supertag #note can be enough for Tana to find the right tag to use, but you can specify it more precisely by adding the ^nodeID to it. See the Tana Paste doc for more info on this convention. To retrieve the nodeID of a supertag, run the command Copy link (HTML formatted) on a supertag definition and paste the results. It will paste with the nodeID written out:

The second line is the field. After the name of the field and the double-colon :: is a reference to the current node that the command is being run on, which it is able to target by retrieving the nodeID of the current node using the title expression ${sys:nodeId}.

This is what the command node should look like:

Special thanks to Navigator Emmanuel Galanos for this clever solution!