Pre-release 1.3 with plugin support is now available! (Updated 31/10/20)

Please provide an ENEX file to replicate the issue.

I plan on doing that, but since I have personal information in the large .enex files, I'm trying to determine the specific notes that are triggering the issue, allowing me to create an .enex containing only those notes.

However, the information on debugging the command line app here: is not working as I would expect.

joplin --debug --log-level debug import filename.enex

is not adding any additional debug information in $HOME/.config/joplin/log.txt

I can't find anything in log-database.txt that lets me correlate the error to a specific note. Do you have any suggestions?


The error you've posted above is already good enough, but it's even better if I can replicate with an ENEX, then it's much easier to find a fix. So indeed if you can narrow it down to a few notes that you can share that would be perfect. You can also send them by PM if you prefer.

Some combinations of modifier keys can't be assigned via the UI keyboard shortcut editor:



You can use them in the json file, but not via the UI.

@laurent shall I open a gh issue for this ^^^ or is above post enough?

I don't know how to fix this to be honest as I don't understand why the Option key wouldn't work. Perhaps @anjulalk would know something?

This is very strange. I have thoroughly tested the editor in macOS, and it worked fine. However it was a virtualized instance, and I used the accessibility keyboard for sending key presses as I don't have access to a Mac.

Let me look into this issue. I don't know what's causing the issue at the moment, but I'll try to give a fix as soon as possible.


No I think that's reasonable, I thought about something like this too, and the underlying component is made with that in mind. The layout in particular can be saved/loaded from JSON if needed.

The problem indeed is how to create a UI that can be developed relatively easily. Drag and drop is often messy to implement so I'd favour a solution without it but not sure what.

Version 1.3.11 is now available:

  • Improved: Make sure all commands appear in keymap editor
  • Fixed: Add history backward and forward commands to keymap and menus (#4010)
  • Fixed: Fixed handling of Option key for shortcuts in macOS
  • Security: Remove "link" and "meta" tags from notes to prevent XSS
1 Like

That would be great. I didn't think you thought so, too.
I understand the drag and drop problem.

Initially, you could let users edit the layout directly in the JSON file. So Joplin would read this "layout-desktop.json" only once at startup. This is not for "standard" users, but if they can currently install a plugin, they should also be able to edit the JSON file.

Later it might be possible to implement an UI (whatever that might look like) in the options view to define the layout graphically. From which the JSON file is written then.

A little bit of beta-testing

Windows 10 Pro x64
Joplin 1.3.11 Portable

  • Placing a plugin in a plugins folder in the profile directory (\plugins\SideBarToggle.js) works.
    Moving the plugin to a sub-directory of the plugins folder in the profile directory (\plugins\SideBarToggle\SideBarToggle.js) does not.
    Previous post indicates that the plugin in the sub-directory should be loaded.
    Joplin was restarted after every change.

  • Keyboard shortcuts settings page appears to have two entries for rename (Rename Folder & Rename Tag?)

1 Like

Right, the doc wasn't clear. If it's in a sub-directory, Joplin expects a certain structure, as built by the yo plugin command, but if it's a single JS file it can be name anything. So the rule is actually:

The plugin service will look at the following locations:

  • plugins/(PLUGIN_ID).js
  • plugins/(PLUGIN_ID)/index.js
  • plugins/(PLUGIN_ID)/dist/index.js
  • Any directory or file that starts with "_" will be excluded (convenient to quickly disable a plugin)

PLUGIN_ID can be any string but it must be unique.

Thanks, for now these two commands will have to be removed anyway because they don't appear in the main menu (only commands in that menu can have a shortcut associated with them).

Unfortunately the fix (using the KeyCode) had a side effect, which makes it even less usable now.

If you press

  • option+cmd the following appears in the field: Option+Cmd+[
  • Cmd+Left (for the history back operation), the following appears in the field: Cmd+%
    The are not only shown like this, they are registered a such. So Cmd+Left wouldn't do anything. To use the shortvut to go back I have to press Cmd+Shift+5 (shift 5 is % on the US keyboard)

Some other keys can't be assigned anymore. e.g. the backtick.

I'm trying to debug this, but there's no debug output in that code, so it's hard....

I think I found a way to make this work. The problem is that fromCharCode returns incorrect characters.
I know how to fix this, but it will take a while to get it right. I have a few other things to do this weekend, but I should be able to get it done.

Here's the fix:

Version 1.3.15 is now available. I expect this will be the final release for 1.3 although there's still one issue with the keymap editor on macOS but it's difficult to fix so will be in 1.4

  • Improved: Remove from keymap editor commands that cannot be associated with a shortcut
  • Regression: Reverted keymap Option fix as it was making problem worse


I'm going back to previous posts to see what plugin features could be implemented, and I haven't answered this one. I believe that should already be possible using the data API, by setting the order property of the note. Then you could create two commands that grabs the currently selected note and move it up or down.

And finally you would associate these commands with menu items, which will allow you to se a keyboard shortcut. If you decide to give it a try and need some info, let me know.

Thanks for your answer and the tip. I will definitely give it a try :+1:
If I have any problems or questions, I will get back to you. But then rather in a new thread I think.

Thanks again.