Add support for Kakoune Script

[lenormf]

Description

This PR adds basic highlighting support for the scripting language interpreted by the Kakoune editor.

Checklist:

• I am adding a new language.
  • The extension of the new language is used in hundreds of repositories on GitHub.com.
    • Search results for each extension:
      • https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Akak+NOT+nothack
  • I have included a real-world usage sample for all extensions added in this PR:
    • Sample source(s):
      • https://github.com/mawww/kakoune/blob/9a5cf2fc9f/rc/tools/doc.kak
      • https://github.com/mawww/kakoune/blob/9a5cf2fc9f/rc/filetype/c-family.kak
      • https://raw.githubusercontent.com/kakoune-editor/community-articles/master/assets/download/two_hours_two_minutes/kakrc
    • Sample license(s): https://github.com/mawww/kakoune/blob/master/UNLICENSE
  • I have included a syntax highlighting grammar: https://github.com/kakoune-editor/language-kak
  • I have updated the heuristics to distinguish my language from others using the same extension.

[lildude]

Overall usage of the .kak extension currently falls just short of the minimum requirement so we can't merge this PR just yet, though it's not far off at about 180 unique user/repo combos.

However the kakrc and kakrc.local filenames is far from popular enough with only 182 of the former and zero of the latter. Thus the filenames section would also need to be removed before this could be merged or a sudden growth in usage would need to occur.

[occivink]

How far off is it? I cannot find any documented popularity requirement for extensions and filenames.

[lildude]

From https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language

We try only to add languages once they have some usage on GitHub. In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

"hundreds" is vague but we go on at least 200 unique user/repo combos. The same thing applies to filenames.

[lenormf]

I don't understand why the filenames would have to be removed. kakrc and kakrc.local contain the same language stored in .kak files, and are known to/read by the editor itself.

Why would a user's ability to read a highlighted kakrc file be predicated on how many .kak files others have uploaded to Github?

[lildude]

I don't understand why the filenames would have to be removed. kakrc and kakrc.local contain the same language stored in .kak files, and are known to/read by the editor itself.

Why would a user's ability to read a highlighted kakrc file be predicated on how many .kak files others have uploaded to Github?

They might be written in the same language, however a filename search for each returns far too few results for inclusion right now:

• kakrc - 181 results
• kakrc.local - 0 results, even extension:local kakrc returns zero results.

The lack of kakrc.local files entirely suggests people aren't storing these files on GitHub at all so support isn't warranted at this stage. Samples of these files weren't included in the PR either, which is required, but I didn't mention this because the lack of popularity makes the point moot.

[lenormf]

Sorry, this is still perplexing.

There are 4259 files with the .kak extension.

There are 517 kakrc files.

They both contain the exact same language — that's why there's no sample for kakrc files.

Why does the amount of either files, discriminated by their extension or lack thereof, matter? Both number of files should count towards the same metric: whether a language is being used on Github or not.

I guess I could remove kakrc.local, but it wouldn't make sense because either this file uniquely known for containing KakScript is supported along with all other files that are also known for containing KakScript, or it's not — users shouldn't have to wonder why kakrc.kak is being highlighted, but not kakrc, even though the naming of the latter is significant.

Finally, Linguist supporst .exrc extensions for Vim, despite Github hosting a grand total of 39 of such files. So I'm assuming that this low amount of files counted towards the total amount of Vim files, which is a reasonable rule that should apply here as well.

[lildude]

Why does the amount of either files, discriminated by their extension or lack thereof, matter? Both number of files should count towards the same metric: whether a language is being used on Github or not.

That's the point, the number of files does not count. It's the number of unique user/repos that count. If the number of files were the determining factor, anyone could qualify adding support for their new language based off a single repo with ten thousand files in it, or ten repos with a thousand files each, which wouldn't qualify as wide spread usage. As with many things, there are ways to game the system, but that's not really in the spirit of things.

I only called out the specific number files for the named files because their number alone would indicate there aren't enough unique user/repos containing the files in question, assuming a user would have at least one copy of the file per repo.

They both contain the exact same language — that's why there's no sample for kakrc files.

We still like to have samples to train the classifier so it can hopefully identify files that aren't explicitly identified by name or extension based on the content. The classifier is limited by the quality of the samples so the more representative of a language and usage the samples are, the better the chances of the classifier getting it right.

Finally, Linguist supporst .exrc extensions for Vim, despite Github hosting a grand total of 39 of such files. So I'm assuming that this low amount of files counted towards the total amount of Vim files, which is a reasonable rule that should apply here as well.

Linguist supports the .exrc filename, not extension:

linguist/lib/linguist/languages.yml

Lines 5915 to 5937 in ab675b0

	Vim script:
	type: programming
	color: "#199f4b"
	tm_scope: source.viml
	aliases:
	- vim
	- viml
	- nvim
	extensions:
	- ".vim"
	- ".vba"
	- ".vmb"
	filenames:
	- ".exrc"
	- ".gvimrc"
	- ".nvimrc"
	- ".vimrc"
	- _vimrc
	- gvimrc
	- nvimrc
	- vimrc
	ace_mode: text
	language_id: 388

You'll see the files in your search results have not been associated with any language nor are they highlighted due to the lack of support for the .exrc extension.

Searching by filename returns 667 results spread across 263 unique user/repos so it meets the requirements.

That all said, as I mentioned before, you're almost there for adding support based on the .kak extension, hence I've added the "Pending Popularity" label. This is an indicator for the peeps to check the popularity every once in a while without risk of the PR going stale. If usage is growing rapidly, things could be ready for merging within a few weeks at most. If growth is slower, it could take a little longer.

Once usage is widespread enough, the PR can be merged and an override can be used for the kakrc and kakrc.local files if the classifier doesn't get it right. A new PR can be submitted to add each named file as their popularity increases.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity, and will be closed if no further activity occurs. If this pull request was overlooked, forgotten, or should remain open for any other reason, please reply here to call attention to it and remove the stale status. Thank you for your contributions.

[lildude]

Good news @lenormf the .kak extension and kakrc files are now popular enough for inclusion in Linguist. 🎉 kakrc.local however isn't. 😞

Please merge the master branch into your branch and address my inline comments.

Thanks for your patience. 🙇

[lenormf]

I've addressed the comments, and pushed the rebased branch. The new sample is a configuration file that I wrote, placed under the UNLICENSE.

[lenormf]

PING

[lildude]

🤔 CI doesn't appear to have run on this PR at all. Could you grant me write access to your PR.

[lenormf]

It seems that you already have write access, according to Github (I also don't see any other menu that would allow me to tweak permissions):

I edited the last commit and force pushed it to try to force CI to re-run, it doesn't look like it worked…

[lildude]

It seems that you already have write access, according to Github

🤔 are you sure? I can't see the button I'd normally see that allows me to merge master into your branch. Is "Allow edits and access to secrets by maintainers" in the sidebar checked? https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork has more info.

I edited the last commit and force pushed it to try to force CI to re-run, it doesn't look like it worked…

Try merging master into your branch. No need to rebase and/or force push as we don't care about commits as we squash when merging.

[lildude]

Oh wait. I can't see the update button but I can now see the approve CI button I couldn't see before.