- If a mouse event is bound to a Lua function, pass *tcell.EventMouse to
this Lua function, so that it can find out the position where a button
was clicked etc, just like the built-in MousePress and MouseMultiCursor
actions.
- Make mouse actions more a first-class citizen: allow chaining them and
running onAction and preAction callbacks for them, just like key actions.
* SpawnMultiCursorUp/Down: change order of adding cursors
SpawnMultiCursor{Up,Down} currently works in a tricky way: instead of
creating a new cursor above or below, it moves the current "primary"
cursor above or below, and then creates a new cursor below or above the
new position of the current cursor (i.e. at its previous position),
creating an illusion for the user that the current (top-most or
bottom-most) cursor is a newly spawned cursor.
This trick causes at least the following issues:
- When the line above or below, where we spawn a new cursor, is shorter
than the current cursor position in the current line, the new cursor
is placed at the end of this short line (which is expected), but also
the current cursor unexpectedly changes its x position and moves
below/above the new cursor.
- When removing a cursor in RemoveMultiCursor (default Alt-p key), it
non-intuitively removes the cursor which, from the user point of view,
is not the last but the last-but-one cursor.
Fix these issues by replacing the trick with a straightforward logic:
just create the new cursor above or below the last one.
Note that this fix has a user-visible side effect: the last cursor is
no longer the "primary" one (since it is now the last in the list, not
the first), so e.g. when the user clears multicursors via Esc key, the
remaining cursor is the first one, not the last one. I assume it's ok.
* SpawnMultiCursorUp/Down: move common code to a helper fn
* SpawnMultiCursorUp/Down: honor visual width and LastVisualX
Make spawning multicursors up/down behave more similarly to cursor
movements up/down. This change fixes 2 issues at once:
- SpawnMultiCursorUp/Down doesn't take into account the visual width of
the text before the cursor, which may be different from its character
width (e.g. if it contains tabs). So e.g. if the number of tabs before
the cursor in the current line is not the same as in the new line, the
new cursor is placed at an unexpected location.
- SpawnMultiCursorUp/Down doesn't take into account the cursor's
remembered x position (LastVisualX) when e.g. spawning a new cursor
in the below line which is short than the current cursor position, and
then spawning yet another cursor in the next below line which is
longer than this short line.
* SpawnMultiCursorUp/Down: honor softwrap
When softwrap is enabled and the current line is wrapped, make
SpawnMultiCursor{Up,Down} spawn cursor in the next visual line within
this wrapped line, similarly to how we handle cursor movements up/down
within wrapped lines.
* SpawnMultiCursorUp/Down: deselect when spawning cursors
To avoid weird user experience (spawned cursors messing with selections
of existing cursors).
It is useful to be able to use mouse not only for adding new cursors
but also for removing them. So let's modify MouseMultiCursor behavior:
if a cursor already exists at the mouse click location, remove it.
* Comment fix & gofmt fix
* Goto next/previous diff commands
These commands will work in `git` repositories or whenever `set diff on` is
working. They are bound to `Alt-[` and `Alt-]` by default. I would prefer
`Alt-Up` and `Alt-Down`, but that's already taken.
There are no tests at the moment; I'm looking into writing some since that will
be needed for the rest of the plan to make
https://github.com/zyedidia/micro/discussions/2753 a reality. I'm not sure how
difficult that will be.
* Realign JSON in keybindings.md
* Update for fixing bug issue
Adds YNprompt when user tries save new file as existing file name in current directory.
https://github.com/zyedidia/micro/issues/2709
* Update actions.go
error handled. gonna have to be tested on permission errors, etc
Introduce separate mouse release and mouse drag (move while pressed)
events: MouseLeftRelease, MouseLeftDrag, MouseRightRelease etc,
to allow binding them to actions independently from mouse press events
(MouseLeft, MouseRight etc).
This change:
- Makes it possible to handle mouse release and drag for arbitrary mouse
events and actions (including Lua actions), not just for MouseLeft as
in the current code.
- Fixes issue #2599 with PastePrimary and MouseMultiCursor actions:
selection is pasted not only when pressing MouseMiddle but also when
moving mouse with MouseMiddle pressed; similarly, a new multicursor is
added not only when pressing Ctrl-MouseLeft but also when moving mouse
with Ctrl-MouseLeft pressed.
My initial approach was not to introduce new events for mouse release
and mouse drag but to pass "mouse released" info to action functions
in addition to *tcell.EventMouse to let the action functions do the
necessary checks (similarly to what MousePress is already doing). But
then I realized it was a bad idea, since we still want to be able also
to bind mouse events to regular key actions (such as PastePrimary)
which don't care about mouse event info.
* Improve buffer view relocation after jumping to a far-away location
When the cursor is moved to a location which is far away from the
current location (e.g. after a search or a goto line), the buffer view
is always relocated in such a way that the cursor is at the bottom or
at the top (minus scrollmargin), i.e. as if we just scrolled to this
location. It's not like in other editors, and IMHO it's annoying. When
we jump to a new location far away, we usually want to see more of its
context, so the cursor should be placed closer to the center of the
view, not near its edges.
This change implements the behavior similar to other editors:
- If the distance between the new and the old location is less than one
frame (i.e. the view either doesn't change or just slightly "shifts")
then the current behavior remains unchanged.
- Otherwise the current line is placed at 25% of the window height.
* Postpone calling onBufPaneOpen until the initial resize
It is currently not possible to find out the geometry of a newly created
bufpane in onBufPaneOpen lua callback: bp:GetView() returns {0,0,0,0}
instead of the actual window. The reason is that the bufpane view is not
properly initialized yet when the bufpane is created and the callback is
triggered. It is initialized a bit later, at the initial resize.
So postpone calling onBufPaneOpen until after the initial resize.
* Improve buffer view relocation when opening a file at a far-away location
When a file is opened with the initial cursor location at a given line
which is far away from the beginning of the file, the buffer view is
relocated so that the cursor is at the bottom (minus scrollmargin)
as if we just scrolled to this line, which is annoying since we'd rather
like to see more of the context of this initial location.
So implement the behavior similar to the earlier commit (which addresses
a similar issue about jumping far away after a search or goto):
- If the initial cursor location is less than one frame away from the
beginning of the buffer, keep the existing behavior i.e. just display
the beginning of the buffer.
- Otherwise place the cursor location at 25% of the window height.
It should not return false immediately when no matching brace is found. This makes the jump fails in certain case: `[ )I]` =/=> `[I )]`.
When there is no brace near the cursor, the last statement is also executed. This may cause problems when chaining commands.
* Support for highlighting all search matches (hlsearch)
hlsearch is implemented efficiently using the buffer's line array,
somewhat similarly to the syntax highlighting.
Unlike the syntax highlighter which highlights the entire file,
hlsearch searches for matches for the displayed lines only.
Matches are searched when the given line is displayed first time
or after it was modified. Otherwise the previously found matches
are used.
* Add UnhighlightSearch action
and add it to the list of actions triggered by Esc key by default.
* Add comment explaining the purpose of search map
* Add hlsearch colors to colorschemes
Mostly just copied from the corresponding original (mostly vim) colorschemes.
* Highlight matches during/after replace as well
As a side effect it also changes the last search value, i.e. affects FindNext
and FindPrevious, but it's probably fine. In vim it works the same way.
* Improve hlsearch option description
The new feature of prefilling the search bar with the selected text (added
in 3d0b5db) has an annoying side effect: if we do have some text selected
but we want to search for some other pattern, not the selected text,
then we have to manually delete the prefilled text before we can start
entering our wanted search pattern.
A simple solution is to select the prefilled text, so that we can replace it
with our pattern right away just by typing, without any additional keystrokes.
BufView returns not only the buffer's width and height but also its
x,y position. It may be useful e.g. for checking if a mouse click was
on the actual buffer or ourside it, e.g. on the gutter.
Modified behavior of CursorUp, CursorDown, CursorPageUp etc:
if softwrap is enabled, cursor moves by visual lines, not logical lines.
TODO: implement it also for Home and End keys: move cursor to the
visual start or end of a line. I haven't implemented it for now, because
I'm not sure what should be the behavior of StartOfTextToggle then
(considering that Home key is bound to StartOfTextToggle by default).
Fixes#1598
Fixes issue with the usage of a slightly incorrect buffer height value
(v.Height should be v.Height-1 if statusline is displayed).
Also, to avoid too many duplications, the code reorganized a little:
buffer display params (width, height, gutter offset and others) are
calculated in a single place.
Softwrap implementation enhanced to fix various issues with scrolling,
centering, relocating etc.
The main idea is simple: work not with simple line numbers but
with (Line, Row) pairs, where Line is a line number in the buffer
and Row is a visual line (a row) number within this line.
The logic remains mostly the same, but simple arithmetic operations
on line numbers are replaced with corresponding operations on
(Line, Row) pairs.
Fixes#632, #1657
In JumpToMatchingBrace, the loop should stop immediately after finding the matching bracket.
It causes multiple jumps in certain situations:
`(I [ ]{ }) => ( I[ ]{ })`
