External Editor Problem

Support
1

Operating system

Linux

Joplin version

2.19.20

Editor

Markdown Editor

What issue do you have?

Running 2.19.20 from the appimage on Manjaro XFCE (updated to current) on a Nitro 50 computer. I have been running Joplin in this config for years, and have never had a problem.
Now, however, I cannot open the external editor. Both the menu and Ctrl-E give no response. No error message of any kind.
Troubleshooting steps:
Tried several different markdown editors, including Ghostwriter and Retext, both installed on my system, rebooting Joplin after each change.
Removed and reinstalled the appimage, updating to 2.19.20 in the process. I was previously running 2.19.19.
Ensured permissions correct on external editor apps. The editor apps themselves open markdown files with no issues.
Rebooted system after new appimage install.
Running a LTS kernel, 6.6, no change in that.

Any suggestions, said he, hopefully?

2

Can you try:

xdg-open https://google.com

in the terminal and let us know if it works and any errors it happens to produce.

3

Thanks for your response.

Just tried it. Worked, took me straight to Google. No errors.

4

That's strange then, I believe Electron just calls xdg-open and there's not much more to it than that; I'm curious, could you try extracting the AppImage to expose the raw Joplin binary and invoke the binary directly; just incase the AppImage itself is changing your environment ever so slightly that might be causing this.

There's a handy script here that might help; Extracting appimage to improve io/cpu startup performance - it's unsupported because the majority of people won't be doing it, but it's not risky in the sense of data loss, just the potential weird edge case issues. It would be interesting though if the discussion in that thread is the root cause of your problem here, i.e, I'm suspicious the AppImage changing the $XDG_DATA_DIRS could be related.

1 Like
5

Thanks for the suggestion. I'll try it and get back to you.
Nice to know that it's an edge case problem, not me being silly.

6

James:
I tried it. The script downloaded the latest appimage and put it in the .joplin file it created. Nice safety precaution, appreciated. It didn't put the shortcut on the desktop as I believe, reading the script, it would normally do.

I went into the .joplin file and ran StartApp from the terminal. It did run, but this error showed in the terminal.

./AppRun
Sentry: Initialized with autoUploadCrashDumps: false
[16485:0406/070426.058558:ERROR:object_proxy.cc(590)] Failed to call method: org.freedesktop.portal.Settings.Read: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
libva error: vaGetDriverNames() failed with unknown libva error

That's where I'm at.

Lee

7

James:
Further update, whether this is valid or has anything to do with the problem, I have no idea. I tried xdg-open ghostwriter and got an error.

Unable to detect the URI-scheme of "ghostwriter".

Lee

8

James:

Thanks for the help, you pointed me in the right direction. If I put in the entire path of the app binary, such as /usr/bin/ghostwriter, it works.

1 Like
9

Hi,

Sorry about that; I've suddenly come down with 2 different illnesses at once that have been plaguing me with brain fog for the past 2 weeks now, add in some turbulance with my IT setup recently and I didn't even see a response via email :(.

What I think is going on in your case is that if you were to do e.g:

touch ~/test.md
xdg-open ~/test.md

You'd possibly find that .MD files don't open via xdg-open. That's effectively the behaviour that must have been going on before you explicitly set Ghostscript as a the explicit external editor.

What I should have checked earlier is whether the buttons such as "Open Profile Directory" work in the app, because these too use xdg-open. If they did work, it'd have hinted that it's specifically MD files sooner.

I'm not 100% sure with how xdg-open actually identifies the applications to use, and it'll likely vary based on distribution to some extent. If I had to guess, it might be that the Ghostwriter you have installed hasn't registered .md file format support in it's .desktop entry (the file that adds it to the start menu). It could be trivial to override this on your end since there's a well supported user-override directory for it (~/.local/share/applications), and it's possible that if you explicitly stated it, and xdg-open picked up on it, the problem would go away without having to manually ghostwriter in Joplin, as well as potentially other apps.

Of course, there's no real downside to manually specifying it, presuming the rest of xdg-open is working in Joplin as expected, which it looks like it is.

If you do fancy trying the .desktop override let me know, otherwise I'll assume you're happy to have it working properly :).

@graphit0 reading Lee's comments above, I'd noticed he'd used the /AppRun binary; given I do the snap I avoid that binary entirely and forgot it actually existed, I.E, the snap just calls the joplin-desktop/@joplinapp-desktop binary directly, since it sets up its own environment variables.

What this means for your script is that, if you were using ./AppRun rather than joplin-desktop/@joplinapp-desktop, you'd probably be getting the environment wrapper that gets used without extraction anyway, keeping your script feature-for-feature (or bug-for-bug) identical, in which case my concerns in the other thread become moot. You get the CPU and IO gains (in exchange for some disk space) but shouldn't have any real bugs, assuming it works how I'd guess it would.

1 Like
10

Thanks for all your help. I was able to figure it out, and it was simple once I was pointed in the right direction. I had to specify the path to the binary, then it works.

Lee