From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: link interfering with brackets when abbreviated Date: Thu, 27 Feb 2014 12:04:13 +0100 Message-ID: <87d2i8x1ea.fsf@bzg.ath.cx> References: <87ppm9sxoh.fsf@gmail.com> <87lhwxswby.fsf@gmail.com> <87ha7lsu5o.fsf@gmail.com> <8761o1n63t.fsf@bzg.ath.cx> <8738j5snms.fsf@gmail.com> <87vbw11o3q.fsf@bzg.ath.cx> <87ppm8rgrf.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIylq-0005uu-7t for emacs-orgmode@gnu.org; Thu, 27 Feb 2014 06:04:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIyll-00046R-C6 for emacs-orgmode@gnu.org; Thu, 27 Feb 2014 06:04:54 -0500 Received: from rs249.mailgun.us ([209.61.151.249]:38977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIyll-00046M-53 for emacs-orgmode@gnu.org; Thu, 27 Feb 2014 06:04:49 -0500 In-Reply-To: <87ppm8rgrf.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 27 Feb 2014 11:28:52 +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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Michael Brand , Org Mode Hi Nicolas, Nicolas Goaziou writes: > So they should belong to the next object? I don't find it more > intuitive. Anyway, it's an internal representation for white spaces so > it doesn't matter here. See next answer. I've no problem with this internal representation. > That's not a problem, it is easy to remove this. C-c C-o will do nothing > on white spaces after an object. Yes, I think that would be better. >>> Also in the following example: >>> >>> [fn:1] This is some text [[http://orgmode.org]] >>> >>> C-c C-o on "some" currently triggers `org-footnote-action' since point >>> is in a footnote definition. >> >> Which is counterintuitive too! > > It was part of the specs of the _previous_ implementation. I didn't > change anything here. Yes. There was an inconsistency in the previous implementation (as just tested from the maint branch): when point is in between two non-footnote links, C-c C-o opens the one on the right, while between [fn:1] and a http:// link, C-c C-o calls org-footnote-action iff point is within the footnote... > But it can be removed. Yes, this should be removed IMO. >>> But with the behaviour you describe, it would be hard to predict >>> whether it should move to the link or still open the footnote. >> >> Let me describe the behavior I favor: >> >> C-c C-o opens the link at point (i.e. "the link that the cursor is >> visibly on") > > This is already the case (minus the trailing spaces situation) > >> or the next link on the same line. > > Not really possible, as explained before. And not intuitive, IMO. I don't understand why this is not possible. The fact that the end of the line is not a structural element from Org's parser point of view should not prevent features that rely on some notion of "end of the line". >> When on a headline > > This is the case. > >> and if there are several links on the same line, prompt the user for >> which one she wants to visit. > > Come on. This wasn't done even in the previous implementation. When I meant is this: * Visit http://orgmode.org and http://www.gnu.org ^ When point is on the headline, the current implementation in maint is to prompt the user whether he wants to visit one of the two links. The new implementation does this too, I mentioned it for the sake of completeness -- so maybe there is a misunderstanding. >> I find it very simple and predictable. > > The only really predictable behaviour is: "open the link under point". > Everything else is arguable. Then I argue that the previous behavior, which is to open the next link on the same line, is very convenient and very human-predictable when encoutered at least once. If I'm alone in thinking this, I'm fine surrending, but I hope we can give this another chance :) -- Bastien