Nice add, but as expected, this doesn't work when there is a TODO item below the comment.

Example:

function myFunction1(array &$p1, string $p2, &$p3 = NULL, \Drupal\core\Entity\Node $p4) {
}

/**
 * [TODO:description]
 *
 * @param array $p1 [TODO:description]
 * @param string $p2 [TODO:description]
 * @param [TODO:type] $p3 (optional) [TODO:description]
 * @param \Drupal\core\Entity\Node $p4 [TODO:description]
 * @return [TODO:type] [TODO:description]
 */
function myFunction2(array &$p1, string $p2, &$p3 = NULL, \Drupal\core\Entity\Node $p4) {
}

I didn't finish myFunction2 and I started to do myFunction1 in the meanwhile. Then I'm not able to cycle through it. It doesn't work because of this.

I suggest you enable this by default only if the bug I just described is fixed. You can disable it by default for the tests in the vimrc used for the tests.

This is an option worth having its own tests, so I will add those later if you can fix the bug.

The option is disabled by default and it can stay optional. I see the problem and I couldn't find an easy fix due to how comment positions are updated at every jump. I understand that you're trying to restrict jumps between definite positions, but this is complicating things a lot, maybe a bit unnecessarily, because the TODO pattern is rather specific and unlikely to be found otherwise.
Anyway this is how it's working right now and it's your decision.

The main problem I've come across is how the function doge#comment#update_interactive_comment_info() looks for the end of the comment, without caring if there are other older comments after that, and overwrites the comment end position.
So even if I 'extend' the start/end positions at comment generation, taking into account pending comments, the values are overwritten by this function.

The easiest 'fix' that I can think of right now, is: when the option wrap_around is set, just loop among found placeholders and ignore start/end positions. Otherwise it becomes too complicated to update positions in a scenario where looping is unrestricted.

This would also allow (if desired, but totally secondary) a command like DogeCommentAll where you add comments to all functions that currently don't have one, and you fill them in one go.

I just thought of the solution actually because of your comment. Since we have the b:doge_interactive variable we can use the b:doge_interactive['lnum_comment_start_pos'] and go there if we reach the end of the function and then call the search() again.

I'll look into it this evening and/or else the end of the week.

I suggest we rename the name to g:doge_comment_wrap_around or maybe more preferablyg:doge_comment_jump_wrap. A main convention being held is g:doge_<context>_<name>.

maybe more preferably g:doge_comment_jump_wrap.

Ok for that.

I think the other problem is unrelated to the PR anyway, because it exists either way. I think it's better to consider it a different problem entirely. Personally I am for a simple solution (the one I proposed), but anyway.

this is complicating things a lot, maybe a bit unnecessarily, because the TODO pattern is rather specific and unlikely to be found otherwise.

The case is definitely not rare to appear. It is possible to have more TODO items around the just-generated comment. The placeholder regex matches [TODO:<context>] but also regular TODO items. The case is very likely to happen, that's why it's covered in this way.

TODOs wrapped in square brackets? I never saw them anywhere else. And if they're part of some DoGe comment, they are eligible for jumping anyway. But maybe I didn't understand.

TODOs wrapped in square brackets?

You haven't noticed these things like: [TODO:description] ?

Outside of this plugin? No. But if that's the problem, you can make the pattern more specific to the plugin, like [-TODO-:description]

Outside of this plugin? No.

It's a common pattern IDEs use for generating comment skeletons as well.

But if that's the problem, you can make the pattern more specific to the plugin, like [-TODO-:description]

There is no problem. Adding [TODO:<context>] is already unique enough. That's the reason why I used it just like other editors. I've done more than 10 languages and I haven't experiences any issues or conflicts with it and no one made an issue about it.

Ok so what's the problem if the mapping can loop over these TODOs as well? If there are TODOs to process, I don't see it as a problem, if I can loop over them even if they were not generated by DoGe.

I don't see it as a problem, if I can loop over them even if they were not generated by DoGe.

Because that's not the purpose of the plugin. Read the introduction in the README.

I have just fixed the extra scenario. I'll add specific tests later today or by the end of this week.

Pressing S-Tab with two comments (currently selected is first TODO of first comment), brings you to the last TODO of the last comment, and from there it can't move, you should also check that it doesn't go beyond last comment.

Works on my machine :) What Vim version are you using and what is the code you're testing it with?

It doesn't work for me (vim 8.0, but tested also in 8.1 and neovim)

What Vim version are you using and what is the code you're testing it with?

Can you provide me with this debug information?

Code is from here (line around 600):

https://raw.githubusercontent.com/mg979/vim-packs/master/vpacks

Vim version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 21 2019 04:10:35)                                                                                                                                     
Patch incluse: 1-197, 322, 377-378, 550, 649, 651, 703, 706-707                                                                                                                                        
Patch aggiuntive: 8.1.1401, 8.1.1382, 8.1.1368, 8.1.1367, 8.1.1366, 8.1.1365, 8.1.1046, 8.1.0613, 8.1.0547, 8.1.0546, 8.1.0544, 8.1.0540, 8.1.0539, 8.1.0538, 8.1.0506, 8.1.0208, 8.1.0206, 8.1.0205, 8
.1.0189, 8.1.0177, 8.1.0067, 8.1.0066                                                                                                                                                                  
Modificato da pkg-vim-maintainers@lists.alioth.debian.org                                                                                                                                              
Compilato da pkg-vim-maintainers@lists.alioth.debian.org                                                                                                                                               
Versione gigante con GUI GTK2.  Funzionalità incluse (+) o escluse (-):                                                                                                                                
+acl             +cmdline_compl   +digraphs        +folding         +langmap         +mouseshape      -mzscheme        +python3         +syntax          +toolbar         +writebackup                 
+arabic          +cmdline_hist    +dnd             -footer          +libcall         +mouse_dec       +netbeans_intg   +quickfix        +tag_binary      +user_commands   +X11                         
+autocmd         +cmdline_info    -ebcdic          +fork()          +linebreak       +mouse_gpm       +num64           +reltime         +tag_old_static  +vertsplit       -xfontset                    
+balloon_eval    +comments        +emacs_tags      +gettext         +lispindent      -mouse_jsbterm   +packages        +rightleft       -tag_any_white   +virtualedit     +xim                         
+browse          +conceal         +eval            -hangul_input    +listcmds        +mouse_netterm   +path_extra      +ruby            +tcl             +visual          +xpm                         
++builtin_terms  +cryptv          +ex_extra        +iconv           +localmap        +mouse_sgr       +perl            +scrollbind      +termguicolors   +visualextra     +xsmp_interact               
+byte_offset     +cscope          +extra_search    +insert_expand   +lua             -mouse_sysmouse  +persistent_undo +signs           +terminfo        +viminfo         +xterm_clipboard             
+channel         +cursorbind      +farsi           +job             +menu            +mouse_urxvt     +postscript      +smartindent     +termresponse    +vreplace        -xterm_save                  
+cindent         +cursorshape     +file_in_path    +jumplist        +mksession       +mouse_xterm     +printer         +startuptime     +textobjects     +wildignore                                   
+clientserver    +dialog_con_gui  +find_in_path    +keymap          +modify_fname    +multi_byte      +profile         +statusline      +timers          +wildmenu                                     
+clipboard       +diff            +float           +lambda          +mouse           +multi_lang      -python          -sun_workshop    +title           +windows                                      
   file vimrc di sistema: "$VIM/vimrc"                                                                                                                                                                 
       file vimrc utente: "$HOME/.vimrc"                                                                                                                                                               
    II file vimrc utente: "~/.vim/vimrc"                                                                                                                                                               
        file exrc utente: "$HOME/.exrc"                                                                                                                                                                
  file gvimrc di sistema: "$VIM/gvimrc"                                                                                                                                                                
      file gvimrc utente: "$HOME/.gvimrc"                                                                                                                                                              
   II file gvimrc utente: "~/.vim/gvimrc"                                                                                                                                                              
       defaults file: "$VIMRUNTIME/defaults.vim"                                                                                                                                                       
    file menu di sistema: "$VIMRUNTIME/menu.vim"                                                                                                                                                       
         $VIM di riserva: "/usr/share/vim"                                                                                                                                                             
Compilazione: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/i
nclude/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/incl
ude/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -Wdate-time  -g -O2 -fdebug-prefix-map=/build/vim-xBMBkh/vim-8.0.01
97=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1                                                                                                   
Link: gcc   -L. -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0
 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl  -lselinux  -lacl -la
ttr -lgpm -ldl  -L/usr/lib -llua5.2 -Wl,-E  -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.24/CORE -lperl -ldl -lm -lpthread -lcrypt  -L/usr/lib/python3.5/config-3.5m-x
86_64-linux-gnu -lpython3.5m -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm -lruby-2.3 -lpthread -lgmp -ldl -lcrypt -lm

I fixed the problem by removing our double logic, which simplifies the code and also when we would've allow w inside the search() function you would get a message from the search() function that I wasn't able to silence. However, I prefer this version anyway since it's a more of a simplified version. I'll start to add tests right away.

It was better, but still having problems when wrapping backwards (S-Tab), does it work for you?

Ah, I do have the same yes, but your fix was the fix I immediately thought of. Good catch.

I've added the tests for jumping forwards/backwards functionality. I think it's ready to merge. Agree @mg979 ?

It's working ok for me.

If you update the readme, there's the FAQ section that's probably outdated.

If you update the readme, there's the FAQ section that's probably outdated.

I will test it out immediately. This is a great PR again from you. I had to ditch UltiSnips personally to use my own plugin. This would probably solve it. Also, I added the ^ as well to ensure the search always results in the first TODO again. See this commit.

Ultisnips was actually solved by buffer mappings, this is more of an usability feature.

By the way, I get some annoying highlight when tabbing in vim (but not neovim), do you get the same?

I get some annoying highlight when tabbing in vim (but not neovim), do you get the same?

Nope. It should be removed by this part: :silent! noh\<CR> in this part. Can you add a GIF with your reproduced bug?

I confirm the problem is fixed and thus it also fixed #16.

This. By the way it's totally off topic, sorry.

That's because you don't have lazyredraw set. It fixes those annoying things and improves your overall Vim performance. I don't think it's something that can be fixed unless you add set lazyredraw to your vimrc.

EDIT: I will confirm this in IRC right away.

Yes that fixes it. Might I make a PR to take care of it? I don't think it's that common to have that setting in the vimrc, and if it's disabled by default there may be some reason.

Might I make a PR to take care of it?

Sure. You can do let &hlsearch = 0 in the doge#activate() and let &hlsearch = 1 in the doge#deactivate(), but the catch here is that: What if I want to search halfway through a DoGe comment? Then the search doesn't get highlighted. If I do: /<any char> or ?<any char> then it doesn't highlight it anymore. I've been thinking about using the InsertChange event and then check if / or ? is pressed, if so then do let &hlsearch = 1 again, but I don't know if there's a better way. This is just a suggestion.

EDIT: I think if we want to do the above we actually have to map the / and ? key in order to check whether they were pressed. Anyway, let's continue this discussion at a new PR.

I will merge this PR. The merge seems ready and this is a very good update. Thanks a lot!

I think it's ready. The PR with the lazyredray thing is also there, I'm just enabling the setting, it's working in my setup.