* Fix gutter overwriting other split pane
When we resize a split pane to a very small width, so that the gutter
does not fit in the pane, it overwrites the sibling split pane.
To fix it, clean up the calculation of gutter width, buffer width and
scrollbar width, so that they add up exactly to the window width, and
ensure that we don't draw the gutter beyond this calculated gutter
width (gutterOffset).
As a bonus, this also fixes the crash #3052 (observed when resizing a
split pane to a very small width, if wordwrap is enabled), by ensuring
that bufWidth is never negative.
[*] By the gutter we mean of course gutter + diffgutter + ruler.
* Don't display line numbers if buffer width is 0 and softwrap is on
If softwrap is enabled, the line numbers displayed in the ruler depend
on the heights of the displayed softwrapped lines, which depend on the
width of the displayed buffer. If this width is 0 (e.g. after resizing
buffer pane to a very small width), there is no displayed text at all,
so line numbers don't make sense. So don't display line numbers in this
case.
* Fix buffer text overwriting scrollbar when window width is 1 char
Fix the following funny issue: if we open 3 vertical split panes (i.e.
with 2 vertical dividers between them) and drag the rightmost divider
to the left (for resizing the middle and the rightmost split panes), it
does not stop at the leftmost divider but jumps over it and then hovers
over the leftmost split pane. And likewise with horizontal split panes.
* 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>
* Update C syntax with keywords up to C23.
* Update C syntax with some GCC extensions.
* Update C# syntax with new keywords up to C# 12.
* Update C# syntax with preprocessor directives.
* Add Cake build script (C#) syntax.
* Add MSBuild (XML) syntax.
* 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.
If ~/.config/micro/plug directory contains a plugin with the same name
as a built-in plugin, the expected behavior is that the user-defined
plugin in ~/.config/micro/plug is loaded instead of the built-in one.
Whereas the existing behavior is that the built-in plugin is used
instead of the user-defined one. Even worse, it is buggy: in this case
the plugin is registered twice, so its callbacks are executed twice
(e.g. with the autoclose plugin, a bracket is autoclosed with two
closing brackets instead of one).
Fix this by ensuring that if a plugin with the same name exists in the
~/.config/micro/plug directory, the built-in one is ignored.
Fixes#3029
It doesn't seem necessary to write settings to settings.json when
registering a new option. The option is set to its default value, which
means that it will not be written to settings.json (precisely because
it's the default value), so the contents of settings.json don't change
and thus don't need to be written again.
This unneeded writing, in particular, causes unexpected "The file on
disk has changed. Reload file? (y,n,esc)" each time when we open
settings.json via micro.
Fixes#2647
Avoid code duplication between RegisterCommonOption() and
RegisterCommonOptionPlug(), exactly the same way as it is done for
RegisterGlobalOption() and RegisterGlobalOptionPlug().
* 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>
1. Python decorators begin a compound statement, so they only appear
at the start of a line. So match at the line start to avoid giving
decorator colors to matrix multiplication (@) expressions. Source:
https://docs.python.org/3/reference/compound_stmts.html#function-definitions
2. Python decorators go to the end of the line and might not include
parentheses (for example @functools.cache). So instead of matching
everything until an `(`, just match as many non-`(` characters
as possible---which both catches the @functools.cache example and
allows decorator parameters to fall back to the default color.
3. Instead of hardcoding `brightgreen` (which railscast.micro also
complains about), color decorators as `preproc` (otherwise unused
by the python syntax files, and arguably the right colorscheme
group to be using for syntactic sugars anyway). Note this will
change decorator colors---for example from bright green to kinda
brown on monokai, and from yellow to more of a light orange on
railscast.
* Fixed newline format detection for files not ending with a newline
Files with Windows-style line endings were being converted to
Unix-style if the file did not end with a newline
* Updated file format detection fix for consistency
