Idea for a plugin system for superfile

[voidarclabs]

Hey! I was looking through my superfile config and came across the plugin section. I had a look on the wiki and found only the metadata plugin. I did some more searching through the code and found no other mention of plugins outside of a few related to function.go. This I found confusing. A plugin is meant to be detachable from the rest of the service, right? Well, to my bemusement I found the metadata 'plugin' embedded into the source code as a mere config option! No shade to whichever developer(s) made the plugin, but i found the idea of embedded plugins slightly strange. Then it hit me. Why not have a plugin system? Let me explain:

What I am suggesting is a plugin directory, in which separate files can be placed and loaded as defined in the config.toml file. From what I've seen, the entire program is based off of functions in the 'internal' folder/package. All that would need to be implemented is a wrapper/way to create a window in superfile (i believe using tea), or a way to inject new code into other packages (eg a new section in the sidebar). This would then most likely be treated as any other package by the program, being loaded at runtime and having individual keybinds etc etc. This would allow for much easier implementation of features, with the added benefit of being able to enable and disable whatever you wanted, allowing for a fully customizable experience. Adding this code-based customisation to superfile would, i believe, allow for more of a community aspect. instead of having to rebuild the package locally to change something arguably minor that a friend suggested, before reverting to stock after it broke something, it would only be the difference of one or 2 files in a seperate directory.

I am not a go developer. Therefore, I have absolutely no clue how complex a system like this would be to implement. However, I have looked through the codebase, and I believe you would only have to alter one of the config functions to import a plugin directory and the enclosed functions. You could also define it in one of the main.go files (One leads to the other so i'm not exactly sure which one would be best suited.), before drawing the requested extra windows using the model file. I might be completely wrong about this, so please feel free to correct me if i am, but I'll fork the repo and see what i can come up with. Thanks for the awesome file manager!

Toodles!
Void

[voidarclabs]

So, I've been digging.

All windows in the program are hard coded. Utilizing a render function located in model.go. All the windows are pre-defined in their size and content in model_render.go, making use of set division (m.fullWidth%3 on line 317 and 318 in model_render.go) and being combined statically on line 219 of model.go. Without rewriting the entire footer portion of the program (which I am nowhere near qualified to do), there wouldn't be any feasible way to inject dynamic windows into the program. This is further cemented by the fact that the renders cannot be modified after they are passed to model.go, being rendered when their respective functions are called. This prevents post-call additions of something like a new sidebar tab or extra decoration to the file menu. It's pretty clear that this project wasn't meant for retrospective additions...

However, there is a dynamic window in the project already! When you click n, by default, a new file manager window is brought up. Dynamically. This is achieved by using the following function from model_render.go:

	filePanelRender := ""
	for _, f := range f {
		filePanelRender = lipgloss.JoinHorizontal(lipgloss.Top, filePanelRender, f)
	}
	return filePanelRender

This is located on line 143 of model_render.go. The variable f is an array containing all file browser windows. If something were to inject a new rendered entry into this function, it would come up with the correct spacing relative to other windows, providing you stole the code from the file browser renderer to get the height and width etc. When the program creates a new file panel, it calls the function createNewFilePanel(), and this function is defined on line 51 of handle_panel_navigation.go. This function can be copied and pasted to create a 'plugin panel' of sorts. However, the drawing of the content is still handled by the model_render.go function. This is simply remedied by adding an extra field, plugin, to the array that is created dynamically and sent to the render function, and using an if statement to check if it's true, and if it is, rendering with altered rules (for now an empty box). Now, due to the nature of go, I had to mess around for about 15 minutes adding all the types and methods to type.go and config_type.go. With that all in, you can now, by pressing the letter 'o' (assuming you've added the correct config), make a blank window! Yay! This window can now be altered, made and deleted as if it were a reguar file window, while having custom embedded content.

All the changes I've made can be found on my fork of the project. I hope some devs take notice of this soon, or my horrible programming might get a bit out of control (lol). Nowhere near ready yet but I'll get on a way to make a more modular system soon.

I'll be in touch
Void