Nicolas Goaziou writes: > Hello, > > Alan L Tyree <alanty...@gmail.com> writes: > >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> >>> Alan L Tyree <alanty...@gmail.com> writes: >>> >>>> I have also been bedeviled by this problem. In a long manuscript it is >>>> all too common. Here is a real example of a footnote and its HTML >>>> export: >>>> >>>> ======= >>>> >>>> [fn:79] Some commentators have questioned whether it is an >>>> 'exception'. The argument is that it is merely part of the bank's duty >>>> not to be part of any fraud of which it has knowledge. See Ricky J >>>> Lee, Strict compliance and the fraud exception: balancing the >>>> interests of mercantile traders in the modern law of documentary >>>> credits, (2008) Macquarie Journal of Business Law >>>> 137. There is merit to this argument, but few >>>> practical consequences. >>>> >>> >>> [...] >>> >>> By default, a number followed by a dot or a parenthesis at the beginning >>> of a line starts a plain list. There is nothing new here. Use M-RET >>> after "but few", and you'll see this is not related to export. >>> >>> The filling mechanism should prevent this situation from happening. If >>> it's not the case, please provide an ECM, as I cannot find one. >>> >>> >>> Regards, >> Perhaps the filling mechanism should prevent it, but in my case it does >> not. > > I tried to fill the previous footnote definition at various places with > various fill-column values, to no avail. > >> Both of the paragraphs I sent were the result of filling. Perhaps there >> is some setting that prevents this from happening? What parameters do >> you need to know to reproduce the problem from the above examples? > > I wish I knew what's needed to reproduce the problem. What's your value > for `fill-nobreak-predicate' in an Org buffer? The function responsible > for preventing a list insertion is > `org-fill-paragraph-separate-nobreak-p'. > > Regards, Hi Nicolas, Thanks for taking the time to look at this. The problem is a little different from what I thought.
The above paragraph does not refill when the '137.' is at the front of the line (And of course, it should not since org thinks it is a list item). It does fill properly when the '137.' is anywhere else. So: my problem is that somehow the '137.' got at the head of a line. I have no idea how that happened. I inserted references in this document using reftex, so I suppose that is one source to investigate. The other source is, no doubt, cut and paste. In a 60+ page document, I had four or five of these, so it is a very annoying problem. In view of this, should I explore further about the source of these or try out the patch you sent? Again, many thanks for your time and help. Cheers, Alan -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
