emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Yet another browser extension for capturing notes - LinkRemark
Date: Sun, 27 Dec 2020 19:18:32 +0700	[thread overview]
Message-ID: <rs9u2p$pff$1@ciao.gmane.io> (raw)
In-Reply-To: <87sg7spthm.fsf@localhost>

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	other threads:[~2020-12-27 12:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-25 12:44 Yet another browser extension for capturing notes - LinkRemark Maxim Nikulin
2020-12-25 14:19 ` Ihor Radchenko
2020-12-26 11:49   ` Maxim Nikulin
2020-12-26 13:49     ` Ihor Radchenko
2020-12-27 12:18       ` Maxim Nikulin [this message]
2021-11-18 17:01       ` LinkRemark Firefox extension approved for addons.mozilla.org Max Nikulin
2020-12-25 14:26 ` Yet another browser extension for capturing notes - LinkRemark Russell Adams
2020-12-25 22:11   ` Samuel Wales
2020-12-26  9:16     ` Maxim Nikulin
2022-01-17  2:29       ` Samuel Wales
2022-01-18  1:03         ` Samuel Wales
2022-01-18  5:43           ` Samuel Banya
2022-01-18 10:57             ` Max Nikulin
2022-01-18 10:34         ` Max Nikulin
2022-01-19  3:28           ` Ihor Radchenko
2022-01-19  8:45             ` András Simonyi
2022-01-19 10:00               ` Ihor Radchenko
2022-01-19 10:58                 ` András Simonyi
2022-01-19 11:42                   ` Ihor Radchenko
2022-01-20  0:23             ` Samuel Wales
2022-01-20 12:16               ` Org mode and firefox tabs (feature request) Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='rs9u2p$pff$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).