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
* 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>
* 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
Similarly to the crash fixed by #2967, which happens if sudo failed,
a crash also happens when sudo even fails to start. The reason for
the crash is also similar: nil dereference of screen.Screen caused by
the fact that we do not restore temporarily disabled screen.
To reproduce this crash, set the `sucmd` option to some non-existing
command, e.g. `aaa`, and try to save a file with root privileges.
* Fix panic due to invalid regex in a syntax file
When a user's custom syntax file has a malformed filename regex or
header regex, MakeHeaderYaml() returns error but we do not properly
handle it, which results in a panic due to a dereference of the `header`
pointer which is nil:
Micro encountered an error: runtime.errorString runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:221 (0x44c367)
runtime/panic.go:220 (0x44c337)
github.com/zyedidia/micro/v2/internal/buffer/buffer.go:709 (0x82bc0f)
github.com/zyedidia/micro/v2/internal/buffer/buffer.go:392 (0x828292)
github.com/zyedidia/micro/v2/internal/buffer/buffer.go:261 (0x8278c8)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:203 (0x8b9e7b)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:331 (0x8ba9e5)
runtime/proc.go:255 (0x4386a7)
runtime/asm_amd64.s:1581 (0x467941)
* Do not ignore invalid filename regex error in a syntax file
When the filename regex in a syntax file is malformed but the subsequent
header regex is correct, the filename regex error gets silently ignored,
since the `err` value is overwritten by the subsequent successful header
regex result.
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.
On modern Linux systems, it can take 30 seconds for
the data to actually hit the disk (check
/proc/sys/vm/dirty_expire_centisecs).
If the computer crashes in those 30 seconds, the user
may end up with an empty file as seen here:
https://github.com/neovim/neovim/issues/9888
This is why editors like vim and nano call
the fsync syscall after they wrote the file.
This syscall is available as file.Sync() in Go.
Running strace against micro shows that fsync is
called as expected:
$ strace -f -p $(pgrep micro) -e fsync
strace: Process 3284344 attached with 9 threads
[pid 3284351] fsync(8) = 0
Also, we now catch errors returned from w.Flush().
* 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
Bump zyedidia/terminal, which is the actual dependency. We can get the
information we need from the Term's pty file rather than using a buffer
connected to stdout.
Fixes#2775
Add color groups for displaying statuslines of inactive split panes
and the suggestions menu with colors different from the statusline
of the active pane.
* 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
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.
* Fix incorrect LastVisualX after changing bufWidth w/o resize
When we resize a buffer pane with softwrap enabled, we update the
cursors LastVisualX values to ensure that moving cursor up or down
within a wrapped line will move the cursor to the correct location.
The problem is that we need to do it also in cases when the visual
buffer width within the buffer window is changing without resizing
the window itself, e.g. when toggling the ruler on/off.
So update LastVisualX whenever the buffer width changes, not neccesarily
as a result of resizing the buffer window.
* Update LastVisualX and relocate when toggling wordwrap on/off
Visual location of a cursor may change not only when softwrap is toggled
on or off but also when wordwrap is toggled on or off without changing
the softwrap setting. So need to update cursor LastVisualX values and
relocate the view if needed, just like when softwrap is toggled, to make
sure that moving the cursor up and down will work correctly and that the
cursor will not be left out of the view.
* Add LessEqual and GreaterEqual for SLoc
* Fix relocate at the end of buffer when scrollmargin is 0
Fix the following issue: when scrollmargin is set to 0 and we move the
cursor to the end of buffer (e.g. via Ctrl-End), the buffer view doesn't
move.
The cause is that the condition c.LessThan(w.Scroll(bEnd, -scrollmargin+1))
doesn't hold, since Scroll() takes care not to return a location beyond
the end of buffer, so in this case Scroll() just returns bEnd.
Fix issue where symlinked plugin directories were ignored. For example
$ file ~/.config/micro/plug/example
example: symbolic link to <target directory>
This allows plugins to be managed in a user's "dotfiles" repository, and
be symlinked into micro's plugin directory.
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.
Micro will now also search for a program called micro-clip for handling
the clipboard. This allows the user to make a program called micro-clip
that micro will call out to for performing copy/paste. For copy it will
be called with `micro-clip -i <reg>` and the text will be provided on
stdin. For paste it will be called with `micro-clip -o <reg>` and micro
expects the text to be provided on stdout.
After 9ad4437, directly specifying color names (instead of syntax groups)
in syntax files no longer works. In particular *.patch and *.diff files
are not highlighted, since in patch.yaml direct colors names are used.
Restore the previous behavior of GetColor (fallback to direct colors if
no syntax group found) to fix this regression, but also make some changes
in StringToStyle and StringToColor to still fix the issue which was fixed
by 9ad4437. In other words, ensure that there is no confusion between
direct colors ("red", "green" etc) and syntax groups omitted in the
colorscheme file.
* 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
* Fix default colors for unconfigured syntax groups
When GetColor is called for a syntax group not specified in the
colorscheme, it should fallback not to the terminal's default colors
(tcell.DefaultColor) but to the colorscheme's defaults (DefStyle)
which may be different from tcell.DefaultColor.
For example, if we are using micro's default colorscheme in a terminal
which uses a black-on-white theme, then dots and commas in Go files
("symbol" syntax group in go.yaml) are displayed black on a dark
background, i.e. barely visible.
* Avoid using terminal's default colors directly
If a syntax group color is set to "default" (which we have for some
syntax groups in some colorschemes), it defaults to the terminal's
default colors (tcell.DefaultColor), which is fine for 16-color
colorschemes but not quite fine for truecolor and 256-color
colorschemes which should not depend on the terminal colors.
It should default to the colorscheme's default (DefStyle) instead.
For example, if we are using micro's default colorscheme in a terminal
which uses a black-on-white theme, then "bool" type in C files
("type.extended" syntax group in c.yaml) is displayed black on a dark
background, i.e. barely visible.