Autocomplete Menu for {{Variables}} in the Command Field

[FelipeRearden]

@Taitava , It’s just an idea for us to talk :)

Add a feature that open a context menu when the user is writing {{ in the command field

• This context menu will provide all {{variables}} available in Shell Commands for an easy selection;
• After choosing the variable from the list, }} will be placed in the Command Field and the user continues to type.

[Taitava]

Nice idea! In programming, these kind of context menus are generally called autocomplete menus. (Edit: Whoops, it's autocomplete, not autocomple)

This is a good addition, and I'll have to see what it take to implement something like this. The best thing would be to find a ready made JavaScript component for this. And I can check if Obsidian's autocomplete menu can be invoked by plugins - but I'm not sure if it's public API or not.

Things to consider:

• If a user types {{, then open the menu with all variables, listed alphabetically.
• If a user continues typing, and they have something like {{file, then the menu should narrow its content to the following: {{file_name}} and {{file_path}}. Or, if the user has something like {{path (= they did not type from the beginning of a variable name), then the menu should show: {{file_path}} and {{folder_path}}.
• If a user already has an incomplete variable like {{clipb}}, and they go type more text in it, the menu should open again.
• If a user hits enter, autocomplete the selected variable, then move cursor after }}. If a user hits tab, then autocomplete and move cursor before }}. This is similar to how Obsidian autocompletes links.
• If a variable requires a parameter, it depends on the variable if we can autocomplete it or not. If it's e.g. {{file_path}}, then the autocomplete menu can simply have: {{file_path:absolute}} and {{file_path:relative}}. But if its {{date}}, then we can only give the colon: {{date:}} in addition to the variable name. A user should then hit tab, not enter, so that they can immediately write the parameter.
• Add a setting: Autocomplete variable names (or something). On by default. Users that do not want to be interrupted by popping up menus can turn this off.

Making something like this to work flawlessly and to feel natural, can require quite a bit finetuning. I'm willing to start thinking on this, but it won't be a quick addition. 🙂

Added 2021-11-23: In addition to autocomplete variables, a later version could also support a custom autocomplete list. That would be a file where a user can list what ever they want to be able to autocomplete, e.g. shell command names (echo, git status, xdg-open ...), variable usages with certaing arguments ({{date:YYYY-MM-DD}}, ...) etc.

[FelipeRearden]

Hello @Taitava !!!!

Thank you so much for the reply and I’m glad that you liked!

these kind of context menus are generally called autocomple menus.

Great!!!!! Now I learn how to write about this kind of feature. Thank you very much for this info (I’m always learning ....)

Things to consider:

100% agree. It’s impressive to me the amount of details that needs to be considerate in a feature like this to run flawlessly.

Making something like this to work flawlessly and to feel natural, can require quite a bit finetuning. I'm willing to start thinking on this, but it won't be a quick addition. 🙂

I can imagine! ( I don’t even had courage to define this a Feature Request!)

Totally agree with you. This a secondary feature that just improve a feature this works perfect right now!!!

I’m pretty confident that finding good workflows for #17 and #16 is the best path at this moment. Because it has a groundbreaking impact for our community.

---

I’m gonna change the title description to autocomplete menus :)

Thanks again and have a great day!!!!!!!!!

[Taitava]

Thanks! 🙂

( I don’t even had courage to define this a Feature Request!)

Eventually, it will be converted to an issue, so it becomes a FR. It's useful, now it's only about the timing and implementation technique, that are yet unknown.

I’m pretty confident that finding good workflows for #17 and #16 is the best path at this moment.

Yes, those plus #11 and #5 should be the top priorities for now. Which one of these four gets handled first, is just a matter of which one I happen to find a solution first. Then there are light workload issues like #27 and #30 that don't take too much time from the bigger ones even if they get implemented first.

I just came across a plugin named Autocomplete. I haven't tried it yet, I just wanted to write it down here. I'll check how it handles the autocomplete menu and if there's any ideas I could borrow (with referencing the source, of course).

[FelipeRearden]

There is something that wanna ask you and always forget .... are you on iOS or Android for smartphones?

[Taitava]

Do you mean if I have an Androind/iOS phone? Currently I have an iPhone, but I've had Android phones before for many years. And I have an Android tablet + a spare phone.

[FelipeRearden]

I’m asking this because when I think about {{input}} and {{output}} my mind reminds of Siri Shortcuts.

Which is the only automation tool that I know a little bit.

Now I know if I think about some idea I can use the Siri Shortcuts analogy as a way of communication :)

[Taitava]

Actually, I haven't used Siri, so I don't know its shortcuts - sorry 😄

[FelipeRearden]

No problem :)

[Taitava]

Actually, I'll create an issue for this now. I created today a project board here in GitHub, and it seems that there's no way to include discussion topics there. 🙁

Still, let's keep converstation here (if GitHub lets me convert this to an issue so that the this topic won't get locked), the issue will be a placeholder where I'll later add concrete decision when it's finally time to implement it.

[Taitava]

Nice, the discussion is still open even after creating a new issue from this topic. 👍

[FelipeRearden]

Great @Taitava !!!!

[Taitava]

Now that #43 is done, I think it also makes it a bit easier to make the autocomplete menu to suggest static arguments for certain variables, e.g. when a user is typing file_p, suggest {{file_path:absolute}} and {{file_path:relative}}, not just {{file_path}}.

[FelipeRearden]

That's great news @Taitava !!!

#43 is giving us a new world to explore :)

[Taitava]

Obsidian 0.12.17 is now released. Looks like Obsidian devs are reading our mind: 😎

New EditorSuggest is now accessible to the API to provide in-line suggestions, like auto-complete. This is what powers the link auto-complete, tag auto-complete, and slash commands.

At this point it's an insider build, so it takes a few weeks until it's available to users who haven't bought Catalyst (including me). I might consider buying the Insider level Catalyst at some point, but not sure yet.

I would probably not increase the minimun Obsidian version of this plugin before 1.0.0, at least not for a non-crucial convenience feature like this autocomplete thing. So whenever this autocomplete feature would come to SC, I'd make it check if Obsidian is new enough to use the autocomplete API. If Obsidian is old, then the autocomplete simply won't be available, but SC would otherwise work. 1.0.0 will at last require a newer version of Obsidian. Currently the minimun Obsidian version for SC is 0.12.12.
Edit 2021-11-26: I have decided to raise the minimun required version of Obsidian at the same time with the release of this autocomplete feature. Obsidian API does not mention in documentation comments what methods can be used in what version. When I upgrade the Obsidian API in my development environment, I cannot know what other methods were not available in an older API version. So, it's easier to raise the minimum required version of Obsidian.

[FelipeRearden]

Looks like Obsidian devs are reading our mind: 😎

When I saw this today, I open git to tell you the same thing !!!!!!

I were faster than me :)

This is a gift for this feature :)

[Taitava]

Obsidian 0.13.0 brings one more feature:

You can now setInstructions for an EditorSuggest.

(Source: https://forum.obsidian.md/t/obsidian-release-v0-13-0-insider-build/26919)

I haven't tried it, but to me it sounds like a possibility to include the variable specific help texts from the bottom of SC's settings to the autocomplete list. I haven't started even any experiments on this feature, but I have already hoped that there would be a way to include these help texts - and now I know there is! 😎

[FelipeRearden]

Obsidian 0.13.0 brings one more feature:

You can now setInstructions for an EditorSuggest.

(Source: https://forum.obsidian.md/t/obsidian-release-v0-13-0-insider-build/26919)

I haven't tried it, but to me it sounds like a possibility to include the variable specific help texts from the bottom of SC's settings to the autocomplete list. I haven't started even any experiments on this feature, but I have already hoped that there would be a way to include these help texts - and now I know there is! 😎

What a great news @Taitava !!! I happy to know that Obsidian is helping us to achieve our new future features :)

Have a great day!!!!

[Taitava]

I added one more idea to my first post:

In addition to autocomplete variables, a later version could also support a custom autocomplete list. That would be a file where a user can list what ever they want to be able to autocomplete, e.g. shell command names (echo, git status, xdg-open ...), variable usages with certaing arguments ({{date:YYYY-MM-DD}}, ...) etc.

[FelipeRearden]

I added one more idea to my first post:

In addition to autocomplete variables, a later version could also support a custom autocomplete list. That would be a file where a user can list what ever they want to be able to autocomplete, e.g. shell command names (echo, git status, xdg-open ...), variable usages with certaing arguments ({{date:YYYY-MM-DD}}, ...) etc.

Fantastic @Taitava !!!!

Some comments:

01 - A new Tab Variables & Dictionary that contains our variable list and a custom autocomplete list

02 - As a source of information There is a new plugin in beta that I think you gonna like :)

https://github.com/tadashi-aikawa/obsidian-various-complements-plugin

Have a great day!

[Taitava]

01 - A new Tab Variables & Dictionary that contains our variable list and a custom autocomplete list

1. Do you suggest that the variables help section would be moved to a new tab from the bottom of the shell commands list? I can consider it.
2. I was thinking that the custom autocomplete list would be just a file that can be edited manually, so that it would not clutter up the settings UI as I guess it will be quite rarely edited. What do you think?

02 - As a source of information There is a new plugin in beta that I think you gonna like :)

https://github.com/tadashi-aikawa/obsidian-various-complements-plugin

Have a great day!

That's a good example of autocomplete, thanks! Have a good day, too! 🙂

[FelipeRearden]

1. Do you suggest that the variables help section would be moved to a new tab from the bottom of the shell commands list? I can consider it.

I was holding this thought since the first post about beta because I didn't want to bother you with UI.

For users like us with 30/40+ SC I think would be better to have the variables list in a new Tab. It's easier to confirm the right syntax of a variable in a new tab instead of scroll down and get back to SC#15 for example

2. I was thinking that the custom autocomplete list would be just a file that can be edited manually, so that it would not clutter up the settings UI as I guess it will be quite rarely edited. What do you think?

100% agree. This way we can have a SC_Dictionary.md in a folder inside our vault to insert the words :)

I highly recommend take a look at that plugin. I think it will bring many ideas because it's very complete with a lot of settings options

• One command that I like is to reload the autocomplete list after making a change in the file :)

That's a good example of autocomplete, thanks! Have a good day, too! 🙂

This plugin have the same concept that you described: it's a .md file that is used as Dictionary :)

[Taitava]

1. Do you suggest that the variables help section would be moved to a new tab from the bottom of the shell commands list? I can consider it.

I was holding this thought since the first post about beta because I didn't want to bother you with UI.

For users like us with 30/40+ SC I think would be better to have the variables list in a new Tab. It's easier to confirm the right syntax of a variable in a new tab instead of scroll down and get back to SC#15 for example

Hmm, it's a good idea, but too bad that currently the tab system works a bit against your idea: when scrolling down the list of shell commands, the tab buttons will disappear (= scroll out of view). So, to be able to go to the Variables tab, you'd need to first scroll back up. And I'm not sure I'd like to change it so that the tab buttons would be always visible - it would take up some space when I'd like to see more shell commands.

Maybe this autocomplete menu will bring some help and relaxation to this - at least if I'm able to include the help texts in it. What do you think, would it reduce the need to visit the Variables tab?

2. I was thinking that the custom autocomplete list would be just a file that can be edited manually, so that it would not clutter up the settings UI as I guess it will be quite rarely edited. What do you think?

100% agree. This way we can have a SC_Dictionary.md in a folder inside our vault to insert the words :)

Hmm, I was actually thinking that the file would not be among the normal note files, but rather in .obsidian/plugins/obsidian-shellcommands, next to the data.json settings file. The reason (in my opinion) is that the custom autocomplete list file is not a logical part of notes in an Obsidian vault - it's more like meta knowledge about shell commands. It's different from the Various complements plugin: that plugin wraps heavily around the content of the vault, and it's dictionary.md file will probably be filled with words similar to what is used in the notes. And I'd guess the file will be edited more often than SC's custom autocomplete list file. What do you think?

And the extension might be something else than .md, as there's no need for Markdown formatting. Maybe it could be YAML:

"echo": "Outputs text"
"mycommand": "Help text for for my custom command"
"{{date:YYYY-MM-DD}}": "This is the date format that I use all the time."
"a-command-without-help-text": ""

This format would allow inserting custom help texts so the user can remind themselves about what each of the things do.

I highly recommend take a look at that plugin. I think it will bring many ideas because it's very complete with a lot of settings options

I installed it now (temporarily, but I'll consider if I'll need it in my school vault). I looked at the settings (max number of suggestions, min number of characters for trigger, delay for trigger, custom dictionary paths) and I think I'd like to start with only one setting: an ability to turn autocomplete off. Then, if we feel that some of these settings are needed for SC too, I can add them.

The difference between SC and Various complements is that VC concentrates on the autocomplete function, and so it's reasonable for it to have all these settings, but for SC the autocomplete will be a nice to have feature (and a really cool one!), but not in the middle of the plugin's focus. That's why I try to minimize the amount of settings related to autocomplete, so that they will not take much space in the settings view. But like I said, settings can be added later if needed.

• One command that I like is to reload the autocomplete list after making a change in the file :)

Would be a nice feature, but unfortunately I guess it's not easy to accomplish if the file will reside in the plugin's folder, rather than being a normal note file.

[Taitava]

Another thing that can possibly ease up access to the list of variables, is that there will be a new documentation vault for SC (#99), that I'm planning to open in Obsidian Publish when 0.7.0 is released. It contains a folder for variables, and a note for each variable. The variable notes contain the same help texts as what are shown in the settings, but some variables may also have some extra information.

[FelipeRearden]

Hmm, it's a good idea, but too bad that currently the tab system works a bit against your idea: when scrolling down the list of shell commands, the tab buttons will disappear (= scroll out of view). So, to be able to go to the Variables tab, you'd need to first scroll back up. And I'm not sure I'd like to change it so that the tab buttons would be always visible - it would take up some space when I'd like to see more shell commands.

You are absolutely right @Taitava ! The tab will disappear and that way that is now is the best for the user :)

Maybe this autocomplete menu will bring some help and relaxation to this - at least if I'm able to include the help texts in it. What do you think, would it reduce the need to visit the Variables tab?

Absolutely ! I use the Variables section for two reasons:

• To see the exact syntax of a variable that I already know
• When creating something new, to see if there is a variable that helps me to achieve this new thing (less frequent when you are a experienced user)

So for the daily usage the autocomplete will fill 90% of our needs for the Variable Section :)

Hmm, I was actually thinking that the file would not be among the normal note files, but rather in .obsidian/plugins/obsidian-shellcommands, next to the data.json settings file. The reason (in my opinion) is that the custom autocomplete list file is not a logical part of notes in an Obsidian vault - it's more like meta knowledge about shell commands. It's different from the Various complements plugin: that plugin wraps heavily around the content of the vault, and it's dictionary.md file will probably be filled with words similar to what is used in the notes. And I'd guess the file will be edited more often than SC's custom autocomplete list file. What do you think?

After reading all of your comment in this section I 100% agree with you. The meaning for SC autocomplete in very different from autocomplete in a .md note

We just need to make it simple doing just like you described :)

I installed it now (temporarily, but I'll consider if I'll need it in my school vault). I looked at the settings (max number of suggestions, min number of characters for trigger, delay for trigger, custom dictionary paths) and I think I'd like to start with only one setting: an ability to turn autocomplete off. Then, if we feel that some of these settings are needed for SC too, I can add them.

After using VC is just feel that we could have in SC only this feature without any users setting :

• min number of characters = 2 or 3 to avoid showing autocomplete when writing e

Another thing that can possibly ease up access to the list of variables, is that there will be a new documentation vault for SC (#99), that I'm planning to open in Obsidian Publish when 0.7.0 is released. It contains a folder for variables, and a note for each variable. The variable notes contain the same help texts as what are shown in the settings, but some variables may also have some extra information.

Will be amazing !!!!! Just like we use the https://help.obsidian.md/Index when we have some doubt about a feature !

Let's keep talking !!!!

Have a great day!!!!

[Taitava]

After using VC is just feel that we could have in SC only this feature without any users setting :

• min number of characters = 2 or 3 to avoid showing autocomplete when writing e

That's a good idea. I'm thinking about 2 characters, as then you can type {{ and see a list of all variables. And I'll probably make the maximum number of suggestions to be quite high, so that its easy to see all variables.

Thanks and have a nice day, too! 🙂

[Taitava]

I've now spent a few hours just by finding out what libraries there are that could be used for the autocomplete.

• I didn't actually try the autocomplete feature provided by Obsidian, because just by looking at the API, it looks like it's designed to only work with editor - so it seems to be suitable for note content only, not for simple text fields, but I'm not 100 % certain.
• The couple of community plugins (that are mentioned in this thread) also concentrate on the editor too, so I don't feel like I should spend too much time on interpreting their source code looking for implementation tips, as I think I've found a TypeScript library that can be made to work in Obsidian.

The library: kraaden/autocomplete

By a quick glance, this seems like something than maybe suits for this need. I'm not gonna explain it long, I'll rather give you a demo link: https://kraaden.github.io/autocomplete/

It even has grouping, so pay attention in the demo that when you type a, you'll get two groups: country names that start with a, and continents that start with a. It could be a nice little detail to use different groups like: Variables for one, and let users define their own groups. e.g. Commands, Parameters, Static texts in the custom autocomplete file.

The layout of the autocomplete list will of course be different - mainly the colors will be based on the theme selected in Obsidian. This library requires me to program the actual text matching and replacing parts myself, which is good so that I'll have a lot of control over things. This is to say that if you'd like have the autocomplete feature changed somehow after you've had an opportunity to use it yourself, there should be plenty of room for me to make improvements based on feedback.

kraaden/autocomplete on GitHub

[Taitava]

Damn, I should be sleeping already, but I jumped into a rabbit hole when started to tweak this thing.

It can already search for variables by letters, so a user don't have to type the beginning of a variable's name letter-by-letter, it's enough to type some letters of the variable's name (and of course start with {{, without that no variables will be suggested).

Here the search keyword is {{fa:

• Everything after the caret is exluded from search (= "and some other text" is excluded).
• And everything that comes before {{ or before a space is excluded (echo is excluded).

[Taitava]

Custom suggestions defined in autocomplete.yaml:

Variables:
  "{{date:YYYY}}": "Current year."
  "{{tags:, }}": "Tags separated by a comma and a space."
Custom:
  echo: "Prints text."
I can create a long group name:
  "some long command": "Help text for a long command"

Will turn into this:

So it's possible to define custom {{variable}} suggestions. Of course new variables cannot be created, but this allows creating suggestions that have predefined arguments (e.g. the {{date:YYYY}} variable that gives the current year). By using the group name Variables in the yaml file, the custom suggestion will fit right into the existing Variables group. But you can use a different group, too:

And here are the other two custom autocomplete suggestions:

Note that the suggestion menu is narrower when the content does not need so much space.

[Taitava]

I changed the outlook a bit:

Now it's easier to distinguish help texts from suggestion items. Also the selected item's background color is now --text-selection instead of --interactive-accent-hover. I hope the colors look good on other themes, too.

Just for a nice extra tip, it's possible to put a list of all commands available in your system (+ their help texts) into autocomplete.yaml. I have now CMD commands there. This is how it looks for me now, but I emphasize that these will not be part of SC, this is something you need to set up yourself if you need it. I'm thinking about creating documentation pages that contain lists of shell commands for different shells, so it's easy for users to copy command sets if they want them.

[Taitava]

Released

Just for the record in case discussion continues, this is the point the feature was released.