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.
Samuel Wales 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
Bastien 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
Hi Bastien,
On 6/4/13, Bastien wrote:
>> On 6/3/13, Carsten Dominik 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 typ
Hi Samuel,
Samuel Wales writes:
> On 6/3/13, Carsten Dominik 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 hav
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 t
Hi Carsten,
On 6/3/13, Carsten Dominik 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
resu
On 3 jun. 2013, at 11:54, Michael Strey wrote:
> Hi everyone,
>
> Just for completeness
>
> Carsten Dominik 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 ser
Hi everyone,
Just for completeness
Carsten Dominik 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 fi
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 prett
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'r
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
On 03/06/13 12:17, Nick Dokos wrote:
Alan L Tyree 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-prin
Alan L Tyree 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 :-
On 03/06/13 07:40, Nick Dokos wrote:
Alan L Tyree 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,
Alan L Tyree 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+ pag
Nicolas Goaziou writes:
> Hello,
>
> Alan L Tyree writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>>
>>> Alan L Tyree 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
expor
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
Date: Sun, 2 Jun 20
Hello,
Alan L Tyree writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>>
>> Alan L Tyree 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 co
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
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 r
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 hav
Nicolas Goaziou writes:
> Hello,
>
>
> Alan L Tyree 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
>
Hello,
Alan L Tyree 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
On 01/06/13 03:01, Nicolas Goaziou wrote:
Hello,
Samuel Wales 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
Hello,
Samuel Wales 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 yanki
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 li
27 matches
Mail list logo
