alphapapa/org-protocol-capture-html

Strange emacs buffer instead of capture buffer

Opened this issue · 4 comments

novoid commented

Hi,

This issue was found in this issue of another project and moved to here in order to let it be found by others as well.

Hard to find a good title for my issue. Please rename it if there is a more suitable one.

I'm on Windows 10 with Emacs 26.0.90 and Org 9.1.6 (=most current git/maint).

When I invoke the org-protocol javascript bookmarklet on a web page (not an empty tab or the about page of Firefox), I get an open new Emacs buffer for c:/Program Files (x86)/Mozilla Firefox/org-protocol:/capture-html/?template=l&url=about%%3Ablank&title=%%5Buntitled%%20page%%5D&body=

Mysterious to me 😉

Not only that there is "about:" in the URL and so forth, there is no body. The basic communication from Firefox to Emacs seems to work though.

What should I check?

alphapapa commented

Hi Karl,

I don't know what's going on here. There are potentially 2 or 3 issues here rather than just one:

  1. You're on Windows. I've never attempted to use org-protocol on Windows, so I don't know what needs to be done to configure it differently from on Linux, if anything.
  2. The c:/Program Files... path before the org-protocol:/ part of the URL is strange. This may be related to configuring it on Windows, or maybe a Firefox issue.
  3. The bookmarklet doesn't appear to be working correctly since it's not passing the page title, URL, etc. Firefox has undergone a lot of changes recently, and it wouldn't surprise me if something they did (e.g. e10s-related) broke the bookmarklet. I'd suggest checking the Mozilla bug tracker for bookmarklet-related bug reports, or filing one if necessary.

I'm sorry I can't offer more help than that. Please feel free to use this issue to report any solutions you may find. We can update the readme if necessary. Thanks.

novoid commented

Thanks for your insight.

org-protocol on Windows has no priority to me for now but I'll invest some spare time to debug the issue.

Meanwhile, maybe some other person has some input on this issue ...

Deleted user commented

In case it helps anybody, a small change got it working for me.

klausgena commented

I had exactly the same issue, but with another capture extension (Emacs on Windows, with Chrome). The old link system works, the new creates a buffer with the name of the link. So it's not a Pandoc problem.

But I found a solution (for Chrome and in Windows): using /// slashes instead of // in the address (org-protocol:///...) opens the capture template correctly, with the new link style.

I tried it out in the address bar. Now I will have to change the script in the extension accordingly.

  • 👍1