From mboxrd@z Thu Jan 1 00:00:00 1970 From: ST Subject: Re: Link abbreviations: include abbreviation table and linkwords with spaces Date: Fri, 16 Mar 2018 09:38:43 +0200 Message-ID: <1521185923.17859.1.camel@gmail.com> References: <1520886927.1793.99.camel@gmail.com> <87r2ooanzd.fsf@nicolasgoaziou.fr> <1520931065.1930.4.camel@gmail.com> <871sgo8hbj.fsf@nicolasgoaziou.fr> <1520942003.1930.32.camel@gmail.com> <87sh92lpr5.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewjwy-0001P3-BY for Emacs-orgmode@gnu.org; Fri, 16 Mar 2018 03:38:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewjwv-0006tP-4k for Emacs-orgmode@gnu.org; Fri, 16 Mar 2018 03:38:52 -0400 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:40562) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ewjwu-0006sv-TH for Emacs-orgmode@gnu.org; Fri, 16 Mar 2018 03:38:49 -0400 Received: by mail-wm0-x22b.google.com with SMTP id t6so1241170wmt.5 for ; Fri, 16 Mar 2018 00:38:48 -0700 (PDT) Received: from debox ([37.26.146.167]) by smtp.gmail.com with ESMTPSA id 1sm6214046wmj.35.2018.03.16.00.38.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 00:38:46 -0700 (PDT) In-Reply-To: <87sh92lpr5.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Emacs-orgmode@gnu.org Hello, to those engineers, who are responsible for adding new features: does this case of enabling linkwords with spaces (see below) qualifies as a new feature request? If yes - where should I file it? Thank you! ---------------------------------------------------------------- > > > Why should this not be parse-able? Cut #+LINK: from the beginning, URL > > (last token) from the end, and the rest will be "link word", even with > > (several) spaces in between... > > Can we be sure so-called URL part will never contain a space? You put > a constraint either on the linkword or on the "URL" part. 1. If I were to choose on which part to put a constraint - I'll do so with the "URL" part as it appears only once and in the best case as meta data in comments, while "link word" can appear tens or hundreds of times in the text itself, which needs to look nice. 2. Spaces in URLs a rare, while all docs that have more than one word in their title look nicer with spaces. I found only 3 cases here: https://orgmode.org/manual/External-links.html 3. Anyway the problem of spaces in the URLs is not a new one - you have the same in bash. Solution - just put URL part in "URL", as you usually do on command line. And as you already do defining org-link-abbrev-alist: ("url-to-ja" . "http://translate.google.fr/translate?sl=en&tl=ja&u=%h") so for the cases where there must be spaces in the URL do: #+LINK: My Book "path/to/My Book.org" but by default in normal case just use: #+LINK: My Book path/to/My_Book.org What is your opinion? Can this qualify as feature request? Thanks!