aligrudi / neatvi

A small vi/ex editor for editing UTF-8 text
http://litcave.rudi.ir/
305 stars 25 forks source link

Suggestions for registers improvement #78

Open lobre opened 8 months ago

lobre commented 8 months ago

Playing with buffers/registers is super powerful. I might post some examples of workflows that it allows later for documentation.

But to be able to fully make use of them, I would suggest a few improvements that I think can make the design more powerful and elegant.

  1. Allow the user to manually set some special registers.

See: https://github.com/aligrudi/neatvi/issues/77

  1. Fix this bug about the line register:

If I have a line that only contains a single k character, when executing @;, the cursor should jump one line up as the k should be executed. Or said differently, the first character seems to be ignored because if I have kk on the line, it will just move one line up instead of two. With j, this is the opposite. Just having j will jump 2 lines directly instead of one. I am not sure I understand why.

  1. Revert back to not having the : in the @: register.

This was added because it allowed to just type @: and have the last command executed again. I still think this should be doable, but using some custom logic to just prepend : before executing @:. This is what vim and neovim do. I realize that I often do ^R: in my command prompt to reapply a last command that was slightly wrong. And if I do multiple mistakes, I end up having multiple ::: at the beginning of my command. While it still technically work, it is not pretty. And when using ^R: in a text buffer, I usually don't want the initial :. At least I can add it manually if I need it.

  1. Rename registers to make them more compliant with vi's initial design.

First, I still don't understand the usage of the . register (which is supposed to be the "last vi command" after the README). Is it what the dot command (.) uses internally to reapply the last command? If so, does it mean @. equals .?

If that is the case, I understand that having @. could semantically mean that we should execute the content of ., which contains the last vi command. This is accurate. But at the same time, this dot register, as used with @. will never be executed by the end user, as the shorter form . exists. And I don't think it will be accessed with ^R. either, or at least I don't see how someone could find a purpose for this.

Also, I proposed in another issue that the line register could be named _. To me, it resonates with vi's design of _ being the line-wise character. And I think that it is sad that we don't use this to keep coherent with the design. My guess is that you preferred @; because it was easier to type on qwerty.

So having those two points in mind, I would suggest two possible solutions to answer those problems.

Proposition A

Proposition B

I'd be glad to hear your feedback about those propositions. And sorry about the long post.

Neatvi is the cleanest modern vi implementation that does not contain a lot of fluff/bloat. So following a tight and integrated design would allow a lot of workflows without adding too many disparate features. Thanks!

aligrudi commented 8 months ago

Thanks for these comments.

Loric Brevet @.***> wrote:

  1. Fix this bug about the line register:

If I have a line that only contains a single k character, when executing @;, the cursor should jump one line up as the k should be executed. Or said differently, the first character seems to be ignored because if I have kk on the line, it will just move one line up instead of two. With j, this is the opposite. Just having j will jump 2 lines directly instead of one. I am not sure I understand why.

This is because the current line is assumed to be in line mode. See vi(1p) for more information.

  1. Revert back to not having the : in the @: register.

This was added because it allowed to just type @: and have the last command executed again. I still think this should be doable, but using some custom logic to just prepend : before executing @:. This is what vim and neovim do. I realize that I often do ^R: in my command prompt to reapply a last command that was slightly wrong. And if I do multiple mistakes, I end up having multiple ::: at the beginning of my command. While it still technically work, it is not pretty. And when using ^R: in a text buffer, I usually don't want the initial :. At least I can add it manually if I need it.

Well, it only appends a colon if it is missing. So, it cannot start with more than one colon.

  1. Rename registers to make them more compliant with vi's initial design.

First, I still don't understand the usage of the . register (which is supposed to be the "last vi command" after the README). Is it what the dot command (.) uses internally to reapply the last command? If so, does it mean @.***equals.`?

If that is the case, I understand that having @.could semantically mean that we should execute the content of.`, which contains the last vi command. This is accurate. But at the same time, this dot register, as used with @.will never be executed by the end user, as the shorter form.exists. And I don't think it will be accessed with^R.` either, or at least I don't see how someone could find a purpose for this.

It helps if one needs to put it in another register to apply it later.

Also, I proposed in another issue that the line register could be named _. To me, it resonates with vi's design of _ being the line-wise character. And I think that it is sad that we don't use this to keep coherent with the design. My guess is that you preferred @; because it was easier to type on qwerty.

Let's not mix movements and buffer names.

So having those two points in mind, I would suggest two possible solutions to answer those problems.

Proposition A

  • Have @.repeat the last macro. We don't have any way of doing that as of now (as.` will not save/reply macro executions, but it is in accordance with what nvi also does). Dot means "last thing", so @.` could mean "last macro".
  • Have @@ be an alias to @_ so that it is more convenient to type (as dd is also the deletion of the current line, aliasing d_).

@@ must repeat the last macro, according to vi(1p).

Thanks, Ali