How can I make pepe/janet.kak properly override built-in janet.kak?

I use pepe/janet.kak which should override built-in janet.kak.

Whenver I open a janet file, I see this error message in debug buffer.

error running hook WinSetOption(filetype=janet)/janet-highlight: 2:5: 'add-highlighter': duplicate id: 'janet'

How can I eliminate this error message?

Ah, that’s because the standard library’s WinSetOption hook to enable janet highlighting is declared outside the janet module, so provide-module -override doesn’t override it.

1 Like

How can I fix the error?

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 subscribed to the issue.

Yes but kinda, sorta no. I do it successfully with my kakoune-java.kak plugin #L59

Kakoune orginal file is here:

You will also come up against ‘error running hook,’ my solution to the problem was #L86

# error running hook, not any more just override and build it empty 
define-command -override -hidden java-insert-on-new-line %[ ]
define-command -override -hidden java-indent-on-new-line %[ ]
define-command -override -hidden java-indent-on-opening-curly-brace %[ ]
define-command -override -hidden java-indent-on-closing-curly-brace %[ ]

Bitbucket is not a dangerous place, entry is free so take a look at my above links as it will be of help.

I’ve done it so you can too. Bye :wave:

Hi, guys!

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).

What do you think?

1 Like

Hello, great.

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.

I want to fix pepe/janet.kak first before anything is merged into kakoune.

hook -group janet-highlight global WinSetOption filetype=janet %{
    # Give the     `-override` flag a shot.
    add-highlighter -override window/janet ref janet
    hook -once -always window WinSetOption filetype=.* %{ remove-highlighter window/janet }

Cool buddy bye :wave:.

Hi, @timber! No problem, we can do it carefully in order to get a good result.

Hi, @pepe!

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.

On the other hand, populating static-words with the value returned by (all-bindings) like you did is a handy feature the Janet support in Kakoune current lacks.

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.


I improved automatic indentation of pepe/janet.kak. Built-in janet.kak doesn’t yet have my improvements to indentation.

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 :wink:

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:

hook global WinSetOption filetype=janet %{
    set-option buffer formatcmd 'jfmt'
    hook buffer BufWritePre .* format

    set-option buffer lintcmd 'jlnt'
    hook buffer BufWritePost .* lint

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.

I think janet.kak should put hooks into provide-module janet %{} so that pepe/janet.kak can override hooks.

There should be ways for third party modules to override built-in modules.

1 Like