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 <dmitrymaluka@gmail.com>
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 <dmitrymaluka@gmail.com>
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.
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 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.
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#3172
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 #3218), the first suggested filetype is this empty string.
* 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 <dmitrymaluka@gmail.com>
---------
Co-authored-by: Dmytro Maluka <dmitrymaluka@gmail.com>
* Revert "Don't expose Go timers directly to lua"
This reverts commit 4ffc2206ee.
Reason for revert: some plugins happen to use raw Go timers via
time.AfterFunc(), in an unsafe way (without synchronizing their
async code with micro). Let them keep doing that for now, in an
unsafe way but at least without immediate crashes.
Fixes#3209
* Add TODO about Go timers deprecation
`unknown` is a valid value for the `filetype` option (and executing
`set filetype unknown` does what is expected: it forces filetype
autodetection). So let's add `unknown` to the autocomplete suggestions
for `filetype`, along with actual filetypes.
The section says that users may use their own .hdr files for their own
custom syntax files, which is simply not true.
As a matter of fact, .hdr files are an implementation detail that
doesn't need to be mentioned in the user documentation.
Turning `header` patterns into `signature` patterns in all syntax files
was a mistake. The two are different things. In almost all syntax files
those patterns are things like shebangs or <?xml ... ?> or
<!DOCTYPE html5> i.e. things that:
1. can be (and should be) used for detecting the filetype when there is
no `filename` match (and that is actually the purpose of those
patterns, so it's a regression that it doesn't work anymore).
2. should only occur in the first line of the file, not in the first
100 lines or so.
In other words, the old `header` semantics was exactly what was needed
for those filetypes, while the new `signature` semantics makes little
sense for them.
So replace `signature` back with `header` in most syntax files. Keep
`signature` only in C++ and Objective-C syntax files, for which it was
actually introduced.
Replacing header patterns with signature patterns was a mistake, since
both are quite different from each other, and both have their uses. In
fact, this caused a serious regression: for such files as shell scripts
without *.sh extension but with #!/bin/sh inside, filetype detection
does not work at all anymore.
Since both header and signature patterns are useful, reintroduce support
for header patterns while keeping support for signature patterns as well
and make both work nicely together.
Also, unlike in the old implementation (before signatures were
introduced), ensure that filename matches take precedence over header
matches, i.e. if there is at least one filename match found, all header
matches are ignored. This makes the behavior more deterministic and
prevents previously observed issues like #2894 and #3054: wrongly
detected filetypes caused by some overly general header patterns.
Precisely, the new behavior is:
1. if there is at least one filename match, use filename matches only
2. if there are no filename matches, use header matches
3. in both cases, try to use signatures to find the best match among
multiple filename or header matches
Replacing header patterns with signature patterns was a mistake, since
both have their own uses. So restore support for header regex, while
keeping support for signature regex as well.
The original meaning of foundDef was: "we already found the final syntax
definition in a user's custom syntax file". After introducing signatures
its meaning became: "we found some potential syntax definition in a
user's custom syntax file, but we don't know yet if it's the final one".
This makes the code confusing and actually buggy.
At least one bug is that if we found some potential filename matches in
the user's custom syntax files, we don't search for more matches in the
built-in syntax files. Which is wrong: we should keep searching for as
many potential matches as possible, in both user's and built-in syntax
files, to select the best one among them.
Fix that by restoring the original meaning of foundDef and updating the
logic accordingly.
* 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.
* help: Exchange all indentations to spaces and remove trailing ws
* Add some missing `` marks
Co-authored-by: Jöran Karl <3951388+JoeKar@users.noreply.github.com>
* help: Generalize indentation levels
* help: Some small visual changes
- removed some superfluous whitespaces
- add a line break in before an link
- corrected one typo
---------
Co-authored-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
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.
