Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option global mark goto buffer instead of line #1413

Conversation

dalanicolai
Copy link

This PR is a first proposal to add, in a first commit, an option to jump to last location in buffer instead of specific line for evil-mark-goto-line for global marks.

A second commit additionally adds functionality to show marks in the *evil-marks* buffer after some delay (similar to which-key behaviour) when the value of the evil-mark-goto-buffer-not-line is t (default). This is especially handy to get reminded about which mark is associated with which buffer.

I have implemented it as an option, and because of adding the various conditionals, the code became a little more "complicated".
I would propose to make the buffer jump the default behavior (breaking with vim behavior, although the change could be proposed there also). If users want to jump to a specific line via a global mark they can just jump with backtick (followed by pressing ^).

I have seen various requests for functionality to easily jump to buffers by shortcut. This (arguably simpler) solution was inspired by @yyoncho his evil-markers-plus package.

I am opening this PR as a proposal. If you like it, then I would appreciate some feedback and I would be happy to add documentation for it also.

@yyoncho
Copy link
Contributor

yyoncho commented Feb 1, 2021

Just want to mention that evil-markers-+ allows using normal global markers and special(which will go to the buffer). IMHO if this PR is accepted it should support that as well.

@dalanicolai
Copy link
Author

dalanicolai commented Feb 1, 2021

@yyoncho This PR also supports both. It uses the backtick for normal global marker functionality, but it "replaces" the goto-mark-line via single quote with the 'go to buffer' variant (jump via quote ' currently jumps to first non-blank character of line, which I guess is of low priority for global jumps as there is jump via backtick already)

@dalanicolai dalanicolai force-pushed the add_option_global_mark_goto_buffer_instead_of_line branch from 82621b2 to 916532a Compare February 1, 2021 13:49
Because of multiple requests to have some quick way to mark buffers for quickly
switching between multiple buffers, and also inspired by @yyoncho his
[evil-marker-plus](https://github.com/yyoncho/evil-markers-plus), I figured that
it is often preferred to just jump to the last buffer position instead of a
specific line number when jumping to a global mark (if one wants to jump to the
specific line then one could jump with backtick, optionally follow by a zero,
instead of jumping with quote.

A following commit implements listing the marks with some delay in *evil-marks*
buffer (similar to which-key package behavior)
This commit adds functionality to the previous commit (i.e.
mark-goto-buffer-not-line), and shows marks in the *evil-marks* window after a
delay (similiar to which-key). It is especially handy to remind of which mark is
associated with which buffer.
@dalanicolai dalanicolai force-pushed the add_option_global_mark_goto_buffer_instead_of_line branch from 916532a to cc1e751 Compare February 1, 2021 13:54
@dalanicolai
Copy link
Author

I am closing this PR for now because I have found some errors.

Still I think that when making a global jump (i.e. between different buffers), using the evil-goto-mark-line could better be used to merely jump to the buffer and then stop (instead of continue to also find the line). In that way, the quote can naturally be used to quickly jump between buffers (with very little implementation effort). It is nice if no extra and less efficient key-sequence has to be found/reserved for that (jumping to the first non blank character of the line can still be achieved by using the backtick jump followed by a ^).

Also, it might be nice to additionally offer the which-key-like behavior that was implemented here in the second commit.

I will probably reopen this PR later, but I'd like to take a little more time to find a cleaner implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants