From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Bug: link beginning with parenthesis doesn't work [9.0.5 (release_9.0.5-474-g942b62 @ /home/joe/org-mode/lisp/)] Date: Fri, 21 Apr 2017 09:04:31 +0200 Message-ID: <87tw5i44xs.fsf@nicolasgoaziou.fr> References: <871ssnqjh6.fsf@gmail.com> <878tmu6fe0.fsf@nicolasgoaziou.fr> <87zifa4tkd.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1ScQ-0003jE-Ll for emacs-orgmode@gnu.org; Fri, 21 Apr 2017 03:04:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1ScN-0005Yc-Ic for emacs-orgmode@gnu.org; Fri, 21 Apr 2017 03:04:38 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:c:538::200]:40627) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d1ScN-0005Wu-Dx for emacs-orgmode@gnu.org; Fri, 21 Apr 2017 03:04:35 -0400 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id A98DE132E for ; Fri, 21 Apr 2017 09:04:32 +0200 (CEST) In-Reply-To: (Joe Corneli's message of "Fri, 21 Apr 2017 00:02:53 +0100") 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: Joe Corneli Cc: Org-mode mailing list Hello, Joe Corneli writes: > The (xxx) form for a link target, especially one outside of a block, > doesn't seem to have meaning within the document model that Org > understands. Of course it does. It belongs to the link syntax. See, for example `org-link-search' docstring. It could, however, be more visible in the manual. In particular, it could be emphasized in both (info "(org) Internal links") and (info "(org) External links"). Patch welcome ! > But I still think there is a legitimate bug report here, since the > behaviour is not likely to be expected by the user. Only if the user doesn't know about the syntax, which shouldn't happen if the manual was great. > Someone in my position has no interest in code refs, I was only trying > to link to a bit of text in the buffer. Saying "oh but you can't link > to this *one* kind of text" is perhaps a fair move. On the other hand, > given that "following a link" just means "run a search process", that > search process *could* be smart enough to notice that "no coderef was > found, maybe the user meant to link to some plain text in > parentheses". Then I wouldn't see an error. But then, you wouldn't catch real, but mis-typed, coderef links. At least, the error tells you something is wrong in the link syntax, without creating false positives. So, I don't think this would be a net gain overall. Note that the same happens if your regular search text starts with an asterisk. Org will understand you're looking after headlines only, which may not be what you want. Ditto with the hash sign. Org has some syntax for links, you need to know about it if you don't want to get bitten. Hopefully, the manual could help you about it. Regards, -- Nicolas Goaziou