From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: link interfering with brackets when abbreviated Date: Sat, 01 Mar 2014 21:20:18 +0100 Message-ID: <87ha7hpt6l.fsf@gmail.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJqOF-0006KI-RG for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 15:20:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJqO6-00012f-9h for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 15:20:07 -0500 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:46477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJqO6-00012T-3S for emacs-orgmode@gnu.org; Sat, 01 Mar 2014 15:19:58 -0500 Received: by mail-wi0-f173.google.com with SMTP id bs8so1973471wib.0 for ; Sat, 01 Mar 2014 12:19:57 -0800 (PST) In-Reply-To: <87zjl9vjw4.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Sun, 02 Mar 2014 03:44:27 +0900") 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: Yasushi SHOJI Cc: bzg@altern.org, michael.ch.brand@gmail.com, emacs-orgmode@gnu.org Hello, Yasushi SHOJI writes: > However, we humans are not machines nor slave of computers. We tell > computers what we want, or even, we want to make computers think and > do what we are thinking. That's the reason why we, these days, have > *-dwim commands. We don't want to make our users to adopt how > computers work. This is one of the things that annoy me: opening next link on the same line is not, IMO, "dwim". See below. >> 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. 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. 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". So, why do we care about the same line? We could as well open the next link in the same paragraph (or verse block, table cell). I'm not arguing for the latter, but I insist on the fact that opening "next link on the same line" is arbitrary and not really "dwim". OTOH, I'm sure Emacs users know (beginners aside, but they'll learn soon) how to move quickly point wherever they want, without even thinking about it. > b) many other commands _do_ work even if it's not right on the > elements. ie. S-right right after a timestamp, C-c C-c on checkbox > list. Are you planning to remove these features, too? C-c C-c already uses Elements. I'll leave S-right for another day. >> I think that the coolness of the feature eludes me for all I can see is >> a crude hack. > > What if we create org-open-at-point-dwim and map to C-c C-o. Nicolas, > do you object? Implementing it in `org-open-at-point' or `org-open-at-point-whatever' is still implementing it in Org. I still think it's not worth it. Regards, -- Nicolas Goaziou