patch to allow locking/unlocking the jump list

[Carlo Baldassi]

Hi,

First, my use case: I'd like to be able to invoke functions or commands (particularly some which I didn't write, e.g. from other people plug-ins/scripts) and not have them update the jump list. The "keepjumps" command is not sufficient in this regard, because it does not act recursively.

For example, I have some code[1] which uses the matchit.vim plugin, which:
1) doesn't use keepjumps internally (this may be seen as a plugin bug, and I sent a patch[2] to the author to do that).
2) calls m' on the starting position before jumping to its destination[3]. This is not a bug and it's currently unavoidable.

My code calls "normal %" in the middle of some processing, and this inevitably pollutes the jump list, so that using CTRL-O jumps to irrelevant places in the file. Also, my code in turn sets jumps, and people might want to use it without that being the case. You get the idea.

I know I should have tried not to introduce new options ;) but it seems to me that having an option to lock the jump list (and restoring it afterwards) is the simplest way to introduce a mechanism to avoid that behaviour. I mean not only simple to implement, but also to document, understand, and maintain. My patch adds such an option, called 'lockjumps' or 'lkj'. It's a window option since the jumplist is also associated to the window.

I tested it and it works as intended, and valgrind passes. When I removed the `FEAT_JUMPLIST` setting in features.h, it compiled and worked fine; two tests failed (test49 and test_command_count) but this is unrelated to the patch since they failed anyway with that setting disabled.

The patch is against the latest code downloaded today with mercurial (ca3db36a6ed8).

I followed the instructions in option.c, but I never worked on the vim source code before so please let me know if I should do something more, or if I overlooked something etc.

Carlo

[1] example: https://github.com/JuliaLang/julia-vim/blob/9bb84c2f3586c8d6f1263254ae21bb16a66abb4a/autoload/julia_blocks.vim#L319
[2] https://github.com/benjifisher/matchit.zip/pull/2
[3] example: https://github.com/benjifisher/matchit.zip/blob/73f7f7051eca95ed90537f931e9a4559fb3a494b/plugin/matchit.vim#L277

[Justin M. Keyes]

On Fri, May 22, 2015 at 7:42 PM, Carlo Baldassi <carlob...@gmail.com> wrote:
> For example, I have some code[1] which uses the matchit.vim plugin, which:
> 1) doesn't use keepjumps internally (this may be seen as a plugin bug, and I sent a patch[2] to the author to do that).
> 2) calls m' on the starting position before jumping to its destination[3]. This is not a bug and it's currently unavoidable.
>
> My code calls "normal %" in the middle of some processing, and this inevitably pollutes the jump list, so that using CTRL-O jumps to irrelevant places in the file. Also, my code in turn sets jumps, and people might want to use it without that being the case. You get the idea.

I have wanted this too, in particular the surround.vim plugin adds
unwanted jumps.

But why can't keepjumps be made recursive instead?

> I know I should have tried not to introduce new options ;) but it seems to me that having an option to lock the jump list (and restoring it afterwards) is the simplest way

These one-off commands ("keepjumps", "lockjumps", etc, etc) are
extremely disappointing to me. Why can't there be, instead, a general
mechanism to save/restore these lists? Similar to
winsaveview()/winrestview(), except, you know--not a band-aid
solution. A *general* solution.


Justin M. Keyes

[Carlo Baldassi]

On Saturday, May 23, 2015 at 10:52:16 PM UTC+2, Justin M. Keyes wrote:
> But why can't keepjumps be made recursive instead?

That's the first thing I thought too. Of course it would break existing code, so it should be something else, perhaps keepjumps!. But it also seemed a more complicated and less flexible model to me: does it apply to exec'd code, mappings etc.? Well, essentially if the answer to all questions is no you'd almost have what I have here. One trickier point is what to do if the code changes window.
The option route seemed the most straightforward to me; I can have a look at a different implementation (but again, my knowledge of vim source code is extremely poor).

> These one-off commands ("keepjumps", "lockjumps", etc, etc) are
> extremely disappointing to me. Why can't there be, instead, a general
> mechanism to save/restore these lists? Similar to
> winsaveview()/winrestview(), except, you know--not a band-aid
> solution. A *general* solution.

I'm open to suggestions, but I don't see what you have in mind exactly. Care to elaborate?

[Carlo Baldassi]

Ok, here is my attempt at a recursive version of the keepjumps command.
It's called lockjumps, and works in the same way as keepjumps except that:
1) it's recursive
2) it only locks the jumplist, it does not affect the marks list

Again, it seems to work as intended, "make test" passes and valgrind too.

The reason for not touching the marks is that:
1) I think it is actually fairly common for functions/plugins/etc to use marks in jumping around, e.g. calling "normal ``" to get back after a jump, or having a mapping which does things like "ggdd``". It is much more uncommon to use CTRL-O in a script I think.
2) The marks can be set explicitly by the user and are much easier to control from user code (e.g. it is trivial to write a save_marks()/restore_marks() pair if needed).

All things considered, I prefer this version to the previous one with the option. (I just hope it's correct!)

[Justin M. Keyes]

On Mon, May 25, 2015 at 3:44 PM, Carlo Baldassi <carlob...@gmail.com> wrote:
> On Saturday, May 23, 2015 at 10:52:16 PM UTC+2, Justin M. Keyes wrote:
>> But why can't keepjumps be made recursive instead?
>
> That's the first thing I thought too. Of course it would break existing code, so it should be something else, perhaps keepjumps!. But it also seemed a more complicated and

:keepjumps! is definitely more palatable IMO from a user-interface perspective.

>> These one-off commands ("keepjumps", "lockjumps", etc, etc) are
>> extremely disappointing to me. Why can't there be, instead, a general
>> mechanism to save/restore these lists? Similar to
>> winsaveview()/winrestview(), except, you know--not a band-aid
>> solution. A *general* solution.
>
> I'm open to suggestions, but I don't see what you have in mind exactly. Care to elaborate?

I'm thinking of something like the histadd()/histget() family of
functions, but more generic: expose the jumplist, marks list,
changelist, yanks list, etc., as Lists. So for example, in the
use-case of your patch, instead of locking the list, just save it and
restore it:

let j = v:jumplist
normal %
let v:jumplist = j

Anyways, it's not fair to expect you to solve this, it's a
far-reaching design decision in Vim. I think :keepjumps! is a good
compromise.


Justin M. Keyes

[Justin M. Keyes]

On Mon, May 25, 2015 at 5:58 PM, Carlo Baldassi <carlob...@gmail.com> wrote:
> Ok, here is my attempt at a recursive version of the keepjumps command.
> It's called lockjumps, and works in the same way as keepjumps except that:
> 1) it's recursive
> 2) it only locks the jumplist, it does not affect the marks list
>
> Again, it seems to work as intended, "make test" passes and valgrind too.
>
> The reason for not touching the marks is that:
> 1) I think it is actually fairly common for functions/plugins/etc to use marks in jumping around, e.g. calling "normal ``" to get back after a jump, or having a mapping which does things like "ggdd``". It is much more uncommon to use CTRL-O in a script I think.
> 2) The marks can be set explicitly by the user and are much easier to control from user code (e.g. it is trivial to write a save_marks()/restore_marks() pair if needed).

In my case at least, allowing the marks to be modified defeats the
purpose. And the inconsistency between :keepjumps (keeps '. '^
jumplist and changelist) and :lockjumps (keeps only jumplist...?)
would be unpleasant.

In your implementation, you could save the './'^/jumplist/changelist
and then restore it after the script ends. This would allow plugins to
use marks et. al. as needed but the user can use :keepjumps! to
prevent side effects from the plugin.

Justin M. Keyes

[Carlo Baldassi]

On Tuesday, May 26, 2015 at 3:50:06 AM UTC+2, Justin M. Keyes wrote:
> In your implementation, you could save the './'^/jumplist/changelist
> and then restore it after the script ends. This would allow plugins to
> use marks et. al. as needed but the user can use :keepjumps! to
> prevent side effects from the plugin.

Ok, I did this, see the attached patch.
Everything seems to work great (and all tests pass etc), and I am quite pleased with the result.
However, this is now a considerably larger patch, and I really need some feedback on both the implementation and the interface.

Reagrding the implementation:

The way it works is that there are duplicated entries for all items which need to be restored at the end of the execution, and more precisely:
1) for buffers: last_cursor, last_insert, last_change, changelist, changelistlen
2) for windows: pcmark, prev_pcmark, jumplist, jumplistsen, changelistidx
There are also additional entries in the structs, to keep track if we're actively keeping a backup of those.

Then, within functions `mark_adjust`, `mark_col_adjust` and `cleanup_jumplist`, the backup entries are updated (if the backup tag is active).
This ensures that, if the code called by keepjumps! is making changes, those are reflected in the jumplist/changelist/etc when those are restored at the end.

I thought about alternative ways to achieve the same effect but I can't see any simpler way to keep that guarantee (which is essential in my opinion).
This is the major point on which I'd like to have feedback. Is this ok? Did I miss something? Will this get merged (possibly after some polishing, of course)?

Regarding the interface:

As discussed, I used :keepjumps! for the recursive version.
This has forced me to make some changes to the parser, to account for the possibility of the trailing bang in the command.
I don't particularly like those changes.
First, they are very slightly breaking, in that before, ":keepjumps! command" was parsed as "keepjumps" followed by "!command". I don't think this is important (note: all other commands still parse the same).
Second, ":keepjumps" and ":keepjumps!" behave in a slightly different way in some cases, besides the fact that :keepjumps! is recursive. Consider this example:

:keepjumps normal ggdd``
:keepjumps! normal ggdd``

In the first case, the ' mark is not set by the gg jump, and therefore the cursor is brought back to the *previous* location of the ' mark, if any.
In the second case, the ' mark is set by the gg jump, the cursor is brought back to the location from where the command was invoked, and the previous ' mark is restored afterwards (if it existed at all).

I have a proposal: instead of introducing keepjumps!, just redefine :keepjumps to act recursively.
This is slightly breaking for 2 reasons: 1) examples such as the one above, 2) cases in which :keepjumps would have been a no-op.
I don't know what's the vim policy about these kind of slightly breaking changes, but I think that the recursive version is what one would want most of the time.
I also doubt that anyone would be relying on such behaviours as the ones which would be broken by the change.


Carlo Baldassi

[Justin M. Keyes]

On May 27, 2015 2:28 AM, "Carlo Baldassi" <carlob...@gmail.com> wrote:
>
> On Tuesday, May 26, 2015 at 3:50:06 AM UTC+2, Justin M. Keyes wrote:
> > In your implementation, you could save the './'^/jumplist/changelist
> > and then restore it after the script ends. This would allow plugins to
> > use marks et. al. as needed but the user can use :keepjumps! to
> > prevent side effects from the plugin.
>
> Ok, I did this, see the attached patch.
> Everything seems to work great (and all tests pass etc), and I am quite pleased with the result.
> However, this is now a considerably larger patch, and I really need some feedback on both the implementation and the interface.
>
> Reagrding the implementation:
>
> The way it works is that there are duplicated entries for all items which need to be restored at the end of the execution, and more precisely:
> 1) for buffers: last_cursor, last_insert, last_change, changelist, changelistlen
> 2) for windows: pcmark, prev_pcmark, jumplist, jumplistsen, changelistidx
> There are also additional entries in the structs, to keep track if we're actively keeping a backup of those.
>
> Then, within functions `mark_adjust`, `mark_col_adjust` and `cleanup_jumplist`, the backup entries are updated (if the backup tag is active).
> This ensures that, if the code called by keepjumps! is making changes, those are reflected in the jumplist/changelist/etc when those are restored at the end.
>
> I thought about alternative ways to achieve the same effect but I can't see any simpler way to keep that guarantee (which is essential in my opinion).
> This is the major point on which I'd like to have feedback. Is this ok? Did I miss something? Will this get merged (possibly after some polishing, of course)?

:/

> Regarding the interface:
>
> As discussed, I used :keepjumps! for the recursive version.
> This has forced me to make some changes to the parser, to account for the possibility of the trailing bang in the command.

ea->forceit should already indicate presence of bang.

> I don't particularly like those changes.
> First, they are very slightly breaking, in that before, ":keepjumps! command" was parsed as "keepjumps" followed by "!command". I don't think this is important (note: all other commands still parse the same).
> Second, ":keepjumps" and ":keepjumps!" behave in a slightly different way in some cases, besides the fact that :keepjumps! is recursive. Consider this example:
>
>   :keepjumps normal ggdd``
>   :keepjumps! normal ggdd``
>
> In the first case, the ' mark is not set by the gg jump, and therefore the cursor is brought back to the *previous* location of the ' mark, if any.
> In the second case, the ' mark is set by the gg jump, the cursor is brought back to the location from where the command was invoked, and the previous ' mark is restored afterwards (if it existed at all).
>
> I have a proposal: instead of introducing keepjumps!, just redefine :keepjumps to act recursively.
> This is slightly breaking for 2 reasons: 1) examples such as the one above, 2) cases in which :keepjumps would have been a no-op.
> I don't know what's the vim policy about these kind of slightly breaking changes, but I think that the recursive version is what one would want most of the time.
> I also doubt that anyone would be relying on such behaviours as the ones which would be broken by the change.

Many plugins use keepjumps, would need to analyze those cases.

Justin M. Keyes

[Carlo Baldassi]

On Wednesday, May 27, 2015 at 8:00:30 PM UTC+2, Justin M. Keyes wrote:

> > I thought about alternative ways to achieve the same effect but I can't see any simpler way to keep that guarantee (which is essential in my opinion).
>
> > This is the major point on which I'd like to have feedback. Is this ok? Did I miss something? Will this get merged (possibly after some polishing, of course)?
>
> :/

Sorry, I don't know how to interpret this.

>
> > Regarding the interface:
>
> >
>
> > As discussed, I used :keepjumps! for the recursive version.
>
> > This has forced me to make some changes to the parser, to account for the possibility of the trailing bang in the command.
>
> ea->forceit should already indicate presence of bang.

I should certainly use that instead of the ugly "TRUER" return value I have come up with, but as far as I can tell in the current code that field is not used for command modifiers, which are parsed with "checkforcmd" and are only expected to consist of "isalpha" characters. That's why I had to change "checkforcmd".

> > I also doubt that anyone would be relying on such behaviours as the ones which would be broken by the change.
>
> Many plugins use keepjumps, would need to analyze those cases.

Sure, that would need to be done. I may try to have a look at that at some point (e.g. by looking at the code found in vimscripts and/or in popular github repos - vimawesome.com has a list which would help there). This is a secondary aspect anyway; agreeing upon the internal implementation is what matters the most at this stage.


Carlo

[Bram Moolenaar]

Carlo Baldassi wrote:

> Ok, here is my attempt at a recursive version of the keepjumps command.
> It's called lockjumps, and works in the same way as keepjumps except that:
> 1) it's recursive
> 2) it only locks the jumplist, it does not affect the marks list
>
> Again, it seems to work as intended, "make test" passes and valgrind too.
>
> The reason for not touching the marks is that:
> 1) I think it is actually fairly common for functions/plugins/etc to
> use marks in jumping around, e.g. calling "normal ``" to get back
> after a jump, or having a mapping which does things like "ggdd``". It
> is much more uncommon to use CTRL-O in a script I think.
> 2) The marks can be set explicitly by the user and are much easier to
> control from user code (e.g. it is trivial to write a
> save_marks()/restore_marks() pair if needed).
>
> All things considered, I prefer this version to the previous one with
> the option. (I just hope it's correct!)

Makes sense. I didn't like the solution with an option.

I don't like using ":keepjumps!", adding an exclamation mark to a
command modifier is weird, I don't think this exists yet. We only have
the exclamation mark on commands.

Any comments from plugin writers?

--
From "know your smileys":
:-H Is missing teeth

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Ben Fritz]

On Sunday, June 7, 2015 at 8:57:38 AM UTC-5, Bram Moolenaar wrote:
> Carlo Baldassi wrote:
>
> > Ok, here is my attempt at a recursive version of the keepjumps command.
> > It's called lockjumps, and works in the same way as keepjumps except that:
> > 1) it's recursive
> > 2) it only locks the jumplist, it does not affect the marks list
> >
> > Again, it seems to work as intended, "make test" passes and valgrind too.
> >
> > The reason for not touching the marks is that:
> > 1) I think it is actually fairly common for functions/plugins/etc to
> > use marks in jumping around, e.g. calling "normal ``" to get back
> > after a jump, or having a mapping which does things like "ggdd``". It
> > is much more uncommon to use CTRL-O in a script I think.
> > 2) The marks can be set explicitly by the user and are much easier to
> > control from user code (e.g. it is trivial to write a
> > save_marks()/restore_marks() pair if needed).
> >
> > All things considered, I prefer this version to the previous one with
> > the option. (I just hope it's correct!)
>
> Makes sense. I didn't like the solution with an option.
>
> I don't like using ":keepjumps!", adding an exclamation mark to a
> command modifier is weird, I don't think this exists yet. We only have
> the exclamation mark on commands.
>
> Any comments from plugin writers?
>

Justin mentioned that he needed a solution that also keeps marks.

I guess it may be possible to use getpos/setpos to save/restore specific mark positions, but I'm not 100% sure this patch plus that method would meet his needs.

[Bram Moolenaar]

It might be better to "lock" marks separately. In case someone wants to
lock the jumplist but set a mark. If we always keep marks that would
not be possible. I'm not sure if we should re-use :keepmarks. Perhaps
it's better to have :lockmarks to be paired with lockjumps.

:lockmarks lockjumps call MyJumpingFunction()

--
From "know your smileys":

...---... SOS

[Carlo Baldassi]

Yes, I had that thought as well. However, as also clearly stated in the documentation of lockmarks, the major drawbacks of this model are 1) not adjusting for line insertions / deletions 2) the possibility of making the command you're calling non-functional, it that command uses marks to jump around internally (and even if it uses the jumplist, although I think that's much less common.)

The third patch I submitted after Justin's comments (the one which introduces "keepjumps!" - but the name can be easily changed! - file name "lkjbang_patch.txt") actually solves all this, quite nicely in my opinion. All operations inside keepjumps! work normally, and the state at the end is restored as best as possible keeping track of insertions/deletions. Of course, it comes at a slight cost in complexity/memory/speed. I could not observe any noticeable difference in practice though. To me, its worst issue is some code duplication, but it's not terrible.

So that's actually my favourite choice at the moment (as I mentioned, I'd even use that in place of the current "keepjumps"), and if the costs are considered acceptable, I'd gladly polish that/rename/apply all required changes.

(Otherwise, I'm still reasonably happy with the simpler "lockjumps" version - please let me know if there's anything I should do about that as well.)

[Charles Campbell]

Carlo Baldassi wrote:
> Yes, I had that thought as well. However, as also clearly stated in the documentation of lockmarks, the major drawbacks of this model are 1) not adjusting for line insertions / deletions 2) the possibility of making the command you're calling non-functional, it that command uses marks to jump around internally (and even if it uses the jumplist, although I think that's much less common.)
>
> The third patch I submitted after Justin's comments (the one which introduces "keepjumps!" - but the name can be easily changed! - file name "lkjbang_patch.txt") actually solves all this, quite nicely in my opinion. All operations inside keepjumps! work normally, and the state at the end is restored as best as possible keeping track of insertions/deletions. Of course, it comes at a slight cost in complexity/memory/speed. I could not observe any noticeable difference in practice though. To me, its worst issue is some code duplication, but it's not terrible.
>
> So that's actually my favourite choice at the moment (as I mentioned, I'd even use that in place of the current "keepjumps"), and if the costs are considered acceptable, I'd gladly polish that/rename/apply all required changes.
>
> (Otherwise, I'm still reasonably happy with the simpler "lockjumps" version - please let me know if there's anything I should do about that as well.)
>

Hello!

I'm wondering about how the patch(es) work -- is it a save&restore or is
it a prevent-any-modification? I'm in favor of save&restore;
prevent-any-modification is certainly going to cause problems.

Regards,
Chip Campbell

[Carlo Baldassi]

> Hello!
>
> I'm wondering about how the patch(es) work -- is it a save&restore or is
> it a prevent-any-modification? I'm in favor of save&restore;
> prevent-any-modification is certainly going to cause problems.
>

Hi!

The "lockjumps" patch (filename: "lkjcmd_patch.txt") does a "prevent-any-modification to the jumplist". It works as the current keepjumps, except 1) it's recursive 2) it doesn't lock marks. So it will only cause problems with scripts which try to use the jumplist, e.g. by trying to run `exe "normal \<c-o>"`. The lock is only for adding entries in the jumplist; the jumplist is still updated in case of insertions/deletions. (However, this will no longer be true if used in conjunction with lockmarks, obviously.)

The "keepjumps!" patch (filename: "lkjbang_patch.txt") does a "save-and-restore". It acts on the same marks as the current "keepjumps" implementation, plus the jumplist. It should not cause any problems to running code, and keeps track of insertions/deletions in the backed-up list, so that when it's restored everything should still make sense. Of course, saving and restoring and keeping track of changes requires more internal work than just locking up everything.

Carlo Baldassi

[Charles Campbell]

Carlo Baldassi wrote:
>> Hello!
>>
>> I'm wondering about how the patch(es) work -- is it a save&restore or is
>> it a prevent-any-modification? I'm in favor of save&restore;
>> prevent-any-modification is certainly going to cause problems.
>>
> Hi!
>
> The "lockjumps" patch (filename: "lkjcmd_patch.txt") does a "prevent-any-modification to the jumplist". It works as the current keepjumps, except 1) it's recursive 2) it doesn't lock marks. So it will only cause problems with scripts which try to use the jumplist, e.g. by trying to run `exe "normal \<c-o>"`. The lock is only for adding entries in the jumplist; the jumplist is still updated in case of insertions/deletions. (However, this will no longer be true if used in conjunction with lockmarks, obviously.)

Which includes netrw and its netrw#BrowseX() function (ie. hit x with the cursor atop a special filename such as abc.pdf or use gx outside of netrw buffers).

>
> The "keepjumps!" patch (filename: "lkjbang_patch.txt") does a "save-and-restore". It acts on the same marks as the current "keepjumps" implementation, plus the jumplist. It should not cause any problems to running code, and keeps track of insertions/deletions in the backed-up list, so that when it's restored everything should still make sense. Of course, saving and restoring and keeping track of changes requires more internal work than just locking up everything.
>

Regards,
Chip Campbell

[Carlo Baldassi]

I just realized that the "keepjumps!" patch I sent is not working correctly under some circumstances.

A single backup list is not sufficient, it really needs to keep a stack of them in order to work properly.

I'll make a new patch in a short while (unless I'm told it has zero chance of getting in...)

Sorry for the annoyance.

best

Carlo Baldassi

--
--
You received this message from the "vim_dev" 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 a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/IOrR9_ZF6Jo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bram Moolenaar]

Carlo Baldassi wrote:

> I just realized that the "keepjumps!" patch I sent is not working correctly
> under some circumstances.
> A single backup list is not sufficient, it really needs to keep a stack of
> them in order to work properly.
> I'll make a new patch in a short while (unless I'm told it has zero chance
> of getting in...)
> Sorry for the annoyance.

Looking at this again, I wonder what the problem is that we are solving.

In general, it appears we want to prevent new jumps being added to the
jumplist. Thus commands (and called functions) can move around without
changing what CTRL-O jumps to.

A save and restore using a local variable won't work, because when lines
are inserted or deleted we do want the existing jumps to end up at the
correct line. We need to somehow update the marks inside the saved
list, which requires it to be internal to Vim.

Another problem is when a function or script terminates early because of
an error. If there would be a lock and unlock then the unlock doesn't
happen and the user is stuck with a locked jumplist.

What was also mentioned, is a bunch of nested functions is used,
somehwere further down the code might depend on a mark or jumplist entry
to work, E.g. by jumping to some line and then using CTRL-O to jump
back. Thus locking possibly breaks code that isn't aware of jumps being
locked.

What appears to be the best solution:
- Do not lock the jumplist but restore it.
- Make it work recursively, thus every save results in another copy to
be created.
- Do update for inserted/deleted lines in the jumplist that is restored.

In case a restore command is missed, we could have the list of saved
jumplists grow. To prevent that a command modifier is better, then we
can always restore when the command finishes, even when it fails.

The idea mentioned to use ":keepjumps!", I think that would be OK.

This is not so easy to implement, but it's possible.

--
Marriage isn't a word. It's a sentence.