sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
807 stars 39 forks source link

Add count and wrap options for git next_modification and prev_modification #2623

Open gerardroche opened 5 years ago

gerardroche commented 5 years ago

In a recent build two commands for jumping to the next and previous change we're added, re Diff gutter suggestions.

The comparative commands in Git Gutter provide both the options were count defaults to 1 and wrap to False:

self.view.run_command('git_gutter_next_change', {'count': 1, 'wrap': False})
self.view.run_command('git_gutter_prev_change', {'count': 3, 'wrap': False})

Reason

NeoVintageous has support for jumping forward and backwards through changes using GitGutter. I'd like to support the built in commands in newer builds.

command description documentation
[c Jump backwards to the previous start of a change. diff
]c Jump forwards to the next start of a change. diff

The jump commands allow a count e.g. 4]c jump to 4th change forward.

Generally we want to stop at the EOF (no wrap), because it can be really confusing if it wraps.

See also: https://github.com/jisaacks/GitGutter/issues/458.

It would also be nice to have an option to disable the visual selection on jumps i.e. currently, next and prev modification visual selects the modification. In NeoVintageous we need to clear the selection on jump, because we're jumping from normal mode (non visual) and don't want the mode to change on jumps.

michaelhogg commented 5 years ago

Generally we want to stop at the EOF (no wrap), because it can be really confusing if it wraps.

Yes, I completely agree.

With GitGutter, I always had the next_prev_change_wrap setting switched off (_"determines whether the next_change and prev_change commands wrap around on reaching the beginning/ending of the file"_), and I'd really appreciate the ability to disable wrapping for Sublime's next_modification and prev_modification commands.

gerardroche commented 5 years ago

It would be nice if other commands like next_misspelling and prev_misspelling command could have a similar api to control the count and wrapping.