Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

byte2line() can return -1 #5334

Closed
mg979 opened this issue Dec 9, 2019 · 6 comments
Closed

byte2line() can return -1 #5334

mg979 opened this issue Dec 9, 2019 · 6 comments

Comments

@mg979
Copy link

@mg979 mg979 commented Dec 9, 2019

Describe the bug
In certain situations byte2line() returns -1 when it should not. See this issue and this comment.

The bug first appears in 8.1.1522 (it works in 8.1.1521).

The issue is triggered by a plugin (in this case coc.nvim), but it seems related to the popup feature.

To Reproduce
In that file, with the coc.nvim plugin activated, byte2line() returns -1 for values after a threshold.
In that file it's byte2line(39) for me (right after the line with first error that would also show a popup).

Expected behavior
byte2line() shouldn't stop working.

Screenshots
Imgur

Environment (please complete the following information):

  • Vim version: first affected is 8.1.1522
  • OS: tested in both windows and linux, terminal or GUI (gvim)
@brammool

This comment has been minimized.

Copy link
Member

@brammool brammool commented Dec 11, 2019

Can you please reproduce without the plugin?

@mg979

This comment has been minimized.

Copy link
Author

@mg979 mg979 commented Dec 11, 2019

I don't know what that plugin does, that messes up byte2line() return value. If I disable it with CocDisable and reload the buffer, byte2line() returns the correct value again. Note that even if that issue was posted for my plugin, the problem is caused by the other plugin (coc.nvim), that uses popup and signs column.

I'll see if I can reproduce without plugins, just with function calls. I'll take a look at that plugin source and see if I can figure out something.

@bhcleek

This comment has been minimized.

Copy link

@bhcleek bhcleek commented Jan 13, 2020

I'm seeing something similar when trying to use byte2line in vim-go. Both vim-go and coc use text properties, and I think the use of text properties might be relevant, because when I change vim-go by commenting out the prop_add call, byte2line always returns the right value and when prop_add is used, it seems like it byte2line returns the correct value until after a prop_add call.

I've tried unsuccessfully to get a very simple reproduction path. However, I do have a clear (though not simple) reproduction path.

  1. With a functioning version of vim-go installed from https://github.com/bhcleek/vim-go/tree/vim/byte2line (the branch is required, as it contains the refactors to use byte2line).
  2. Edit decoder.go from https://github.com/bhcleek/sqldecoder/tree/vim/byte2line (the branch is required, because it contains the Go syntax errors needed for vim-go to add text properties).
  3. Position the cursor at or after line 33, with line 27 also showing. Sometimes I've had to scroll the screen up and down some to cause the byte2line problems.

byte2line will return the wrong value for byte2line(line2byte(33)+1, but not for byte2line(line2byte(33)).

Here's the line that I can comment out to avoid the byte2line problem: https://github.com/bhcleek/vim-go/blob/c2418ec1933783cf8144bca13add13112beaa865/autoload/go/util.vim#L624.

Here's my :version output:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov  6 2019 08:27:51)
macOS version
Included patches: 1-2250
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl               +clipboard         -dnd               +gettext           +localmap          +mouse_urxvt       +profile           +statusline        +timers            +windows
+arabic            +cmdline_compl     -ebcdic            -hangul_input      +lua               +mouse_xterm       -python            -sun_workshop      +title             +writebackup
+autocmd           +cmdline_hist      +emacs_tags        +iconv             +menu              +multi_byte        +python3           +syntax            -toolbar           -X11
+autochdir         +cmdline_info      +eval              +insert_expand     +mksession         +multi_lang        +quickfix          +tag_binary        +user_commands     -xfontset
-autoservername    +comments          +ex_extra          +job               +modify_fname      -mzscheme          +reltime           -tag_old_static    +vartabs           -xim
-balloon_eval      +conceal           +extra_search      +jumplist          +mouse             +netbeans_intg     +rightleft         -tag_any_white     +vertsplit         -xpm
+balloon_eval_term +cryptv            -farsi             +keymap            -mouseshape        +num64             +ruby              -tcl               +virtualedit       -xsmp
-browse            +cscope            +file_in_path      +lambda            +mouse_dec         +packages          +scrollbind        +termguicolors     +visual            -xterm_clipboard
++builtin_terms    +cursorbind        +find_in_path      +langmap           -mouse_gpm         +path_extra        +signs             +terminal          +visualextra       -xterm_save
+byte_offset       +cursorshape       +float             +libcall           -mouse_jsbterm     +perl              +smartindent       +terminfo          +viminfo
+channel           +dialog_con        +folding           +linebreak         +mouse_netterm     +persistent_undo   -sound             +termresponse      +vreplace
+cindent           +diff              -footer            +lispindent        +mouse_sgr         +postscript        +spell             +textobjects       +wildignore
-clientserver      +digraphs          +fork()            +listcmds          -mouse_sysmouse    +printer           +startuptime       +textprop          +wildmenu
@dreamcoat

This comment has been minimized.

Copy link

@dreamcoat dreamcoat commented Jan 13, 2020

I can reproduce a bug with byte2line for buffers which have text properties. If byte2line is given a byte count for any line after (but not including) the first line in the buffer which has text props, either the correct line number minus 1 is returned (for the line after) or -1 is returned (for all other subsequent lines).

byte2line returning correct line number - 1

new
call setline(1, ['one one', 'two two', 'three three', 'four four', 'five'])
echo byte2line(line2byte(4))

call prop_type_add('prop', {'highlight': 'Directory'})
call prop_add(3, 1, {'length': 5, 'type': 'prop'})
echo byte2line(line2byte(4))

call prop_type_delete('prop')
bd!

Outputs 4 then 3. Should of course be 4 for both.

byte2line returning -1 (only the line number for line2byte is changed).

new
call setline(1, ['one one', 'two two', 'three three', 'four four', 'five'])
echo byte2line(line2byte(5))

call prop_type_add('prop', {'highlight': 'Directory'})
call prop_add(3, 1, {'length': 5, 'type': 'prop'})
echo byte2line(line2byte(5))

call prop_type_delete('prop')
bd!

Outputs 4 then -1. The same result can be achieved by adding another text prop before line 3.

I don't think line2byte is affected by this, just byte2line.

@dreamcoat

This comment has been minimized.

Copy link

@dreamcoat dreamcoat commented Jan 13, 2020

I've been looking at ml_find_line_or_offset in memline.c which is called by byte2line and I've found that removing lines 5783 to 5793 (which sets len when a buffer has text props) seems to fix this bug, but likely has other side effects. Any thoughts on this?

Sorry to double-post. I thought it better to add this seperately.

@brammool brammool closed this in 9df53b6 Jan 13, 2020
@brammool

This comment has been minimized.

Copy link
Member

@brammool brammool commented Jan 13, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.