a flaky case when editting e.g `quickfix.c`

[Shane-XB-Qian]

the string(a:fname) printed to quickfix instead of quickfix.c, though bufnr and &bt was correct. so far not sure that's a bug of vim (v8.2.2220) itself or this plugin, cannot simplified to reproduce it, but sure this is a corner case, but/and headache once faced it.. spent much time to find out.. if someone knew or fixed it that's great, or at least a headup to bring notice to buddies..

[lcd047]

Please explain what did you do, what did you expect to happen, and what happened instead. If you have to add screenshots do that to illustrate the description of the problem rather than replace the description entirely. Don't expect me to infer your supposed problem from a screenshot.

Can you reproduce the problem with all plugins disabled except syntastic? Have you considered switching to ALE instead, that is actively maintained and is meant to be used with recent versions of Vim?

[Shane-XB-Qian]

diff --git a/plugin/syntastic.vim b/plugin/syntastic.vim
index 82a63bf..fa3289c 100644
--- a/plugin/syntastic.vim
+++ b/plugin/syntastic.vim
@@ -273,13 +273,13 @@ endfunction " }}}2
 " Autocommands {{{1

 augroup syntastic
     autocmd!
     autocmd VimEnter    * call s:VimEnterHook()
     autocmd BufEnter    * call s:BufEnterHook(expand('<afile>', 1))
-    autocmd BufWinEnter * call s:BufWinEnterHook(expand('<afile>', 1))
+    autocmd BufWinEnter * if &ft!='qf' | call s:BufWinEnterHook(expand('<afile>', 1)) | endif
 augroup END

 if g:syntastic_nested_autocommands
     augroup syntastic
         autocmd BufReadPost  * nested call s:BufReadPostHook(expand('<afile>', 1))
         autocmd BufWritePost * nested call s:BufWritePostHook(expand('<afile>', 1))

// perhaps should get rid qf buf itself... and looks this overcome this issue..

And line# 329 of autoload/syntastic/util.vim :

    if buf == -1
        " XXX definitely wrong, but hope is the last thing to die :)
        let buf = bufnr(fnamemodify(a:fname, ':p'))
    endif

// it canNot identify quickfix.c or quickfix, both returned same bufnr, i guess this maybe the problem.

// but whatever, to get rid of qf buf itself was better workaround/fix.. pls try -i cannot fully test use cases..

btw: i am old-school.. not tried ALE yet, unless your guys give-up first.. :rofl:

[lcd047]

Syntastic itself doesn't attempt to check qf buffers. The only scenario where your patch makes a difference is when you have another plugin with an improperly written BufWinEnter hook. Then again, you still haven't explained the problem you're trying to solve, and I'm not a mind reader. So please feel free to re-open this when you're ready to disclose enough useful information to allow me to reproduce the problem...

[Shane-XB-Qian]

function! s:BufWinEnterHook(fname) abort " {{{2
    let buf = syntastic#util#fname2buf(a:fname)
    call syntastic#log#debug(g:_SYNTASTIC_DEBUG_AUTOCOMMANDS,
        \ 'autocmd: BufWinEnter, buffer ' . buf . ' = ' . string(a:fname) . ', &buftype = ' . string(&buftype))
    if buf > 0 && getbufvar(buf, '&buftype') ==# ''
        let idx = index(reverse(copy(s:_check_stack)), buf)
        if idx >= 0 && !has('vim_starting')
            call remove(s:_check_stack, -idx - 1)
            call s:UpdateErrors(buf, 1, [])
        endif
    endif
endfunction " }}}2

// this your/this plugin's bufwinenter, not mine, // that judgement getbufvar(buf, '&buftype') ==# '' this gave wrong signal, since it cannot identify quickfix.c with quickfix.

anyway, this is a corner case, so whatever going to fix or not.. :) -and i am not able to 're-open' ticket. // but registed bufwinenter into qf did not looks wasted something?

[lcd047]

// this your/this plugin's bufwinenter, not mine,

Sure, but SqBufGrep in your screenshot above is yours, not mine. :smile:

Like I said: I can't fix a problem I can't reproduce. It's your burden to explain to me how to reproduce the problem, not mine to coerce that information out of you.

[Shane-XB-Qian]

-_-# that's just a wrap of vimgrep, did not reg any event.. i said i cannot simplified the case.. but just per code itself, i guess you knew that issue now.. or whatever i believe this would not bother other guys too much, since would not too much chance to edit same file name.. but come on, man, if that's no harm to get rid of qf from bufwinenter event of this plugin, then why not just do it.. or if yes (i am not familiar with this plugin code very much), then let it be..

[lcd047]

No, I honestly have no idea what you're trying to say here. I don't know what the problem is supposed to be to begin with, let alone how to reproduce it.

[Shane-XB-Qian]

in a qf window:

echo bufnr() | echo syntastic#util#fname2buf('quickfix') | echo bufname('quickfix') | echo syntastic#util#fname2buf('quickfix.c') | echo bufname('quickfix.c')

output:

7
6
quickfix.c
6
quickfix.c

this-plugin's event in qf kicked off those hook, but this func syntastic#util#fname2buf() wrong thought/treat 'quickfix' was 'quickfix.c' (these are different **2 bufs**). this is the problem, wish now clear enough... // i think get rid of qf itself away from those event can avoid others unexpected cases also.. i saw previous tickets said qf had competitions.. // but again, to this ticket itself, this is a corner case, and i cannot test others unexpected cases, so up to you, if to fix or not.. :)

[lcd047]

I still can't get an E788 as in your first message. You know, being able to describe problems is an useful skill, you might consider working on it some more.

Why do you have two buffers, one named quickfix and another one named quickfix.c? Yes, syntastic#util#fname2buf() is broken, like everything else in Vim it only works in ~95% of cases. Patches fixing that are welcome.

[Shane-XB-Qian]

i am using latest/dev/unstable version vim, pls do not expect me can answer the left ~5% also. so far, i do not know E788 came from or why that was that err num also. but regardless that, were you really not getting my point, and not clear the case? happy to discuss and tried to accept -also was a good manner, :) but looks you were not, so let it be. thx.

[lcd047]

were you really not getting my point, and not clear the case?

Sorry, but no. You have a buffer named quickfix; syntastic uses loclist not quickfix, so that buffer is likely created by some other plugin. How does that plugin interact with syntastic? Can't tell without knowing what that plugin is, and you refuse to disclose that information.

Is syntastic#util#fname2buf() broken? Sure. Would fixing it also solve your problem? Maybe; can't tell without understanding the exact path syntastic takes to get there, and you refuse to disclose that information.

Is the autocmd broken? Maybe, but probably not; can't tell without understanding how is that related to the E788, and you refuse to disclose that information.

Would changing the autocmd fix your problem? Maybe; can't tell without understanding the exact path syntastic takes to get there. Would that change break something else? It's almost guaranteed it would. Can it be fixed some other way? Can't tell without understanding the exact path syntastic takes to get there.

pls do not expect me can answer the left ~5% also.

I'd settle for fixing syntastic#util#fname2buf() in this particular case. I can't do that if I can't reproduce the problem.

so let it be. thx.

Sure.

[Shane-XB-Qian]

were you really not getting my point, and not clear the case?

Sorry, but no. You have a buffer named quickfix; syntastic uses loclist not quickfix, so that buffer is likely created by some other plugin.

i think you are very good at vim scripting, defintily better than me, i believe this. sorry but let me explain some or correct me if wrong:

• loclist and quickfix both was a qf, though looks a bit confused. // as for why? that's not my designed, same as why was not that err num, etc, perhaps bram can answer why..
• that quickfix buf name was <afile>, i think it was not from any other plugins but vim itself, and this plugin that func gave wrong judgement. // that's it.

[Shane-XB-Qian]

FYI: not sure since when, (looks it was patch 8.2.3018 ?), but this issue looks had been fixed. thx was arguing with me.. :-) aha.....................