From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ethan Ligon Subject: Re: Problem with org-export--delete-comments Date: Sun, 20 Dec 2015 18:04:45 -0800 Message-ID: References: <87h9jgrec8.fsf@nicolasgoaziou.fr> <87oadllb4k.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11432b40ed1bc505275eea5a Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aApqW-0006vu-5C for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 21:05:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aApqU-0007Of-Bz for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 21:05:08 -0500 Received: from mail-vk0-x234.google.com ([2607:f8b0:400c:c05::234]:35334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aApqU-0007NS-6h for emacs-orgmode@gnu.org; Sun, 20 Dec 2015 21:05:06 -0500 Received: by mail-vk0-x234.google.com with SMTP id a189so93267263vkh.2 for ; Sun, 20 Dec 2015 18:05:05 -0800 (PST) In-Reply-To: <87oadllb4k.fsf@nicolasgoaziou.fr> 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: "Emacs-orgmode@gnu.org" , mail@nicolasgoaziou.fr --001a11432b40ed1bc505275eea5a Content-Type: text/plain; charset=UTF-8 On Sun, Dec 20, 2015 at 1:29 AM Nicolas Goaziou wrote: > 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. > 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 --001a11432b40ed1bc505275eea5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, De= c 20, 2015 at 1:29 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">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 e= quations in org
>> > #
>> > \[
>> >=C2=A0 =C2=A0 =C2=A0u_i(c)=3Dp_i\lambda
>> > \]
>> > #
>> > which (i) gives nice space for reading equations in the org-s= ource, and
>> > (ii) nicely protects the display equation from (fill-paragrap= h) and
>> > friends.
>> >
>> > However, exporting with this construction *stopped* working a= fter commit
>> > 53a4209; what happens now is that ox.el replaces the # with a= blank line,
>> > breaking my single paragraph into=C2=A0 three.
>>
>> I see only one paragraph above. Could you elaborate a bit?
>>
>
> Sure.=C2=A0 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)=3Dp_i\lambda \]
>
> which (i) gives nice space for reading equations in the org-source, an= d
> (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,=C2=A0 and I appreciate that you must have thought about t= his quite
s> a lot.=C2=A0 =C2=A0But I still wish for the old behavior, which=C2=A0= would have simply
> deleted the # comment line.
>
> This would break SW's footnote example, but perhaps that (contrive= d? maybe
> I don't understand his=C2=A0 use case) problem could be addressed = by changing
> the documentation.=C2=A0 Right now the docs say that a footnote
>
> "ends at the next footnote definition, headline, or after two con= secutive
> empty lines."
>
>=C2=A0 Why not just change to
>
> "ends at the next footnote definition, headline, or two empty lin= es
> (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.= =C2=A0 That was simply =C2=A0a work-around I'd developed that worked un= til a few weeks ago, to solve the deeper problem you =C2=A0identify below..= .=C2=A0

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

=C2=A0 (defun my-handle-comments ()
=C2=A0 =C2=A0 (while (re-search-forward "^[ \t]*#\\( \\|$\\)" nil= t)
=C2=A0 =C2=A0 =C2=A0 (let ((element (org-element-at-point)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (eq (org-element-type element) 'comme= nt)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (delete-region (org-element-property :be= gin element)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(progn (goto-char (org-element-property :end element))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (skip-chars-backward " \t\n&quo= t;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (line-beginning-position 2)))))))

Thanks!=C2=A0 I really appreciate the hel= p.=C2=A0

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.,

=C2=A0 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.=C2=A0= In my (admittedly LaTeX-centric) view the whole point of the =C2=A0distinc= tion between \(\) and \[\] is that the former is meant to be an in-line con= struct, while the latter is meant to indicate a typographically distinct el= ement. =C2=A0=C2=A0

Thanks,
-Ethan
=
--001a11432b40ed1bc505275eea5a--