Respect the :push-jump passed by user, integrate better with third party jumplist implementations

[CloseToZero]

trafficstars

[CloseToZero]

This pull request fixes two things:

1. evil-easymotion will still push a jump point even if a user passes nil for both :push-jump and :scope, I think most users would expect that evil-easymotion won't push a jump point since we pass nil for :push-jump explicitly.
2. evil-easymotion push a jump point by evil--jumps-push, this seems to make it difficult for third-party jumplist implementations like better-jumper to integrate with evil-mode.

[CloseToZero]

I'm not sure about whether the second commit is appropriate, but it seems to work pretty well with both built-in evil-jumps and third-party better-jumper.

Internally, evil-mode also use evil-set-jump to set a jump point for those commands that have non-nil :jump property (e.g. (evil-get-command-property command :jump) returns non-nil).

[artenator]

First, I want to say I'm not affiliated with this project; I found your PR because I was trying to figure out why my evil-easymotion + better-jumper setup was not behaving as expected.

I was trying to debug why my jumplist wasn't being pushed to when invoking evilem-motion-previous-line and evilem-motion-next-line. It seemed like it should be the correct behavior to push to the jump list with these motions, because they are un:scoped.

I quickly added these changes to my local setup, and now it seems to be working as expected! However, I haven't done any extensive testing -- only a quick test.

Looking forward to this PR getting merged.

[PythonNut]

Hi everyone, I'll take a look at this sometime soon.

[PythonNut]

Hey, so I took a look at this. It's definitely clear that evil-set-jump is the correct thing to use. However, to fix the argument passing I think there is a cleaner solution, which looks like (&key ... scope ... (push-jump (not scope)) ...) and then the pushing line is just ,(when push-jump '(evil-set-jump)). Of course, this needs to be done everywhere where we take :push-jump, which is making this verbatim passing of args through the wrappers look increasingly goofy, but that's a problem for another time.

[CloseToZero]

Hey, so I took a look at this. It's definitely clear that evil-set-jump is the correct thing to use. However, to fix the argument passing I think there is a cleaner solution, which looks like (&key ... scope ... (push-jump (not scope)) ...) and then the pushing line is just ,(when push-jump '(evil-set-jump)). Of course, this needs to be done everywhere where we take :push-jump, which is making this verbatim passing of args through the wrappers look increasingly goofy, but that's a problem for another time.

Yes, it's redundant and error-prone to pass :push-jump in a special way. I still do in this way for two reasons:

1. backward compatibility, if the default value of :push-jump is nil, then we don't need special handling.
2. fewer code changes, since the number of wrappers is not that much.

Before I take your suggestion, I have a question about (&key ... scope ... (push-jump (not scope)) ...), do you mean to change every wrappers in this way (or just evilem-make-motion)? If so, then we don't have a central point to control the default value.

[PythonNut]

Apologies for the delay,

1. I think it's okay if we break backwards compatibility here, since this behavior wasn't described in the docs.
2. Don't you need to change the same number of wrappers, since you'd want the push-jump-supplied? flag to propagate through the wrappers?
3. Yes I think every wrapper should be changed, this will duplicate the default value for now, but every function has identical &key signature so it should be easy to keep them in sync. Anyway in the future I may redo these wrappers to remove the duplication.

[CloseToZero]

The solution you suggest is done.

1. I think it's okay if we break backwards compatibility here, since this behavior wasn't described in the docs.

Sorry, I did not describe my intention well. I mean if the default value of :push-jump is nil (instead of (not scope)), then we don't need to pass :push-jump in a special way, just ... &key ... push-jump ... is enough, and there won't have repeated push-jump-supplied? (or (not scope)).

[PythonNut]

Sorry, is there a reason you closed this?

[CloseToZero]

No, I just think it takes too long to merge this request. I guess you may have some considerations on your side. It seems that's not the case. I will reopen this request.