When adding a new `BufPane` it is always being inserted last into `MainTab().Panes`.
This leads to a confusion when using the actions `PreviousSplit`, `NextSplit` as the previous/next split may not be the expected one.
How to reproduce:
- Launch micro and insert char "1"
- Open a new vsplit via the command `vsplit` and insert "2"
- Switch back to the left split (1) by using `PreviousSplit`
- Again open a new vsplit via command: `vsplit` and type char "3"
- Now switch between the 3 splits using `PreviousSplit`, `NextSplit`
Switching from most left split to the most right, the expected order would be 1, 3, 2 but actually is 1, 2, 3.
When we temporarily disable the screen (e.g. during RunInteractiveShell)
and then enable it again, we reinitialize tcell.Screen from scratch, so
we need to register all previously registered raw escape sequences once
again. Otherwise raw escape bindings stop working, since the list of
raw escape sequences of this newly create tcell.Screen is empty.
Fixes#3392
It doesn't need to loop over the DefaultCommonSettings() again,
since they're already included in the default settings and set via
SetGlobalOptionNative().
Add `matchbraceleft` option to allow disabling the default behavior
matching not just the brace under cursor but also the brace to the left
of it (which is arguably convenient, but also ambiguous and
non-intuitive). With `matchbraceleft` disabled, micro will only match
the brace character that is precisely under the cursor, and also when
jumping to the matching brace, will always move cursor precisely to the
matching brace character, not to the character next to it.
Nota bene: historical journey:
- There was already a `matchbraceleft` option introduced in commit
ea6a87d41a, when this feature (matching brace to the left) was
introduced first time. That time it was matching _only_ the brace
to the left, _instead_ of the brace under the cursor, and was
disabled by default.
- Later this feature was removed during the big refactoring of micro.
- Then this feature was reintroduced again in commit d1e713ce08, in
its present form (i.e. combined brace matching both under the cursor
and to the left, simulating I-beam cursor behavior), and it was
introduced unconditionally, without an option to disable it.
- Since then, multiple users complained about this feature and asked
for an option to disable it, so now we are reintroducing it as an
option again (this time enabled by default though).
Also tweaked the behavior of Paragraph/{Previous/Next} so that it skips
all empty lines immediately next to cursor position, until it finds the
start/end of the paragraph closest to it. Once it finds the paragraph
closest to it, the same behavior as before applies. With the previous
behavior if the cursor was surrounded by empty lines, then
Paragraph/{Previous/Next} would only jump to the next empty line,
instead of jumping to the start/end of a paragraph.
Instead of calling execAction() and then letting it check whether it
should actually execute this action, do this check before calling
execAction(), to make the code clear and straightforward.
Precisely: for multicursor actions, call execAction() in a loop for
every cursor, but for non-multicursor actions, call execAction() just
once, without a loop. This, in particular, allows to get rid of the
hacky "c == nil" check, since we no longer iterate a slice that may
change in the meantime (since SpawnMultiCursor and RemoveMultiCursor
are non-multicursor actions and thus are no longer executed while
iterating the slice).
- SpawnMultiCursor and RemoveMultiCursor actions change the set of
cursors, so we cannot assume that it stays the same. So refresh the
`cursors` list after executing every action in the chain.
- If execAction() did not execute an action since it is not a
multicursor, it should return true, not false, to not prevent
executing next actions in the chain.
If the original selection was not done by the user manually but as a
result of the initial SpawnMultiCursor, deselect this original selection
if we execute RemoveMultiCursor and there is no multicursor to remove
(i.e. the original spawned cursor is the only one). This improves user
experience by making RemoveMultiCursor behavior nicely symmetrical to
SpawnMultiCursor.
When there is no selection (i.e. selection is empty), SkipMultiCursor
searches for the empty text, "finds" it as the beginning of the buffer,
and as a result, jumps to the beginning of the buffer, which confuses
the user. Fix it.
ClearInfo and ClearStatus actions do exactly the same thing. Let's keep
them both, for compatibility reasons (who knows how many users are using
either of the two), but at least document that there is no difference
between the two.
Return false if there is nothing to undo/redo.
This also fixes false "Undid action" and "Redid actions" infobar
messages in the case when no action was actually undone or redone.
Fix regression caused by the fix 0de16334d3 ("micro: Don't forward
nil events into the sub event handler"): even if the terminal was
started with `wait` set to false, it is not closed immediately after
it finished its job, instead it shows "Press enter to close".
The reason is that since the commit b68461cf72 ("Terminal plugin
callback support") the termpane code has been (slightly hackily) relying
on nil events as notifications to close the terminal after it finished
its job. So fix this by introducing a separate CloseTerms() function
for notifying termpanes about that, decoupled from HandleEvent() which
is for tcell events only.
The lastCutTime feature (reset the clipboard instead of appending to the
clipboard if the last CutLine was more than 10 seconds ago) was
implemented 8 years ago but was always buggy and never really worked,
until we have accidentally found and fixed the bug just now. No one ever
complained or noticed that, which means it is not a very useful feature.
Fixing it changes the existing behavior (essentially adds a new feature
which did not really exist before) and there is no reason to assume that
this new behavior will be welcome by users. So it's better to remove
this feature.
According to tcell documentation, Rune() should only be used for KeyRune
events. Otherwise its return value is not guaranteed and should not be
relied upon.
This fixes issue #2947: Esc key not working on Windows, since tcell
sends lone Esc key event with rune == 0 on Unix but with rune == 27
(the keycode) on Windows.
Similarly to CutLine, DeleteLine and CopyLine actions, if there is a
selection, duplicate not just the current line but all the lines covered
(fully or partially) by the selection.
- Add a new Duplicate action which just duplicates the selection (and
returns false if there is no selection).
- Change the behavior of the DuplicateLine action to only duplicate the
current line, not the selection.
- Change the default action bound to Ctrl-d from DuplicateLine to
Duplicate|DuplicateLine, so that the default behavior doesn't change.
This allows the user to rebind keybindings in a more flexible way, i.e.
to choose whether a key should duplicate just lines, or just selections,
or both, - in a similar fashion to Copy, Cut, Delete actions.
If we ever encounter this clipboard.Read() failure, return false
immediately. Otherwise, InfoBar.Error(err) will have no effect (it will
be immediately overwritten by InfoBar.Message()) so we won't even know
that there was an error.
Weird behavior is observed e.g. if we cut some lines with CutLine, then
copy some selection with Copy, then cut some other lines with CutLine,
and then paste. The pasted cliboard contains not just the lines that
were cut at the last step, but also the selection that was copied before
that.
Fix that by resetting the CutLine's repeated line cuts whenever we
copy anything to the clipboard via any other action (Cut, Copy or
CopyLine).
Since CutLine may add lines to the clipboard instead of replacing the
clipboard, improve its info message to show how many lines are in the
clipboard in total, not just how many lines were added to it last time.
When there is a selection containing multiple lines, CutLine, DeleteLine
and CopyLine actions currently cut/delete/copy just the "current" line,
as usual. This behavior is at least confusing, since when there is a
selection, the cursor is not displayed, so the user doesn't know which
line is the current one.
So change the behavior. When there is a multi-line selection,
cut/delete/copy all lines covered by the selection, not just the current
line. Note that it will cut/delete/copy whole lines, not just the
selection itself, i.e. if the first and/or the last line of the
selection is only partially within the selection, we will
cut/delete/copy the entire first and last lines nonetheless.
