Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply motion API refinement #6061

Closed
wants to merge 9 commits into from
Closed

Conversation

gibbz00
Copy link
Contributor

@gibbz00 gibbz00 commented Feb 20, 2023

Summary:

last_motion is now a private field and can only be set by calling editor.apply_motion(). Removing the need (and possibility of forgetting) to write the following every time a motion is to be applied and saved:

motion(editor); 
editor.last_motion = motion

Now it's just: editor.apply_motion(motion)

New behavior that fell out from this is that repetitions of t,T,f,F motions are stored in the context extension/move and count. (Not defaulting to extend by 1 count). So 3f -> repeat_last_motion becomes 3f and not 1f. I'm not sure the old behavior was intentional, as I saw no discussion of it when introduced in #891.

Builds upon: #6056

API encourages users to not forget setting `editor.last_motion` when
applying a motion. But also not setting `last_motion` without applying a
motion first.
method name makes it sound like it would be returning a boolean.
Feature that falls out from this is that repetitions of t,T,f,F are
saved with the context extention/move and count. (Not defaulting to extend
by 1 count).
last_motion is now a private field and can only be set by calling
Editor.apply_motion(). Removing need (and possibility) of writing:

`motion(editor); editor.last_motion = motion`

Now it's just: `editor.apply_motion(motion)`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant