From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 2MFqI2L9W2I/hAEAgWs5BA (envelope-from ) for ; Sun, 17 Apr 2022 13:43:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +CwoHGL9W2JxkwAAG6o9tA (envelope-from ) for ; Sun, 17 Apr 2022 13:43:30 +0200 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 17078196A2 for ; Sun, 17 Apr 2022 13:43:29 +0200 (CEST) Received: from localhost ([::1]:56762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ng3JQ-0001mr-RV for larch@yhetil.org; Sun, 17 Apr 2022 07:43:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ng3IT-0001mW-VR for emacs-orgmode@gnu.org; Sun, 17 Apr 2022 07:42:29 -0400 Received: from ciao.gmane.io ([116.202.254.214]:34868) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ng3IS-0007FQ-66 for emacs-orgmode@gnu.org; Sun, 17 Apr 2022 07:42:29 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ng3IP-0007JV-9Y for emacs-orgmode@gnu.org; Sun, 17 Apr 2022 13:42:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: What's the flow for adding info: links in Org documents? Date: Sun, 17 Apr 2022 18:42:17 +0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US In-Reply-To: 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: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 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=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 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-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650195810; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=0htbMHY/qG5DnZachVIkf+G+fRG9Xf6t5lgFZhT7uRQ=; b=NP4lk372jZoh3g2uLbriPO77VrxeKiLk6yAQ/Ia60iG6+3ARXOO0UzVgzIeD53xulPCngD XhBAVC9p2XevZ1v2H2HZtAq5uIY8cfdlZbtRYlpA0oyrxWZ3I9SSJbOqgLaFTrWqnoapsc mG7Ag4WAhMNCpGcLKRwX/0IR/m3EBd0o2csHUiyblbhy62iyV2CQLbMty9MBKJ2hkscQDy BvQLRRGSgu0dNDSeUB1RgLLkhtGrFWm7oOuq6aQfsUWbBOrW0Azvcs3ypDSMOndr7AUrqc zxxbSjIuJ1kz0ihTKwkkrvBDsxEXMwea452rqsLpsyr+vSnbCC1+EgAt5NO50A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650195810; a=rsa-sha256; cv=none; b=amASYMlwx+NqokLR02t0Cc1uazNIsA1ETEZmShMo79q3cq5recw+51wuKOdyVAcfQsy2Ws K3OI4eRcVRaNC6v6oihYJ3HrGkZbedid3c96aZTan5E4BPRngsrf4ixuH7wfHxBRAGe+/s 7TRZrcqYZMm+otA9RiWlTkfImEN0PInQ4LVY6TJE39Q8EHW+qzbBpGYsFSioCEAYtNV2Zg xSW22zLpGh5Ju/LwpSX3q8d+ULKVsiHXRIIAwH3627pPniYpcZ/b/fSkFgVCaGBb9hqt5v dkBdeVLTxJHvcjzsRglrANhjfTade0FrG7xX2LGPBgbBmH/tpy9d8Ylfz9OPww== ARC-Authentication-Results: i=1; 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+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 3.66 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+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 17078196A2 X-Spam-Score: 3.66 X-Migadu-Scanner: scn1.migadu.com X-TUID: Md7C08sdnh3+ On 16/04/2022 10:07, Kaushal Modi wrote: > On Wed, Apr 13, 2022 at 7:38 AM Max Nikulin wrote: >> >> For export to html produces the following link: >> https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Browse_002dURL >> I think, a better variant is >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Browse_002dURL.html >> even though for the Org manual I often prefer single-page HTML version. > > Thanks for your feedback! I absorbed almost all of it into ox-hugo and > wrote about it in a followup blog post: > https://scripter.co/improving-ox-hugo-exported-org-info-links/. I hope to see similar changes in ol-info.el as well. I appreciate your activity since it allows to test such feature and to choose better variant of its implementation. > I wanted the link descriptions in the exported markdown to be > more“English” and understandable to people not familiar with the > Emacs Info interface. So I decided to keep this mostly unchanged .. From my point of view, references like (info "(org) Top") resembles scholar citations and does not harm. Citations are used for a lot of time with established language constructs. The only thing I do not like is the nested parenthesis. Traditions hypertext formatting is different though. I believe, your variant is acceptable since it allows to realize whether linked document is known to the reader. It is much better than "here" links or series of links hidden behind of words of some statement. What I am looking for is something like man(1) that became standard way to mention man pages. https://blog.tecosaur.com/tmio/2021-07-31-citations.html > I did not change the link description, but I did add a new HTML title > attribute to the link. This attribute contains the Emacs Lisp code > needed to access the Info manual from Emacs. … Of course, the user will > still not be able to copy that text and paste in Emacs. But it will > still provide them enough hint on how to access Info nodes in Emacs. Your decision is certainly better than a multistep recipe from "emacs --help": "Run M-x info RET m emacs RET m emacs invocation RET inside Emacs to read the main documentation for these command-line arguments." At some moment I got tired of aggressive kindness of sites using relative timestamps in text and put full timestamps to titles. I created a browser extension that tries to extract text from title, alt and some other attributes: https://addons.mozilla.org/firefox/addon/altcopy/ I was disappointed when I discovered that e.g. bugzilla has some countermeasures and may temporary remove title in response to right click... Back to info links. I am curious if it is possible to implement handlers for particular URLs to allow users to choose whether they would like to open a web page or a local application. It is doable on Android, but I am unsure concerning regular desktop environments since I never tried to do it. Mozilla promised to not remove intercepting network request handlers from manifest v3 add-ons, but I would prefer declarative approach. Certainly it will require either desktop-wide scheme handler of info links or a native messaging helper. For a while I spent some time experimenting with per-link switch to choose its representation. - It should work with disabled JavaScript. - It should allow keyboard navigation. I learned a trick from Timothy when he was redesigning Org site. Unfortunately the approach adds some noise for text-only browsers ignoring CSS (eww, etc.). I am unsure concerning accessibility and convenience to screen reader users and proper aria attributes. Even appearance in regular browsers should be tuned, e.g. to use some icons instead of text and to make the element recognizable as a switch: info "(org) Working with Source Code" . .link-alternate > input.link-switch-nojs { appearance: none; width: 6em; font-size: 1ex; border-color: blue; border-width: 2px; border-radius: 20%; } .link-alternate > input.link-switch-nojs::after, .link-alternate > input.link-switch-nojs::before { padding: 2px; } /* ::before can not be styled for :checked state */ .link-alternate > input.link-switch-nojs::before { content: "Web"; vertical-align: super; } .link-alternate > input.link-switch-nojs::after { content: "Info"; vertical-align: sub; } .link-alternate > input.link-switch-nojs:not(:checked) { border-top-style: solid; border-left-style: solid; } .link-alternate > input.link-switch-nojs:checked { border-bottom-style: solid; border-right-style: solid; } I have tried "