Add mappings for other g* commands

[memotype]

j and k are mapped to gj and gk, which is awesome, but you should also include these mappings for consistent behavior, otherwise it's confusing:

noremap $ g$
noremap <End> g<End>
noremap 0 g0
noremap <Home> g<Home>
noremap ^ g^

[spf13]

Great idea, Pull request?

[lukedomanski]

Hi,

This is annoying when ':set nowrap' is on.

While gj and gk seem to collapse to the same behavior as j and k for wrap and nowrap, the same can not be said for g$ , g0, and g^ versus $, 0, and ^, where it STILL causes the cursor to only move to the first/last column of the display in nowrap mode.

Since the default $, 0, and ^ are overwritten, you then have to find some other way of jumping to the start/end of the nowrapped line.

@memotype - can you please fix this so that either:

1. you can optionally turn it off by putting a option into .vimrc.before, as is done for other features (easiest way)
2. the mappings toggle on and off when wrap mode is changed (harder, but most transparent and thorough)

[lukedomanski]

This was so crippling to the way I use VIM that I tried to fix it myself.

With my limited vimscript experience I could not figure out a way to toggle these mappings when wrap is set or reset. All I could come up with was to check if wrap was set each time the mapping triggered, and alter the normal mode command executed.

The following seems to work, if you are happy with it, please include it::

    " Same for 0, home, end, etc
    function! WrapRelativeMotion(key)
        if &wrap
            execute "normal! g" . a:key
        else
            execute "normal!" a:key
        endif
    endfunction

    noremap $ :call WrapRelativeMotion("$")<CR>
    noremap <End> :call WrapRelativeMotion("$")<CR>
    noremap 0 :call WrapRelativeMotion("0")<CR>
    noremap <Home> :call WrapRelativeMotion("0")<CR>
    noremap ^ :call WrapRelativeMotion("^")<CR>

[lukedomanski]

Close?

[memotype]

Sorry, I haven't been doing any coding recently. Life, etc. If some one
else wants to take over these changes feel free.
On Jan 19, 2014 3:19 PM, "lukedomanski" notifications@github.com wrote:

Close?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/464#issuecomment-32718663
.

[gonzaloserrano]

I just run with this problem but something weird is happening.

Either i set wrap or nowrap, when i do a simple d$ the last character is not removed.

Anyone noticed this?

[rekendahl]

I have his issue too. I haven't searched for a solution but it's driving me crazy.

Sent from my iPad

On Jan 26, 2014, at 10:53 AM, Gonzalo Serrano notifications@github.com wrote:

I just run with this problem but something weird is happening.

Either i set wrap or nowrap, when i do a simple d$ the last character is not removed.

Anyone noticed this?

—
Reply to this email directly or view it on GitHub.

[lukedomanski]

Hi guys,

Sorry, can you please describe in more detail what the problem is?

On a standard txt file (i.e. filetype="") C/C++ files and various other file types, I am not getting the behavior you describe.

[lukedomanski]

As a work around, sometime today I will add a g:spf13_no_wraprelmotion variable and conditional statement around this code. That way you can run with the official spf13-vim branch and still disable it easily.

[gonzaloserrano]

It happens to my with every filetype (i tried php, js, erl, py and no filetype) , i just go to the beggining of any line, do a d$ and the last character is not removed.

Deleting from https://github.com/spf13/spf13-vim/blob/3.0/.vimrc#L266 till 282 solves this.

[lukedomanski]

Okay,

I'll take a closer look today. Maybe someones else's updates/pull request has clashed with it, because the version I currently have does not do this.

I don't think deleting it straight out is the answer, unless we roll back to before memotype's original change. As I said above, I'll also put an option to turn it on and off in case it is causing issue for some and not for others.

[lukedomanski]

I've managed to reproduce the problem. It was not occurring for me originally because I was using YankRing (which remaps d).

The reason it is occuring is due to the use of the :execute "normal! $" command in combination with d. While $ and :execute "normal! $" visually have the same effect, they must differ slight in what they actually mean.

If you run vim with the WrapRelativeMotion code removed as explained by @gonzaloserrano, d$ works as expected. If you type the key combination d:execute "normal! $" you get the problematic behavior.

I'll try and determine the difference between $ and :execute "normal! $" and fix the code.

[rekendahl]

You rock. This is REALLY annoying.

Sent from my iPhone

On Feb 4, 2014, at 5:54 PM, lukedomanski notifications@github.com wrote:

I've managed to reproduce the problem. It was not occurring for me originally because I was using YankRing (which remaps d).

The reason it is occuring is due to the use of the :execute "normal! $" command in combination with d. While $ and :execute "normal! $" visually have the same effect, they must differ slight in what they actually mean.

If you run vim with the WrapRelativeMotion code removed as explained by @gonzaloserrano, d$ works as expected. If you type the key combination d:execute "normal! $" you get the problematic behavior.

I'll try and determine the difference between $ and :execute "normal! $" and fix the code.

—
Reply to this email directly or view it on GitHub.