GNOME Bugzilla – Bug 744286
make indent operations repeatable with '.'
Last modified: 2016-01-21 18:30:35 UTC
When I add a new public function to my code, I unsurpringly end up with the function signature in two places (the declaration in the header file, and the definition in the source file). In order to prevent retyping the whole thing I normally just type it in one place and copy and paste it to the other. The problem, though, is they are formatted differently. In my source file the return type is put on its own line, but in the header file, the return type is on the same line as the symbol name. That means the arguments need to be at different indention levels in each file. In vim I deal with this by selecting the lines that need to be moved over and then hitting '>' twice (to initiate an indent), followed by multiple '.' operations (to repeat the indent). This doesn't work in builder because '>' isn't recorded for replay. I'm attaching a patchset that implements this feature, but it has the somewhat undersirable side-effect of leaving the selection alive after the user hits '>'. A better patch would probably record the selection at the same time the '>' is recorded. Consider this a first draft, though I don't know if I'll pick it back up and do a second draft right away.
hmm, git-bz failed with 'Failed to attach patch to bug 744286, status=200'
I'd rather not upload the patches manually, so until git-bz and new gnome bugzilla get fixed, i've just pushed them to a branch here: https://git.gnome.org/browse/gnome-builder/log/?h=wip/halfline/repeatable-indent
(In reply to Ray Strode [halfline] from comment #0) > and then hitting '>' twice (to initiate an indent) that should say hitting '>' once. I confused myself, when I wrote the above. I only hit '>' twice if I need to indent one single line, not multiple, already selected lines.
(In reply to Ray Strode [halfline] from comment #1) > hmm, git-bz failed with 'Failed to attach patch to bug 744286, status=200' http://cgit.collabora.com/git/user/pwith/git-bz.git/tree/git-bz?h=bugzilla-4.4 has an updated version that's compatible with the new bugzilla version.
(In reply to Alexandre Franke from comment #4) > (In reply to Ray Strode [halfline] from comment #1) > > hmm, git-bz failed with 'Failed to attach patch to bug 744286, status=200' > > http://cgit.collabora.com/git/user/pwith/git-bz.git/tree/git-bz?h=bugzilla-4. > 4 has an updated version that's compatible with the new bugzilla version. Thanks, I actually read about that earlier today and installed it. I had assumed the branch needed further updates to work, but come to think of it, I didn't install it on this laptop, just my workstation.
Created attachment 296542 [details] [review] vim: make gb_source_vim_recording_end no-op when in replay When in the middle of a replace, gb_source_vim_recording_begin is aa no-op, so gb_source_vim_recording_end should be, too.
Created attachment 296543 [details] [review] vim: don't require non-zero captured events for replay Some commands that should be replayable don't have input events associated with them, so requiring captured events is wrong in those cases.
Created attachment 296544 [details] [review] vim: don't clear selection after indenting Technically, clearing the selection is right, but the selection isn't saved turn recording, and it's needed to implement replay. This commit keeps the selection around, to make way for adding replay support to '<' and '>'
Created attachment 296545 [details] [review] vim: support replaying '>' with '.' command One reasonable way to reindent code in vim is to select the lines, hit '>' to indent one time and then hit '.' several times until the desired indention level is reached. This doesn't work in gnome-builder because the '>' command isn't recorded. This commit make sure '>' (and '<') get recorded, so they can be replayed with '.'
Review of attachment 296543 [details] [review]: ::: src/vim/gb-source-vim.c @@ -4588,3 @@ if (!GTK_SOURCE_IS_VIEW (vim->priv->text_view) || - !vim->priv->recording_trigger || - !vim->priv->captured_events->len) So if we do end up saving the selection at record time, a better patch than this one would be (!vim->priv->captured_events->len && !vim->priv->captured_selection) (or something like that)
Review of attachment 296544 [details] [review]: One issue with this patch is the old selection isn't exactly correct. Ideally, if keeping the selection around is right, and the selection was initiated with shift-V, then the selection should get expanded to include the newly added whitespace. ::: src/vim/gb-source-vim.c @@ -4745,3 @@ gb_source_vim_indent (vim); - - gb_source_vim_clear_selection (vim); One issue with this is the old selection isn't exactly correct. Ideally, if keeping the selection around is right, and the selection was initiated with shift-V, then the selection should get expanded to include the newly added whitespace. Of course, I think a better solution is to clear the selection here but tuck it away from replay.
hi, Most things have been fixed in master and those patches are obsolete now ( code has changed ) thanks anyway for your work. I close this bug report but open a new one about non-working of repeat after indenting a selection