* [html] non-lists showing up as lists
@ 2013-05-31 16:54 Samuel Wales
2013-05-31 17:01 ` Nicolas Goaziou
0 siblings, 1 reply; 27+ messages in thread
From: Samuel Wales @ 2013-05-31 16:54 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-05-31 16:54 Samuel Wales
@ 2013-05-31 17:01 ` Nicolas Goaziou
2013-05-31 20:39 ` Alan L Tyree
0 siblings, 1 reply; 27+ messages in thread
From: Nicolas Goaziou @ 2013-05-31 17:01 UTC (permalink / raw)
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-05-31 17:01 ` Nicolas Goaziou
@ 2013-05-31 20:39 ` Alan L Tyree
2013-06-01 6:39 ` Nicolas Goaziou
2013-06-01 20:10 ` Samuel Wales
0 siblings, 2 replies; 27+ messages in thread
From: Alan L Tyree @ 2013-05-31 20:39 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-05-31 20:39 ` Alan L Tyree
@ 2013-06-01 6:39 ` Nicolas Goaziou
2013-06-01 19:35 ` Alan L Tyree
2013-06-01 20:10 ` Samuel Wales
1 sibling, 1 reply; 27+ messages in thread
From: Nicolas Goaziou @ 2013-06-01 6:39 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-01 6:39 ` Nicolas Goaziou
@ 2013-06-01 19:35 ` Alan L Tyree
2013-06-02 7:57 ` Nicolas Goaziou
0 siblings, 1 reply; 27+ messages in thread
From: Alan L Tyree @ 2013-06-01 19:35 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-05-31 20:39 ` Alan L Tyree
2013-06-01 6:39 ` Nicolas Goaziou
@ 2013-06-01 20:10 ` Samuel Wales
2013-06-01 20:18 ` Samuel Wales
1 sibling, 1 reply; 27+ messages in thread
From: Samuel Wales @ 2013-06-01 20:10 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-01 20:10 ` Samuel Wales
@ 2013-06-01 20:18 ` Samuel Wales
2013-06-01 22:58 ` Alan L Tyree
0 siblings, 1 reply; 27+ messages in thread
From: Samuel Wales @ 2013-06-01 20:18 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-01 20:18 ` Samuel Wales
@ 2013-06-01 22:58 ` Alan L Tyree
0 siblings, 0 replies; 27+ messages in thread
From: Alan L Tyree @ 2013-06-01 22:58 UTC (permalink / raw)
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-01 19:35 ` Alan L Tyree
@ 2013-06-02 7:57 ` Nicolas Goaziou
2013-06-02 9:12 ` Nicolas Goaziou
2013-06-02 20:24 ` Alan L Tyree
0 siblings, 2 replies; 27+ messages in thread
From: Nicolas Goaziou @ 2013-06-02 7:57 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-02 7:57 ` Nicolas Goaziou
@ 2013-06-02 9:12 ` Nicolas Goaziou
2013-06-02 20:24 ` Alan L Tyree
1 sibling, 0 replies; 27+ messages in thread
From: Nicolas Goaziou @ 2013-06-02 9:12 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
[-- 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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-02 7:57 ` Nicolas Goaziou
2013-06-02 9:12 ` Nicolas Goaziou
@ 2013-06-02 20:24 ` Alan L Tyree
2013-06-02 21:40 ` Nick Dokos
1 sibling, 1 reply; 27+ messages in thread
From: Alan L Tyree @ 2013-06-02 20:24 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-02 20:24 ` Alan L Tyree
@ 2013-06-02 21:40 ` Nick Dokos
2013-06-02 23:05 ` Alan L Tyree
0 siblings, 1 reply; 27+ messages in thread
From: Nick Dokos @ 2013-06-02 21:40 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-02 21:40 ` Nick Dokos
@ 2013-06-02 23:05 ` Alan L Tyree
2013-06-03 2:17 ` Nick Dokos
0 siblings, 1 reply; 27+ messages in thread
From: Alan L Tyree @ 2013-06-02 23:05 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-02 23:05 ` Alan L Tyree
@ 2013-06-03 2:17 ` Nick Dokos
2013-06-03 4:29 ` Alan L Tyree
0 siblings, 1 reply; 27+ messages in thread
From: Nick Dokos @ 2013-06-03 2:17 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 2:17 ` Nick Dokos
@ 2013-06-03 4:29 ` Alan L Tyree
2013-06-03 5:40 ` Samuel Wales
0 siblings, 1 reply; 27+ messages in thread
From: Alan L Tyree @ 2013-06-03 4:29 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 4:29 ` Alan L Tyree
@ 2013-06-03 5:40 ` Samuel Wales
2013-06-03 5:45 ` Alan L Tyree
2013-06-06 16:37 ` Bernt Hansen
0 siblings, 2 replies; 27+ messages in thread
From: Samuel Wales @ 2013-06-03 5:40 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 5:40 ` Samuel Wales
@ 2013-06-03 5:45 ` Alan L Tyree
2013-06-03 7:52 ` Carsten Dominik
2013-06-06 16:37 ` Bernt Hansen
1 sibling, 1 reply; 27+ messages in thread
From: Alan L Tyree @ 2013-06-03 5:45 UTC (permalink / raw)
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 5:45 ` Alan L Tyree
@ 2013-06-03 7:52 ` Carsten Dominik
2013-06-03 19:59 ` Alan L Tyree
0 siblings, 1 reply; 27+ messages in thread
From: Carsten Dominik @ 2013-06-03 7:52 UTC (permalink / raw)
To: Alan L Tyree; +Cc: emacs-orgmode
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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
@ 2013-06-03 9:54 Michael Strey
2013-06-03 10:05 ` Carsten Dominik
0 siblings, 1 reply; 27+ messages in thread
From: Michael Strey @ 2013-06-03 9:54 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 9:54 [html] non-lists showing up as lists Michael Strey
@ 2013-06-03 10:05 ` Carsten Dominik
2013-06-03 16:28 ` Samuel Wales
0 siblings, 1 reply; 27+ messages in thread
From: Carsten Dominik @ 2013-06-03 10:05 UTC (permalink / raw)
To: Michael Strey; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 10:05 ` Carsten Dominik
@ 2013-06-03 16:28 ` Samuel Wales
2013-06-04 10:02 ` Bastien
0 siblings, 1 reply; 27+ messages in thread
From: Samuel Wales @ 2013-06-03 16:28 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Michael Strey, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 7:52 ` Carsten Dominik
@ 2013-06-03 19:59 ` Alan L Tyree
0 siblings, 0 replies; 27+ messages in thread
From: Alan L Tyree @ 2013-06-03 19:59 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 16:28 ` Samuel Wales
@ 2013-06-04 10:02 ` Bastien
2013-06-04 17:49 ` Samuel Wales
0 siblings, 1 reply; 27+ messages in thread
From: Bastien @ 2013-06-04 10:02 UTC (permalink / raw)
To: Samuel Wales; +Cc: Michael Strey, emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-04 10:02 ` Bastien
@ 2013-06-04 17:49 ` Samuel Wales
0 siblings, 0 replies; 27+ messages in thread
From: Samuel Wales @ 2013-06-04 17:49 UTC (permalink / raw)
To: Bastien; +Cc: Michael Strey, emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
@ 2013-06-06 10:26 Michael Strey
0 siblings, 0 replies; 27+ messages in thread
From: Michael Strey @ 2013-06-06 10:26 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-03 5:40 ` Samuel Wales
2013-06-03 5:45 ` Alan L Tyree
@ 2013-06-06 16:37 ` Bernt Hansen
2013-06-06 17:25 ` Samuel Wales
1 sibling, 1 reply; 27+ messages in thread
From: Bernt Hansen @ 2013-06-06 16:37 UTC (permalink / raw)
To: Samuel Wales; +Cc: emacs-orgmode, Alan L Tyree
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [html] non-lists showing up as lists
2013-06-06 16:37 ` Bernt Hansen
@ 2013-06-06 17:25 ` Samuel Wales
0 siblings, 0 replies; 27+ messages in thread
From: Samuel Wales @ 2013-06-06 17:25 UTC (permalink / raw)
To: Bernt Hansen; +Cc: emacs-orgmode, Alan L Tyree
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-06-06 17:25 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-03 9:54 [html] non-lists showing up as lists Michael Strey
2013-06-03 10:05 ` Carsten Dominik
2013-06-03 16:28 ` Samuel Wales
2013-06-04 10:02 ` Bastien
2013-06-04 17:49 ` Samuel Wales
-- strict thread matches above, loose matches on Subject: below --
2013-06-06 10:26 Michael Strey
2013-05-31 16:54 Samuel Wales
2013-05-31 17:01 ` Nicolas Goaziou
2013-05-31 20:39 ` Alan L Tyree
2013-06-01 6:39 ` Nicolas Goaziou
2013-06-01 19:35 ` Alan L Tyree
2013-06-02 7:57 ` Nicolas Goaziou
2013-06-02 9:12 ` Nicolas Goaziou
2013-06-02 20:24 ` Alan L Tyree
2013-06-02 21:40 ` Nick Dokos
2013-06-02 23:05 ` Alan L Tyree
2013-06-03 2:17 ` Nick Dokos
2013-06-03 4:29 ` Alan L Tyree
2013-06-03 5:40 ` Samuel Wales
2013-06-03 5:45 ` Alan L Tyree
2013-06-03 7:52 ` Carsten Dominik
2013-06-03 19:59 ` Alan L Tyree
2013-06-06 16:37 ` Bernt Hansen
2013-06-06 17:25 ` Samuel Wales
2013-06-01 20:10 ` Samuel Wales
2013-06-01 20:18 ` Samuel Wales
2013-06-01 22:58 ` Alan L Tyree
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).