Moving through completion list doesn't update description in scratch buffer correctly

[ackalker]

When moving up and down in the completion list, the description displayed in the scratch buffer doesn't update correctly.

$ vim --version | head -n 3
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun  1 2014 10:47:35)
Included patches: 1-307
Compiled by Arch Linux

tern_for_vim@master

Steps to reproduce:

• In a directory, make sure the following file exists:

.tern-project

{
  "plugins": {
    "node": { }
  }
}

• Edit a new JavaScript file (say example.js) with Vim
• Type global. and start omni completion, make sure the selection is on the first item: __dirname (str). Observe the following in the scratch buffer:

string
The name of the directory that the currently executing script resides in.

[Scratch] [Preview]

• Move the selection one entry down (Tab, C-N, ...), so that it is now on: __filename (str). Observe the following in the scratch buffer (minor issue: are those @ characters supposed to be there?):

string
@                                                                                                   
@                                                                                                   
[Scratch] [Preview]

• Move the selection down one entry, so that it is now on: clearInterval (fn). Observe the following in the scratch buffer (again those @ characters...):

fn(id: timers.Timer)
@                                                                                                   
@                                                                                                   
[Scratch] [Preview]

• Move the selection up two items, so that it is again at __dirname (str). Observe the following in the scratch buffer:

string 
@                                                                                                   
@                                                                                                   
[Scratch] [Preview]

• Note that now the description: The name of the directory that the currently executing script resides in. is missing.
• Move the selection up once more (this should clear the completion at the curser), then down again, so that it is once again at __dirname (str). Observe that now the full description is shown correctly again in the scratch buffer:

string
The name of the directory that the currently executing script resides in.

[Scratch] [Preview]

[marijnh]

On my vim (see below), this bug does not appear to occur -- there are no @ characters, and the descriptions update properly as I move around. It seems something is getting corrupted, but I don't know enough about vim to guess where that might be coming from.

@clausreinke Have you seen something like this before?

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 12 2013 00:23:19)
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@

[ackalker]

I've tried updating the nodejs modules in tern_for_vim package (oops, I forgot to do that for a while) which pulled in tern@0.6.0. Sadly, the problem remains.

I did discover that the description text for the entries with @s in them is actually there: if I scroll the scratch buffer, it 'magically' appears. The odd thing (which does hint at corruption of some kind) is that when my cursor is on the first char of the type definition and I try to move down one line, the cursor skops all the @s at once (scrolling the line with the type definition out of sight) and ends up on the first character of the description.

Example (with completion on global., selected entry __filename:

Before scroll (omnicomplete list open, first few lines of edit buffer copied as well):

string
@                                                                                                   
@                                                                                                   
[Scratch] [Preview]                                                               1,1            Top
global.__filename
~      __dirname          (str)                                                                     
~      __filename         (str)                                                                     

After (switch to scratch buffer, cursor down once):

The filename of the code being executed. This is the resolved absolute path of this code file. For a
 main program this is not necessarily the same filename used in the command line. The value inside a 
 module is the path to that module file.
[Scratch] [Preview]                                                               2,1            50%
global.__filename

Note that the line number in the scratch buffer is 2, but the cursor jumped down 3 lines, past all the @ characters...)

[ackalker]

It appears that the scratch buffer window wasn't big enough to contain the text (in particular the very long description line) in it. Typing C-W + while in the scratch buffer to increase the height of the window makes the description text appear correctly, so I think the issue is more of a Vim quirk rather than with tern_for_vim.

[ackalker]

(Reopening this issue because I think there may be a way for tern_for_vim to mitigate this.)

From some digging, I found out the following (note: I'm by no means a Vim wizard, so correct me if I'm wrong!):

• My Vim window didn't have a lot of space available on my screen (using a tiling WM, many open tiles, and low vision which requires me to use a large font doesn't allow for a lot of lines and columns per Vim window).
• The preview scratch buffer window appears to have a (very minimal) height of only 4 lines (even when :set previewheight shows it to be 12), which combined with the small number of columns doesn't leave much room for the description.
• The @ characters appear to be Vim's way of indicating that it cannot display both the (wrapped) line with the cursor in it and the following line in its entirety in the window, i.e. some kind of 'overflow' indicator.
• doing :set winheight=<n> | set winminheight=<n> before doing any onmi complete doesn't help much, as there are description lines which are so long that they will overflow anyway (in my case, this happens even with n = 5).

From this, it appears that only :setlocal nowrap on the scratch buffer window or breaking up the long description line into smaller chunks which each fit in the window will solve the issue completely.

My question: would it be possible to make the line wrap state configurable? Looking at https://github.com/marijnh/tern_for_vim/blob/master/autoload/tern.vim#L22 , I would think that the split(a:info, "\n") should do this splitting into chunks already. Could it be that some chunks between \n's are really so long that they don't fit? Or is append(..., {list}) not appending the elements in the list as individual lines?

I hope that you have some time to look at this, much appreciated.

[ackalker]

Answering my own question with regard to line length: yes, they are that long :-( Found this out by running Tern standalone: $ ~/.vim/bundle/tern_for_vim/node_modules/.bin/tern --verbose, then starting Vim in another terminal. (Thanks marijnh for this beautiful JSON interface, it is very descriptive and educational :-) ) So I guess that the choice between wrap or nowrap is the only one left...:-(

[ackalker]

More digging, it appears that set previewheight=<n> in .vimrc is useless for increasing the default height of the preview window, because a maximum of 3 lines is hardcoded in the Vim source code (yuck, see src/popupmnu.c, search for g_do_tagpreview (what's in a name...)), even though the default value of previewheight is 12.

As a workaround, I've added this kludge to my .vimrc (suggestions to improve it are very welcome):

" Increase height of preview window
" Adapted from http://stackoverflow.com/a/3787326/588561
set previewheight=6
au WinEnter * call PreviewHeightWorkAround()
func PreviewHeightWorkAround()
        if &previewwindow
                exec 'setlocal winheight='.&previewheight
        endif
endfunc