[Question] A Question About {{Variables}}

[FelipeRearden]

Hello again @Taitava !!!

I'd like to ask you about Variables:

• Did you create the variables for your plug-in or these variables are from Obsidian API ?
• Is it possible to create a feature request to add new variables ?

I'm thinking about a workflow that could need new variables as {{workspace}} and {{file_name}} without the .mdin the end

• it is just an idea now, but I decide to check you before deep dive.

Have a great day !!!!

[Taitava]

Hi again @FelipeRearden ! 🙂

Variables in this plugin are made by me, so yes, I can add new variables or change the behavior of current ones. So feature requests about variables can be made! 🙂

• {{file_name}} without .md has another variable which might be a bit confusing: {{title}}. I think I'll need to add to the description of {{file_name}} that if user wants the name without the extension, then use {{title}}.
• {{workspace}}: Good idea! I have not used workspaces in Obsidian, so I'm not familiar with them. In Thank you + Question + [Feature Request] Alias (names) for commands  #6 you had a shell command in the command palette screenshot that used &workspace=WK1. Should {{workspace}} variable give the current workspace's name, for example WK1?

Todo:

• Add to the description of {{file_name}} that if user wants the name without the extension, then use {{title}}.
• Create {{workspace}} variable.

[FelipeRearden]

This is amazing @Taitava !!!

I'm so excited about this plug-in. We can do everything :)

• Thanks for letting us create FR for variables too!

• Sorry about {{title}}: It was my mistake but a warning in the text for the user would be great .

• You are 100% correct about {{workspace}}

Workspaces are a big deal in my Obsidian workflow. As you start to use, you gonna see that its a great idea but needs a lot of improve yet.

---

Now that I know that is feasible, let me deep dive to see if we can bring some new {{variables}} to our friends.

My idea is to use Shell Commands to input predefined text into other plug-ins to automate plug-ins that needs users decision.

---

We talk soon. Thanks again and have a great day!

[Taitava]

Now that I know that is feasible, let me deep dive to see if we can bring some new {{variables}} to our friends.

Great! 🙂 Just one tip: I think best ideas come from using the software (like you have done) and then over the time you just notice things that could be better. That's when the most useful ideas arise, and so far this is what your ideas have been: command aliases, the {{workspace}} variable, and to make the alias field to have focus. All of these came from a real need.

I just notice myself sometimes creating ideas and new features just because it's fun to create them, but it has a downside too: sometimes I develop a feature that is not actually never used or needed. These are ideas that did not arise while I was actually using the sofware in a real, practical situation, but that came to my mind when developing the software, which is a situation where I might be blind to what an actual user might need. For example, my feature idea #13 is something that came to my mind as "hey we could have this", but now that time has passed, I've come to think about maybe we will not need it. (Maybe the same holds true for #12 too).

TL;DR: Good ideas develop over a long period of time. Be careful what you wish for - you might get it. 🙂

My idea is to use Shell Commands to input predefined text into other plug-ins to automate plug-ins that needs users decision.

Can you elaborate more on this? I didn't quite get what you mean by "to automate plug-ins that needs users decision". 🙂

I have been thinking about a variable like {{input}}. When a command is executed, if the variable is present in the command, the plugin could open an small popup window and ask the user to type something, that will then be the value of {{input}}. But then again, like I said above, I need to think if this is something that would actually be needed. Is there a use case for this? Would you find this useful in your workflows?

[FelipeRearden]

I 100% agree with you @Taitava.

That’s why is so important the relationship between developer and testers and users. In my country we have a say that “two heads thinks better than one”:

• everybody has your own way of life, principles, experiences and together we can make a product better. :)

Classic Example: Search and Replace in Current File
Imagine I have to always search for the phrase “Hello World” and replace with “hello friend” in a subset of notes.

I could use Shell Commands to create the expressions to:

• copy Hello Friend to clipboard
• Paste in the find field
• Press tab to focus on the replace field
• Copy hello friend to the clipboard
• Paste
• Press enter

Using the QuickAdd plug-in in can stack all commands in a MACRO and use a single hotkey to start the automation.

• Search and Replace in Current File
• Shell Command 1
• Shell Command 2
• Shell Command 3 ....

That’s why I love your plug-in so much. Now I can do things that Obsidian can’t

• A new world opens to me.

If you want I can bring more real examples to you.

—-

The {{input}} idea is fantastic and could fit into many workflows.

• I’m thinking about a list of inputs to let the user choose with one is going to be the {{input}}

Let me think about it and I get back to you..

It’s always a pleasure talking to you. I always learn something when we talk.

[Taitava]

That’s why is so important the relationship between developer and testers and users. In my country we have a say that “two heads thinks better than one”

Thats true! We have a similar saying, it goes something like "Two pairs of eyes sees better than one pair".

Using the QuickAdd plug-in in can stack all commands in a MACRO and use a single hotkey to start the automation.

That plugin sounds interesting. I don't have much time to check it now, but maybe later. I just wanted to note that you can also chain multiple shell commands into one. For example in Linux you can use && operator (maybe its the same in Mac?) to "first execute one command, and if it succeeds, execute the next one". E.g. cd AnotherFolder && mkdir NewSubFolder && touch NewFile.md. (In Windows the operator is &).

If you want I can bring more real examples to you.

I think I understood this example quite well, it's a good one 🙂 . Nice that Mac has a command to emulate the keyboard. I do not know if Windows/Linux has those, maybe?

P.S. {{workspace}} variable is now implemented and will come out with version 0.3.0 sometime soon. 😉

It’s always a pleasure talking to you. I always learn something when we talk.

Same with you!

[FelipeRearden]

Different words and the same meaning :)

I think you gonna like QuickAdd . It’s a great companion to Shell Commands.

Wow ‘&&’ looks amazing. I didn’t know and I’m gonna try

• I could copy to clipboard, copy than paste with one command
• Thanks for the help :)

Yes it’s amazing.didn’t know about Apple script since 2 months ago. I’m almost sure that there is something for Windows too.

Thank you very much for the new {{variable}} !!!!!!!

As I can see we will have many talks about this amazing plug-in in the next few days and weeks !

So, we talk soon @Taitava !

Have a great day!

[Taitava]

Thank you! 🙂

I'm thinking about opening a Discussions section here in GitHub. Then we can better separate idea discussions from already decided, to be implemented features (= issues). I haven't used Discussions before in my own repositories, but I've used it just a little bit in Dataview's GitHub repo.

Some general principles:

• If you encounter a bug and you are pretty certain it is a bug, you can still open a new issue directly.
• If you have a feature request that is quite simple and that has clear benefits and probably does not require much discussion about how it should look like from the user's perspective, you can still open a new issue directly.
• If you are unsure whether a problem you encountered is a bug or if it could be solved with better guidance/documentation, then open a new discussion. Of course for clear documentation errors (README.md or in application guidance) you can open an issue directly.
• If you have a feature request, but you are unsure how it should finally work, or unsure if it's possible to create, or you feel that it might otherwise need extensive discussion before implementation, then open a new discussion.
• Discussions can always be transformed into issues, if we later decide that a discussion should lead to concrete development.
• Also issues can be transformed into discussions.

I'll close this issue now, as the two variable related things are now done and waiting for a release. Have a great day too! 🙂

[Taitava]

And when you talked about workflow ideas earlier, in the Discussion section there is a "Show and tell" category where you can post ideas about use cases for this plugin. 🙂