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

End of line behavior for command to transpose characters #805

Closed
ghost opened this issue Sep 16, 2018 · 7 comments
Closed

End of line behavior for command to transpose characters #805

ghost opened this issue Sep 16, 2018 · 7 comments

Comments

@ghost
Copy link

ghost commented Sep 16, 2018

Xi has a command called transpose. It works similarly to the command transpose-chars in Emacs, but doesn't get the end of the line behavior right. From the Emacs manual:

Normally, C-t transposes the two characters on either side of point. When given at the end of a line, rather than transposing the last character of the line with the newline, which would be useless, C-t transposes the last two characters on the line. So, if you catch your transposition error right away, you can fix it with just a C-t.

@scholtzan
Copy link
Member

The current behaviour for transpose is pretty much the same as in Sublime. There it also swaps the last character of the line with the one on the next line. I am not sure which behaviour should be preferred.

@cmyr
Copy link
Member

cmyr commented Sep 17, 2018

We have in general chosen ST3 as a model when nitting various little behaviours, and I'm happy with that choice.

In this case, both approaches address the fundamental problem that transposing a newline is probably not helpful; and if we pretend that newlines don't exist, transposing with the next non-newline character makes sense to me. If there's a specific utility-based argument for the other approach I'm happy to hear it.

@ghost
Copy link
Author

ghost commented Sep 17, 2018

The quote from the Emacs manual makes it clear why that behavior is preferred and why the other behavior is even considered useless. In general I think Emacs and Vi are going to have every text related feature more well-designed than any editor with a shorter history. I assume the feature in Sublime works differently not because it was a conscious design choice, but simply because the author of Sublime never used Emacs, and doesn't know how useful this feature can be when implemented properly.

If you insist on having the Sublime feature, you can simply make two different commands for the two features, and any frontend can choose which one to use, or let the user configure the choice. The Sublime feature will however, as the Emacs manual says, be useless.

@raphlinus
Copy link
Member

The existing behavior was a deliberate choice (mostly because I felt Sublime was a good model to follow), but if people have strong preferences I'm willing to change it.

@cmyr
Copy link
Member

cmyr commented Oct 15, 2018

closed in #847. If we want to make this a config option at some point we can revisit.

@sidsrvstv
Copy link

Are there any issues I can help out with?

@jansol
Copy link
Collaborator

jansol commented Oct 15, 2018

@sidsrvstv sure, feel free to claim any issue tagged as "help wanted" or "hacktoberfest", those have been identified as mostly self-contained projects that should be easy to get started with.

Those issues should have good enough descriptions to get started. If that is not the case, please do ask for clarification in that issue's discussion.

If you have access to a mac you an also help out with xi-mac

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants