Espanso: Feedback request: Default Global Variables

[federico-terzi]

Hello everyone,

I'd really like some feedback from your side about a little feature I'm planning for the next release.

Since version 0.5.0, espanso supports Global Variables that allow the user to define a variable once and then use it in any match, with clear benefits.

A nice addition at this point would be to add some useful global variables "out of the box". A couple of examples to make it clear:

Up to now, if you wanted to use the Clipboard extension, you would have needed to define a custom variable, which is definitely verbose:

  - trigger: ":a"
    replace: "<a href='{{clipboard}}' />$|$</a>"
    vars:
      - name: "clipboard"
        type: "clipboard"

Adding default global variables, would allow a much nicer sintax:

  - trigger: ":a"
    replace: "<a href='{{clipboard}}' />$|$</a>"

Under the hood, espanso would have the following global variable already defined:

global_vars:
      - name: "clipboard"
        type: "clipboard"

The same could go for commonly used data formats with the DateExtension, and so on.

If you have any idea for some default global variables that could be useful "out of the box" for most users, comment on this issue :)

[rbrewer123]

The time and date immediately come to mind. Unfortunately the abundance of formatting options make it tricky to please everyone. I use ISO 8601 time and date strings when I can, so perhaps time_iso -> 19:22, date_iso -> 2020-04-24, datetime_iso -> 2020-04-24 19:22.

The current user running espanso may be handy: username -> rbrewer123.

It might be nice to have some recommended global variable names that users can configure up front, and then expansion packages can assume these are available. For example, user_preferred_email -> [email protected], user_full_name -> Fred Smith.

[federico-terzi]

Thank you @rbrewer123, those are great suggestions

[timorunge]

A nice addition at this point would be to add some useful global variables "out of the box".

I'd argue for KISS.

What I personally really like about espanso is it's simplicity. You are providing a functionality with global variables which is great. But shouldn't it be up to the user to define his own use case for them?

While it might be useful to have some things in common I'd personally rather add them to the default.yaml file during the initialisation of espanso and / or distribute some examples either via the documentation or espanso hub.

[femtocept]

Not sure if this is getting off the original topic, but as to recommended variable names, what if you could set a variable to prepend a character string to all triggers in a yaml file of a certain name (or a package with a given name)? I have a yaml file called dates and all triggers start with a period. If i wanted to change this (perhaps to avoid conflict with another trigger or package) I would have to update the entries. But with a trigger prepend variable I could, say, change "." to ":" and have all of the triggers omit any specific prefix key. Another idea in this vein would be trigger prefix stripping: let's say someone dislikes comma prefixes in a package that uses them and would like to remove all of the commas and use something else instead. You could specify an integer number of characters to remove from the beginning of each and every trigger. In most cases it would be "1", however. I'm inspired by the leader key of vim that is configurable and expected by plugins so to avoid collisions in shortcut commands to an already very full keyboard.

[federico-terzi]

A nice addition at this point would be to add some useful global variables "out of the box".

I'd argue for KISS.

What I personally really like about espanso is it's simplicity. You are providing a functionality with global variables which is great. But shouldn't it be up to the user to define his own use case for them?

While it might be useful to have some things in common I'd personally rather add them to the default.yaml file during the initialisation of espanso and / or distribute some examples either via the documentation or espanso hub.

This is a fair point @timorunge. I'm currently trying to find a good balance between making espanso easy to use for everyone and powerful enough for power users.

At the moment, most tech users are capable of setting up espanso without much effort, but I had many people asking me to make espanso easier. You see, when people are not used to use the terminal often, espanso can become quite difficult to understand.

Variables are another of these things. Many people come from software such as Typinator or PhaseExpress, which come with many built-in variables.

That said, I'm still not sure about this feature. That's why I'm asking :)

[federico-terzi]

Not sure if this is getting off the original topic, but as to recommended variable names, what if you could set a variable to prepend a character string to all triggers in a yaml file of a certain name (or a package with a given name)? I have a yaml file called dates and all triggers start with a period. If i wanted to change this (perhaps to avoid conflict with another trigger or package) I would have to update the entries. But with a trigger prepend variable I could, say, change "." to ":" and have all of the triggers omit any specific prefix key. Another idea in this vein would be trigger prefix stripping: let's say someone dislikes comma prefixes in a package that uses them and would like to remove all of the commas and use something else instead. You could specify an integer number of characters to remove from the beginning of each and every trigger. In most cases it would be "1", however. I'm inspired by the leader key of vim that is configurable and expected by plugins so to avoid collisions in shortcut commands to an already very full keyboard.

Hey @femtocept, some of these are valid suggestions. If you want to discuss them further, please create a separate issue :)

[timorunge]

This is a fair point @timorunge. I'm currently trying to find a good balance between making espanso easy to use for everyone and powerful enough for power users.

I think you have described your ideas and plans in #255.

At the moment, most tech users are capable of setting up espanso without much effort, but I had many people asking me to make espanso easier. You see, when people are not used to use the terminal often, espanso can become quite difficult to understand.

Variables are another of these things. Many people come from software such as Typinator or PhaseExpress, which come with many built-in variables.

It's a fair point to try to find a good balance between different use cases. It's possible to argue in many different ways and in the end it depends on the audience and the target group (that espanso is aiming for).

Just because other people are used to other software it's (for me) not a valid argument to say "the others are doing it this way, so let's also do it this way". espanso should follow it's on way and it's own principles and guide users who are actually willing to use this software to the way how espanso is operating.
What espanso is doing ATM is great. You can adopt it easily to your own needs with the shell extension which gives you never ending possibilities to use the software.

Coming back to the topic: I think global variables are great. They can and will simplify some of the modules and extensions that people are building. But what is the difference between an internal global variable which is is maybe called time_iso (just grabbing this as an example as well) and giving you back the time (but which format should be used here, the basic format which is [hh][mm][ss]or the extended using [hh]:[mm]:[ss]) and a custom global variable that I can define via

global_vars:
  - name: time_iso
     type: date
     params:
       format: "%H:%M:%S"

[federico-terzi]

But what is the difference between an internal global variable which is is maybe called time_iso (just grabbing this as an example as well) and giving you back the time (but which format should be used here, the basic format which is [hh][mm][ss]or the extended using [hh]:[mm]:[ss]) and a custom global variable that I can define via

Not much difference. In fact, I was planning to implement it by just adding a "user/variables.yml" file by default, containing all the "built-in" global variables.

Maybe it would be just better to create some packages for that purpose (packages can also define global variables), so that a user can just use:

espanso install base-vars

and get all of them. In this way, we can keep espanso lean by default.
What do you think?

[wadbr]

This following might be only useful for when the GUI is implemented, but what about a wizard that asks the user (on install or on first run) about their name, email, signature and create global variables through that data.

Here's how I'm imagining the wizard to be:

---

| Hello! I see this is the first time you are running Espanso!
|
| Would you like to provide a couple of your commanly used expressions to get you started? [Yes] [No]
|
| Enter your name:
| [John Doe]
|
| Great! You can now type :JD to quickly write your name!

---

(I imagine this as a getting started/first help thing, sorry if this is a bit out of context for this topic)

[timorunge]

Maybe it would be just better to create some packages for that purpose (packages can also define global variables), so that a user can just use:

espanso install base-vars

and get all of them. In this way, we can keep espanso lean by default.
What do you think?

Yes, I like it. :)

[federico-terzi]

This following might be only useful for when the GUI is implemented, but what about a wizard that asks the user (on install or on first run) about their name, email, signature and create global variables through that data.

Here's how I'm imagining the wizard to be:

| Hello! I see this is the first time you are running Espanso!
|
| Would you like to provide a couple of your commanly used expressions to get you started? [Yes] [No]
|
| Enter your name:
| [John Doe]
|
| Great! You can now type :JD to quickly write your name!

(I imagine this as a getting started/first help thing, sorry if this is a bit out of context for this topic)

This could be a good compromise @wadbr, thanks for suggesting it :)

@timorunge glad to hear that :)