Suggestions for registers improvement

[lobre]

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: #77

2. 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.

3. 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.

4. 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

• 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 the execution of the current line (as d_ is the deletion of the current line).
• 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_).

Proposition B

• Make the . register contain the "last inserted text" and the the "last vi command". This would change maybe how neatvi's . command works internally (as it could not directly rely on the . register anymore) but it would make @. more useful. By the way, this is what vim and neovim do.
• Make the @ register contain the last register name, so that @@ would execute the last register. This is also what vim and neovim do, even if doing ^R@ does not work (it does not return the name of the last executed register, but I think that could be useful to have it).
• Still, make @_ the execution of the current line (I understand it can be less practical to type on a qwerty keyboard, but to me, it still makes more sense conceptually. And it is not executed that often anyway). Another possibility would be to then alias this @_ to @<ret> but I am not sure that it makes a lot of sense and if this is technically doable.

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]

Thanks for these comments. Loric Brevet ***@***.***> wrote:

2. 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.

3. 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.

4. 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