How about adding sub-directories to [rc] scripts?
Inside [core], [base], [extra], add languages, tools, linters, etc.
Agreed, I would actually remove core/ base/ extra/ in favor of one directory per category.
This would also allow us to document some implicit conventions in bundled scripts, for example in languages/ we could just put a README that would explain what a language script should do, instead of having users copy-paste stuff from other scripts.
Yeah, seems like this would be more useful than the current split, I would accept a PR for that, however it would be nice to discuss a bit more what hierarchy we would set-up there.
For example, jedi.kak is a python specific tool, where should it go ? inside languages/python/jedi.kak, next to languages/python/python.kak ? tools/python/jedi.kak ? or just tools/jedi.kak ?...
I think it would be good to discuss guidelines here before somebody starts preparing a PR.
@mawww tools/python/jedi.kak?
I understand it as _Jedi is a tool for Python_.
I don't know if we need the subdirectories on top, for most languages there is only one script and maybe one tool script. I can see 3 clear categories
โโโ languages
โย ย โโโ c-family.kak
โย ย โโโ python.kak
โย ย โโโ sh.kak
โโโ tools
โย ย โโโ jedi.kak
โย ย โโโ make.kak
โโโ windowing
โโโ new-client.kak
โโโ tmux.kak
All existing scripts seem to fit into one of the three. Maybe languages can be further split to distinguish between actual languages and simple formats (such as exherbo.kak or systemd.kak), but it can be hard to draw the line.
In my personal rc, where I symlink to the existing rc, I have been recategorizing core, base, and extra to something similar to @occivink's system, except I name languages as filetype, and tools as command, and then left the rest at the top level because I couldn't think of a name. For me, any plugin that defines a new filetype is slotted into filetype, and any other plugin that defines new commands is slotted into command.
Looking at something like base/git.kak I think the name filetype will be better than language (as it provides filetype support for various git files/formats, but it seems a stretch to call a git commit message a language, another example would be diff.kak).
windowing or something similar definitely makes sense, and then I am not sure between command and tools, maybe more tools as windowing does define commands as well. In general I do like this 3 categories, and looking at scripts I cannot find one that would not belong clearly to one of those.
So yeah, I'd say filetype, tools, windowing would be my preference so far.
And about language specific tools?
I think putting them directly in tools/ will work for now, if we end up with many tools related to the same language, we can introduce an additional subdirectory tools/<lang>/
Why not to put all language specific tools to per filetype folders? It will be consistent and clear.
Most helpful comment
Agreed, I would actually remove core/ base/ extra/ in favor of one directory per category.
This would also allow us to document some implicit conventions in bundled scripts, for example in
languages/we could just put aREADMEthat would explain what a language script should do, instead of having users copy-paste stuff from other scripts.