Reload all runtime files on SIGUSR1 - #4239
Open
SotoAugusto wants to merge 2 commits into
Open
SotoAugusto wants to merge 2 commits into
SotoAugusto wants to merge 2 commits into
Conversation
Expose the same reload that the `reload` command performs, so that it can be triggered from outside of a `BufPane`.
This allows external tools, e.g. desktop theme switchers, to apply a changed colorscheme or configuration to all running micro instances (`pkill -USR1 -x micro`), like kitty and helix already do. Unlike `config.Reload()` the full `reload` is used, since the former reinitializes the commands and bindings without rerunning the plugins, which loses e.g. the commands registered by plugins.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Right now, when a desktop theme switcher (matugen, Omarchy, etc.) rewrites a colorscheme, micro instances that are already open keep the old colors until you run
reloadin each one. This came up in #3736 (now #4197), where SIGUSR1 was suggested because kitty uses it. Helix does the same thing for:config-reload.With this PR, micro on Unix-like systems runs the same reload as the
reloadcommand when it getsSIGUSR1:Changes:
action.Reload()exposes the reload thatReloadCmdalready does.cmd/micro: SIGUSR1 goes into its own channel and is handled in theDoEvent()select loop, so the reload runs on the main loop and the next iteration redraws. The signal setup lives in build-tagged files (signal_posix.go/signal_other.go), following the same split asactions_posix.go/actions_other.go. Windows and plan9 get a no-op.help/commands.mddocuments it next toreload.I used the full
reloadon purpose instead ofconfig.Reload().config.Reload()re-runsInitCommands()/InitBindings()without re-running plugins, so it loses commands registered by plugins. For example, afterconfig.Reload(),> commentfails withUnknown command. That matches the "other plugins don't really work" report in #4197. That's a separate bug, and I can open an issue for it if you want.Testing (Linux, in a pty with
COLORTERM=truecolor):color-link defaultfrom#ff0000to#00ff00and sentSIGUSR1. The running instance redrew with38;2;0;255;0and kept running. On master nothing changes.commentcommand still works after the signal.go test ./cmd/micro ./internal/...passes. It cross-builds for windows, darwin, freebsd and openbsd.About the signal choice: #1888 asks for SIGUSR1 to trigger a save. I went with SIGUSR1 to match kitty and Helix. If you'd rather keep it for #1888, switching this to SIGUSR2 is a one-line change.