Kakoune: Spurious golint-kak linting errors

[melboyce]

When running the lint command (golint-kak) via BufWritePost or manually, there's a high likelihood of getting spurious linting errors. It seems like the larger the file, the worse it gets. Usually they're line terminator errors (missing brackets or quotes and so on) which makes me think the data the linter is getting is being truncated. I can't replicate this outside of kak.

[maximbaz]

This issue probably belongs to the golint-kak repo. I personally found that it is quite simple to make kak use original :lint without any dependencies to external plugins, try this:

:set window lintcmd "run() { cp $1 $1.go; golint $1.go; go vet $1.go 2>&1 | sed -E 's/: /: error: /'; } && run"
:lint-enable
:lint

I haven't experienced any issues so far, but I haven't been using it for long time yet. Let me know how it works 😉

[melboyce]

@maximbaz Unfortunately, it's at least as error prone as golint-kak, if not more so. Just now, 3 :w commands yielded 3 different errors each of which was different (one was an error on a comment line). This makes me think it's somewhere between lint.kak and my hardware/distro setup.

[melboyce]

I can repro this issue by doing this: kak /usr/lib/go/src/fmt/print.go (1100+ lines) and running :lint a few times.

[dedelala]

+1; I am experiencing this issue

[maximbaz]

I have a suspicion that when kak runs lint and copies file in a temp directory, it doesn't actually wait for the disk caches to flush. Try to add sync call and see if you still reproduce the issue. If this solves it, we will know what to fix 🙂

set window lintcmd "run() { sync; cp $1 $1.go; golint $1.go; go vet $1.go 2>&1 | sed -E 's/: /: error: /'; } && run"

[melboyce]

Looks like a winner, thanks a bunch.

[maximbaz]

I believe kak's :write should take care of this internally, not us running around and adding sync everywhere, maybe keep the issue open? @mawww what are your thoughts?

[lenormf]

It feels a bit brutal to force a full filesystem synchronization after ever write on disk, do we know how other editors handle that? Also, could that not be a bug of whatever filesystem you're all using (who knows)?

[melboyce]

I can't speak to how other editors do things, but I'm using EXT4 on LVM w/ LUKS, so it's quite possible there's some wiggle room between those layers. @dedelala uses OS X w/ encryption (HFS+?). Should I leave this issue open?

[maximbaz]

Even if we conclude that changing :write is not desirable, I think sync should probably be part of :lint command.

But isn't there a way to flush writes to a single file? That's what :write should do, I believe, and it will be much better than syncing an entire file system with sync.

[mawww]

I think it would be reasonable to do a fsync(fd) in Kakoune's write implementation. We dont need to sync the whole filesystem, but guaranteeing that a file is properly written once the :write command returns seems a good behaviour.

Alternatively it could be an opt-in switch to the write command (:write -sync). Might make sense is it would avoid slow :write on remote filesystems in the case where we dont really care about the file being synced immediatly.

Opinions ?

[melboyce]

+1 for the flag

[dedelala]

i like the flag option

[maximbaz]

How about a reverse, -nosync option? I've seen the commit "rc: Synchronize important file writes" in the linked PR and it instantly got me thinking, are you ready to accept that sometimes an "important" place will be missed, we would get other bugs "Spurious * errors" and people would waste time searching where else a -sync is needed?

[maximbaz]

Seems like you went with the -sync option after all

[mawww]

My mind is not really made up on that, although I dont really see where the -nosync would be used (would you choose not to sync explicitely ?). Frankly I am tempted to just always sync, I am not convinced we need the flag in the end.

[maximbaz]

I agree, even on remote file systems I'd rather wait an extra second, but be sure the file is really saved.

[mawww]

Alright, I did try, its actually very noticeable, make test is more than twice as slow, opt-in is relatively easy (define a syncwrite command that does write -sync, alias write to syncwrite), so I think the -sync switch is the best solution.