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 16:49:44 +0100 Message-ID: <878ussk3c7.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> <87wqgcka56.fsf@bzg.ath.cx> <87y50sn09o.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WK8eL-0000Ai-Jk for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 10:50:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WK8eD-0000v0-Cm for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 10:49:57 -0500 Received: from rs249.mailgun.us ([209.61.151.249]:32948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WK8eD-0000uU-3J for emacs-orgmode@gnu.org; Sun, 02 Mar 2014 10:49:49 -0500 In-Reply-To: <87y50sn09o.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 02 Mar 2014 15:27:47 +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: >> 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. You are pushing things to the extreme. Even if the syntax is used for 57% of the functions, there is a point in defining one, and there would be no point for all users to define their own. >> 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?". We agree here: a proper syntax is needed for exporting. >> 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. I'm sorry you don't see the point: `org-end-of-line' being backed by Org syntax does not mean "the end of a line" has a meaning for the Org parser. My point is: it does not have a meaning for the parser while is has one for the user. This illustrates the fact there are several representations, which I need for my reasoning: if there was a unique representation, there would be no point in trying to balance several of them when defining features. >> 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. Ideally, yes. >> 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. Agreed. >> 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. Let's ping the users about this particular 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 Er.. shall I quote Alice in Wonderland here? You seem to consider Org comments as comments in programming languages. But Org is not a programming language, it is used for any kind of text. > 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. This is not a all-or-nothing issue, and all-or-less is still different than all-or-nothing. > Some users apparently don't want a parser, i.e. a global consistent > definition of Org syntax, for reasons that I cannot understand. Nobody ever said anything coming close to that. > So, there is no middle path. I can see plenty of them! > Either the project continues towards its goal, or it stops > here. Obviously, I'd rather have the maintainer's opinion on this. Yes. In the meantime, other users' voices can help us step back and see things differently. -- Bastien