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

Limit f/F/t/T scope to current line for macros and :normal #14

Open
ggandor opened this issue Jun 26, 2021 · 4 comments
Open

Limit f/F/t/T scope to current line for macros and :normal #14

ggandor opened this issue Jun 26, 2021 · 4 comments
Labels
API brainstorming Open-ended discussion about multiple viable approaches enhancement New feature or request help wanted Extra attention is needed

Comments

@ggandor
Copy link
Owner

ggandor commented Jun 26, 2021

This should definitely be an option at least, even for 2-character search maybe. I wonder what would be the best solution interface-wise. Should we add an opts flag, something like limit_scope_to_current_line_for_macros? Or a prefix key that switches off multiline search on demand? Any ideas/preferences?

Also, is there any hack out there that makes it possible to detect whether we are currently executing a normal command, and not actually typing it live (like we can check macro playback with reg_executing)?

@ggandor ggandor added enhancement New feature or request question Further information is requested labels Jun 26, 2021
@ggandor ggandor added brainstorming Open-ended discussion about multiple viable approaches and removed question Further information is requested labels Jun 26, 2021
@B4rc1
Copy link

B4rc1 commented Jun 26, 2021

So let me get this straight, you want to limit the scope (if enabled) of f/F/t/T only when recording macros?
Because if so, that sounds very inconsistent. Some keys working differently sometimes. To me that just sounds confusing and something I would neither expect nor want.

A global switch to limit it to the current line all the time tho sounds like something I'd use. So just the cool highlighting of letters, although I would ideally prefer a separate plugin for that in order to provide minimalism and modularity.

@rktjmp
Copy link
Contributor

rktjmp commented Jun 27, 2021

I would pref an option over a prefix. I find prefixes a bit awkward because they're another key combo to remember and maybe avoid conflicts.

I also generally want my macros to be pessimistic, they can easily over step their intentions.

Fantastic plugin. Really top tier.

@B4rc1
Copy link

B4rc1 commented Jun 27, 2021

I would pref an option over a prefix.

Yeah, me too.

I also generally want my macros to be pessimistic, they can easily over step their intentions.

What do you mean?

Fantastic plugin. Really top tier.

What do you mean?

@ggandor
Copy link
Owner Author

ggandor commented Aug 29, 2021

Obviously, the cleanest solution is exposing a limit_ft_scope_to_current_line option (that would take effect unconditionally). I also agree with @B4rc1 that keys behaving differently in different contexts is confusing, and might not be desirable even as an option.

But I'm still curious, having the aforementioned option exposed, if one would like to have this feature, how could we trigger it only for macro recording/execution? (And the same question goes for :normal.) (This new PR probably addresses the "recording" part for macros.)

If we'd have a workaround that we can put into the readme or the wiki, I would add this option right now... But otherwise, a different API might make that much easier, so I'm a bit hesitant to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API brainstorming Open-ended discussion about multiple viable approaches enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants