Micro "allows" plugins to register colorschemes via
config.AddRuntimeFile(). However, that has never really worked, since
InitColorscheme() is called earlier than plugins init() or even
preinit() callbacks are called.
To work around that, plugins that use it (e.g. nord-tc [1]) are using a
tricky hack: call config.AddRuntimeFile() not in init() or preinit() but
directly in Lua's global scope, so that it is called earlier, when the
plugin's Lua code is loaded. This hack is not guaranteed to work, and
works by chance. Furthermore, it only works when starting micro, and
doesn't work after the `reload` command. (The reason it doesn't work is
that PluginAddRuntimeFile() calls FindPlugin() which calls IsLoaded()
which returns false, since, well, the plugin is not loaded, it is only
being loaded. And the reason why it works when starting micro is that
in that case IsLoaded() confusingly returns true, since
GlobalSettings[p.Name] has not been set yet.)
So move InitColorscheme() call after calling plugins init/preinit/
postinit callbacks, to let plugins successfully register colorschemes
in any of those callbacks instead of using the aforementioned hack.
[1] https://github.com/KiranWells/micro-nord-tc-colors
Adding early validation of options in ReadSettings() caused a regression:
colorschemes registered by plugins via config.AddRuntimeFile() stopped
working, since ReadSettings() is called when plugins are not initialized
(or even loaded) yet, so a colorscheme is not registered yet and thus
its validation fails.
Fix that with an ad-hoc fix: treat the "colorscheme" option as a special
case and do not verify it early when reading settings.json, postponing
that until the moment when we try to load this colorscheme.
Pass *tcell.EventMouse to action callbacks for "mouse actions", i.e. to
onMousePress, preMouseDrag and so on, similarly to how we pass it to lua
functions bound to mouse events.
Swaping `MainTab` calls to `h.tab` will not change the normal micro
behaviour.
This changes will make possible to call `ForceQuit`, `VSplitIndex` and
`HSplitIndex` for tabs that aren't main one.
- `auto`: enable usage of true color if it is supported, otherwise disable it
- `on`: force usage of true color
- `off`: disable true color usage
Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
Whenever the user changes the value of an option that affects the
calculation of display params in updateDisplayInfo(), we should
immediately recalculate those params and relocate the buffer view
accordingly.
For example: after enabling ruler via `set ruler on`, if the cursor is
currently at the rightmost edge of the bufpane and softwrap is disabled,
then the cursor becomes invisible (since it is now outside the view,
since the buffer view width is decreased as a result of adding the ruler
but StartCol is not updated accordingly), it only becomes visible again
after the user types a character (or performs some other action that
triggers updateDisplayInfo() + relocate). Fix it.
This slightly changes the open and term command to be similar with the
Quit action, where the buffer or pane is replaced after the prompts are
completed if "n" wasn't pressed after the 1st prompt.
Copy build constraints in actions_other.go to terminal_unsupported.go,
to avoid maintaining separate build constraints that are similar with
terminal_supported.go.
Support terminal emulation on platforms below:
- Solaris
- NetBSD: Supported in creack/pty since v1.1.12
- OpenBSD with GOOS != amd64
- Other architectures are supported now in creack/pty
The patch is taken from:
https://github.com/zyedidia/micro/pull/2738
The mentioned file was already removed with the following commit:
fe3186ba9d
The `micro` binary itself takes now care of validating the syntax definitions
and informs about possible issues.
Different assemblers have different syntaxes for comments: ";", "#",
"!", "|", "@", "*" and finally C-like comments "//" and "/* ... */".
Micro currently highlights only ";". This is causing various problems
with broken highlighting with other types of comments (i.e. those not
recognized by micro as comments), when the text in those comments
contains special characters, causing wrong highlighting of text after
them.
On the other hand, highlighting comments like "#", "|" etc would cause
conflicts with other syntax elements, e.g. constants in ARM assembly,
preprocessor directives, arithmetic expressions etc.
So let's highlight at least C-like comments. They are quite commonly
used and they are not so likely to cause conflicts with other syntax
elements.
