From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: link interfering with brackets when abbreviated Date: Sun, 02 Mar 2014 15:27:47 +0100 Message-ID: <87y50sn09o.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> <87ha7hpt6l.fsf@gmail.com> <87wqgdv48n.wl@dns1.atmark-techno.com> <87mwh9nf6h.fsf@gmail.com> <87wqgcka56.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WK7Md-0006su-F9 for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 09:27:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WK7MW-0001mg-Cq for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 09:27:35 -0500 In-Reply-To: <87wqgcka56.fsf@bzg.ath.cx> (Bastien's message of "Sun, 02 Mar 2014 14:22:45 +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: Bastien Cc: michael.ch.brand@gmail.com, emacs-orgmode@gnu.org, Yasushi SHOJI Bastien writes: > 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. This is not a use case. A use case would explain me why (or, better, where) you need to use C-c C-x C-n C-c C-o. No worries, though, as I do not expect to get an answer anymore. > 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'=C3=AAtre 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. The goal of the parser was to define properly Org syntax, by merging concepts from different parts of Org. The exporter was only a proof of concept for the parser, and also a way to exercise the choices made in the syntax. > 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 should be, or the whole concept is moot. If "Org syntax" is only valid during export, if fontification interprets Org differently, if users see Org differently too, there is no point in defining a syntax. Just let everyone implement its own private Org. Note that this is what happened recently. One would like to use UTF-8 characters instead of stars for headlines. Another one would like to use ## for emphasis... > 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. Again, this will not work if we do not agree on the structure. This will raise questions like "How come that my document is exported this way, even though I interpret it that way?". > 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. You are mixing subjects here. For example, `org-end-of-line' is backed up with Elements already. This has nothing to do with Org syntax. > 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. Of course, but the "maximalistic" view can only be a superset of the "minimalistic" one. The former can see more than the latter, but it cannot disagree on what the latter sees. > But Org is no library: it's the Emacs way to manipulate Org files. And Org files are expressed in an Org format. Org syntax tries to define it. > The users' representations of their Org buffer and the affordances > that are based on them are as important as the parser representation. Their Org buffer is still expressed in the Org format. > 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. Sorry, this is not convenient. This is just nonsense. For example, Org prevents a user from inserting a footnote reference in a comment (for good reasons), but links should be allowed? Can't every part of Org agree? AFAICT, a comment is a comment, and it is to be expected that comments only contain raw text. According to the manual: Lines starting with zero or more whitespace characters followed by one '#' and a whitespace are treated as comments and will never be exported. Note that "are treated as comments" is different from "will never be exported" since we write both. The parser simply treats comments as comments. Until recently, some parts of Org were careless and didn't treat them as such. This is a fix. [...] > 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. IMO, there is a single representation for the Org format, and it must be defined clearly. Org syntax is an attempt to do so (but I never said it was definitive) and Org elements implements it. I started to work on the parser because it was high time to give Org one. From the beginning, I wanted all core functions to rely on it, for reasons I already explained. And for the same reasons, anything less is not worthy, as it would become yet another part of Org interpreting Org its own way. I never pretended to think or act otherwise. Some users apparently don't want a parser, i.e. a global consistent definition of Org syntax, for reasons that I cannot understand. I think it is a major mistake, but I'm fine with it. So, there is no middle path. Either the project continues towards its goal, or it stops here. Obviously, I'd rather have the maintainer's opinion on this. Regards, --=20 Nicolas Goaziou