Carsten Dominik writes: > Hi everyone. > > As far as I can see, the filling code is already pretty smart about this > issue. The question is then: What else can we do about it. > After doing some analysis of my problems last night, I agree that filling is not the issue. All of the instances that I have found in my own files are the result of pasting in from another file (case law plain text database or a web page).
> Possibilities: > 1. We could change the parser to ignore lists where the first > item does not start with `1.' or `a)'. But this would > be a pretty serious change. > > 2. We could implement a good function that could find problematic > cases, so that they can be fixed by hand. This is basically > what Nick proposed - only it would be implemented in Lisp. > > 3. We could implement a function that finds and fixes such issues. > It would basically scan the buffer and find lists that have > only a single item, not starting with 1, and change the wrapping > to fix it. > > In any case, some hand work would be involved. > I think we cannot fix this problem in full generality. The reason > is simply that Org is a plain text format and has to be heuristic about > parsing. There will always be edge cases like this. I agree with this, Carsten. As to the choices, it seems to me that the only real choices here are between 2 or 3. I can't imagine ever needing a list with a single item, but there might be a single list item in a partially completed manuscript, so I guess an "automatic" fix should offer the user the option to leave each instance alone. For my purposes, either 2 or 3 would be more than satisfactory. Cheers, Alan > > Anyone volunteering to write a command that will > check the buffer and warn about it? Maybe it could be > implemented as org-find-next-funny-list-start, so that > it could be used to search through the whole buffer. > > - Carsten > > > On 3 jun. 2013, at 07:45, Alan L Tyree <alanty...@gmail.com> wrote: > >> On 03/06/13 15:40, Samuel Wales wrote: >>> I don't recall whether I said I had a filling problem. >>> >>> Filling is a red herring for my use case. >>> >>> My point is that regardless of filling, it would be a good idea to be >>> stricter about what a list is, for the reasons I listed. In my use >>> case. >>> >>> Samuel >>> >> You're right - you said "filling and yanking" in your first post. >> >> As I said to Nick, I don't know if my problems stem from filling or not. >> Just know there are problems and I will track them down when I have a little >> time. >> >> Cheers, >> Alan >> >> -- >> Alan L Tyree http://www2.austlii.edu.au/~alan >> Tel: 04 2748 6206 sip:172...@iptel.org >> >> -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
