Re: Yet another browser extension for capturing notes - LinkRemark

[Maxim Nikulin <manikulin@gmail.com>]

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.