From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: link interfering with brackets when abbreviated Date: Sun, 02 Mar 2014 14:22:45 +0100 Message-ID: <87wqgcka56.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> <87lhwwgqe4.fsf@bzg.ath.cx> <878uswqfzc.fsf@gmail.com> <87zjl9vjw4.wl@dns1.atmark-techno.com> <87ha7hpt6l.fsf@gmail.com> <87wqgdv48n.wl@dns1.atmark-techno.com> <87mwh9nf6h.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WK6M5-0002NZ-Fb for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 08:23:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WK6Lz-0005GH-GT for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 08:22:57 -0500 Received: from rs249.mailgun.us ([209.61.151.249]:41754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WK6Lz-0005G3-7K for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 08:22:51 -0500 In-Reply-To: <87mwh9nf6h.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 02 Mar 2014 10:05:42 +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.ch.brand@gmail.com, emacs-orgmode@gnu.org, Yasushi SHOJI Hi Nicolas, Nicolas Goaziou writes: > And all I got so far was drama. Please: everyone is showing great respect for your work, it is not helpful to dismiss our contributions as "drama". Your time is highly valuable and so is ours. I don't think Michael, Yasushi or me would care replying if it was just for drama. Here is my use-case: I often use C-c C-o as a shortcut for C-c C-x C-n C-c C-o -- that's 2.5 shorter. This is convenient, and I would need a good reason for removing something that convenient. Now there are really two issues: this one above, which can easily be fixed by making `org-open-at-point' more flexible. And the general issue of when and how Org features should rely on Org syntax, as defined by the parser. (Whether links in comments should be treated as links by C-c C-o belongs to the second issue, this is what I'd like to discuss now.) To my knowledge, the first raison d'être of the parser was to create a stable and reliable infrastructure for the export engine. In this case, a parser is needed, because that's the only way to consistently have a common denominator for all export backends. Now the parser can also be used for other features. You already explained the reasons very well: features will be easier to maintain, and the whole set of features relying on the parser will evolve more smoothly. That said, Org syntax is not the only valid representation of an org-mode buffer. It is the only useful one when exporting a buffer to a certain format, because we need to map the structure of the original contents to the structure of the target one. But another representation of an org-mode buffer is the one that a user has in mind when manipulating it, part of this representation depends on Org syntax, part of it depends on Emacs general facilities. For example, Emacs and the user have a notion of `end-of-line', but Org syntax does not. Org syntax says whitespaces after an object belong to the object but my immediate representation says they do not. Or we do have a notion of visual indentation (with org-indent-mode turned on), but this does not correspond to any real content, and /a fortiori/ to an Org syntactic element, since this is just visual sugar. (At this point, I feel like I'm "lecturing" the list -- I am not, I'm just trying to express myself clearly, because I really care about removing emotional distortion from this thread, and would like to make my point very simple, so please bare with me.) There is a minimalistic view of Org as the combination of a syntax and a set of features to manipulate this syntax. There is a maximalistic view of Org as a syntax, a set of features to manipulate it, and a set of Emacs facilities to manipulate the mental representation of an Org buffer, which will *never* be the same than the parser representation. If Org were to be a Ruby gem, then the minimalistic view would be the right one, because libraries need to stick to common denominator and favor predictability. For example, in such a library, we don't care about "\n" characters by themselves in paragraphs, because the end of lines is irrelevant here, syntactictly speaking. But Org is no library: it's the Emacs way to manipulate Org files. The users' representations of their Org buffer and the affordances that are based on them are as important as the parser representation. Hence the case for links in comment, for example: the user read them as links, there is no value in preventing the users to open them with C-c C-o, and it is convenient to allow them to do so. Long story short: when users ask for to keep a feature they find convenient, this is no drama or conservative position, this is the expression that their interaction with an Org buffer will be less smooth if they have to constrain their representation to that of the parser. Finding the correct balance here does not impact the value of the parser at all, quite on the contrary. The better the parser, the easier it will be to draw the line between the minimalistic and the maximalistic views, even in the code. For example, a comment in `org-open-at-point' can clearly explain why opening the next link on the same line is allowed, even if it makes `org-open-at-point' unpure syntactic-wise. In a sense, the value of the parser grows with the number of functions that depend on it, hence the temptation to use it everywhere possible. But IMO this does not capture the whole truth: the value of the parser also depends on the number of decisions it helps us make regarding these minimalistic/maximalistic trade-offs. It is a unvaluable tool to clearly think about features, precisely because it empowers the developers to think in terms of syntactic elements, and see where this thinking comes short. I'm done: please don't stop working on the parser just because the parser is not the only way to think about feature, and please just remember all participants on this thread are goodwilling users who try to make a point. Thanks, -- Bastien