Add mappings for other g* commands #464

memotype · 2013-10-12T19:32:00Z

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^

The text was updated successfully, but these errors were encountered:

spf13 · 2013-10-13T02:45:10Z

Great idea, Pull request?

lukedomanski · 2013-12-04T22:18:28Z

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:

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

lukedomanski · 2013-12-11T01:37:43Z

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 · 2014-01-19T20:18:54Z

Close?

memotype · 2014-01-21T17:17:33Z

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 · 2014-01-26T15:53:41Z

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 · 2014-01-26T17:21:14Z

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 · 2014-02-03T20:14:51Z

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 · 2014-02-03T20:44:21Z

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 · 2014-02-04T13:47:36Z

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 · 2014-02-04T19:20:00Z

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 · 2014-02-04T22:54:08Z

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 · 2014-02-04T23:06:01Z

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.

lukedomanski · 2014-02-05T00:25:36Z

In the mean time, here is a commit that adds the option to enable/disable wrap relative motion.

lukedomanski/spf13-vim@33091b2

…f13#464 , d$ now deletes last character of line

…spf13#464

lukedomanski · 2014-02-05T11:55:24Z

Okay guys,

Please try the changes/commits above and see how you go. Then I'll put through the Pull Request.

The reason for, and solution to, this problem is revealed in the details of :help motion and :help motion.txt

From :help motion:

Ex commands can be used to move the cursor. This can be
used to call a function that does some complicated motion.
The motion is always characterwise exclusive, no matter
what ":" command is used.

:help motion.txt or more specifically :help exclusive, gives details of what characterwise exclusive/inclusive means:

A character motion is either inclusive or exclusive. When inclusive, the
start and end position of the motion are included in the operation. When
exclusive, the last character towards the end of the buffer is not included.

form this we can infer that $ must be an inclusive motion, as d$ deletes the "end position of the motion". However, the command d:execute "normal! $" is exclusive due to the rule stated in :help motion re. Ex commands for motion.

A section further down in :help motion.txt provides a solution. :help o_v:

v - When used after an operator, [...snip...]
If the motion already was characterwise, toggle
inclusive/exclusive. This can be used to make an exclusive
motion inclusive and an inclusive motion exclusive.

So the command dv:"execute normal! $" is the one required. I have change the operator pending mappings for $ and <End> to include the v.

I had originally done the same for 0 and ^, but then realized this was not the same as the default d0 and d^.

rekendahl · 2014-02-05T18:54:16Z

Luke:

I don't understand how to test the dv:execute normal! $ fix. How do I include the v?

lukedomanski · 2014-02-05T20:17:07Z

Sorry, I left the inverted commas out of the command in the last post (now fixed).

To test, you can either:

view the new .vimrc code by clicking on the commit links above, then click "view", and copy the new .vimrc over your old one.
run with the old .vimrc, then instead of pressing d$ where you want to delete to the end of line, type exactly this key combination/sequence dv:execute "normal! $". Everything after the : will appear in the command line of vim. This is what the new code does as opposed to the current d$ mapping, whihc excludes the v.

rekendahl · 2014-02-05T20:18:56Z

I will modify my .vimrc and test. I will let you know shortly

rekendahl · 2014-02-05T20:33:26Z

Ok. I feel like an idiot but I cannot get it working trying to follow your instructions.

Additionally I cannot find the link above that includes this fix (I only see one that puts a opt-out variable in). Can you gist me the lines you have in your .vimrc and I will paste them into mine?

lukedomanski · 2014-02-05T20:42:53Z

The link is actually sitting between posts. It says:
lukedomanski referenced this issue from a commit in lukedomanski/spf13-vim 9 hours ago
lukedomanski rolled back some changes to ensure d0 and d^ match default behaviours, … … 4122da2

But direct link is below.

https://github.com/lukedomanski/spf13-vim/blob/4122da250229dc7988d4ce436875a89f5f5fb756/.vimrc

    " End/Start of line motion keys act relative to row/wrap width in the
    " presence of `:set wrap`, and relative to line for `:set nowrap`.
    " Default vim behaviour is to act relative to text line in both cases
    " If you prefer the default behaviour, add the following to your
    " .vimrc.before.local file:
    "   let g:spf13_no_wrapRelMotion = 1
    if !exists('g:spf13_no_wrapRelMotion')
        " Same for 0, home, end, etc
        function! WrapRelativeMotion(key, ...)
            let vis_sel=""
            if a:0
                let vis_sel="gv"
            endif
            if &wrap
                execute "normal!" vis_sel . "g" . a:key
            else
                execute "normal!" vis_sel . a:key
            endif
        endfunction

        " Map g* keys in Normal, Operator-pending, and Visual+select
        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>
        " Overwrite the operator pending $/<End> mappings from above
        " to force inclusive motion with :execute normal!
        onoremap $ v:call WrapRelativeMotion("$")<CR>
        onoremap <End> v:call WrapRelativeMotion("$")<CR>
        " Overwrite the Visual+select mode mappings from above
        " to ensure the correct vis_sel flag is passed to function
        vnoremap $ :<C-U>call WrapRelativeMotion("$", 1)<CR>
        vnoremap <End> :<C-U>call WrapRelativeMotion("$", 1)<CR>
        vnoremap 0 :<C-U>call WrapRelativeMotion("0", 1)<CR>
        vnoremap <Home> :<C-U>call WrapRelativeMotion("0", 1)<CR>
        vnoremap ^ :<C-U>call WrapRelativeMotion("^", 1)<CR>
    endif

lukedomanski · 2014-02-05T20:49:17Z

thanks for the help by the way....i'm getting the feeling I should have just left this one at my original bug report :)

rekendahl · 2014-02-05T20:53:04Z

I can confirm that it works on Mac and Linux for me

(I didn't realize that putting v: before that call did what you described.

I owe you a coffee!

I vote for quick merge/release to main

lukedomanski · 2014-02-05T22:07:06Z

No coffee required, as I was just fixing a problem I imposed on you in the first place :)

gonzaloserrano · 2014-02-05T22:15:52Z

👍 i just tested it and works fine, thanks

lukedomanski · 2014-02-05T22:56:30Z

"I vote for quick merge/release"
@rekendahl Done #550 Steve merge it

spf13 · 2014-02-05T23:00:27Z

Merged it already :)

lukedomanski · 2014-02-06T01:34:14Z

I meant "Steve merged it" :)

# By Johnny Robeson (4) and others # Via Steve Francia (11) and others * '3.0' of github.com:spf13/spf13-vim: (22 commits) Removed screen program mapping Screen program mapping is now opt-in This as it slows down exit from insert mode for many users Delete .gitmodules rename BASE_DIR to APP_DIR add $app_dir var to point to application root Fix neosnippet and neosnippet-snippets order to follow the instructions at Shougo/neosnippet Add Shougo/neosnippet-snippets. Fixes spf13#539. Shougo/neosnippet version 4.1 split the repository into two and the other half is now missing, see the PR for details. rolled back some changes to ensure d0 and d^ match default behaviours, spf13#464 fixed wrap relative motion mappings to address problem reported in spf13#464 , d$ now deletes last character of line added spf13 option to enable/disable wrap relative movement mappings fix spelling of occurred in debug() Fix no_conceal on youcompleteme bash requires the space in this case store the vundle uri in a variable. Correct load order of config files in readme add a switch to disable omni complete fixed formatting for readme windows install instructions Added Chocolatey install for ctags to readme for windows install modified windows install instructions in readme added instructions for windows install with Chocolatey ... Conflicts: .vimrc bootstrap.sh

…f13#464 , d$ now deletes last character of line

…spf13#464

memotype mentioned this issue Oct 13, 2013

Add other g* commands to go with gj, gk, etc. #466

Merged

lukedomanski mentioned this issue Dec 11, 2013

Changed g* wrap relative mappings to revert to standard behaviour under nowrap #513

Merged

lukedomanski added a commit to lukedomanski/spf13-vim that referenced this issue Feb 5, 2014

fixed wrap relative motion mappings to address problem reported in sp…

7b21d20

…f13#464 , d$ now deletes last character of line

lukedomanski added a commit to lukedomanski/spf13-vim that referenced this issue Feb 5, 2014

rolled back some changes to ensure d0 and d^ match default behaviours, …

4122da2

…spf13#464

lukedomanski mentioned this issue Feb 5, 2014

add control to prevent changing normal motion #541

Open

lukedomanski mentioned this issue Feb 5, 2014

Fixing d$ not deleting last character of the line after wrap relative motion code was replaced #550

Merged

spf13 closed this as completed Feb 5, 2014

francoisjacques pushed a commit to francoisjacques/spf13-vim that referenced this issue Feb 20, 2014

fixed wrap relative motion mappings to address problem reported in sp…

d1d71c5

…f13#464 , d$ now deletes last character of line

francoisjacques pushed a commit to francoisjacques/spf13-vim that referenced this issue Feb 20, 2014

rolled back some changes to ensure d0 and d^ match default behaviours, …

75bad46

…spf13#464

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add mappings for other g* commands #464

Add mappings for other g* commands #464

memotype commented Oct 12, 2013

spf13 commented Oct 13, 2013

lukedomanski commented Dec 4, 2013

lukedomanski commented Dec 11, 2013

lukedomanski commented Jan 19, 2014

memotype commented Jan 21, 2014

gonzaloserrano commented Jan 26, 2014

rekendahl commented Jan 26, 2014

lukedomanski commented Feb 3, 2014

lukedomanski commented Feb 3, 2014

gonzaloserrano commented Feb 4, 2014

lukedomanski commented Feb 4, 2014

lukedomanski commented Feb 4, 2014

rekendahl commented Feb 4, 2014

lukedomanski commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

gonzaloserrano commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

spf13 commented Feb 5, 2014

lukedomanski commented Feb 6, 2014

Add mappings for other g* commands #464

Add mappings for other g* commands #464

Comments

memotype commented Oct 12, 2013

spf13 commented Oct 13, 2013

lukedomanski commented Dec 4, 2013

lukedomanski commented Dec 11, 2013

lukedomanski commented Jan 19, 2014

memotype commented Jan 21, 2014

gonzaloserrano commented Jan 26, 2014

rekendahl commented Jan 26, 2014

lukedomanski commented Feb 3, 2014

lukedomanski commented Feb 3, 2014

gonzaloserrano commented Feb 4, 2014

lukedomanski commented Feb 4, 2014

lukedomanski commented Feb 4, 2014

rekendahl commented Feb 4, 2014

lukedomanski commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

rekendahl commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

gonzaloserrano commented Feb 5, 2014

lukedomanski commented Feb 5, 2014

spf13 commented Feb 5, 2014

lukedomanski commented Feb 6, 2014