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

Question/Brainstorming: Recommendation for managing macros #3

Closed
matu3ba opened this issue Jul 20, 2022 · 7 comments
Closed

Question/Brainstorming: Recommendation for managing macros #3

matu3ba opened this issue Jul 20, 2022 · 7 comments

Comments

@matu3ba
Copy link

matu3ba commented Jul 20, 2022

Do you have a recommendation for storing and loading macros with lua?

  1. If I store them inside the lua file, stylua gets invalid UTF8 errors.
  2. Macros tend to be tailored to a language or project, so storing them in another repo (not with the dotfiles) sounds like a good idea.
  3. I did not find anything in lua yet.
  4. Macro debugging is horribly hard. They fail silently and may fail with or without any action. Any kind of visually highlighting that "something was changed" and "it failed" would be helpful.
  5. It would be extremely helpful, if there could be a highlighting of lines, which a macro can be applied to. Think of single and multiline code inside switches,if-else prongs, where one wants to know that each switch case/if-else works before trying.
  6. Checking for "marker symbols inside the line/section" before applying the macro and saving this info alongside the macro would be awesome. This would allow fast inspection, if the macro "would do something". Logic could be applied on top of that.

Please let me know, what you think of those ideas and how to structure them into actionable items (for investigation).

@smjonas
Copy link
Owner

smjonas commented Jul 20, 2022

Hey, thanks for checking out my plugin! Regarding your questions:

  1. If I store them inside the lua file, stylua gets invalid UTF8 errors.

Could you give an example for that? For me, it works to surround the macro in [[ ]] brackets as a string and store it as a local variable. This way, you can also store special characters such as <Esc> entered by typing <C-v><Esc>. Though, there are probably some edge cases. However, I am currently not aware of any plugin that generates macros from these strings.

  1. I did not find anything in lua yet.

Even though, it's not in Lua, did you check out https://github.com/svermeulen/vim-macrobatics? This plugin seems to contain many features regarding managing of macros.

  1. Macro debugging is horribly hard. They fail silently and may fail with or without any action. Any kind of visually highlighting that "something was changed" and "it failed" would be helpful.

That is actually a usecase of this plugin and one reason why I started creating it. Essentially, you would use the :Norm command to test out the series of commands you want to apply. While typing, you get visual feedback and modify the arguments until it does what you want. You will be able to see deletions, replacements and insertions separately, by default highlighted in different colors.

After you ran the command, you can then store the command as a macro. (Did you know about <C-f> in commandline mode?)

  1. It would be extremely helpful, if there could be a highlighting of lines, which a macro can be applied to. Think of single and multiline code inside switches,if-else prongs, where one wants to know that each switch case/if-else works before trying.

Not sure I understood you correctly here: could you clarify when a macro can and cannot be applied to some lines of code?

  1. Checking for "marker symbols inside the line/section" before applying the macro and saving this info alongside the macro would be awesome. This would allow fast inspection, if the macro "would do something". Logic could be applied on top of that.

That definitely seems useful, but seems a bit out of scope for this plugin. Maybe there is already a plugin for this though? If not that sounds like a great idea! :)

@smjonas
Copy link
Owner

smjonas commented Jul 20, 2022

A question to you, since you're already here: what do you think of changing the plugin's name to live-command.nvim instead of command-preview.nvim. Reasons:

  • sounds a bit less boring / standard
  • when I hear the word previewing in Neovim, I think of previewing buffers (like telescope pickers or floaterm)
  • previewing does not carry with it the connotation that it's "real-time" as in the word "live"

@matu3ba
Copy link
Author

matu3ba commented Jul 20, 2022

"real-time"

Real-time is to me more related with deterministic time result, but mostly due to the misnaming in the Linux Kernel.
I dont think the name is very good either, because unreal-time would be simulated time, which is what we dont really want to operate on.

"live"

Sounds good. Telescope also has live_grep, so folks kinda know what to expect and you can compare it to that.

@matu3ba
Copy link
Author

matu3ba commented Jul 20, 2022

Could you give an example for that?

Here is the upstream issue: JohnnyMorganz/StyLua#494

This plugin seems to contain many features regarding managing of macros.

Yes, the plugin is great. However, it is lacking a way to debug problems and a good way to organize the macros (tailor it via lua to projects or languages).

After you ran the command, you can then store the command as a macro.

Ah. Mhm. But what about doing vice versa? Many things are much quicker with f( to the bracket than defining lua commands, but unfortunately hard to decipher quickly (let alone organize or see if it works later on a different file).
I need to check C-f, the latest thing I did was to test + review completion plugins and the useful manual inbuilds in vim.

could you clarify when a macro can and cannot be applied to some lines of code

case 1
test123("bla");
x (cursor position)

case 2
-- test123()
x (cursor position)

Let f"vf"d be the macro (only visible characters for simplicity). This will work on case 1, but not on case 2, because there is no ". Unfortunately is there no error indication and the macro just does nothing, which is a pain in the ass, if you combine it with j as downwards movement, because the macro will stop in between and does not signal any error etc.

What usually the programmer expects is any kind of error on a failing f" movement, which could be computed from the cursor position changes (and cell content for t".

Maybe there is already a plugin for this though?

That would be indeed very nice, but there are not even any errors/error handling for applying macros, so I doubt that.
My guess is that the macro implementation is cryptic/hackish, but I need some starters to dig/search.

I really hope its not like upstream vim refuses fixing the behavior like in https://github.com/linty-org/key-menu.nvim/issues/10
vim/vim#10503

@smjonas
Copy link
Owner

smjonas commented Jul 22, 2022

This will work on case 1, but not on case 2, because there is no ".

Ah got you. Unfortunately, I am fairly certain that there is currently no way in Vim / Nvim to check whether any default motion such as f "worked" or not. That could certainly be changed by a plugin which could set vim.v.errmsg on failure for example. But until such a feature is available, there is sadly nothing that can be done by my plugin here, sorry.

But what about doing vice versa?

Sorry, not sure I can follow here. Do you mean that you want to create a command from an existing mapping?

@matu3ba
Copy link
Author

matu3ba commented Jul 22, 2022

Do you mean that you want to create a command from an existing mapping?

Assuming the first problem has been solved, one could translate the functionality to lua (including an error message) "for debugging". This sounds less error-prone to me and one could use the debug infrastructure for neovim + lua then.

@smjonas
Copy link
Owner

smjonas commented Jul 30, 2022

Closing since there is nothing actionable by my plugin currently :) Feel free to reopen if you think there are concrete things that can be improved.

@smjonas smjonas closed this as not planned Won't fix, can't repro, duplicate, stale Jul 30, 2022
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

No branches or pull requests

2 participants