From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Problem with org-export--delete-comments Date: Sun, 20 Dec 2015 10:31:23 +0100 Message-ID: <87oadllb4k.fsf@nicolasgoaziou.fr> References: <87h9jgrec8.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAaJ4-00078c-9I for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 04:29:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAaJ1-0007wU-33 for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 04:29:34 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:56020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAaJ0-0007wC-TM for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 04:29:31 -0500 In-Reply-To: (Ethan Ligon's message of "Fri, 18 Dec 2015 00:59:06 +0000") 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: Ethan Ligon Cc: emacs-orgmode@gnu.org Hello, Ethan Ligon writes: > On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou > wrote: > >> Hello, >> >> Ethan Ligon writes: >> >> > I've long used the following construction for displayed equations in org >> > # >> > \[ >> > u_i(c)=p_i\lambda >> > \] >> > # >> > which (i) gives nice space for reading equations in the org-source, and >> > (ii) nicely protects the display equation from (fill-paragraph) and >> > friends. >> > >> > However, exporting with this construction *stopped* working after commit >> > 53a4209; what happens now is that ox.el replaces the # with a blank line, >> > breaking my single paragraph into three. >> >> I see only one paragraph above. Could you elaborate a bit? >> > > Sure. If I export the above using ox-ascii, I obtain, in part: > > #+begin_example > I've long used the following construction for displayed equations in org > > \[ u_i(c)=p_i\lambda \] > > which (i) gives nice space for reading equations in the org-source, and > (ii) nicely protects the display equation from (fill-paragraph) and > friends. > #+end_example Actually this is consistent with the Org document. As explained somewhere else in this thread, comments separate elements (e.g., paragraphs). They cannot be inlined within a paragraph. This is exactly what happens in the output. I think you are simply mis-using comments in this particular case. > Point taken, and I appreciate that you must have thought about this quite s> a lot. But I still wish for the old behavior, which would have simply > deleted the # comment line. > > This would break SW's footnote example, but perhaps that (contrived? maybe > I don't understand his use case) problem could be addressed by changing > the documentation. Right now the docs say that a footnote > > "ends at the next footnote definition, headline, or after two consecutive > empty lines." > > Why not just change to > > "ends at the next footnote definition, headline, or two empty lines > (consecutive, or with a comment)." This is not related to footnote syntax. We could find a similar example in, e.g., plain lists. The problem is simply that comment syntax doesn't fit for your use-case. The simplest solution is to write a function handling commented lines the way you want them to be handled and add it to `org-export-before-processing-hook', e.g. (untested), (defun my-handle-comments () (while (re-search-forward "^[ \t]*#\\( \\|$\\)" nil t) (let ((element (org-element-at-point))) (when (eq (org-element-type element) 'comment) (delete-region (org-element-property :begin element) (progn (goto-char (org-element-property :end element)) (skip-chars-backward " \t\n") (line-beginning-position 2))))))) Also, I have a dusty patch somewhere that promotes \[...\] and $$...$$ to the rank of elements and prevent them from being filled. However, it also means that these constructs are not recognized as math snippets within a line anymore, e.g., Text \[1+1\] ... I'm not sure how much of an issue it is. Hence the dust. Regards, -- Nicolas Goaziou