| Age | Commit message (Collapse) | Author |
|---|
|
This function no longer needs any extra arguments.
|
|
Fix visual mode bug where when the cursor is at the top of a visual
selection, pressing `gG` changes the bottom of the visual selection
instead of the top.
|
|
Holdover from old code.
|
|
Clean up the file by removing old code that's no longer necessary.
|
|
Previously, if we stored a number in `s:line`, for example with `17G`,
then `>gG` would cause lines .,17 to be indented 17 times due to the use
of `V`.
When I removed `V` from the omap, any commands using `gG` operated
characterwise, when they should operate linewise.
Found this answer from Liu Sha
(https://stackoverflow.com/users/7026980/liu-sha)
https://stackoverflow.com/questions/4261177/discarding-count-in-expr-mappings/53182922#53182922
that shows how to discard the count for different types of mappings:
> nnoremap <expr> s "@_" . ToNthSpace()
> vnoremap <expr> s "@_" . ToNthSpace()
> onoremap <expr> s printf(":normal %s\<cr>", ToNthSpace())
The `:normal!` looks like it discards the count, so this gives us what
we want. Adapted the suggestion into a new `<expr>` omap that indents
only once for e.g. .,17.
|
|
gG omap works characterwise but should work linewise.
Adding V to the gG omap causes >17G to indent 17 times instead of once.
Try changing `G` to an `<expr>` mapping to simplify the code, allowing
it to work more exactly like the normal `G`. This resulted in moving the
logic to `grappele#Recall()`, causing problems for `gG`.
|
|
I previously added o- and v-maps for the `gG` mapping, but hadn't done
so for `G`.
This change allows us to reuse lines given to `G` from other modes. For
example:
173>>..ygG
Didn't use `<Plug>` mappings here because after testing them, there was
a noticeable delay. Found 07a75d523eadaf1027aa8bf287256602ad05f97f,
which describes a performance penalty, so used direct mappings instead.
Kept the `<Plug>Grappele` mapping for a measure of backward
compatibility.
|
|
New mappings that allow the stored `G` position to be used in both
visual mode and operator-pending mode for greater flexibility.
|
|
Previously, if `gG` (the recall mapping) was pressed before previously
having pressed a `G` command, the following error would appear:
Error detected while processing function grappele#Recall:
line 1:
E121: Undefined variable: s:line
E116: Invalid arguments for function grappele#Grappele
This happened because no previous `G` location had been saved.
Displaying an error here makes for a bad user experience. Instead if
this happens, we should just do nothing. To prevent the error, check for
the existence of the `s:line` variable before trying to use it.
|
|
Previously, we would save the location of the `G` command regardless of
whether it was used with a count or not. Thus, `34G` and `G` would both
save locations.
Saving the location of `G` isn't really useful, but it's easily
accessed. Instead, only save location when using a count with `G`. This
allows the Grappele command to be useful even after having pressed `G`.
|
|
Turns out that invoking `G` wouldn't push your movement to the jumplist
(unlike Vim's real `G`). This was not only confusing, it was also wrong.
Just an oversight on my part that I didn't notice until now.
|
|
* Add mapping for the recall command. Using `gG` because it's quick,
easy to remember, and doesn't appear to be used for anything.
* Create `grappele#Recall()` function that goes to the last `G` count
* Store the most recent count passed into `G`
Using the recall command, you can `G` to the same count that you
previously used no matter what buffer you're now in.
TODO: The `G` command appears to be running slowly now for whatever
reason. Investigate what's going on.
|
|
Go to the end of the buffer when typed with no count, otherwise go to
the line specified by `v:count`.
|
|
* Basic setup for the plugin:
* `loaded` global
* Create mapping definition based on style from tpope and System
Copy
* Create dummy function in autoload
|
