emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Problem with org-export--delete-comments


From: Ethan Ligon
Subject: Re: [O] Problem with org-export--delete-comments
Date: Sun, 20 Dec 2015 18:04:45 -0800


On Sun, Dec 20, 2015 at 1:29 AM Nicolas Goaziou <address@hidden> wrote:
Hello,

Ethan Ligon <address@hidden> writes:

> On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou <address@hidden>
> wrote:
>
>> Hello,
>>
>> Ethan Ligon <address@hidden> 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.

That's fair.  That was simply  a work-around I'd developed that worked until a few weeks ago, to solve the deeper problem you  identify below... 

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)))))))

Thanks!  I really appreciate the help. 

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.

Well, I most certainly vote for applying your dusty patch.  In my (admittedly LaTeX-centric) view the whole point of the  distinction between \(\) and \[\] is that the former is meant to be an in-line construct, while the latter is meant to indicate a typographically distinct element.   

Thanks,
-Ethan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]