| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Since these `<Plug>` mappings are mode-specific, ensure we specify the
mode in the `hasmapto()` call.
|
|
Previously, if you typed, for example:
dgGk
this would perform `dk`, deleting the current line and the one above it.
That doesn't really make any sense. Instead, the `gG` should cancel the
operator. Do this by mapping to `<C-c>`.
In normal and visual modes, `gG` would move the cursor to the 0th
column. Returning an empty {rhs} causes the cursor to stay in the same
position it was in before pressing `gG`.
|
|
Now that this is an `<expr>` mapping, we don't need any special handling
for visual mode as this will be taken care of automatically.
Remove the `mode` argument as it's no longer used.
|
|
Since the plugin doesn't use this mapping any more due to the
performance delay, let's remove it. Tells people that it shouldn't be
used.
|
|
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`.
|
|
* Update CHANGELOG
* Increment version number in help file
|
|
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.
|
|
* Update version number in help file
* Update CHANGELOG
|
|
Don't output the mapping result in the command line when using the `G`
command.
Was handling this prevously with the `<Plug>Grappele` mapping but not
with the new one that I added in
07a75d523eadaf1027aa8bf287256602ad05f97f.
|
|
Include information about the initial v0.0.1 release.
|
|
Include a description of the plugin, installation instructions (copied
from one of my other plugins), and license information.
|
|
Create a help file with information about the plugin, its primary use
case, and information about its mappings (although one of them isn't
really noticeable as a customised mapping).
Also generate helptags.
|
|
MIT license
|
|
Looked into the performance issues I was having with the `G` command.
After a little profiling and then messing around with
let start = reltime() | <do stuff> | echom reltimestr(reltime(start))
Using the `reltime` method I discovered that `grappele#Grappele()` was
running pretty quick (~60 time units). I then ran it around the
:<c-u>call grappele#Grappele(v:count)<cr>
part of the mapping and found that it took about 130 time units.
Then doing
nnoremap G :let start = reltime() \| execute 'normal! G' | echom reltimestr(reltime(start))
was pretty quick.
With that information, I decided to try a direct mapping bypassing the
`<Plug>` mapping just to see what that would do. Turns out the custom
`G` command works much faster with this method for some reason. In terms
of feel it's as fast as the normal `G` command.
Replacing the `<Plug>` mapping with the direct one for speed. Not really
sure what the reason for this is but I'm glad the performance is up to
snuff and actually usable now.
I'm testing this on OS X 10.8.5 with the stock Vim (7.3 (2010 Aug 15,
compiled Jun 20 2012 13:16:02)). Also noticed this issue on my Debian
server which I just found out uses the same version of Vim (7.3 (2010
Aug 15, compiled May 4 2012 04:25:35)).
|
|
* 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.
|
|
Otherwise the mapped command is printed on the command line which isn't
necessary and adds visual noise and distraction.
|
|
Go to the end of the buffer when typed with no count, otherwise go to
the line specified by `v:count`.
|
|
|
|
Should be mapping `<Plug>Grappele` to the function call. `G` doesn't
belong in this map call. That's what the one at the end is for.
|
|
* Basic setup for the plugin:
* `loaded` global
* Create mapping definition based on style from tpope and System
Copy
* Create dummy function in autoload
|
