[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Yet another browser extension for capturing notes - LinkRemark

From: Maxim Nikulin
Subject: Re: Yet another browser extension for capturing notes - LinkRemark
Date: Sun, 27 Dec 2020 19:18:32 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 26/12/2020 20:49, Ihor Radchenko wrote:
> Maxim Nikulin <manikulin@gmail.com> writes:

I have reordered some parts of discussion

Also, do you pass any of the parsed metadata to org-protocol? If you
do, it would be trivial to get it into capture templates on Elisp
(and org-capture-ref) side.

I decided that capture could be too complicated to fit into simple query parameters of org protocol, e.g. it could be a chain of frames. That is why I implemented just simple option title + body (url is available but it is contained in the body). I am considering generating of tree of headings in some cases.

On the other hand almost all captured data is available to native messaging backend https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging A dumb example is included into the sources. It is python, but you could use any other language. It is just streaming JSON with message size sent in binary form. I have added JSON-RPC to let native messaging host to report errors and to avoid ambiguity related to attribution of response to particular request. I do not think that setting up of org-protocol handler is harder than adding manifest for native messaging backend. It should be even a bit safer since some weird org-protocol message could not be placed behind an innocent link text.

I think it should be no problem to call emacs-client from such application. Isn't it enough for customization? Do you still need raw html? Currently I am trying to avoid customization inside the extensions since it is harder to keep history of settings changes in git. Extensions are quite isolated from host. Also I do not think that something like mustache/handlebars templates would be warmly welcomed by emacs users.

I do not have clear vision how to use collected data for queries.
Certainly I want to have more human-friendly representation than BibTeX
entries (maybe in addition to machine-parsable data) adjacent to my notes.

So far, I found author, website name, publication year, title, and
resource type useful. My standard capture template for links is:

* <Author> [<Website>] (<Year>) Title

I see that my current choice to prefer og:title or twitter:title for header is far from been optimal, even head/title text usually is better. However I was writing about a bit more detailed two or three-line representation. Often I prefer a kind of "card" representation to table/columns view.

Concerning queries, see below.

Completely agree here. That's why I directly reuse the current DOM state
from qutebrowser in my own setup. However, extension for qutebrowser was
easy to write for me as it can be simply a bash script. I know nothing
about Firefox/Chrome extensions and I do not know javascript.

It is too easy to underquote some variable reference in bash and to get executed something unexpected. Almost any other script language is safer in this sense.

  From my point of view, you should be happy with any of projects you
mentioned below. Are all of them have some problems critical for you?

They are all javascript, except one (unicontent), which can be easily
replaced with built-in Elisp libraries (dom.el).

I mean running them using a very thin wrapper that generates metadata in the form easily parsable in emacs.

Another idea would be providing a callback from elisp to browser (I am
not sure if it is possible). org-capture-ref has a mechanism to check if
the link was captured in the past. If the link is already captured, the
information about the link location and todo-state can be messaged back
to the browser.

Example message (only qutebrowser is supported now):

Bookmark not saved!
Already captured into org-capture-ref:TODO maxnikulin [Github] linkremark: 
LinkRemark - page or link notes with context

Why it should be a callback from elisp? From my point of view it is extension that should initiate a query if particular URL has been captured already. I have realized that in my drafts I even have a native messaging backend that could filter matched URLs from a text file. It was intended to autocomplete URLs typed in the browser location bar using text file as a kind of bookmark storage, but it could be adapted for checks similar to yours.

Though it is better to get link to the header with URL (e.g. CUSTOM_ID), so additional links or quotes could be added and linked to the "main" entry. I have not tried if such query using emacs-client is fast enough. I have seen a thread on Language Server Protocol but have not checked if that protocol supports such queries.

I especially like idea of references to existing headers because it allows to avoid cluttering context menus with options to capture link without page metadata in addition to existing ones.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]