Closed Utagai closed 5 years ago
Any idea on this? It's not critical but it is pretty irritating.
@w0rp If you are blocked by other work and/or are too busy in general, let me know. I have never worked with Vim plugins or Vim script, but I can give it a shot, as I am guessing that the bug and its fix is pretty localized.
I've had the flu for the past few days, but I'm near 100% again now. As always, the fastest way to fix a bug is to try and fix it yourself. I might have a look if I get the time.
Sorry to hear that @w0rp. Hope you recover fully.
I'll post here again if I end up taking a look. Will probably have to be this coming weekend at best.
Thanks for the update, all I really needed.
It was just a seasonal flu, I'm fine.
I'm also seeing this issue consistently @Utagai @w0rp.
Is it goimports
which is causing the issue. The error message is printed whenever something changes a file while ALE is trying to fix it. If goimports
is modifying the file, it shouldn't be doing that. If something else is modifying the file, turn that off.
@w0rp Note that this is happening even with C++. This isn't a Go-specific issue, as I had predicted. (See my original post for details on the C++ case).
This problem persists with gofmt
as well.
It's finally worth noting that all three of these tools work perfectly fine with Vim (not neovim). This should suggest that the issue is something else, not the fixers.
From my investigation, this really just boils down to ALE trying to mess with a temporary file created by nvim
that is somehow made inaccessible by the time it gets there. In either case, disabling the use of clang-format
, gofmt
or goimports
would be a pretty bad hit to ALE, as these are pretty popular fixers/formatters for their respective languages and never caused issues before.
I'll try to see if there is any sort of setting or flag that we can use to these fixers that may help with stopping any kind of file modification tonight. If I find anything promising, I'll post them here.
I suppose you'll have to figure out why NeoVim is deleting temporary files before ALE is done with them.
That sounds about right for the path we need to walk to get to the bottom of this. :)
@Utagai Just wanted to note that I see this issue with fixers for JavaScript, TypeScript and Haskell too. So it's obvious that the fixers isn't at fault here.
I have no experience with Vim script but let me know if I can help in some way.
@sQVe Yes, that seems to corroborate my hunch that this is not a fixer problem, but a timing problem with ALE and temporary files. I'll have to look into the code to confirm this, however.
In either case, I also don't know anything about Vim script. I gave this a cursory look, I believe two weeks ago and found it quite dizzying. I had found some kind of resource about debugging plugins in Vim, but it seems like no matter how you look at it, debugging this stuff is a pretty bad experience.
I've found newfound respect for plugin developers. :)
I noted yesterday when using prettier
as a fixer that it actually has troubles inside nvim
too. If I save but change something in the file before it fix was finished I get the following error:
Error detected while processing function <SNR>128_NeoVimCallback[29]..<SNR>143_HandleExit[41]..<SNR>143_RunFixer[57]..ale#fix#ApplyFixes:
line 12:
The file was changed before fixing finished
Yup, not surprised, since if my hunch is right, this should appear anytime the fixer runs and nvim
decides to switch stuff up. This does mean that the problem is more complicated than I hoped, and if the file is changing even during mid-execution, that is actually pretty bad, because we have no guarantees anymore.
I haven't looked at this yet since my last look, so sorry to anyone following this. :)
On a more serious note, if this is a critical issue for anyone (it is not a big deal for me), then do not wait on me. I will have no problem if someone else decides to take this on before me. :)
Hi all. I just gave this a pretty hard look for quite some time, and have some findings.
I believe I have confirmed that the temporary file that ale
needs is being created, but then deleted before it can be used. I had a script watching a personal $TMPDIR
and noticed that the path ale
is assuming exists comes into being and then is deleted sometime later. The fact that we can't open the file at exit and it doesn't seem to exist anymore should mean that our hunch was right.
Secondly, I've found some places in the codebase where we seem to be deleting directories/files, but these are not the culprit, because even disabling them does not solve the issue. In order to completely rule out ale
, I'd like to know if @w0rp knows of any other places in the codebase where ale
may be responsible for deleting tempnames or directories that it creates. My guess is there is not, but I've only ever looked for instances of call delete(...)
.
Moving on, I also realized that this problem seems to exists in vim
too, but the difference being that vim
is silent about it. In other words, in neovim
, you get an error and fix_on_save
does not work, therefore, your source file isn't fixed. In vim
your source file is also not fixed, you just don't get the error. Therefore, issue #2014 may actually be under the same umbrella as this issue. @RyanSquared @danielepiccone.
Finally, if there is indeed no other cases where ale
deletes its tempnames or directories, then the culprit is probably neovim
deleting these temporary directories/files too soon. If this is the case, which I imagine it is, then we need to find a way to avoid vim
/neovim
's handling of temporary files. Some ideas that came to mind:
git-gutter
for a separate issue of theirs, but is obviously not as pretty. ale_fix_on_save
in a way that does not rely on temporary files holding the buffer and instead run it as a straight command, perhaps via system(...)
where we run the fixer on the source file, but I'm not sure if this comes with other limitations or issues.vim-go
. vim-go
seems to use temporary files, but implements its 'fix on save' equivalent feature using a BufWritePre
rule.Any thoughts, critique, etc. are welcome. Needless to say: I'm taking a break from looking at Vimscript for a bit :).
Thanks for all of the information. I wouldn't want to manage creating temporary files in some other way than using tempname
, because Vim manages deleting those files after Vim exits, and we can't run plugin code after Vim exits. It might be easier to just make it so you can't fix files on :wq
.
@w0rp That's fine, and like I said, its not a very pretty idea. I'd rather avoid it as well.
What are your thoughts on the other ideas? My guess is that both are not satisfactory for ale
, since you haven't said anything about them, but why? I feel like at least the third option is pretty intuitive and the way most people would have implemented something like this in vim
if they didn't have ale
, and is clearly an approach that at least one other plugin has deemed acceptable (and has made clear is possible).
BufWritePre
won't help because the execution of the commands is non-blocking.
I changed the code so ALE won't try to fix files on :wq
any more. I think it just can't work. I updated the documentation to mention that you should save your file, look at the changes if they are any, and then quit the buffer instead.
@w0rp This will not solve the case where the file had changed before the fixer is finished though.
That should continue to be an error. The message is there to tell you something else modified the buffer, so ALE can't safely continue modifying the file.
@w0rp The non-blocking thing is indeed a little unfortunate, but I actually personally have no issue with it. In either case, it isn't too hard to write my own BufWritePre
so this is fine with me. Thanks!
I am seeing the same message when editing js files:
let arr=[]
my cursor is in the middle of the bracket, I hit enter key in insert mode(vim8.1) and I saw the red error message before it disappears quickly. if I put anything inside [] before hit enter key it works fine, it came up each time when there is a blank [], {} followed by enter key. For () etc there is no issue.
I got the same error in nvim v0.7.2
My work around was to put this in my .vimrc
:
let g:ale_fix_on_save = 1
cnoreabbrev wq autocmd User ALEFixPost q<CR>:w
However the second command has some other side effects (for example it will replace :sleep wq
with :sleep autocmd User ALEFixPost q<CR>:w
).
Information
VIM version
Operating System:
:ALEInfo
What went wrong
This error does not occur to me when using
vim
, whose version is:This only occurs on
neovim
. In particular, it only happens whenale_fix_on_save
is turned on, and a fixer is ran. Furthermore, it only occurs when running:wq
. Just writing the buffer via:w
works perfectly, and just quitting via:q
also works. Also, running:ALEFix
works on its own. It is the combination of:wq
that causes this issue. An error is printed byneovim
upon closing:After looking into this a bit more myself, I realized that it seems like the temporary file/buffer/whatever, (in this situation, at
/tmp/nvimvOq7Mv/6/test.go
, but this can obviously change across runs) does not exist by the time ALE gets around to doing its magic. I think what may be happening here is thatneovim
is destroying the file at that location beforeale
can get around to runninggofmt
orgoimports
on the buffer contents. This is further corroborated by the fact that when the file is re-opened, no fixes can be observed, suggesting that the fixer either never ran or ALE was not able to fix the buffer successfully in time for the write.EDIT: I just tried this out with a .h file, related to my
st
configuration, and got this error on:wq
:All other symptoms of this issue are the same, but seems like the error is slightly different. In either case, this is hinting at some sort of timing/race problem. The
:ALEInfo
output for this is littered with issues since this is basically someone else'sconfig.h
who breaks a lot of rules forcpplint
, so I've gutted out most of those warnings/errors:Reproducing the bug
ale_fix_on_save
.go
, usinggoimports
; however, my guess is this issue applies to any language for which a fixer is assigned).:wq
.When browsing for issues pertaining to this, I saw that some people included
ale
specific configuration lines from their.vimrc
for reproduction, here are mine:Also, this problem seems to have been experienced by at least one other person, at this issue. I searched his username in the issues on this project, but did not find anything, and I didn't see anyone else post an issue about this, so I'm hoping this isn't a duplicate that wastes your time.
Thanks for your hard work on ALE. It has been really useful. :)