Java linter requires a small modification to rc/tools/lint.kak - or a suggestion to work around

Help
1

I’ve got a Java Linter working - mostly.

the only issue remaining:

hmm
hmm923×201 15.8 KB

in Java it’s an error to have a public class (such as KakouneLinter) not reside in a file named KakouneLinter.java. Since the buffer that’s actually linted is /tmp/kak-lint.XXXXXX/buf.java the linter reports an error.

To fix this I’ve modified lint.kak so the tmp filename is instead /tmp/kak-lint.XXXXXXX/KakouneLinter.java, like so:

<         extension=""
<         if printf %s "${kak_buffile}" | grep -qE '[^/.]\.[[:alnum:]]+$'; then
<             extension=".${kak_buffile##*.}"
<         fi
---
>         filename="${kak_buffile##*/}"
25c22
<         printf '%s\n' "evaluate-commands -no-hooks write -sync $dir/buf${extension}"
---
>         printf '%s\n' "evaluate-commands -no-hooks write -sync $dir/${filename}"
36c33
<         eval "$kak_opt_lintcmd '$dir'/buf${extension}" | sort -t: -k2,2 -n > "$dir"/stderr
---
>         eval "$kak_opt_lintcmd '$dir'/${filename}" | sort -t: -k2,2 -n > "$dir"/stderr

Should I do a pull request on github? any suggestions as a work around or an improvement to that patch?

2

I think it is fine adjustment to the script.

3

The change is fine for that specific lint rule.
But what if the next lint rule states “the directory structure must match package name”, i.e. -> package us.kinoha.tools; -> ./us/kinoha/tools ?

Btw. I`d be interested to hear how you use Java with kakoune.

4

No issue there. I’m using the standard Java Compiler API, and while the compiler actually emits an error and stops on the first pass if the Class Name doesn’t match the File, it doesn’t actually enforce that the package name matches the directory structure.

Sure. I put up the first iteration of the Java code: http://ix.io/1JEP . It takes in a file on the command line and looks for a classpath file to load if there is one. (I have other code that inspects a pom.xml file and generates a classpath file if the pom.xml is more recent than the classpath file. I omitted that code because it’s longer than the interesting code, and you can generate the classpath file as part of mavens build cycle in a few lines anyways.).

There’s also a wrapper shell script:

#!/bin/sh

java -cp /usr/local/share/java/kakoune-linter-1.0-SNAPSHOT.jar us.kinoha.tools.KakouneLinter $@

and the relevant hooks into kakrc:

hook global WinSetOption filetype=java %{
    set window lintcmd kl.sh
    lint-enable
}

hook global BufWritePost .*\.java %{
    lint
}

It works very well, I get feedback faster than mvn compile generates it’s first couple log messages.

I may add autocomplete for import statements since it’s a low-hanging nice-to-have, and / or cherry pick features from the checkstyle project (which only does actual linting / style enforcement), but between that and running entr mvn package in a second window to run tests and build the project I’ve got all I need at the moment.