Thank you for the information on this issue. Can you please provide me with some direction, how is it possible to solve this problem? My kak script knowledge is very limited, most of the plugin is just copy/paste from other plugins around.
If somebody wants to replace a file-format plugin from the standard library with one of their own, today the most reliable way to do that is by adding all the plugins they do want to an allow-list.
A longer-term solution would be to submit the changes to the Kakoune standard library.
The longest-term solution would be to come up with an easier-to-manage way for users to select the parts of the standard library they want to use, and submit that to Kakoune.
I have some experience witting scripts for Kakoune and, since I’m the author of the current Janet support for Kakoune, perhaps I can help you.
I think the best solution would be for you to contribute to Kakoune repository with the changes you would like to introduce to the current code. That way, the whole community would benefit from it out-of-the-box. I don’t see much value in keeping an implementation segregated from the one developed by the community.
I would be happy to start a collaborative effort with you to make a unified implementation shipped with Kakoune by default. Provided, of course, you are open to collaborate (you know, vaguely stating the code is broken is not a good way to collaborate; it doesn’t help to make the code any better).
Thank you very much for your answer! In this incarnation, my version cannot be included in the official repository, as it is using Janet executable to extract binding from the environment for the code highlighting. Also, part of my implementation uses jfmt and jlnt.kak to format and lint the code. These constraints were the primary reasons I have never attempted to get it to the official repository.
And frankly, I do not link janet.kak from the official distribution to my .config/kak/autoload (along with some other stuff), and I am OK with that. Not that I see it as a superb solution, especially for newcomers.
Yet maybe there is a better way, that I in my inexperience, do not see, or the constraints I put above are not that hard, and I will be pleased to cooperate on some better solution.
Regarding the use of jfmt and jlnt, we can extract the code using them to the tools directory. There are other languages defining commands using external tools there.
That part is trickier, and it sets a hard dependency on the janet program, making highlighting Janet code on machines without it impossible.
But, personally, I see another problem in that solution: it highlights every binding as a keyword, even functions and macros, something that doesn’t seem quite right (at least to my taste; obviously it’s OK if you think differently). What I opted to do for the Kakoune repository is highlight as keyword only Janet’s special forms. Except for those, everything else that looks like a function call (including calling functions, macros and methods) is highlighted as function, and doesn’t matter if its a built-in function or a custom one. A function call is a function call after all. It’s the same approach taken by other highlighters in the Kakoune repo.
In any case, I’m open to discuss any aspect of it. Nothing is set in stone. I’m confident we can arrive to a solution you feel good enough to use by yourselves. And your janet.kak repo can eventually continue to exist as a complement of the official Janet support, building upon it. That would be the perfect solution.
Hello, thank you for the janet.kak review. I guess most of what you said makes a lot of sense. I am very open to any improvements. Let me sleep couple nights on this, and I am sure we will find common ground.
Hi, @timber! You can, if you wanto to, directly open a merge request to Kakoune’s repo to update indentation with your changes. That way, you record your name in Kakoune’s history
But I can do it myself if you don’t have the wish to do it by yourself.
For more substantial changes, I’d rather wait until we see if we could agree on a common denominator for the project.
Hi, @pepe! Regarding using jfmt and jlnt, I just realised that Kakoune already has formating and linting functionality built in. We just need to set the formatcmd and lintcmd options properly.
Here is how I set my kakrc to run jfmt and jlnt on every buffer update:
I don’t know if your janet.kak does something differently on linting because I couldn’t make it work to test it (I don’t know exactly why… I did set janet_autolint to true but that didn’t seem to work…). But the setup above does work well, and have the nice property of using features the community is used to.
On the other hand, one thing janet.kak has I’ve found pretty useful is the janet-doc command (albeit it lacks a docstring). There’s also a janet-fly command I have no idea what it’s used for (since, again, it lacks a docstring), so I couldn’t test it.