org-protocol not responding

Question

Description

I use org-capture extension which had been working great for about 6 months.

I have trouble making org-protocol work from Firefox since 8/1/19. When hitting the extension button in FF, the page is captured (I got a gray background with "captured" message) but nothing happens in Emacs. This used to work fine until then.

I run Emacs 27.0.50 on Ubuntu 16.04 with org-mode 9.2.5 (and Firefox 68.0.1).

Diagnosis

1. My org-protocol config in init:

(require 'org-protocol) ; call for org-protocol
(server-start)
(add-to-list 'load-path "~/.local/share/applications/org-protocol.desktop/") ;path to org-protocol

My org-protocol.desktop file is set and mimeinfo.cache is up to date.

2. My org-capture-templates have not been edited and other templates (not called through the FF extension) work fine. The templates used by org-protocol are:

("L" "Web link" entry (file+headline org-default-notes-file "Web")
 "** [%:description]%? \nSource: [[%:link][%:description]] \nCaptured: %U")
("p" "Web quote" entry (file+headline org-default-notes-file "Web")
 "** [%:description]%? \nSource: [[%:link][%:description]] \nCaptured: %U \n#+BEGIN_QUOTE\n%i\n#+END_QUOTE")

3. The FF extension runs well and sends capture instructions (the grey background ie 2nd snapshot on org-capture extension) according to FF console:

[1]

Capturing the following URI with new org-protocol:  org-protocol://capture?template=p&url=http%3A%2F%2Fwww.mediaonfire.com%2Fblog%2F2017_07_21_org_protocol_firefox.html&title=Firefox%20and%20org-protocol%20URL%20Capture&body=emacsclient%20-n%20%22org-protocol%3A%2F%2F%2Fcapture%3Furl%3Dhttp%253a%252f%252fduckduckgo%252ecom%26title%3DDuckDuckGo%22

4. Org-protocol executes neatly on my other latptop running Emacs 24 (from Ubuntu repo) with similar config.

5. Conclusion

I'm having a hard time trying to understand what the problem is. I found some inspiration on this page and tried to run the test suggested. Adapted to my config, the test is:

[2]

emacs-snapshot "org-protocol://capture?template=p&url=http%3A%2F%2Fwww.mediaonfire.com%2Fblog%2F2017_07_21_org_protocol_firefox.html&title=Firefox%20and%20org-protocol%20URL%20Capture&body=emacsclient%20-n%20%22org-protocol%3A%2F%2F%2Fcapture%3Furl%3Dhttp%253a%252f%252fduckduckgo%252ecom%26title%3DDuckDuckGo%22"

with [1] object.

When Emacs is closed, a frame opens with an empty buffer with mini-buffer saying file is write protected.

I think this test drives me in the right direction to solve my problem but maybe this has nothing to do with that.

Answer 1

Here is how I solved my problem.

I clarified my understanding of emacs-snapshot vs emacsclient according to the manual here and here.

When running [2] (see question), nothing would happen in current Emacs frame (same as when hitting the extension button in FF).

I then tried the same command replacing emacs-snapshot by emacsclient: I got the message emacsclient: can't find socket; have you started the server? although server-start is set in my init.

In the mean time, I realized I had made some clean up on my init and was wondering I might have messed up org-protocol set up. No problem on this side since org-protocol runs smoothly on laptop B with the same init.el. Laptop B runs same org version in different Emacs (Emacs 25.2.2, Org 9.2.5 on Ubuntu 18.04 with FF 68.0.2).

I thought I should try with the same Emacs version on two laptops. I checked how different were my Emacs install on laptops A vs B which made me realize I had both emacs24 and emacs-snapshot installed on laptop A. I first removed emacs24 (I always run emacs-snapshot) and HURRAY! connection between FF extension and emacs-snapshot through MIME is back.

The verbose command speaks for itself:

:~$ sudo apt autoremove emacs24 Lecture des listes de paquets... Fait Construction de l'arbre des dépendances
Lecture des informations d'état... Fait Les paquets suivants seront ENLEVÉS : emacs24 emacs24-bin-common emacs24-common emacs24-common-non-dfsg emacs24-el 0 mis à jour, 0 nouvellement installés, 5 à enlever et 0 non mis à jour. Après cette opération, 104 Mo d'espace disque seront libérés. Souhaitez-vous continuer ? [O/n] (Lecture de la base de données... 458358 fichiers et répertoires déjà installés.) Suppression de emacs24 (24.5+1-6ubuntu1.1) ... update-alternatives: utilisation de « /usr/bin/emacs-snapshot » pour fournir « /usr/bin/emacs » (emacs) en mode automatique Remove latex-cjk-thai for emacs24 remove/latex-cjk-thai: purging byte-compiled files for emacs24 Remove dictionaries-common for emacs24 remove/dictionaries-common: Purging byte-compiled files for flavour emacs24 Remove latex-cjk-common for emacs24 remove/latex-cjk-common: purging byte-compiled files for emacs24 Remove emacsen-common for emacs24 emacsen-common: Handling removal of emacsen flavor emacs24 Suppression de emacs24-bin-common (24.5+1-6ubuntu1.1) ... update-alternatives: utilisation de « /usr/bin/ctags-snapshot » pour fournir « /usr/bin/ctags » (ctags) en mode automatique update-alternatives: utilisation de « /usr/bin/ebrowse-snapshot » pour fournir « /usr/bin/ebrowse » (ebrowse) en mode automatique update-alternatives: utilisation de « /usr/bin/emacsclient-snapshot » pour fournir « /usr/bin/emacsclient » (emacsclient) en mode automatique update-alternatives: utilisation de « /usr/bin/etags-snapshot » pour fournir « /usr/bin/etags » (etags) en mode automatique Suppression de emacs24-el (24.5+1-6ubuntu1.1) ... Suppression de emacs24-common (24.5+1-6ubuntu1.1) ... Suppression de emacs24-common-non-dfsg (24.4+1-2) ... Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) ... Traitement des actions différées (« triggers ») pour desktop-file-utils (0.22-1ubuntu5.2) ... Traitement des actions différées (« triggers ») pour gnome-menus (3.13.3-6ubuntu3.1) ... Traitement des actions différées (« triggers ») pour mime-support (3.59ubuntu1) ... Traitement des actions différées (« triggers ») pour hicolor-icon-theme (0.15-0ubuntu1.1) ... Traitement des actions différées (« triggers ») pour install-info (6.1.0.dfsg.1-5) ... :~$

That does not explain though why this would have worked great for 6 months.

Here some r/emacs threads that I found inspirational and helped me to solve my (stupid yet annoying) problem.

https://www.reddit.com/r/emacs/comments/3hvmka/making_use_of_orgprotocol_to_have_a_bookmarking/

https://www.reddit.com/r/emacs/comments/bi2lwp/does_emacs_have_the_capability_of_capturing/

https://www.reddit.com/r/emacs/comments/cnzj7d/org_mode_update_broke_orgcapture/

https://www.reddit.com/r/emacs/comments/ai7hf0/does_anyone_here_still_use_orgprotocol/

https://www.reddit.com/r/orgmode/comments/akazos/orggrasp_browser_extension_for_orgcapture/

Answer 2

I recently ran into this problem while using Brave, and what worked for me was making a small change to ~/.local/share/applications/org-protocol.desktop.

[Desktop Entry]
Name=org-protocol
Exec=emacsclient -n %u
Type=Application
Terminal=false
Categories=System;
MimeType=x-scheme-handler/org-protocol;

emacsclient -n %u

The change was to use emacsclient -n %u. The original example from sprig/org-capture-extension did not use -n, but when I added it, org-capture-extension started working reliably again. The -n makes emacsclient immediately return, and that seemed to help.

Prior to this, it had worked fine for years without the -n. I don't know if the breakage was Brave's fault or org-mode's fault, but at least it works for me again. Maybe this will help someone deal with this mysterious problem.