Youcompleteme: Set the scratch buffer/window to nobuflisted

[unphased]

I tried looking really hard but I can't find whether it is Syntastic or YCM (or possibly even some other plugin) that actually performs the action of setting the buffer settings for the "scratch" buffer that is created by semantic completions. I get semantic completions in JS (via Tern), Python, and (Obj-)C/C++ files...

Basically due to some other scripting I really need to avoid e.g. :bnext bringing me into the scratch buffer, and using nobuflisted does the trick.

Currently I am hacking it where if I see any buffer whose bufhidden is equal to wipe or hide I set nobuflisted on it.

[vheon]

What is this "scratch" buffer you're referring to?

[unphased]

It's referred to as the "preview window".

[vheon]

I tried and I don't get that behaviour so I'm going to ask you to post some steps to reproduce this bug. Closing until the bug is confirmed.

[unphased]

Alright I think YCM may simply be using Vim's own preview window functionality. So then this could not be more relevant, so I think it should address my problem (at the expense of setting up yet another global autocommand -- which means I'll probably keep my hack).

[swenzel]

I am trying to solve the same issue... I use :bprev and :bnext a lot to change between my source files so it also bugs me that this "scratch" buffer shows up. Tagbar and NERDTree also manage to be unlisted.
A screenshot to show what we mean:

I think that YCM might at least know the ID of that buffer since it gets updated with the function docstrings when going through the completions (in this case of np.array), so maybe YCM can also set nobuflist on it after its creation.
But the project so so big that I am also lost as to where this could be done, if at all.
By the way the "scratch" buffer is mentioned in vim's help files under special-buffers.

[vheon]

Just to be sure: so autocmd BufNew * if &previewwindow | setlocal nobuflisted | endif doesn't work?

[unphased]

@vheon All that does is remove the wrong buffer (the one having focus, instead of the new previewwindow buffer that just got made) from the buffer list.

The vim help for BufNew explains

NOTE: When this autocommand is executed, the
current buffer "%" may be different from the
buffer being created "<afile>".

BufAdd and BufCreate also have this problem. Not sure what the right autocommand to use is...

Hopefully "<afile>" can somehow be used to switch to the new one to set nobuflisted for it. Not sure how or if possible.

[yashsriv]

I know this has been inactive for a while but I think that this should be the solution to the problem
You won't be changing buffers in the midst of an autocomplete, hopefully, so the following 2 lines in your vimrc would close this extra buffer automatically once the completion is done:

let g:ycm_autoclose_preview_window_after_completion = 1
let g:ycm_autoclose_preview_window_after_insertion = 1

[puremourning]

@unphased

All that does is remove the wrong buffer (the one having focus, instead of the new previewwindow buffer that just got made) from the buffer list

You can use wincmd P to jump to the preview window then setlocal nobuflisted or whatever then wincmd w to jump back.

[dojoteef]

@vheon @puremourning I think there is some confusion on this point. The issue is not the use of the preview window, but rather the buffer that is displayed in the preview window. It's due to the way WriteToPreviewWindow is written in vimsupport.py. It is equivalent to:

:pclose! | execute 'silent! pedit! '.tempname() | wincmd P | set modifiable noreadonly | call append(0, 'This is a scratch buffer in a preview window') | set buftype=nofile nomodifiable noswapfile readonl y nomodified | wincmd p

If you type that into vim then CTRL-W z to close the preview window, then type :ls you will see that the buffer is still listed. That's what people are talking about. The problem is that if you use the visible buffers for quickly jumping between open buffers (for example :bnext as the OP mentioned) you run into a lot of these scratch buffers. That list grows very quickly.

If you simply added the following to line to the WriteToPreviewWindow function it would address the issue:

    vim.current.buffer.options[ 'buftype' ]    = 'nofile'
    vim.current.buffer.options[ 'swapfile' ]   = False
    vim.current.buffer.options[ 'modifiable' ] = False
    vim.current.buffer.options[ 'readonly' ]   = True
    vim.current.buffer.options[ 'buflisted' ]   = False

That is not quite the ideal solution as the buffer will still show up when using :ls! but it's better than what is currently being done. Ideally YouCompleteMe would use the same scratch buffer (evaluate tempname() once and store the value to be reused so it as not to create an excessive number of buffers) like so:

def GetPreviewBuffer():
  """ Get the preview buffer. Create it if it does not exist. """
  variable_name = 'g:ycm_preview_buffer_name'
  if not VariableExists( variable_name ):
    SetVariableValue( variable_name, vim.eval( 'tempname()' ) )

  return GetVariableValue( variable_name )


def WriteToPreviewWindow( message ):
...
  OpenFileInPreviewWindow( GetPreviewBuffer() )
...

Those two things combined would address the underlying issue. I've tested it out locally and it works well. If you want I can make a pull request for the change.

[Valloric]

@dojoteef It would be easier to evaluate that change in the PR, so please send one. :)