context.vim icon indicating copy to clipboard operation
context.vim copied to clipboard

Make it work with folds and wrapped lines

Open lourenci opened this issue 5 years ago • 5 comments

Hi, thanks for this awesome plugin. It's improved my workflow a lot.

Are the signed contexts below expected?

image

In the line where my cursor is on, they're just cluttering my reading on.

lourenci avatar Feb 09 '20 14:02 lourenci

Hey, could you share this file (or a similar one where you can reproduce a similar case)?

wellle avatar Feb 09 '20 19:02 wellle

Of course.

lourenci avatar Feb 09 '20 20:02 lourenci

Thanks! I played around with the file a bit but could not reproduce such a context. I also couldn't find the visible text custom header lane for example. Could you give me some instructions on how I could reproduce such a case with that file? Thanks!

wellle avatar Feb 09 '20 21:02 wellle

Sorry, I sent you an updated version of that file. Here is the right version: https://github.com/lourenci/react-kanban/blob/2d4f6a273921416f7223bcbccc3b46795d09e174/src/components/Board/index.spec.js.

I think the "problem" is more visible when using folds. I'll try to capture some reproducible steps to send to you later.

lourenci avatar Feb 09 '20 22:02 lourenci

I believe I know what you mean. If you have a fold which ends up behind the context popup, then the context will be misleading. This is because the context is about some lines which are hidden in the fold. I did run into similar issues when 'wrap' is set. I have this code comment about it:

" NOTE: there's a problem if some of the hidden lines
" (behind the popup) are wrapped. then our calculations are off

Currently context.vim assumes that each buffer line between the top line line('w0') and the bottom line line('w$') occupies exactly one screen line. In both of these cases (folds and wrapped lines) this isn't true. The problem is that in Vim script I can only easily (without moving the cursor) access buffer lines. I'm not aware of any way of accessing the line which is displayed in the 5th screen line for example. What I could do (and probably will have to) is actually moving the cursor from line to line (via gj) to "see" which screen line belongs to which buffer line(s).

It'll get a bit complicated, so I'm pushing that off for now. But thanks for opening this issue, I am very much interested in fixing this issue.

wellle avatar Feb 11 '20 21:02 wellle