latex export issue

latex export issue

[Stephen Eglen]

With the following minimal org buffer:

Simple test

here here here here here here here here here here here here here here
2010.  here here here here here here here here here here here here
here here here here here here here here here here here here here here


when I export this to latex, I get:

----------------------------------------------------------------------
\title{Simple test}
\author{Stephen Eglen}
\date{09 March 2011}
\maketitle

\setcounter{tocdepth}{3}
\tableofcontents
\vspace*{1cm}

here here here here here here here here here here here here here here

\begin{enumerate}
\item here here here here here here here here here here here here
\end{enumerate}
here here here here here here here here here here here here here here


\end{document}
----------------------------------------------------------------------

This is modified from a real case; is there any way that the "2010." can
be interpreted as the end of the sentence rather than the start of a
enumerate list?  (I have fixed it for now by reformatting my paragraph
so that 2010 does not begin the line.)  I get similar behaviour with
html export.

Thanks, Stephen

Re: latex export issue

[Nicolas]

Hello,

Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:

> With the following minimal org buffer:
>
> Simple test
>
> here here here here here here here here here here here here here here
> 2010.  here here here here here here here here here here here here
> here here here here here here here here here here here here here here

> This is modified from a real case; is there any way that the "2010." can
> be interpreted as the end of the sentence rather than the start of a
> enumerate list?  (I have fixed it for now by reformatting my paragraph
> so that 2010 does not begin the line.)  I get similar behaviour with
> html export.

I usually suggest to insert a non-breakable space just after the
dot. Thus, the pattern doesn't match definition of a numbered list item
anymore.

Regards,

--
Nicolas

Re: Re: latex export issue

[Scot Becker]

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

That sounds like it means that any documents you might want to export to
LaTeX (and format with hard line breaks) should always have non-breaking
spaces after the periods---or you should keep a manual eye on your paragraph
formatting to make sure no numbers come first on the line.

Although I really like the new list code (many, many thanks, Nicolas!), this
does seem an unfortunate (if rare) little 'gotcha' arising from it.  I
hadn't realized that lists are triggered with no indentation at all.

Scot

On Wed, Mar 9, 2011 at 11:46 PM, Nicolas <n.goaziou@gmail.com> wrote:

> Hello,
>
> Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:
>
> > With the following minimal org buffer:
> >
> > Simple test
> >
> > here here here here here here here here here here here here here here
> > 2010.  here here here here here here here here here here here here
> > here here here here here here here here here here here here here here
>
> > This is modified from a real case; is there any way that the "2010." can
> > be interpreted as the end of the sentence rather than the start of a
> > enumerate list?  (I have fixed it for now by reformatting my paragraph
> > so that 2010 does not begin the line.)  I get similar behaviour with
> > html export.
>
> I usually suggest to insert a non-breakable space just after the
> dot. Thus, the pattern doesn't match definition of a numbered list item
> anymore.
>
> Regards,
>
> --
> Nicolas
>
>

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

Re: latex export issue

[Nicolas]

Hello,

Scot Becker <scot.becker@gmail.com> writes:

> That sounds like it means that any documents you might want to export to
> LaTeX (and format with hard line breaks) should always have non-breaking
> spaces after the periods---or you should keep a manual eye on your paragraph
> formatting to make sure no numbers come first on the line.

Would that work for you?

#+begin_src emacs-lisp
(defun org-fill-item-nobreak-p ()
  "Non-nil when line break would insert a new item."
  (and (looking-at (org-item-re)) (org-list-in-valid-block-p)))

(add-to-list 'fill-nobreak-predicate 'org-fill-item-nobreak-p)
#+end_src

If it is fine, we may as well include it by default in Org.

Regards,


-- 
Nicolas

Re: latex export issue

[Scot Becker]

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

Looks good, but I can't get it to work.  To test it, can I just evaluate the
two sexp's in the block you gave inside a scratch buffer, then switch to my
trial org file and export to LaTeX?  Trying the OP's sample file gives the
same results before and after I evaluate this new bit of code, but I suspect
I'm doing something wrong....

Scot


On Thu, Mar 10, 2011 at 8:24 AM, Nicolas <n.goaziou@gmail.com> wrote:

> Hello,
>
> Scot Becker <scot.becker@gmail.com> writes:
>
> > That sounds like it means that any documents you might want to export to
> > LaTeX (and format with hard line breaks) should always have non-breaking
> > spaces after the periods---or you should keep a manual eye on your
> paragraph
> > formatting to make sure no numbers come first on the line.
>
> Would that work for you?
>
> #+begin_src emacs-lisp
> (defun org-fill-item-nobreak-p ()
>  "Non-nil when line break would insert a new item."
>  (and (looking-at (org-item-re)) (org-list-in-valid-block-p)))
>
> (add-to-list 'fill-nobreak-predicate 'org-fill-item-nobreak-p)
> #+end_src
>
> If it is fine, we may as well include it by default in Org.
>
> Regards,
>
>
> --
> Nicolas
>

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

Re: latex export issue

[Nicolas]

Hello,

Scot Becker <scot.becker@gmail.com> writes:

> Looks good, but I can't get it to work. To test it, can I just
> evaluate the two sexp's in the block you gave inside a scratch buffer,
> then switch to my trial org file and export to LaTeX?

Yes, but I guess you misunderstand the goal of the snippet. It will not
"fix" export (which isn't broken in that case) but will prevent
auto-fill-mode from creating a new item by cutting line at a wrong
position i.e. you won't have to keep an eye on the formatting anymore.

Regards,

-- 
Nicolas

Re: latex export issue

[Scot Becker]

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

Ah, right.  I did misunderstand.  Yes, that seems like a good solution.

Scot


On Thu, Mar 10, 2011 at 10:00 PM, Nicolas <n.goaziou@gmail.com> wrote:

> Hello,
>
> Scot Becker <scot.becker@gmail.com> writes:
>
> > Looks good, but I can't get it to work. To test it, can I just
> > evaluate the two sexp's in the block you gave inside a scratch buffer,
> > then switch to my trial org file and export to LaTeX?
>
> Yes, but I guess you misunderstand the goal of the snippet. It will not
> "fix" export (which isn't broken in that case) but will prevent
> auto-fill-mode from creating a new item by cutting line at a wrong
> position i.e. you won't have to keep an eye on the formatting anymore.
>
> Regards,
>
> --
> Nicolas
>

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

Re: latex export issue

[Stephen Eglen]

Thanks Nicolas and Scot for your feedback.  I think the fill approach
will probably catch most issues.

Stephen