:goto is broken with text properties

[sam-mccall]

Describe the bug
When textprops are set, :goto goes to the wrong position in some cases. The ifdef'd calculations in ml_find_line_or_offset seem to be incorrect.

To Reproduce

1. vim --clean and create the following buffer

abc
..........
..........

2. :call prop_type_add('foo', {})
3. :call prop_add(1,1,{'length':2, 'type':'foo'})
4. :goto 4 goes to line 1 col 3 (correct)
5. :goto 5 goes to line 2 col 1 (correct)
6. :goto 6 goes to line 2 col 1 (incorrect)
7. any :goto from 7 - 15 also goes to line 2 col 1 (incorrect)
8. :goto 16 goes to line 3 col 1 (correct)

Expected behavior
:goto 6 should go to line 2 col 2
:goto 7 should go to line 2 col 3 etc

Environment (please complete the following information):

• Vim version: v8.2.0579 (master)
• OS: debian (glinux)
• Terminal: xfce4-terminal 0.8.9.1

Additional context
The relevant call to ml_find_line_or_offset stores a negative offset in *offp which seems suspicios (e.g. :goto 5 -> -20, :goto 6 -> -19).
But I don't understand the code well enough to proceed further myself.

My distro-installed vim is 8.1.2269 and shows quite different incorrect behavior for the same :gotos, jumping to the start or end of buffer. My guess is b413d2e was intended to fix this but was not correct.

[sam-mccall]

Workaround: since things work at line boundaries, line2byte and byte2line both seem to work. For a quick hack

:command! -nargs=1 Goto :call cursor(byte2line(<args>), <args>-line2byte(byte2line(<args>))+1)

(This only gives the right answer with a recent vim, with my distro 8.1.2269 byte2line is broken too)

[dbarnett]

Has the bug in vim been fixed?

[dpelle]

@dbarnett wrote:

Has the bug in vim been fixed?

The bug has simple reproducible steps.
I could still reproduce it with vim-8.2.1313 on Linux x86_64.
So it is not fixed yet.

:help todo also has this:

Text properties:
- :goto does not go to the right place when test properties are present.
  (#5930)

[AndrewRadev]

Ran into the same bug and did some debugging before finding this issue. To add something very minor to the conversation, here's a regression test that can be added to src/testdir/test_textprop.vim to replicate the issue:

func Test_prop_go()
  enew

  call setline(0, 'one')
  call setline(1, '')
  call setline(2, 'two')
  call setline(3, '')
  call setline(4, 'three four')

  call prop_type_add('testprop', {'highlight': 'Directory'})
  call search('^two')
  call prop_add(line('.'), col('.'), {
        \ 'length': len('two'),
        \ 'type':   'testprop'
        \ })

  call search('three \zsfour')

  let expected_byte_position = line2byte(line('.')) + col('.') - 1
  exe expected_byte_position 'goto'
  let actual_byte_position = line2byte(line('.')) + col('.') - 1

  eval actual_byte_position->assert_equal(expected_byte_position)

  call prop_type_delete('testprop')
  bwipe!
endfunc

If the prop_add call is commented out, this test passes just fine, otherwise I get the error Test_prop_go line 23: Expected 13 but got 7.