[html] non-lists showing up as lists

[html] non-lists showing up as lists

[Samuel Wales]

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: [html] non-lists showing up as lists

[Nicolas Goaziou]

Hello,


Samuel Wales <samologist@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: [html] non-lists showing up as lists

[Alan L Tyree]

On 01/06/13 03:01, Nicolas Goaziou wrote:
> Hello,
>
>
> Samuel Wales <samologist@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 Tyree                    http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206		sip:172385@iptel.org

Re: [html] non-lists showing up as lists

[Nicolas Goaziou]

Hello,


Alan L Tyree <alantyree@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: [html] non-lists showing up as lists

[Alan L Tyree]

Nicolas Goaziou writes:

> Hello,
>
>
> Alan L Tyree <alantyree@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:172385@iptel.org

Re: [html] non-lists showing up as lists

[Nicolas Goaziou]

Hello,

Alan L Tyree <alantyree@gmail.com> writes:

> Nicolas Goaziou writes:
>
>> Hello,
>>
>>
>> Alan L Tyree <alantyree@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: [html] non-lists showing up as lists

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-Slight-change-to-filling-mechanism.patch --]
[-- Type: text/x-patch, Size: 2172 bytes --]

From 0b3480cf161d58cbf0bd337fd1a7fabbe2aae0c3 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@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: [html] non-lists showing up as lists

[Alan L Tyree]

Nicolas Goaziou writes:

> Hello,
>
> Alan L Tyree <alantyree@gmail.com> writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>>
>>> Alan L Tyree <alantyree@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:172385@iptel.org

Re: [html] non-lists showing up as lists

[Nick Dokos]

Alan L Tyree <alantyree@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: [html] non-lists showing up as lists

[Alan L Tyree]

On 03/06/13 07:40, Nick Dokos wrote:
> Alan L Tyree <alantyree@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 Tyree                    http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206		sip:172385@iptel.org

Re: [html] non-lists showing up as lists

[Nick Dokos]

Alan L Tyree <alantyree@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: [html] non-lists showing up as lists

[Alan L Tyree]

On 03/06/13 12:17, Nick Dokos wrote:
> Alan L Tyree <alantyree@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 Tyree                    http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206		sip:172385@iptel.org

Re: [html] non-lists showing up as lists

[Samuel Wales]

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: [html] non-lists showing up as lists

[Alan L Tyree]

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:172385@iptel.org

Re: [html] non-lists showing up as lists

[Carsten Dominik]

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 <alantyree@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:172385@iptel.org
> 
> 

Re: [html] non-lists showing up as lists

[Alan L Tyree]

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 <alantyree@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:172385@iptel.org
>> 
>> 


-- 
Alan L Tyree           http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206     sip:172385@iptel.org

Re: [html] non-lists showing up as lists

[Bernt Hansen]

Samuel Wales <samologist@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: [html] non-lists showing up as lists

[Samuel Wales]

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: [html] non-lists showing up as lists

[Samuel Wales]

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: [html] non-lists showing up as lists

[Samuel Wales]

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: [html] non-lists showing up as lists

[Alan L Tyree]

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 Tyree                    http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206		sip:172385@iptel.org

Re: [html] non-lists showing up as lists

[Michael Strey]

Hi everyone,

Just for completeness

Carsten Dominik <carsten.dominik@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:mstrey@strey.biz
http://www.strey.biz

Re: [html] non-lists showing up as lists

[Carsten Dominik]

On 3 jun. 2013, at 11:54, Michael Strey <mstrey@strey.biz> wrote:

> Hi everyone,
> 
> Just for completeness
> 
> Carsten Dominik <carsten.dominik@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:mstrey@strey.biz
> http://www.strey.biz

Re: [html] non-lists showing up as lists

[Samuel Wales]

Hi Carsten,

On 6/3/13, Carsten Dominik <carsten.dominik@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: [html] non-lists showing up as lists

[Bastien]

Hi Samuel,

Samuel Wales <samologist@gmail.com> writes:

> On 6/3/13, Carsten Dominik <carsten.dominik@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: [html] non-lists showing up as lists

[Samuel Wales]

Hi Bastien,

On 6/4/13, Bastien <bzg@gnu.org> wrote:
>> On 6/3/13, Carsten Dominik <carsten.dominik@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: [html] non-lists showing up as lists

[Michael Strey]

Bastien <bzg@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:mstrey@strey.biz
http://www.strey.biz