matsui54 / ddc-source-buffer Goto Github PK

@matsui54

Hi, I'm setting up the plugin and have questions regarding these two parameters.

fromAltBuf: I'm usually working within a loaded nvim session. Even though a buffer is loaded in another tab, I noticed that I need to switch to the tab/buffer before ddc picks up the buffer as a source. Is there a way to have it automatically use all loaded buffers (visible and non-visible) without navigating to them?

forceCollect: I'm a bit confused about this parameter. Is this just an override for limitBytes for buffers in the current tab?

If you want to ensure that keywords are always collected on initialization of ddc, enable this feature.

What does this mean exactly?

Thank you

So I've been having this issue recently that when performing :Git commit and :Git push using vim fugitive, the output from those commands and the cursor would get re-positioned in very strange ways:

You can see a video of the issue here:

macvim-dev/macvim#1207

Essentially, after running those commands, you should see a press ENTER prompt, but visually there is nothing, and it's almost as if Vim gets in a weird draw state. For what it's worth, this happens in both Vim and MacVim, latest versions with all the latest patches.

Originally I thought this was either a fugitive issue, or a MacVim rendering bug. However, after more digging I found the issue was not reproducible if I ran Vim with JUST the fugitive plugin. After some binary searching across all my plugins, I eventually found that source of the issue is this plugin; specifically -- when it reacts to the BufReadPost event:

https://github.com/matsui54/ddc-buffer/blob/main/denops/%40ddc-sources/buffer.ts#L52

If I remove that specific event, Fugitive's output from those commands works perfectly -- I see the green press ENTER prompt.

Not sure if it's totally related, but I did see in the documentation for BufReadPost that there's another event you can use BufWinEnter that will handle events after processing the modelines. Replacing BufReadPost with BufWinEnter seems to fix the bug, but my autocmd vim fu is not strong enough for me to tell whether this is an acceptable workaround, but figured I would share it here as well.

The repository name should be ddc-source-buffer.

Shougo/ddc.vim#30

https://github.com/matsui54/ddc-buffer/blob/main/denops/ddc/sources/buffer.ts#L50

It gets whole buffer lines by one RPC.
It exceeds current RPC in/out buffer(probably 65535).

You need to use multiple RPCs like deoplete.

def getlines(vim: Nvim, start: int = 1,
             end: typing.Union[int, str] = '$') -> typing.List[str]:
    if end == '$':
        end = len(vim.current.buffer)
    max_len = min([int(end) - start, 5000])
    lines: typing.List[str] = []
    current = start
    while current <= int(end):
        # Skip very long lines
        lines += [x for x in vim.call('getline', current, current + max_len)
                  if len(x) < 300]
        current += max_len + 1
    return lines

Can you add file/path completion source for ddc.vim?

Version

NVIM v0.6.0-dev+313-g490e09c6d
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by [email protected]

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/opt/homebrew/Cellar/neovim/HEAD-490e09c/share/nvim"

Run :checkhealth for more info

Minimal vimrc

set rtp+=~/.cache/dein/repos/github.com/vim-denops/denops.vim
set rtp+=~/.cache/dein/repos/github.com/Shougo/ddc.vim
set rtp+=~/.cache/dein/repos/github.com/matsui54/ddc-buffer

call ddc#custom#patch_global('sources', ['buffer'])
call ddc#enable()

Description

When save, it does like Gzt (vim normal command).

Reproduction

1. Open buffer
2. Type something.
3. G or Gk
4. :w

Sometimes happens, but sometimes it doesn't happen.

Screenshot