* infocomplete: Complete filetypes (follow-up)
The first shot of the feature unfortunately completed the *.yaml file
names instead of the included filetypes. This will be corrected with
this follow up.
* infocomplete: Correct comment of filetypeComplete according to review hint
Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
---------
Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
`unknown` is a valid value for the `filetype` option (and executing
`set filetype unknown` does what is expected: it forces filetype
autodetection). So let's add `unknown` to the autocomplete suggestions
for `filetype`, along with actual filetypes.
* rtfiles: Initialize all-/realFiles and Plugins in InitRuntimeFiles
* command: Reload plugins at ReloadCmd too
* command: Don't reload plugins in case of ReloadConfig()
* rtfiles: Split InitRuntimeFiles() into one func for assets and one for plugins
* rtfiles: Remove the unnecessary init function
With this modification the InitRuntimeFiles() and InitPlugins() (if needed)
must be called first, otherwise uninitialized runtime file variables are most
likely.
InfoBar should really receive the resize event, to know the window width
in order to do horizontal scrolling of the command line when it doesn't
fit in the screen. Although currently it doesn't scroll the command line
at all (see issue #2527) and just ignores the resize event, but we
should fix that anyway, so let's forward the resize event to it.
* command: Fix replace to be able to insert '$'
* help: commands: Precise the documentation of `replace`
* help: commands: Further improvement suggested within the review
Co-authored-by: Beni Cherniavsky-Paskin <cben@redhat.com>
* Fix replace with '$' in a more kosher way
On top of JoeKar's fix.
---------
Co-authored-by: Beni Cherniavsky-Paskin <cben@redhat.com>
Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
* settings: Move all options to the start of the file
This will help with the overview of all available options and their optional
validators.
* settings: Add generic string option validator
* settings: Autocomplete string options
Passing options via micro -option=value in the command line should only
temporarily override the option value for the current micro session,
not change it permanently in settings.json. But currently it wrongly
writes it to settings.json in the case when the value passed via command
line is the default value of this option, while the current permanent
setting in settings.json is a non-default value.
Fixes#3005
If we add something like this to init.lua:
config.AddRuntimeFile("status", config.RTHelp, "help/foo.md")
then start micro and run "help foo", the resulting error message looks
weird:
Unable to load help textfooopen plugins/status/help/foo.md: file does not exist
Change it to:
Unable to load help text for foo: open plugins/status/help/foo.md: file does not exist
- 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.
Improve user experience: if we are at a line with a new (i.e.
not highlighted yet) trailingws and we begin selecting text,
don't highlight the trailingws until we are done with selection,
even if we moved the cursor to another line while selecting.
Added option `hltrailingws` for highlighting trailing whitespaces
at the end of lines. Note that it behaves in a "smart" way.
It doesn't highlight newly added (transient) trailing whitespaces
that naturally occur while typing text. It would be annoying to
see transient highlighting every time we enter a space at the end
of a line while typing.
So a newly added trailing whitespace starts being highlighting
only after the cursor moves to another line. Thus the highlighting
serves its purpose: it draws our attention to annoying sloppy
forgotten trailing whitespaces.
* Update docs to include `matchbracestyle`
* Add `matchbracestyle` to infocomplete.go
* Add validator and default settings for `matchbracestyle`
* Highlight or underline braces based on `matchbracestyle`
* Add `match-brace` to default colorschemes
* Correct `FindMatchingBrace()` counting
Make brace under the cursor have priority over brace to the left in
ambiguous cases when matching braces
Co-authored-by: Dmitry Maluka <dmitrymaluka@gmail.com>
* Fix conflicts
---------
Co-authored-by: Jöran Karl <3951388+JoeKar@users.noreply.github.com>
Co-authored-by: Dmitry Maluka <dmitrymaluka@gmail.com>
* 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.
* Add reload setting
Can be set to:
* auto - Automatically reload files that changed
* disabled - Do not reload files
* prompt - Prompt the user about reloading the file.
* option: Add default value for reload option and documentation
---------
Co-authored-by: Wilberto Morales <wilbertomorales777@gmail.com>
Add HistorySearchUp and HistorySearchDown actions which are similar to
HistoryUp and HistoryDown but search for the prev/next history item
whose beginning matches the currently entered text in the infobuffer
(more precisely, the text before cursor).
Also fixed the following issue: if we scrolled to an older history item
and then edit the infobuffer, this older item gets modified.
We should not edit old history entries. So in this case set HistoryNum
to the last (newly added) item and modify the last item.
* 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
Since now bufpane handles mouse move and release events generically and
separately from mouse press events, that creates a mess when we dispatch
a mouse press event to an inactive pane without making it active.
For example:
1. Click the right button on an inactive pane. It remains inactive.
2. Then click the left button on it. It becomes active, and an
unexpected text selection appears.
The reason is that the release event for the first click was dispatched
to a wrong pane - the (then) active one, so the (then) inactive pane
didn't get the release event and treats the second click not as a mouse
press but as a mouse move.
The simplest way to fix it is to avoid this scenario entirely, i.e.
always activate the pane when clicking any mouse button on it, not just
the left button.
For mouse wheel motion events we keep the existing behavior: the pane
gets the event but doesn't become active. Mouse wheel motion events are
not affected by the described issue, as they have no paired "release"
events.
When we temporarily disable the screen (e.g. during TermMessage or
RunInteractiveShell), if the mouse is pressed when the screen is still
active and then released when the screen is already stopped, we aren't
able to catch this mouse release event, so we erroneously think that the
mouse is still pressed after the screen is restarted. This results in
wrong behavior due to a mouse press event treated as a mouse move event,
e.g. upon the left button click we see an unexpected text selection.
So need to reset the mouse release state to "released" after restarting
the screen, assuming it is always released when the screen is restarted.
If we press mouse, drag and then release, the release event is
generated twice, since both mouse press and mouse drag events have been
saved in mousePressed map. To fix that, ensure that we only store mouse
press events in it.
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.
Adds config option `multimode`, which takes values `tab`, `vsplit`,
or `hsplit` (corresponding to the file-opening commands). I mean to
use it with a command line like
micro -multimode vsplit foo.h foo.c
to open files in a side-by-side split, but if one really wanted to
one could set it in the config file to change the default behavior of
opening multiple files in tabs.
* 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.
