From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2A3WFv176F/YegAA0tVLHw (envelope-from ) for ; Sun, 27 Dec 2020 12:20:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id AJO0Ev176F9STgAA1q6Kng (envelope-from ) for ; Sun, 27 Dec 2020 12:20:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9F476940149 for ; Sun, 27 Dec 2020 12:20:12 +0000 (UTC) Received: from localhost ([::1]:49462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktV1u-0002d4-JM for larch@yhetil.org; Sun, 27 Dec 2020 07:20:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktV0U-0002cp-VG for emacs-orgmode@gnu.org; Sun, 27 Dec 2020 07:18:46 -0500 Received: from ciao.gmane.io ([116.202.254.214]:37596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktV0T-0001B5-94 for emacs-orgmode@gnu.org; Sun, 27 Dec 2020 07:18:42 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ktV0Q-0006ss-69 for emacs-orgmode@gnu.org; Sun, 27 Dec 2020 13:18:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Maxim Nikulin Subject: Re: Yet another browser extension for capturing notes - LinkRemark Date: Sun, 27 Dec 2020 19:18:32 +0700 Message-ID: References: <87v9cqx91l.fsf@localhost> <87sg7spthm.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <87sg7spthm.fsf@localhost> Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.619, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.72 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 9F476940149 X-Spam-Score: -1.72 X-Migadu-Scanner: scn1.migadu.com X-TUID: BxS7mhaazy5P On 26/12/2020 20:49, Ihor Radchenko wrote: > Maxim Nikulin 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: > > * [] () 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.