'false' list item

'false' list item

[Juan Manuel Macías]

Hi,

If a line in a paragraph starts with a digit (or letter) + period +
space, Org misinterprets that as a list item. I almost always notice
this only when I export my document, which is a nuisance.

I wonder if there is any standard solution to that, or if I'm missing
something... All that occurred to me is this "preventive" solution,
using `highlight-regexp':

#+begin_src emacs-lisp
  (defface my-lists-item-box
    '((t :weight bold :foreground "white" :background "orange"))
    "")

  (defun my-org-item-highlight ()
    (highlight-regexp org-list-full-item-re 'my-lists-item-box))

  (add-hook 'org-mode-hook 'my-org-item-highlight)
#+end_src

Best regards,

Juan Manuel 

Re: 'false' list item

[Kyle Meyer]

Juan Manuel Macías writes:

> If a line in a paragraph starts with a digit (or letter) + period +
> space, Org misinterprets that as a list item. I almost always notice
> this only when I export my document, which is a nuisance.
>
> I wonder if there is any standard solution to that, or if I'm missing
> something... All that occurred to me is this "preventive" solution,
> using `highlight-regexp':

It seems that your approach would do a good job of helping you catch
cases that you don't want to be treated as lists.  I'm not aware of any
related functionality in Org, so I don't think you're missing something
there.

Once you know that there is a particular spot that you want to prevent
from being interpreted as a list, you could add a zero-width space in
front of it:

    (info "(org)Escape Character")

I'm not sure if that's the sort of solution you're asking for, though.

Re: 'false' list item

[Tim Cross]

Kyle Meyer <kyle@kyleam.com> writes:

> Juan Manuel Macías writes:
>
>> If a line in a paragraph starts with a digit (or letter) + period +
>> space, Org misinterprets that as a list item. I almost always notice
>> this only when I export my document, which is a nuisance.
>>
>> I wonder if there is any standard solution to that, or if I'm missing
>> something... All that occurred to me is this "preventive" solution,
>> using `highlight-regexp':
>
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists.  I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
>     (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.

If a line starts with a number, period and space, but that line is
within a paragraph (i.e. no blank line above), then I don't think it
should be interpreted as an enumerated list item. If this is what the OP
is referring to, I would argue it is a bug. If it is a 'paragraph'
starting with a number, period and space, then being interpreted as a
list item would be 'normal'.

--
Tim Cross

Re: 'false' list item

[Juan Manuel Macías]

Hi,

Tim Cross <theophilusx@gmail.com> writes:

> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
> starting with a number, period and space, then being interpreted as a
> list item would be 'normal'.

The problem occurs on the lines within a paragraph (no blank line
above). I have uploaded this screenshot:

https://gnutas.juanmanuelmacias.com/images/false-list-item.webm

It also happens with a clean startup.

Best regards,

Juan Manuel

Re: 'false' list item

[Juan Manuel Macías]

Kyle Meyer <kyle@kyleam.com> writes:

> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists.  I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
>     (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.

Thanks for your advice, Kyle. Adding the U+200B char. works fine to
avoid false positives. Anyway, like Tim Cross says, that situation
maybe should be considered as a bug. I think the ideal behavior would
be for Org to consider a list only when there is a blank line above.
But, well thought out, I am afraid that it would not prevent false
positives, as one may want perfectly write a list at the beginning of
the document, or start a plain paragraph with (for example) a digit + a
period + a space...

Best regards,

Juan Manuel 

Re: 'false' list item

[Diego Zamboni]

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

Juan Manuel,

YMMV depending on your needs and habits, but another workaround for this
problem would be to use visual-line-mode instead of filling paragraphs.

--Diego




On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Kyle Meyer <kyle@kyleam.com> writes:
>
> > It seems that your approach would do a good job of helping you catch
> > cases that you don't want to be treated as lists.  I'm not aware of any
> > related functionality in Org, so I don't think you're missing something
> > there.
> >
> > Once you know that there is a particular spot that you want to prevent
> > from being interpreted as a list, you could add a zero-width space in
> > front of it:
> >
> >     (info "(org)Escape Character")
> >
> > I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.
> But, well thought out, I am afraid that it would not prevent false
> positives, as one may want perfectly write a list at the beginning of
> the document, or start a plain paragraph with (for example) a digit + a
> period + a space...
>
> Best regards,
>
> Juan Manuel
>
>

[-- Attachment #2: Type: text/html, Size: 1982 bytes --]

Re: 'false' list item

[Samuel Wales]

perhaps if there is no blank line above or below, then it could be not a list.


On 2/21/21, Diego Zamboni <diego@zzamboni.org> wrote:
> Juan Manuel,
>
> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.
>
> --Diego
>
>
>
>
> On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Kyle Meyer <kyle@kyleam.com> writes:
>>
>> > It seems that your approach would do a good job of helping you catch
>> > cases that you don't want to be treated as lists.  I'm not aware of any
>> > related functionality in Org, so I don't think you're missing something
>> > there.
>> >
>> > Once you know that there is a particular spot that you want to prevent
>> > from being interpreted as a list, you could add a zero-width space in
>> > front of it:
>> >
>> >     (info "(org)Escape Character")
>> >
>> > I'm not sure if that's the sort of solution you're asking for, though.
>>
>> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
>> avoid false positives. Anyway, like Tim Cross says, that situation
>> maybe should be considered as a bug. I think the ideal behavior would
>> be for Org to consider a list only when there is a blank line above.
>> But, well thought out, I am afraid that it would not prevent false
>> positives, as one may want perfectly write a list at the beginning of
>> the document, or start a plain paragraph with (for example) a digit + a
>> period + a space...
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: 'false' list item

[Juan Manuel Macías]

Samuel Wales <samologist@gmail.com> writes:

> perhaps if there is no blank line above or below, then it could be not a list.

I think this solution would be fine, although plain paragraphs starting
with digit/letter + period + space would be false positives. Anyway,
some kind of highlighting in the items, a defined face as in
markdown-mode (markdown-list-face), would be also helpful.

Best regards,

Juan Manuel 

Re: 'false' list item

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> perhaps if there is no blank line above or below, then it could be not a list.
>

Initially, that was my thought as well. Unfortunately, it isn't quite
that straight forward. Consider the list

     1. Item 1
     2. Item 2
     3. Item 3

The second item has no blank line above or below, but it is a list item.
With the blank line approach, the list would have to be

     1. item 1

     2. item 2

     3. item 3

which I doubt many would like. What I guess is really needed is a list
'environment' - once you see the first list item, following a blank
line, your in a list environment until the next blank line. However,
then, if you have list items which are multi-line items, you cannot have
a blank line between items as that would signal a new list environment.
Personally, if the items are longer, visually, I do like a blank line
between the items. So now either we need to add some sort of list
'marker' or we need something else, such as saying a list must be
indented further than the surrounding paragraphs i.e. if you had (using
loren ipsum for text)

-----
Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam
tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede.
Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus
neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.

1. Mauris ac felis vel velit tristique imperdiet.

Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam
vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean
in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis
nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu.
Phasellus at dui in ligula mollis ultricies. Integer placerat tristique
nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a
tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae
lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu.
Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla
facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et
dictum nunc justo sit amet elit.
-----

the 1. line is not a list, but

-----
Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam
tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede.
Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus
neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.

    1. Mauris ac felis vel velit tristique imperdiet.

Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam
vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean
in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis
nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu.
Phasellus at dui in ligula mollis ultricies. Integer placerat tristique
nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a
tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae
lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu.
Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla
facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et
dictum nunc justo sit amet elit.
---

the 1. is a list item i.e. being indented compared to surrounding text makes it
a list item. Any further lines indented to that level or more (for sub
lists) are also considered part of the list, until the next blank line.

The problem with this of course is that if you have a sub-heading which
only has a list of items, there is no surrounding text within that
section, so how would you identify it was a list?

The issue is, if we decide this is a bug, can we fix it? Is it a bug or
is it just an accepted limitation of the org document format and what we
have to do is ensure either no line starts with a '1. ' or we use
something like a unicode character so that it doesn't look like a
number+period+space and therefore not a list item?

--
Tim Cross

Re: 'false' list item

[Kyle Meyer]

Diego Zamboni writes:

> Juan Manuel,
>
> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.

Note that filling paragraphs in Org should already guard against
inadvertently creating a list item.  (Some related discussion is at
<https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>.)

Re: 'false' list item

[Kyle Meyer]

Juan Manuel Macías writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>> It seems that your approach would do a good job of helping you catch
>> cases that you don't want to be treated as lists.  I'm not aware of any
>> related functionality in Org, so I don't think you're missing something
>> there.
>>
>> Once you know that there is a particular spot that you want to prevent
>> from being interpreted as a list, you could add a zero-width space in
>> front of it:
>>
>>     (info "(org)Escape Character")
>>
>> I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.

You can find some previous discussion of this longstanding and known
behavior at <https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>.

Re: 'false' list item

[Juan Manuel Macías]

Tim Cross <theophilusx@gmail.com> writes:

> The issue is, if we decide this is a bug, can we fix it? Is it a bug or
> is it just an accepted limitation of the org document format and what we
> have to do is ensure either no line starts with a '1. ' or we use
> something like a unicode character so that it doesn't look like a
> number+period+space and therefore not a list item?

Interesting all the points you comment, and this paragraph is important.
I'm thinking that without a clear and explicit environment (a begin/end
marks), any possible solution will always have its exceptions. However,
IMHO, I would not find desirable two explicit marks environment in the
style of LaTeX, since this would go against the virtue of legibility and
lightness in Org. I don't know if Markdown (on what it has in common
with Org as a lightweight markup language) also has similar problems in
lists formatting, since I hardly use Markdown and am not aware of its
many implementations...

I still think that highlighting the items would at least be a preventive
solution for Org.

Best regards,

Juan Manuel 

Re: 'false' list item

[Greg Minshall]

Tim,

> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
> starting with a number, period and space, then being interpreted as a
> list item would be 'normal'.

i know this isn't precisely the discussion, but i use *unnumbered*
lists, and i most often have no blank line separating the list from the
paragraph above (or, indeed, below).  i could get used to a modified
requirement, to reduce the false positives, but, would want heads up
(or, maybe, sigh, an option?).

cheers, Greg

Re: 'false' list item

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

> Tim,
>
>> If a line starts with a number, period and space, but that line is
>> within a paragraph (i.e. no blank line above), then I don't think it
>> should be interpreted as an enumerated list item. If this is what the OP
>> is referring to, I would argue it is a bug. If it is a 'paragraph'
>> starting with a number, period and space, then being interpreted as a
>> list item would be 'normal'.
>
> i know this isn't precisely the discussion, but i use *unnumbered*
> lists, and i most often have no blank line separating the list from the
> paragraph above (or, indeed, below).  i could get used to a modified
> requirement, to reduce the false positives, but, would want heads up
> (or, maybe, sigh, an option?).
>

There is no plans to change anything as far as I know. What I wrote was
mainly to show why we have the situation and that any proposed solution
has its own drawbacks.

Bottom line, we cannot easily prevent the 'false' list item issue
without introducing either other issues or adding some additional syntax
to indicate list items, which defeats the 'plain' aspects which many
appreciate in org. Even the proposed 'solutions' still suffer from false
positives.

The question is probably, how can we 'flag' possible false positives in
a convenient manner. For example, it has been suggested that some form
of highlighting for list elements might make it easier to spot a false
element lurking in a paragraph of text. this could possibly be useful,
but I also worry about adding more font-locking and highlighting due to
the potential to degrade performance further. We already have people
running into issue with performance in large org files.



--
Tim Cross

Re: 'false' list item

[Greg Minshall]

Tim,

> There is no plans to change anything as far as I know. What I wrote was
> mainly to show why we have the situation and that any proposed solution
> has its own drawbacks.

thanks.  (i assumed that, but ...)

> Bottom line, we cannot easily prevent the 'false' list item issue
> without introducing either other issues or adding some additional syntax
> to indicate list items, which defeats the 'plain' aspects which many
> appreciate in org. Even the proposed 'solutions' still suffer from false
> positives.

yeah.  i sort of wonder if one can roughly categorize our typical uses
of org-mode into two types:

- random scribbles, agendas, etc., where the consumer is "ourselves" for
  the most part
- more formal presentations (web sites, papers), where the consumer is
  the broader world

and, to the extent this is true, i wonder if some markup issues have a
tension between those two uses.  e.g., for a formal document, i might be
willing to have "heavier" markup, to eliminate (...) false
positives/negatives.  (another example is in-line math markup, with
dollar signs or backslah-parens.)

cheers, Greg

Re: 'false' list item

[Eric S Fraga]

Hello all,

> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.

as Kyle has already mentioned, this is a well known limitation of org
and no reasonable solution has been found in the past.  I partly moved
to visual-line-mode with org-indent-mode for this reason and this
combination works very well for me.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-231-gf46925