Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to replace default (embedded) plugins? #3029

Closed
dustdfg opened this issue Nov 18, 2023 · 5 comments · Fixed by #3031
Closed

How to replace default (embedded) plugins? #3029

dustdfg opened this issue Nov 18, 2023 · 5 comments · Fixed by #3031

Comments

@dustdfg
Copy link
Contributor

dustdfg commented Nov 18, 2023

The runtime dir is embedded in the binary. The way to change the files from the runtime dir is to place them in loccal folder ~/.config/micro but it doesn't work for plugins...

To change the options of linter #1179 I tried to add the modified version of linter to the local config folder with my own flags to compiler (c++20 instead of c++14"). But it doesn't work. Now each time I open micro I see the following message:

linter:1: attempt to call a non-function object
stack traceback:
	linter:1: in main chunk
	[G]: ?

Press enter to continue

I even could accept the message if it works with new flags but it didn't really change anything. I still get the same errors like there is "c++14" flag...

Commit hash: Version: 2.0.11 (it doesn't show commit hash)
OS: Debian 12
Terminal: foot

@dustdfg dustdfg changed the title How to replace default (embedded) plugins How to replace default (embedded) plugins? Nov 18, 2023
@JoeKar
Copy link
Collaborator

JoeKar commented Nov 18, 2023

The PR #2962 addresses the c++14 standard too in form of removing it completely and leave it to the defaults used by g++ or gcc. Regarding the precedence of user define over builtin plugins I assume that we need to change rtfiles.go#L162.

dmaluka added a commit to dmaluka/micro that referenced this issue Nov 19, 2023
If ~/.config/micro/plug directory contains a plugin with the same name
as a built-in plugin, the expected behavior is that the user-defined
plugin in ~/.config/micro/plug is loaded instead of the built-in one.

Whereas the existing behavior is that the built-in plugin is used
instead of the user-defined one. Even worse, it is buggy: in this case
the plugin is registered twice, so its callbacks are executed twice
(e.g. with the autoclose plugin, a bracket is autoclosed with two
closing brackets instead of one).

Fix this by ensuring that if a plugin with the same name exists in the
~/.config/micro/plug directory, the built-in one is ignored.

Fixes zyedidia#3029
@dmaluka
Copy link
Collaborator

dmaluka commented Nov 19, 2023

Fix which makes user-defined plugins take precedence: #3031.

In fact you could use a workaround in the meantime: disable the linter plugin (set linter off or just manually add "linter": false to settings.json) and name your modified plugin with some other name e.g. linter2.

@dustdfg
Copy link
Contributor Author

dustdfg commented Nov 19, 2023

Fix which makes user-defined plugins take precedence: #3031.

In fact you could use a workaround in the meantime: disable the linter plugin (set linter off or just manually add "linter": false to settings.json) and name your modified plugin with some other name e.g. linter2.

It didn't help. I added "linter": false to settings.json and it really disabled linter but I can't enable custom.

Honestly, I am not sure that I did everything correctly because I don't know what does "rename" means...
I renamed:

  • linter folder to linter2
  • linter.lua to linter2.lua
  • linter to linter2 everywhere in the script

But it doesn't work... Is it renamed? Looks like yes because "error" message that I get is the same but instead of linter there is linter2:

linter2:1: attempt to call a non-function object
stack traceback:
...

@dmaluka
Copy link
Collaborator

dmaluka commented Nov 19, 2023

Just rename the folder, no need to rename anything inside it.

I've just tried it: copied runtime/plugins/linter/ directory as ~/.config/micro/plug/linter2 and removed the -std=c++14 flag from it, i.e. did literally only this modification:

--- src/micro/runtime/plugins/linter/linter.lua	2023-11-19 00:23:53.626805829 +0100
+++ .config/micro/plug/linter2/linter.lua	2023-11-19 13:55:51.151753371 +0100
@@ -66,7 +66,7 @@
     end
 
     makeLinter("gcc", "c", "gcc", {"-fsyntax-only", "-Wall", "-Wextra", "%f"}, "%f:%l:%c:.+: %m")
-    makeLinter("g++", "c++", "gcc", {"-fsyntax-only","-std=c++14", "-Wall", "-Wextra", "%f"}, "%f:%l:%c:.+: %m")
+    makeLinter("g++", "c++", "gcc", {"-fsyntax-only", "-Wall", "-Wextra", "%f"}, "%f:%l:%c:.+: %m")
     makeLinter("dmd", "d", "dmd", {"-color=off", "-o-", "-w", "-wi", "-c", "%f"}, "%f%(%l%):.+: %m")
     makeLinter("eslint", "javascript", "eslint", {"-f","compact","%f"}, "%f: line %l, col %c, %m")
     makeLinter("gobuild", "go", "go", {"build", "-o", devnull, "%d"}, "%f:%l:%c:? %m")

and it works as expected, I'm not getting linter:1: attempt to call a non-function object error.

Also if I change it to -std=c++17 or -std=c++20, it also works as expected. I'm not sure why are you getting this error. Could you double-check?

@dustdfg
Copy link
Contributor Author

dustdfg commented Nov 19, 2023

Yeah, sorry it is my mistake... And thanks a lot for the help

TL;DR

I used the old version of the file....

Full story:

As can be seen from this issue I created it after reading the #1179 issue. There was one comment #1179 (comment) in which someone embedded part of the config and it points to the old version of the config. It is obvious because github must show the same file even when master is changed... I didn't notice that it was old version and copied it.

Sorry for semi wrong report. It is strange because the problem I firstly reported was real (?) even though I experienced another problem...

zyedidia pushed a commit that referenced this issue Jan 17, 2024
…3031)

If ~/.config/micro/plug directory contains a plugin with the same name
as a built-in plugin, the expected behavior is that the user-defined
plugin in ~/.config/micro/plug is loaded instead of the built-in one.

Whereas the existing behavior is that the built-in plugin is used
instead of the user-defined one. Even worse, it is buggy: in this case
the plugin is registered twice, so its callbacks are executed twice
(e.g. with the autoclose plugin, a bracket is autoclosed with two
closing brackets instead of one).

Fix this by ensuring that if a plugin with the same name exists in the
~/.config/micro/plug directory, the built-in one is ignored.

Fixes #3029
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants