complex-repeat Behavior Changed Recently

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
JB
Reply | Threaded
Open this post in threaded view
|

complex-repeat Behavior Changed Recently

JB
Hi Vim,
Typing 'qa0xxj' and executing macro 'a' used to go to the beginning of the line, delete the first two chars, then jump down one line. Now, the cursor goes to the beginning of the line and execution of the macro stops -- no deletions or jumping down one line. The same when using '^' or '$'. Leaving out the movement to the beginning or end of the line results in the expected behavior: the macro is executed completely. What gives?


Sent with ProtonMail Secure Email.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/o29IU9TNEg9imqCcV1JdApUiqhFIkytIM93eTf-nCfhS2aRJEskv65hg1qCOYVBMzWHey54GDYO1j3rQHsGKvImv9UQlo1ukCcpIzF5W7qI%3D%40protonmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: complex-repeat Behavior Changed Recently

Tim Chase
On 2020-12-22 19:43, 'JB' via vim_use wrote:
> Typing 'qa0xxj' and executing macro 'a' used to go to the beginning
> of the line, delete the first two chars, then jump down one line.
> Now, the cursor goes to the beginning of the line and execution of
> the macro stops -- no deletions or jumping down one line. The same
> when using '^' or '$'. Leaving out the movement to the beginning or
> end of the line results in the expected behavior: the macro is
> executed completely. What gives?

A few things occur to me:

1) are you doing this in a stock vim?  Or do you have some
plugin/mapping that might be interfering?  I just tried it here and
it worked fine.  Can you replicate within

   $ vim -u NONE

2) are you doing it on a blank line where the first "x" would fail,
stopping the rest of the macro's execution?

3) (kinda part of #1) do you happen to have some strange mapping for
"0x" that would interfere with the playback? If you manually type

    0xx

  does it work for you outside a macro?

4) you are executing this in Normal mode, not some other mode, right?

-tim


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201225074357.75fa192a%40bigbox.attlocal.net.
JB
Reply | Threaded
Open this post in threaded view
|

Re: complex-repeat Behavior Changed Recently

JB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, December 25th, 2020 at 5:43 AM, Tim Chase <[hidden email]> wrote:

> On 2020-12-22 19:43, 'JB' via vim_use wrote:
>
> > Typing 'qa0xxj' and executing macro 'a' used to go to the beginning
> >
> > of the line, delete the first two chars, then jump down one line.
> >
> > Now, the cursor goes to the beginning of the line and execution of
> >
> > the macro stops -- no deletions or jumping down one line. The same
> >
> > when using '^' or '$'. Leaving out the movement to the beginning or
> >
> > end of the line results in the expected behavior: the macro is
> >
> > executed completely. What gives?
>
> A few things occur to me:
>
> 1.  are you doing this in a stock vim? Or do you have some
>
>     plugin/mapping that might be interfering? I just tried it here and
>
>     it worked fine. Can you replicate within
>
>     $ vim -u NONE
> 2.  are you doing it on a blank line where the first "x" would fail,
>
>     stopping the rest of the macro's execution?
> 3.  (kinda part of #1) do you happen to have some strange mapping for
>
>     "0x" that would interfere with the playback? If you manually type
>
>     0xx
>
>     does it work for you outside a macro?
> 4.  you are executing this in Normal mode, not some other mode, right?
>
>     -tim
>
>     --

Hi Tim,

I've solved this already, but you were on the right track. The offending lines
in my .vimrc were:

nn 0 ^          | " goto first non-blank char in line
nn ^ 0          | " goto start of line

Replacing the <Tab><Tab> characters preceding the pipes with spaces fixed it.
Executing the Normal command outside of a macro worked fine, but inside a macro failed.
My original mapping used to work, but recently broke.

Solved it by typing ':nn', which listed my Normal noremap-s and showed the <Tab> chars.

Thanks for helping.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/gv79idOZmE3gVf8f3MR8TLSZEHCh8wlxvWxHBCl72hWflWj4WrclOKMOQXyaEO9HltuvJQQdRPqkIaESF3VlqIl2pgfPMoZ5fIgnlCEKDac%3D%40protonmail.com.