Add extensibility

[jmattaa]

Idea:

• The user should be able to create scripts at for example .config/laser/
• These scripts could be used as configuration of for example the theme, but also extend the cli (like "plugins")

(This is merely an idea for now)

[EgorWeders]

Proposed tasks: 1.Allow user to create file path for scripts/plugins lsr --create_plugin_dir <path> with needed files and dir structures 2.Allow user to rewrite default path to plugin info lsr --plugin_path <path> 3.Add entry points for plugins/scripts call Possible places: file parsing (filename,extension, additional info from plugin) entire output wrap (like clear screen before output or smth like that)

5. Database/library collection of .so plugins (if you want them) You can use dynamic libraries as plugins to extend basic laser, even move essential functions to them as lsrBase.so. Its difficult but allows you to have different module versions and features check https://github.com/EgorWeders/SimpleMessagerBase/blob/main/base/mutatorloader.h and https://github.com/EgorWeders/DynamicMutator/blob/main/dynamicMutator.h for my idea explanation (not self-promotional)

[jmattaa]

I really liked the idea of the commands lsr --create_plugin_dir and lsr --plugin_path. However I think that it will still need a universal config file (at eg. .config/laser/) where user can set these variables for the different paths for the scripts. I don't think using shared libraries is a good idea (for now at least).

That said, I have one concern I’d like to discuss. Adding these scripts might impact the program's performance, especially if we move some functionality from C to scripting (e.g., Lua or another scripting language). Would the performance difference be noticeable in practice? I’d appreciate hearing opinions or insights on this.

My idea is that an ls-like command should be extremely responsive, generating output almost immediately, as it’s something one would expect to have at their fingertips.

[EgorWeders]

However I think that it will still need a universal config file (at eg. .config/laser/) where user can set these variables for the different paths for the scripts.

You need to add argument for creating template of that config , like lsr --dump-config <path> just copies current (even empty) config keys and values

That said, I have one concern I’d like to discuss. Adding these scripts might impact the program's performance, especially if we move some functionality from C to scripting (e.g., Lua or another scripting language). Would the performance difference be noticeable in practice? I’d appreciate hearing opinions or insights on this.

Yes, especially on recursive printing. But it depends on what use cases you imagine to cover with scripting. If you want to just print pretty title on statrt call that is ok, but if you want to allow script process each entry (maybe even with masks) that will stutter a lot. And you need provide well designed interface for scripts.

[EgorWeders]

I will try to make showcase for shared library plugin for external type checking to prove my point (maybe next week)

[jmattaa]

I've added the development branch with a hacky build solution and exposing the cmp_dirent to lua, I've written the default cmp_dirent in lua now also. Will be working a bit more on this making the build work cross-platform (currently it just works with homebrew on mac) better and adding more functions to the api.

The idea now is that all the laser specific functions will be starting with a L_ and then the name of the function.