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
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 #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 --]
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 #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 --]
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 #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 --]
Thanks Nicolas and Scot for your feedback. I think the fill approach will probably catch most issues. Stephen