Open TomBener opened 1 year ago
Weird issue, I think you can try to change the key binding to another one in the settings file.
Hi @vipzhicheng for what it's worth I wonder if there is a problem with the way the vim shortcuts plugin is exposing the names of it's shortcuts to logseq. I installed a plugin recently that has a conflict with @sawhney17 's sawhney17/logseq-go-now plugin and with your plugin. If you look at the error messages it seems that somehow his plugin is announcing itself in a way that I know which plugin to adjust if needed:
From the screenshot, the conflicting plugin should be the gpt3-openai, not vim shortcuts.
Hi. You are right that the conflict is with the gpt3-openai shortcut. But, a conflict is generally between two plugins (or one plugin and logseq itself I guess). For example in the first error we can see that the both the gpt3-openai plugin and the go-home-now plugin are both trying to map mod_g meta+g to something. Its a conflict so as a logseq user I have to choose how to handle it (for example I could uninstall one of the plugins or go into one of the plugins settings and change it).
In the second warning I can see that the gpt3-openai plugin has a conflict with the mod_j meta+j key but I can't see the name of the other plugin that has that key mapped to something. In this case I know it is the vim shortcuts plug because the warning goes away when I disabled the plugin and also when I modified logseq-vim-shortcuts.json to not map cmd+j cmd+j to exit insert mode.
My goal in posting this comment was to let you know that I think your plugin needs to do something so that it's name shows up in the shortcut conflict warning message. In other words that second warning should not say "Keyboard shortcut conflicts with existing shortcut: null" it should say "Keyboard shortcut conflicts with existing shortcut: plugin.logseq-plugin-vim-shortcuts". Of something like that.
Not sure if this is the problem but when I look in the package.json for the Go Home Now plugin, the logseq
section looks like this:
"name": "logseq-go-home-now",
"description": "Go home now!",
"logseq": {
"id": "logseq-go-home-now",
"title": "logseq-go-home-now",
"icon": "./icon.png"
},
So the logseq.title
field is the same as the name
, while the "friendly" name is in the description
field.
In yours it looks like this:
"name": "logseq-plugin-vim-shortcuts",
"logseq": {
"icon": "./icon.png",
"id": "logseq-plugin-vim-shortcuts",
"title": "Vim Shortcuts"
So your "friendly" name is in the logseq.title
field, and you do not have a description
field. Of course this could have nothing to do with where logseq looks for this info when its presenting the conflict warning! I'll ask in the plugins discord and mention you there.
Thanks for pointing me out, It's weird issue, I will take time to try, but not sure if I can find out.
Every time I launched Logseq, it prompted the warning message below:
I have checked the existing shortcuts, but none of them is
null
. How could I investigate the issue? Thanks!