Inserting a newline currently collapses any connected selections when inserting
or appending. It's happening because we're reducing the selections down to
their cursors (`let selection = ..` line) and then computing the new selection
based on the cursor. We're discarding the original head and anchor information
which are necessary to emulate Kakoune's behavior.
In Kakoune, inserting a newline retains the existing selection and _slides_
it (moves head and anchor by the same amount) forward by the newline and
indentation amount. Appending a newline extends the selection to include the
newline and any new indentation.
With the implementation of insert_newline here, we slide by adding the global
and local offsets to both head and anchor. We extend by adding the global
offset to both head and anchor but the local offset only to the head.
* Making the 'set-option' command help more descriptive.
* Adding the generated docs
* Making the message multi-line
* Replace newline with break in generated docs
* add reflow command
Users need to be able to hard-wrap text for many applications, including
comments in code, git commit messages, plaintext documentation, etc. It
often falls to the user to manually insert line breaks where appropriate
in order to hard-wrap text.
This commit introduces the "reflow" command (both in the TUI and core
library) to automatically hard-wrap selected text to a given number of
characters (defined by Unicode "extended grapheme clusters"). It handles
lines with a repeated prefix, such as comments ("//") and indentation.
* reflow: consider newlines to be word separators
* replace custom reflow impl with textwrap crate
* Sync reflow command docs with book
* reflow: add default max_line_len language setting
Co-authored-by: Vince Mutolo <vince@mutolo.org>
Allow tab-completion to continue when there is only a single, unambigous
completion target which is a directory. This allows e.g. nested directories
to be quickly drilled down just by hitting <tab> instead of first selecting
the completion then hitting <enter>.
* add run_shell_command
* docgen
* fix command name
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
* refactored Info::new
* show 'Command failed' if execution fails
* TypedCommand takes care of error handling and printing the error to the statusline.
* docgen
* use Popup instead of autoinfo
* remove to_string in format!
* Revert chage in info.rs
* Show "Command succeed" when success
* Fix info.rs
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
When fiddling with paths in a :o prompt, one usually would want Ctrl-W to erase a path segment
rather than the whole path. This is how Ctrl-W works in e.g. (neo)vim out of the box.
Currently A-left move one word left and the behavior will be more
consistent for people coming GUI world if the key was changed to control
given that both browsers and editors like vscode uses C-left right by
default to move word rather than alt.
A-hl currently is not very consistent with hl when next object is
selected, since it may go up/down or left/right and this behavior is
confusing such that some people think it should swap the keys with A-jk,
so it is better to use A-pn since that only specifies two direction.
A-jk have the same issue as in it usually moves right and is not
consistent with the behavior of jk so people may think A-hl is better,
maybe A-oi is better here since A-hl will be swapped to A-pn, A-oi can
convey the meaning of in and out, similar to some window manager keys?
