if e.g. doing a 'viw' to select the word under the cursor, the title of then newly created note lacks the last character
I can't reproduce this on Linux or Mac OS X (both running Vim 7.3), so maybe our environments are different? Please indicate the following:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 26 2012 16:45:52)
Inklusive der Korrekturen: 1-547
Ubuntu 12.10, but also tested in Debian 6 (Squeeze), both in vim and gvim.
I select a word with viw from normal mode, using it from insert mode does not really make sense unless you set hidden...
I believe the problem is in autoload/xolox/notes.vim in the func s:get_visual_selection().
It works fine with vaw, because then the cursor is on the non-word-character after the selected word, whereas with viw only the word itself is selected.
lines[-1] = lines[-1][: col2 - 2] removes the last character from the last "line" in all cases which makes it work with vaw, but not viw.
lines[-1] = lines[-1][: col2 - 2]
Changing lines[-1] = lines[-1][: col2 - 2] to lines[-1] = lines[-1][: col2 - 1] makes it work with viw (but breaks vaw)
lines[-1] = lines[-1][: col2 - 1]
I'd check if the character under col2-1 is a whitespace character and then go with -2 otherwise go with -1
I found the reason why I couldn't reproduce it earlier. Which means I now have to admit publicly that I have the following line in my ~/.vimrc:
I started using that way back when I was still on Microsoft Windows, because Vim was too much of a culture shock. I still haven't fully unlearned Control-C/V, however I am way more proficient with Vim, so maybe I should give it another go :-). Anyway, since I know how to reproduce the problem now, I hope to have a bug fix ready soon. Stay tuned!
Edit: To clarify, runtime mswin.vim executes behave mswin which executes set selection=exclusive (the default value is inclusive). This is probably the reason why the bug exists.
Make :NoteFromSelectedText compatible with selection=inclusive (issue #…
Issue #36 on GitHub:
NoteFromSelectedText trims the last character of a visual selection
Thanks for reporting this bug, I think I just squashed it!
Now the implementation of s:get_visual_selection finally makes sense :-). It was originally created on the basis of trial and error, which explains why the - 2 sneaked in there without any explanation. It bothered me from the start but I never once considered that the value of the selection option was to blame.
I'm closing this issue now as the problem should be resolved. If it's not then feel free to reopen this issue.
Confirmed. Thanks for the quick fix.