From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yasushi SHOJI Subject: Re: link interfering with brackets when abbreviated Date: Sun, 02 Mar 2014 09:22:32 +0900 Message-ID: <87wqgdv48n.wl@dns1.atmark-techno.com> 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> <87lhwwgqe4.fsf@bzg.ath.cx> <878uswqfzc.fsf@gmail.com> <87zjl9vjw4.wl@dns1.atmark-techno.com> <87ha7hpt6l.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJuAz-0003aT-27 for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 19:22:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJuAt-00009s-1f for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 19:22:40 -0500 Received: from p654782.hkidff01.ap.so-net.ne.jp ([121.101.71.130]:34767 helo=dns1.atmark-techno.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJuAs-00009m-Nz for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 19:22:34 -0500 In-Reply-To: <87ha7hpt6l.fsf@gmail.com> 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: n.goaziou@gmail.com Cc: bzg@altern.org, michael.ch.brand@gmail.com, emacs-orgmode@gnu.org Hi Nicolas, Thanks for your time. At Sat, 01 Mar 2014 21:20:18 +0100, Nicolas Goaziou wrote: > > >> Anyway, I don't understand why there is so much fuss about this. > > > > That's because a) the commands have been working > > This is not a sufficient reason. We are discussing a minor feature. > Removing it doesn't remove any functionality to Org, as the "thing" just > saves a few keystrokes, on a good day. Ok. If this is yet another bickshed, I'll drop from the discussion. > While re-implementing the function, it appears that the feature just > doesn't fit. So this is a good time to ponder about its real usefulness, > and, if it is worth bending the new function to add it back. I think it > isn't. > > As I already said, opening the next link in the same line is dubious. In > the following example, with point between the links, the previous > behaviour was to open "link2": > > [[link1]] [[link2]] > > Now consider the following case, where point is before the "a": > > [[link1]] a very ... very long line of text [[link2]] > > The previous behaviour implied to also open "link2". This is not > really straightforward. If the point is before the "a", that means the point is right after the link, it should open `link1' instead of `link2', IMNSHO. This isn't even the previous behavior, I admit, but if you move the pointer to the end of the line (that's right after the link2), it _opened_ links2. This behavior works quite well with Emacs' cursor movement. ;; uga, `forward-word' doesn't work as I expected on ;; [[http://google.com][google]]. It stops at the first `o'. > Worse, if `visual-line-mode' is on, > [[link2]] can be many lines below. In the following case, with point > still before the first "a", opening [[link2]] is just odd: > > [[link1]] a very ... very long line > which spans over many visual lines > of text [[link2]]. > > It is odd because in the same situation, without `visual-line-mode' but > with `auto-fill-mode' on, C-c C-o will report "No link found". Both should report "No link found". `org-end-of-line' takes care of `visual-line-mode', why not `org-open-at-link'? -- yashi