Re: [O] [html] non-lists showing up as lists
Bastien b...@gnu.org writes: 4. Define that lists alway have to have a newline in front of them. I presume Michael means blank line. I like this. Mhhh... I don't. Yes, I meant blank lines and after rethinking I don't like it either. My reason for not liking them is the LaTeX exporter. The current exporter respects the difference between the following two examples. #+begin_src org-mode Here is a line of text directly followed by a list - item - item #+end_src #+begin_src org-mode Here is a line of text followed by a blank line followed by a list - item - item #+end_src The blank line makes a difference in LaTeX's PDF output. Michael -- mailto:mst...@strey.biz http://www.strey.biz
Re: [O] [html] non-lists showing up as lists
Samuel Wales samolog...@gmail.com writes: 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 Hi Samuel, I use org indent mode all the time so most of my lists start in column 0. Requiring an indent will break my existing org data (which goes back years now) so I don't want indented lists to be a requirement if it is not absolutely necessary. Just my two cents. Regards, Bernt
Re: [O] [html] non-lists showing up as lists
Hi Bernt, Optional. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
Hi Samuel, Samuel Wales samolog...@gmail.com writes: On 6/3/13, Carsten Dominik carsten.domi...@gmail.com wrote: 4. Define that lists alway have to have a newline in front of them. I presume Michael means blank line. I like this. Mhhh... I don't. 5. Define that lists always have to be indented. I like this also, and have long wanted c-c - on a region to indent the resulting list, but have not figured out how to implement it. I strongly dislike this. Instead, consider this: , | Indented paragraph. | | - Item 1 | - Item 2 ` I propose that: 1. TAB on the dash character of Item 1 could indent the item by two characters. 2. Selecting both items in a region then hitting TAB would indent both items by two characters. 2 cents of course, -- Bastien
Re: [O] [html] non-lists showing up as lists
Hi Bastien, On 6/4/13, Bastien b...@gnu.org wrote: On 6/3/13, Carsten Dominik carsten.domi...@gmail.com wrote: 4. Define that lists alway have to have a newline in front of them. I presume Michael means blank line. I like this. Mhhh... I don't. Perhaps can be optional the way alphabetic lists and numbered list types are. 5. Define that lists always have to be indented. I like this also, and have long wanted c-c - on a region to indent the resulting list, but have not figured out how to implement it. I strongly dislike this. Which part? The latter means this: Mline line line P M and P indicate mark and point, active. C-c - to make this: M- line - line - line P So I have to go to mark, mark, go to point, C-c -, manually fix the list by going to M, ^G to deactivate, then actually control shift right to indent to where I want. I need to do this every time because I never put lists at column 0. All I was saying is that I'd like C-c - on an active region to produce this: - line - line - line Of course I am not saying that this should apply to everybody. Michael and I like to indent by 2, so for us it would make sense to make C-c - support that for us. Instead, consider this: Instead of what? , | Indented paragraph. | | - Item 1 | - Item 2 ` I propose that: 1. TAB on the dash character of Item 1 could indent the item by two characters. 2. Selecting both items in a region then hitting TAB would indent both items by two characters. I don't indent paragraphs. 1 conflicts with cycling. 2 is a good idea in general but not an improvement over the above cumbersome procedure other than getting rid of ^G. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
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 Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] [html] non-lists showing up as lists
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. 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. 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 Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206sip:172...@iptel.org
Re: [O] [html] non-lists showing up as lists
Hi everyone, Just for completeness Carsten Dominik carsten.domi...@gmail.com writes: [...] 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. 4. Define that lists alway have to have a newline in front of them. 5. Define that lists always have to be indented. My favourite would be 4. Michael Strey -- mailto:mst...@strey.biz http://www.strey.biz
Re: [O] [html] non-lists showing up as lists
On 3 jun. 2013, at 11:54, Michael Strey mst...@strey.biz wrote: Hi everyone, Just for completeness Carsten Dominik carsten.domi...@gmail.com writes: [...] 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. 4. Define that lists alway have to have a newline in front of them. 5. Define that lists always have to be indented. Hi Michael, I think this would break too many legacy Org files. It would also cause problems for sublist, so you could no longer make compact deep lists. But thanks for the input. - Carsten My favourite would be 4. Michael Strey -- mailto:mst...@strey.biz http://www.strey.biz
Re: [O] [html] non-lists showing up as lists
Hi Carsten, On 6/3/13, Carsten Dominik carsten.domi...@gmail.com wrote: 4. Define that lists alway have to have a newline in front of them. I presume Michael means blank line. I like this. 5. Define that lists always have to be indented. I like this also, and have long wanted c-c - on a region to indent the resulting list, but have not figured out how to implement it. Hi Michael, I think this would break too many legacy Org files. It would How about making it optional? Was there a time when it was already optional? ISTR regexps for lists. also cause problems for sublist, so you could no longer make compact deep lists. - do you mean - like this? That is already in a list context? Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
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 Tyreehttp://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
Re: [O] [html] non-lists showing up as lists
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, -- Nicolas Goaziou
Re: [O] [html] non-lists showing up as lists
Completing myself: Additionally, you may want to try the following patch (against maint branch), which takes a slightly different approach for filling. Regards, -- Nicolas Goaziou From 0b3480cf161d58cbf0bd337fd1a7fabbe2aae0c3 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou n.goaz...@gmail.com Date: Sun, 2 Jun 2013 11:12:02 +0200 Subject: [PATCH] org.el: Slight change to filling mechanism * lisp/org.el (org-setup-filling): Set `paragraph-start' and `paragraph-separate'. (org-fill-paragraph-separate-nobreak-p): Remove function. --- lisp/org.el | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b9e6d9e..60c5475 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -22068,28 +22068,26 @@ hierarchy of headlines by UP levels before marking the subtree. ;; `org-setup-filling' installs filling and auto-filling related ;; variables during `org-mode' initialization. +(defvar org-element-paragraph-separate) ; org-element.el (defun org-setup-filling () - (interactive) + (require 'org-element) ;; Prevent auto-fill from inserting unwanted new items. (when (boundp 'fill-nobreak-predicate) (org-set-local 'fill-nobreak-predicate (org-uniquify (append fill-nobreak-predicate - '(org-fill-paragraph-separate-nobreak-p - org-fill-line-break-nobreak-p + '(org-fill-line-break-nobreak-p org-fill-paragraph-with-timestamp-nobreak-p) + (let ((paragraph-ending (substring org-element-paragraph-separate 1))) +(org-set-local 'paragraph-start paragraph-ending) +(org-set-local 'paragraph-separate paragraph-ending)) (org-set-local 'fill-paragraph-function 'org-fill-paragraph) (org-set-local 'auto-fill-inhibit-regexp nil) (org-set-local 'adaptive-fill-function 'org-adaptive-fill-function) (org-set-local 'normal-auto-fill-function 'org-auto-fill-function) (org-set-local 'comment-line-break-function 'org-comment-line-break-function)) -(defvar org-element-paragraph-separate) ; org-element.el -(defun org-fill-paragraph-separate-nobreak-p () - Non-nil when a new line at point would end current paragraph. - (looking-at (substring org-element-paragraph-separate 1))) - (defun org-fill-line-break-nobreak-p () Non-nil when a new line at point would create an Org line break. (save-excursion -- 1.8.3
Re: [O] [html] non-lists showing up as lists
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
Re: [O] [html] non-lists showing up as lists
Alan L Tyree alanty...@gmail.com writes: 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? If the problematic lines existed in the file that you pasted into an org file, then there is nothing that org can do of course. The thing to do is to check the file *before* you import it into org. Here's a simple awk script to catch the two cases of plain and numbered lists: --8---cut here---start-8--- #! /usr/bin/gawk -f /^ *- / {printf(Line %d: plain list element: %s\n, NR, $0);} /^ *[0-9]+\. / {printf(Line %d: numbered list element: %s\n, NR, $0);} --8---cut here---end---8--- Catching more cases and integrating the script into your workflow (and fixing any bugs) is left as an exercise. -- Nick
Re: [O] [html] non-lists showing up as lists
On 03/06/13 07:40, Nick Dokos wrote: Alan L Tyree alanty...@gmail.com writes: 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? If the problematic lines existed in the file that you pasted into an org file, then there is nothing that org can do of course. The thing to do is to check the file *before* you import it into org. Here's a simple awk script to catch the two cases of plain and numbered lists: --8---cut here---start-8--- #! /usr/bin/gawk -f /^ *- / {printf(Line %d: plain list element: %s\n, NR, $0);} /^ *[0-9]+\. / {printf(Line %d: numbered list element: %s\n, NR, $0);} --8---cut here---end---8--- Catching more cases and integrating the script into your workflow (and fixing any bugs) is left as an exercise. Indeed, an exercise which I have already done in the form of a lisp function to catch the nasty little numbers at the beginning of lines. For the earlier exporter, I used this to insert non-printing spaces, export, then remove non-printing space. Far from elegant :-). I still like the suggestion that there should be an option so that lists cannot begin at the beginning of a line. Like Samuel earlier in this thread, I always indent lists. Thanks for you consideration of all this, Nicolas. I need to identify where the offending lines are coming from. Cheers, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] [html] non-lists showing up as lists
Alan L Tyree alanty...@gmail.com writes: Indeed, an exercise which I have already done in the form of a lisp function to catch the nasty little numbers at the beginning of lines. For the earlier exporter, I used this to insert non-printing spaces, export, then remove non-printing space. Far from elegant :-). Wouldn't it be better to fix the file once and for all? After all, if you do that and then paste it into the org file, then refilling is *never* going to create the problem (assuming that there is no bug in the filling code of course: if there is, then it has to get fixed.) I may have misunderstood but I took the question to be the following: if I get an arbitrary file from somewhere, and I want to make an org document out of it, can I paste it in? The answer is yes, but...: there might be problems. Checking the file with a script shows the problems, then you go in and fix them (by hand if necessary: four or five instances of the problem in 60+ pages seems insignificant, assuming that you *know* that the problem is there.) I still like the suggestion that there should be an option so that lists cannot begin at the beginning of a line. Like Samuel earlier in this thread, I always indent lists. Who's to guarantee that the file you are pasting in does not have indented dashes or numbers at the beginning of some lines? Wouldn't that cause the same problem? -- Nick
Re: [O] [html] non-lists showing up as lists
On 03/06/13 12:17, Nick Dokos wrote: Alan L Tyree alanty...@gmail.com writes: Indeed, an exercise which I have already done in the form of a lisp function to catch the nasty little numbers at the beginning of lines. For the earlier exporter, I used this to insert non-printing spaces, export, then remove non-printing space. Far from elegant :-). Wouldn't it be better to fix the file once and for all? After all, if you do that and then paste it into the org file, then refilling is *never* going to create the problem (assuming that there is no bug in the filling code of course: if there is, then it has to get fixed.) Yes, probably, but I implemented the other when there was also a problem with footnotes that looked like [1942]. I have hundreds of these in a normal file (legal case references) and so I needed to disable them at each export. That problem doesn't exist now since Bastien kindly did a patch for org-footnote.el. I may have misunderstood but I took the question to be the following: if I get an arbitrary file from somewhere, and I want to make an org document out of it, can I paste it in? The answer is yes, but...: there might be problems. Checking the file with a script shows the problems, then you go in and fix them (by hand if necessary: four or five instances of the problem in 60+ pages seems insignificant, assuming that you *know* that the problem is there.) That is only part of the problem. I'm pretty sure that the footnote example that we have been discussing did *not* come from a cut and paste file. But I don't know where it did come from. Samuel seemed to think that he had a filling problem. In short, I don't know exactly what the problem is or if there is a single source. I'm facing some serious deadlines right now, but when I get clear of the fog I will investigate further and report back, hoping to clarify the problem. Thanks again for your time on this. I still like the suggestion that there should be an option so that lists cannot begin at the beginning of a line. Like Samuel earlier in this thread, I always indent lists. Who's to guarantee that the file you are pasting in does not have indented dashes or numbers at the beginning of some lines? Wouldn't that cause the same problem? Yes, it does, but it's not a problem that I have ever seen. I probably will see it now on the next cut and paste :-). Thanks again for all your time on this. Cheers, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] [html] non-lists showing up as lists
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 -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
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, -- Nicolas Goaziou
Re: [O] [html] non-lists showing up as lists
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. 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? Cheers, Alan -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] [html] non-lists showing up as lists
Perhaps we can make a formal feature request that the user be able to specify (in an option) that a list must have a blank line preceding it? I realize Nicolas's opinion is different. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
In case it helps: I can say that I never, ever, no matter what, and there are no exceptions - make a list like this I always - make a list like this (I happen also to always indent by 2 spaces) IIRC, org-list-allow-alphabetical is default nil largely to avoid making a list. IMO doing so by requiring a blank line (at least optionally) before lists would allow that variable to be safer. IMO it is a lot to expect of users if they paste large documents (or even capture them as part of org-protocol or something), and there are plenty of filling edge cases, such as illustrated in the recent thread about filling with and filladapt, where you'd have to either check manually every time you fill or actually hack the filling code to understand list syntax. Just my opinion, though. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
On 02/06/13 06:18, Samuel Wales wrote: In case it helps: I can say that I never, ever, no matter what, and there are no exceptions - make a list like this I always - make a list like this (I happen also to always indent by 2 spaces) IIRC, org-list-allow-alphabetical is default nil largely to avoid making a list. IMO doing so by requiring a blank line (at least optionally) before lists would allow that variable to be safer. IMO it is a lot to expect of users if they paste large documents (or even capture them as part of org-protocol or something), and there are plenty of filling edge cases, such as illustrated in the recent thread about filling with and filladapt, where you'd have to either check manually every time you fill or actually hack the filling code to understand list syntax. Just my opinion, though. And mine. I always get these damned things when filling a long document. Alan Samuel -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
[O] [html] non-lists showing up as lists
The 30 and the - get exported as lists. === paragraph. Emily died at age 30. New sentence. paragraph - the list is long. === Filling and yanking can create lines like those. Perhaps this is intended behavior? If so, is there a way to change it so that it requires a blank line before every list? Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] [html] non-lists showing up as lists
Hello, Samuel Wales samolog...@gmail.com writes: The 30 and the - get exported as lists. As they should. === paragraph. Emily died at age 30. New sentence. paragraph - the list is long. === Filling If filling creates this, then this is a bug. Could you provide an ECM for this? and yanking can create lines like those. On the other hand, I think it's the user's responsibility to check what he is yanking. Anyway, there's no way to tell if he wants to yank a real list or not. If so, is there a way to change it so that it requires a blank line before every list? No: Org lists can start at column 0. Regards, -- Nicolas Goaziou
Re: [O] [html] non-lists showing up as lists
On 01/06/13 03:01, Nicolas Goaziou wrote: Hello, Samuel Wales samolog...@gmail.com writes: The 30 and the - get exported as lists. As they should. === paragraph. Emily died at age 30. New sentence. paragraph - the list is long. === Filling If filling creates this, then this is a bug. Could you provide an ECM for this? SNIP 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. === Exported as: = 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 1. There is merit to this argument, but few practical consequences. = Or this -- not a footnote, but in the main text: The ICC has issued the International Standard Banking Practice for the Examination of Documents under Documentary Credits (ISBP 2007) which attempts to clarify some of the issues. = Exported as: === The ICC has issued the International Standard Banking Practice for the Examination of Documents under Documentary Credits (ISBP 1. which attempts to clarify some of the issues. == Cheers, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org