From: Ethan Ligon <ligon@are.berkeley.edu>
To: "Emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>, mail@nicolasgoaziou.fr
Subject: Re: Problem with org-export--delete-comments
Date: Sun, 20 Dec 2015 18:04:45 -0800 [thread overview]
Message-ID: <CAJ+2YJOn37G-We6H46rVu2n0-0zv+9z44+JnvfSSN=+OFkfvUA@mail.gmail.com> (raw)
In-Reply-To: <87oadllb4k.fsf@nicolasgoaziou.fr>
[-- 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 --]
prev parent reply other threads:[~2015-12-21 2:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 18:27 Problem with org-export--delete-comments Ethan Ligon
2015-12-17 20:48 ` Nicolas Goaziou
2015-12-17 22:12 ` Andreas Leha
2015-12-17 22:36 ` Nicolas Goaziou
2015-12-17 22:56 ` Andreas Leha
2015-12-18 1:07 ` Ethan Ligon
2015-12-18 20:50 ` Nicolas Goaziou
2015-12-18 0:59 ` Ethan Ligon
2015-12-20 9:31 ` Nicolas Goaziou
2015-12-21 2:04 ` Ethan Ligon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ+2YJOn37G-We6H46rVu2n0-0zv+9z44+JnvfSSN=+OFkfvUA@mail.gmail.com' \
--to=ligon@are.berkeley.edu \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).