Fix regression caused by the fix 0de16334d3 ("micro: Don't forward
nil events into the sub event handler"): even if the terminal was
started with `wait` set to false, it is not closed immediately after
it finished its job, instead it shows "Press enter to close".
The reason is that since the commit b68461cf72 ("Terminal plugin
callback support") the termpane code has been (slightly hackily) relying
on nil events as notifications to close the terminal after it finished
its job. So fix this by introducing a separate CloseTerms() function
for notifying termpanes about that, decoupled from HandleEvent() which
is for tcell events only.
Implement a radical approach to improving abilities of plugins to detect
and handle various changes of micro's state: add onAnyEvent callback
which is called, literally, after any event. A plugin can use this
callback to compare a state after the previous event and after the
current event, and thus is able to catch various events that cannot be
detected using other callbacks.
Some examples of such events:
- change of current working directory
- switching cursor focus between a bufpane and the command bar
- change of message text in the status bar
* 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.
Exposing locking primitives to lua plugins is tricky and may lead to
deadlocks. Instead, if possible, it's better to ensure all the needed
synchonization in micro itself, without leaving this burden to lua code.
Since we've added micro.After() timer API and removed exposing Go timers
directly to lua, now we (probably?) have no cases of lua code possibly
running asynchronously without micro controlling when it is running. So
now we can remove lua.Lock.
This means breaking compatibility, but, until recently lua.Lock wasn't
workable at all (see #2945), which suggests that it has never been
really used by anyone. So it should be safe to remove it.
Directly using Go's time.AfterFunc() from lua is tricky. First, it
requires the lua timer callback to explicitly lock ulua.Lock to prevent
races. Second, it requires the lua timer callback to explicitly redraw
the screen if the callback changes the screen contents (see #2923).
So instead provide micro's own timer API which ensures both
synchronization and redrawing on its own, instead of leaving this burden
to lua code. In fact, its implementation runs the lua timer callback in
the main micro's goroutine (i.e. from micro's perspective it is
synchronous, not asynchronous), so both redrawing and synchronization
are ensured automatically.
Fixes#2923
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
There is already a commented-out code in main() for enabling CPU
profiling of micro, which is often useful. Adjust it to allow enabling
it just by providing -profile flag on the command line, without
modifying and recompiling the code.
This commit introduces several improvements to the backup system.
* Backups are made every 8 seconds for buffers that have been modified
since the last backup.
* The `permbackup` option allows users to specify that backups should
be kept permanently.
* `The backupdir` option allows users to store backups in a custom
directory.
Fixes#1641Fixes#1536
Ref #1539 (removes possibility of race condition for backups)
If screen.Redraw() is called very quickly after a key or mouse event,
it may send the redraw event while micro is not waiting for it but
still processing the key or mouse event. Since drawChan is non-buffered
and at the same time non-blocking, this redraw event will be simply lost,
so the screen content will not be up-to-date.
If you run micro as `micro | cat` for example, micro will disallow
you from saving the file, and when you quit the buffer, the contents
will be sent to the pipe. This allows one to use micro as part of
an interactive unix pipeline.
Closes#1524
