Built-in plugins don't have repo.json and never will, there is no point
in checking if they have one, this only results in code duplication and
dead code.
According to the documentation, micro reads plugin info from the
`repo.json` file in the plugin's directory. In reality, micro reads
plugin info from each and every `*.json` file in the plugin's directory,
not only from `repo.json` (so if there are multiple json files, each
next one overrides info read from the previous one). Fix this absurdity.
A .json file in a plugin directory that decodes to an empty list (`[]`
or `null`) made NewPluginInfo index info[0] on an empty slice. The panic
happens in InitPlugins(), before the recover() in main(), and the
deferred exit(0) ends micro silently with status 0 on every start.
A file whose first entry has no Name did not crash, but it replaced the
plugin name with an empty string, so the plugin was dropped as "not a
plugin".
Return the existing ErrMissingName in both cases. InitPlugins() already
skips files that fail to parse, so the plugin keeps its directory name.
PR #4028 moved the check for autocomplete from action autocomplete to
the buffer one, which caused a few regression for upstream callers
(commandbar autocomplete & plugins that use buffer autocomplete)
that use the buffer autocomplete.
This commit restores pre #4028 behavior by adding a callback variant
for buffer autocomplete functions while keeping the multi-cursor
autocomplete function.
Fixing resize split can cause crashes when node is root.
"Regression" of #3983 where ResizeSplit() assumed that the root node
always has a single child which aligns to the previous behavior
Using file complete for the save command. This is useful when trying to
save as a different file or simply auto complete the directories you
want to save to
Otherwise we can't identify if we have the same file open multiple times via
different symlinks.
The test must be adapted to resolve symlinks in `findBuffer()`.
Otherwise we unnecessarily serialize the shared buffer every time when closing
a bufpane with this buffer, so every such serialize overwrites the previous one,
thus only the last serialize (when closing the last instance of the buffer, i.e.
when actually closing the file, i.e. when the buffer is not shared anymore) will
be used anyway.
Verify the sudo command is available via exec.LookPath() before
creating the backup in safeWrite(). This avoids bogus backup files
when the sudo binary is not found.
Signed-off-by: Nilton Perim Neto <[email protected]>
When saving a protected file, micro spawned two sudo dd subprocesses
concurrently: a truncation dd and a write dd. Both competed for the
TTY to prompt for the sudo password, racing on TCGETS2/TCSETS2 ioctls
and deadlocking stdin routing. This strictly fails with sudo-rs, which
enforces auditable escalation boundaries.
Fix by removing notrunc and the separate truncation subprocess entirely.
A single dd subprocess now handles truncation and write in one shot,
making the race impossible by construction. The conv=fsync guarantee is
preserved on platforms that support it.
Move writeBackup() before openFile() in safeWrite() for the sudo path
so the backup always exists before dd truncates the file. If openFile()
fails after the backup is created, return OverwriteError so the user
knows their data is safe in the backup. The non-sudo path is unchanged.
Link: https://github.com/micro-editor/micro/issues/4050
Signed-off-by: Nilton Perim Neto <[email protected]>
Map-typed values in the parsedSettings map do not represent settings for
individual options, they represent maps of settings for multiple options for
the given glob or ft: pattern, and their keys are not option names, they are
glob and ft: patterns. So do not expose them to the callers of ParsedSettings(),
to prevent the callers from mistakenly treating those patterns as option names,
with unpredicted consequences.
Co-authored-by: Dmytro Maluka <[email protected]>
Micro always saves the undo stack information into the serialized buffer
file as long as either `saveundo` or `savecursor` is enabled. Whereas in
the case when only `savecursor` is enabled, while `saveundo` is
disabled, this information is not used afterwards, so it only wastes the
disk space in `~/.config/micro/buffers`. (And given that currently micro
never automatically removes any serialized buffer files, it may
significantly contribute to the overall ever growing size of the
`~/.config/micro/buffers` directory.)
So avoid saving the undo info if `saveundo` is disabled. This makes the
size of each serialized buffer file with savecursor=on saveundo=off
small and predictable, e.g. around 600 bytes in my observations (whereas
without this fix, it may grow indefinitely big, depending on the number
of modifications the user made before saving the file).
Micro doesn't support chained actions for command mode keybindings yet,
it only supports them for regular buffer keybindings. Whereas Ctrl-c and
Ctrl-x are bound by default to the chained actions Copy|CopyLine and
Cut|CutLine in both buffer mode and command mode, so in command mode
Ctrl-c and Ctrl-x don't work at all (with default keybindings).
Luckily CopyLine and CutLine would not be not very useful in command
mode anyway. So fix the issue by changing the default keybindings in
command mode to the simple non-chained actions Copy and Cut.
"Split(args[0])" has been performed since "open" was added[1], but it
may had been left by accident. It's unlikely desired when using the
command prompt, and doesn't seem to have been added once to commands
such as "vsplit" [2] which were implemented days before.
[1]: 5825353f64
[2]: 541daf212e
* config: Don't hardcode the `fakecursor` under Windows console any longer
We just set the global default and allow the user to override it.
* help: Add a concrete note for the `fakecursor` option in the Windows Console
Dmytro Maluka