[O] Re: latex export issue
Thanks Nicolas and Scot for your feedback. I think the fill approach will probably catch most issues. Stephen
[O] Re: latex export issue
Ah, right. I did misunderstand. Yes, that seems like a good solution. Scot On Thu, Mar 10, 2011 at 10:00 PM, Nicolas wrote: > Hello, > > Scot Becker 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 >
[O] Re: latex export issue
Hello, Scot Becker 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
[O] Re: latex export issue
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 wrote: > Hello, > > Scot Becker 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 >
[O] Re: latex export issue
Hello, Scot Becker 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: [O] Re: latex export issue
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 wrote: > Hello, > > Stephen Eglen 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 > >
[O] Re: latex export issue
Hello, Stephen Eglen 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
