This breaks the feature added in #1691 (changes the semantics of the minus sign), right?

🤦‍♂️
Yep, it break it.

From normal ruler point of view it maybe makes sense, although it's kind of static respective counted from a fixed position.
In relation with relativeruler being set it doesn't make that much sense any longer.

If you are suggesting to make the goto behavior dependent on the relativeruler setting, I'm not sure it's a good idea. Let's not introduce complex rules unnecessarily.

BTW, the current goto behavior is documented in help commands.

I don't need either of these features myself, so it don't know what makes sense and what doesn't. But apparently both features have their users. (I guess it's vim users that are used to "relative goto", and nano users that are used to "wrapped goto".) And there are no technical obstacles for us to provide both features, independently of each other and without limitations. Just need to come up with a nice interface allowing that.

For example, maybe just add a separate command for relative goto? Name it jump or something? Or maybe 2 separate commands, for jumping up and down?

Ok, to don't break the current interface/functionality it's then, as you mentioned, better to expose it on a separate way.

For example, maybe just add a separate command for relative goto? Name it jump or something? Or maybe 2 separate commands, for jumping up and down?

Hm, I'm no friend of having to functions for the same base functionality (up/down). I would prefer one own function (e.g. the mentioned relativegoto) or a further argument as we do for the search (-r for relative). I guess you will prefer the first, right?

I would prefer one own function (e.g. the mentioned relativegoto) or a further argument as we do for the search (-r for relative). I guess you will prefer the first, right?

Both seem fine to me (and neither seems perfect...), but as I said, I'm not gonna use that myself, so I'm not the one to judge what would be the best here from the user perspective.

We should also take into account that micro also has a default Ctrl+L shortcut for goto, so what should we do in this regard when it comes to relative goto? Add another shortcut for it? Or try to make Ctrl+L reusable (and convenient to use) for relative goto as well?

Thinking more about it, the behavior you implemented (i.e. + or - sign indicating that this a relative goto) actually seems the cleanest one to me (if it wasn't unfortunately incompatible with the already existing and documented behavior).

From my point of view the goto command should always work with one shortcut.

A normal number goes to the absolute line number, +xyz goes down xyz and -xyz goes up/back xyz number of lines.

This should not even be affected by which ruler (relative or absolute) you use at the moment.

A normal number goes to the absolute line number, +xyz goes down xyz and -xyz goes up/back xyz number of lines.

That's what this PR does. Unfortunately we've already one kind of behavior, which is derived from nano and documented accordingly. No matter at which position in the test file you are, in the moment you do a goto -# you will not go by # lines from the current position above but from the end of the file instead (see commands.md?plain=1#L34).

Now we've different approaches to solve this:

• break with the previous implementation/approach and directly provide relative goto within the existing command by +/-
• create the capability to have both together (which one would be preferred then?)
  • one new additional command e.g. relativegoto or jump
  • two new additional commands for the explicit direction

Maybe a community vote would be a good choice or a dictatorial decision. 😉

@zyedidia
What are your thoughts?

Now I'm inclined to agree with @dase78 that providing relative goto within the existing command by +/- seems to be the nicest option. Yes, it would break compatibility, but maybe in this case we can let it go and not be dogmatic about that?

We can still provide the existing behavior as well, just with a different (incompatible) interface. How about the ~ (tilde) sign instead of the - sign for it?

Unfortunately we've already one kind of behavior, which is derived from nano and documented accordingly. No matter at which position in the test file you are, in the moment you do a goto -# you will not go by # lines from the current position above but from the end of the file instead...

Yes, right, I remember. I never ever used this kind of navigation, because for me it never made sense.

Now we've different approaches to solve this:

* break with the previous implementation/approach and directly provide relative goto within the existing command by +/-

* create the capability to have both together (which one would be preferred then?)

If I had to decide, I would let the nano-way go. I found it useless for my cases and workflow (never used it in nano also). But that's just my point of view. Some others may see it different.

EDIT: The ~ could be a nice compromise to keep up all 3 kinds of fast navigation.

We can still provide the existing behavior as well, just with a different (incompatible) interface. How about the ~ (tilde) sign instead of the - sign for it?

EDIT: The ~ could be a nice compromise to keep up all 3 kinds of fast navigation.

Yep, this sounds like a good idea to not fully loose this "feature".

Another idea would be:

#-> absolute linenumber
+# / -# -> "nano-movement"
j# / k# -> relative movement to actual linenumber

Myself would not be very happy about it, because I've never been a Vimuser and I don't find the shortcuts intuitive in any kind of way (that's one big reason, why I love Micro that much). But as mentioned from @dmaluka in another related topic, it seems, that many Vimusers are used to this navigation (relativeruler and jk).

My first vote would be #, +-~. This I would use heavily.

I will prepare this suggestion in the next few days and try to update the documentation accordingly.

Shall I already respect #2966?
Hm, a merge conflict is to be expected anyway.

This PR is now proudly present by @dmaluka 😉

I just noticed this breaks my #1691 patch with the latest build. It's a shame the behaviour has changed after 4 years.

Can this be reconsidered?

I use the "Nano way" daily to jump to the end of the document, having developed that habit since before Micro even existed.

In addition I find the new method where "goto 5" is absolute and "goto +5" is relative is completely unintuitive since numerically 5 and +5 are identical.

A better solution to stay compatible with other editors, as well as itself, would've been to use ~ (or another prefix) for relative goto. Or just use "jump" for relative goto.

@JoeKar Reverting then? We can always implement a serapate relativegoto command (with a separate default shortcut for it), if anyone needs it.

In addition I find the new method where "goto 5" is absolute and "goto +5" is relative is completely unintuitive since numerically 5 and +5 are identical.

Just for the record, this method is pretty common. Vim has used it since always, and vi used it before vim, and ed used it before vi.

A separate command would be perfect since it would allow the user to bind Ctrl+L to one command or the other, depending on their own preference.

Point taken about how vi does things. Though arguably vi's un-intuitiveness isn't something Micro should be emulating. :)

I use the "Nano way" daily to jump to the end of the document, having developed that habit since before Micro even existed.

Just as a second method, Ctrl+Up/Down brings you also at start/beginning of a document. But habits are habits. ;)

... We can always implement a serapate relativegoto command (with a separate default shortcut for it), if anyone needs it.

This was already mentioned earlier and would be great, don't know "jumpup" and "jumpdown"? Then we really could bind everything to own shortcuts. +1

Though arguably vi's un-intuitiveness isn't something Micro should be emulating. :)

I don't think, this is going to happen.;)

I've reverted it anyway, since user regressions are not good. I'll let you guys decide among yourselves how to proceed further.

Though arguably vi's un-intuitiveness isn't something Micro should be emulating.

Intuitiveness is subjective.

Ok, since it's reverted anyway already we should open #2897 again, where the whole story should be discussed and voted by the community. So please continue there...