Re: Problem with org-export--delete-comments

[Ethan Ligon <ligon@are.berkeley.edu>]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]

On Sun, Dec 20, 2015 at 1:29 AM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Ethan Ligon <ligon@are.berkeley.edu> writes:
>
> > On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou <mail@nicolasgoaziou.fr
> >
> > wrote:
> >
> >> Hello,
> >>
> >> Ethan Ligon <ligon@berkeley.edu> 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

[-- Attachment #2: Type: text/html, Size: 5402 bytes --]