Test against workflow. #1
Merged
Conversation
This file contains 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
* help: Precise `goto` command documentation * command: Add `jump` to perform a relative `goto` * command: Refactor GotoCmd() and JumpCmd()
* Add missing <release> entries in metainfo file * Fix date * Fix release date
* infocomplete: Complete filetypes (follow-up) The first shot of the feature unfortunately completed the *.yaml file names instead of the included filetypes. This will be corrected with this follow up. * infocomplete: Correct comment of filetypeComplete according to review hint Co-authored-by: Dmytro Maluka <[email protected]> --------- Co-authored-by: Dmytro Maluka <[email protected]>
This typo causes a funny bug: the autodetected filetype for *.jsonnet files is an empty string instead of "jsonnet". Even funnier, when autocompleting "set filetype " (with the fix from PR zyedidia#3218), the first suggested filetype is this empty string.
To avoid surprises like with jsonnet.
Support crontab filetype detection in the case crontab is opened via sudoedit. Also apparently this fixes crontab filetype detection when it is opened normally via `crontab -e` but in MacOS. Fixes zyedidia#3172
Adding InitPlugins() to tests has caused noisy error logs when running
the buffer_test.go test (although the test result is still PASS):
2024/03/23 15:14:30 Plugin does not exist: autoclose at autoclose : &{autoclose autoclose <nil> [runtime/plugins/autoclose/autoclose.lua] false true}
2024/03/23 15:14:30 Plugin does not exist: comment at comment : &{comment comment <nil> [runtime/plugins/comment/comment.lua] false true}
2024/03/23 15:14:30 Plugin does not exist: diff at diff : &{diff diff <nil> [runtime/plugins/diff/diff.lua] false true}
2024/03/23 15:14:30 Plugin does not exist: ftoptions at ftoptions : &{ftoptions ftoptions <nil> [runtime/plugins/ftoptions/ftoptions.lua] false true}
...
These errors are caused simply by the fact that plugins are initialized
but not loaded. Adding config.LoadAllPlugins() to buffer_test.go "fixes"
this problem.
However, at the moment it doesn't seem a good idea to load plugins in
buffer_test.go, since buffer_test.go doesn't properly initialize Lua. It
only does ulua.L = lua.NewState() but doesn't do the other stuff that
init() in cmd/micro/initlua.go does. As a result, plugins will not be
able to do anything correctly.
So in order to initialize Lua correctly we need to be inside cmd/micro/,
so we cannot do it in buffer_test.go or any other tests except
micro_test.go.
When initializing runtime files (syntax files etc) in tests, initialize built-in runtime files only, to ensure that the tests are not affected by whatever is in ~/.config/micro/ on the test machine. micro_test.go already ensures that, by using its own temporary directory as an (empty) config directory. So we only need to fix buffer_test.go and rtfiles_test.go. In those tests, don't repeat the same dance with a temporary directory, instead just ignore the config directory.
Adding InitRuntimeFiles() to buffer_test.go has changed the behavior of this test: now it tests not just buffer editing per se, but also how well buffer editing works together with syntax highlighting (since InitRuntimeFiles() loads syntax files, and many of the test buffers match the json header pattern in the json.yaml syntax file, so they are "highlighted" as json). This revealed long existing races between buffer editing and syntax highlighting. Until we fix those races, temporarily disable InitRuntimeFiles() in this test.
Don't initialize plugins and user settings in tests
This is necessary as a preparation to introduce a lock for the whole LineArray. The modification can then be done without trying to lock the same lock twice. Co-authored-by: Dmytro Maluka <[email protected]>
...which isn't used so far and probably handled better in a different way.
This is achieved by the usage of the new `LineArray` locking machanism, which prevents the interruption in the moment of modifications like insertion or removal of lines. Co-authored-by: Dmytro Maluka <[email protected]>
...since we fixed the race between the syntax highlighting and the buffer editing.
buffer: Add proper lock mechanism to lock the full `LineArray` instead of single lines
Signed-off-by: lvyaoting <[email protected]>
Check if startline value is valid before passing it to input.State(), to prevent a theoretically possible race when the number of lines changes in the meantime, causing an out of bounds access. Actually this race cannot happen: ReHighlightStates() is only called from the main goroutine, and the line array is modified, again, only by the main goroutine. So for now this change is rather cosmetic: it is just to make the highligher API implementation self-sufficiently safe without assumptions about which goroutines are using which API functions and how.
…a#3178) * command: Prevent re-writing settings in case of local option * command: Refactor SetGlobalOptionNative() Co-authored-by: Dmitry Maluka <[email protected]> --------- Co-authored-by: Dmitry Maluka <[email protected]>
We should call the onSetActive callback not only when switching to another bufpane within the same tab but also when switching to another tab. Note on implementation details: - In SetActive() we need to check if the tab is not already active, to avoid calling onSetActive for an already active bufpane. - We cannot check that just by checking if the tab index passed to SetActive() is different from the current active tab index, since this index may remain the same even if the tab itself is different (in the case of removing a tab from the tablist). So we need to check the tab itself, not just the tab index. So we introduce the isActive field, to track the tab's active state in the Tab structure itself.
Currently onSetActive is called when the user clicks with the mouse on a pane even if this pane is already active. We should avoid calling it in this case. Implementation detail: like with tabs in the previous commit, we cannot check if the pane is already active just by checking the index passed to the Tab's SetActive() (since the index may not change while the pane itself changes), we need to check state of the pane itself. So we move the onSetActive invocation from the Tab's SetActive() to the BufPane's SetActive().
It is pane, not panel. Also, let's call it bufpane here, like we do in other callbacks' descriptions.
Cosmetic change: move onSetActive description to keep it together with other callbacks that are associated with bufpane, not with buffer.
…t array index. When adding a new `BufPane` it is always being inserted last into `MainTab().Panes`. This leads to a confusion when using the actions `PreviousSplit`, `NextSplit` as the previous/next split may not be the expected one. How to reproduce: - Launch micro and insert char "1" - Open a new vsplit via the command `vsplit` and insert "2" - Switch back to the left split (1) by using `PreviousSplit` - Again open a new vsplit via command: `vsplit` and type char "3" - Now switch between the 3 splits using `PreviousSplit`, `NextSplit` Switching from most left split to the most right, the expected order would be 1, 3, 2 but actually is 1, 2, 3.
Improve and unify `CopyLine`, `CutLine`, `DeleteLine`, `DuplicateLine` actions
Implemented new actions `FirstTab`, `LastTab`, `FirstSplit` and `LastSplit`
This will keep the symbol table and the DWARF information.
…x 64" It is kept for the next release only to support... https://github.com/benweissmann/getmic.ro/blob/f90870e948afab8be9ec40884050044b59ed5b7c/index.sh#L197-L204 ...and allow a fluent switch via: benweissmann/getmic.ro#40
Makefile: Make all builds explicitly fully static (disable CGO)
Created nftables syntax highlighting
When we are saving a file with sudo, if we interrupt sudo via Ctrl-c, it doesn't just kill sudo, it kills micro itself. The cause is the same as in the issue zyedidia#2612 for RunInteractiveShell() which was fixed by zyedidia#3357. So fix it the same way as in zyedidia#3357.
When saving a file with sudo fails (e.g. if we set `sucmd` to a non-existent binary, e.g. `set sucmd aaa`), we erroneously return success instead of the error, as a result we report to the user that that the file has been successfully saved. Fix it.
Fix SIGINT killing micro when saving with sudo
For downward compatibility the default split type for the `help` command is set to be `hsplit`.
action/command: Allow `-vsplit` & `-hsplit` as optional argument for `help` Additionally the help, vsplit and hsplit command can now open multiple files like the tab command.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.