nnn compatible plugin system

[vlappa]

Hi,
I really like how nnn is using plugins and it's generic approach (using shell scripts) and not being tight to a specific language (contrary to Ranger and Lf).

I'm going to implement a comparable plugin system to a application which manage music production applications in a session. Such a session is just a folder where all the applications in the session store their data. The application I'm working on is listing the sessions and gives the user the option to start, close, save the session etc.
But users might want to do more, like making a backup of the session, clone the session, manage the session changes with git etc. For this I think a plugin system like nnn has would be a nice addition.

The idea is to make it compatible with nnn plugins as much as possible. I don't make a full-featured filemanager, for very specific tasks one might be better of using nnn instead. Then it would be nice if the user could use the same plugin as much as possible.

There are currently no plans to support contexts, so the only thing it would share with a specific nnn plugin is the $nnn environment variable I think.

I'm wondering what is wise to do here. Make up a own variable name or just use $nnn as well. Any thoughts?

Looking at the nnn plugin concepts it uses environment variables and it passes arguments to the plugins (https://github.com/jarun/nnn/wiki/Concepts#special-variables)

I'm wondering, why not export everything as environment variable?

Would supporting only the $nnn environment variable be useful for a nnn plugin, or do I miss something?

Thoughts and suggestions are welcome!

[vlappa]

Thoughts? @jarun

[jarun]

Make up a own variable name or just use $nnn as well. Any thoughts?

You can probably use $nnn. We are not going to change that.

I'm wondering, why not export everything as environment variable?

There are too many of them. We don't want to litter the environment.

[vlappa]

Thanks for your reply @jarun

You can probably use $nnn. We are not going to change that.

I'm leaning towards a custom variable for my use case, so all env variables the tool sets, has resemblance in naming.
Nnn compatible plugins written for the tool I've in mind, could probably use a check.

If $nnn set, the var to use is $nnn; else the var to use is $foo

There are too many of them. We don't want to litter the environment.

I don't really see a problem with a few more environment variable TBH, but maybe that's my inexperience with this stuff.