[bug] org-do-emphasis-faces breaks with incomplete emphasis

[bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

in fundamental mode [to eliminate any extra stuff]:

===
hi
/hi/
hi =test
hi
hi
hi
/hi/
hi
*hi*
hi
hi
hi
===

m-: (org-do-emphasis-faces nil) RET

everything after =test does not get emphasized.

there is code floating around that calls hte function directly instead
of via font lock.  so even if font lock or org mode forgive this, that
code does not seem to.  and idk whether it is forgiven or if there are
unintended consequences.

e.g. to emphasize in agenda.  which, not sure why it isn't?

-- 
The Kafka Pandemic

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

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> in fundamental mode [to eliminate any extra stuff]:
>
> ===
> hi
> /hi/
> hi =test
> hi
> hi
> hi
> /hi/
> hi
> *hi*
> hi
> hi
> hi
> ===
>
> m-: (org-do-emphasis-faces nil) RET
>
> everything after =test does not get emphasized.
>
> there is code floating around that calls hte function directly instead
> of via font lock.  so even if font lock or org mode forgive this, that
> code does not seem to.  and idk whether it is forgiven or if there are
> unintended consequences.
>
> e.g. to emphasize in agenda.  which, not sure why it isn't?

I'm not clear on what you are expecting/wanting here. If you have badly
formed markup, syntax highlighting and other functions can be expected
to fail.

Are you expecting something more informative, like an error message
saying you have an unterminated emphasis marker or similar? If so, while
it might be possible, I suspect it would come at a high cost from a
performance perspective, especially in large org files. For example, at
what point do you decide the closing marker is missing rather than just
a little further along? At what point do you begin doing the checking -
after typing the first marker, after the first character, after the
first space (noting that all this checking comes at a performance cost)?

What does org-lint tell you when you have such malformed markup in your
document? Would that be sufficient to track down issues when they occur?
If org-lint is not picking it up or is not providing enough detail to
help resolve the issue, perhaps tweaking it would be worthwhile.

--
Tim Cross

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

hi tim,

it isn't malformed, so definitely not looking to be told it's
malformed.  it is just text that is not emphasis.

if you think the function works as expected by skipping the rest of
the buffer, then never mind.

i was, in that case, just emphasizing that the code floating around
that is used to fontify the agenda is going to break.  so nm.


On 2/16/21, Tim Cross <theophilusx@gmail.com> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> in fundamental mode [to eliminate any extra stuff]:
>>
>> ===
>> hi
>> /hi/
>> hi =test
>> hi
>> hi
>> hi
>> /hi/
>> hi
>> *hi*
>> hi
>> hi
>> hi
>> ===
>>
>> m-: (org-do-emphasis-faces nil) RET
>>
>> everything after =test does not get emphasized.
>>
>> there is code floating around that calls hte function directly instead
>> of via font lock.  so even if font lock or org mode forgive this, that
>> code does not seem to.  and idk whether it is forgiven or if there are
>> unintended consequences.
>>
>> e.g. to emphasize in agenda.  which, not sure why it isn't?
>
> I'm not clear on what you are expecting/wanting here. If you have badly
> formed markup, syntax highlighting and other functions can be expected
> to fail.
>
> Are you expecting something more informative, like an error message
> saying you have an unterminated emphasis marker or similar? If so, while
> it might be possible, I suspect it would come at a high cost from a
> performance perspective, especially in large org files. For example, at
> what point do you decide the closing marker is missing rather than just
> a little further along? At what point do you begin doing the checking -
> after typing the first marker, after the first character, after the
> first space (noting that all this checking comes at a performance cost)?
>
> What does org-lint tell you when you have such malformed markup in your
> document? Would that be sufficient to track down issues when they occur?
> If org-lint is not picking it up or is not providing enough detail to
> help resolve the issue, perhaps tweaking it would be worthwhile.
>
> --
> Tim Cross
>
>


-- 
The Kafka Pandemic

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

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

to answer your question: i expected it to just skip the non-emphasis.
not emphasizing the rest of the buffer seemed quite unusual.


On 2/16/21, Samuel Wales <samologist@gmail.com> wrote:
> hi tim,
>
> it isn't malformed, so definitely not looking to be told it's
> malformed.  it is just text that is not emphasis.
>
> if you think the function works as expected by skipping the rest of
> the buffer, then never mind.
>
> i was, in that case, just emphasizing that the code floating around
> that is used to fontify the agenda is going to break.  so nm.
>
>
> On 2/16/21, Tim Cross <theophilusx@gmail.com> wrote:
>>
>> Samuel Wales <samologist@gmail.com> writes:
>>
>>> in fundamental mode [to eliminate any extra stuff]:
>>>
>>> ===
>>> hi
>>> /hi/
>>> hi =test
>>> hi
>>> hi
>>> hi
>>> /hi/
>>> hi
>>> *hi*
>>> hi
>>> hi
>>> hi
>>> ===
>>>
>>> m-: (org-do-emphasis-faces nil) RET
>>>
>>> everything after =test does not get emphasized.
>>>
>>> there is code floating around that calls hte function directly instead
>>> of via font lock.  so even if font lock or org mode forgive this, that
>>> code does not seem to.  and idk whether it is forgiven or if there are
>>> unintended consequences.
>>>
>>> e.g. to emphasize in agenda.  which, not sure why it isn't?
>>
>> I'm not clear on what you are expecting/wanting here. If you have badly
>> formed markup, syntax highlighting and other functions can be expected
>> to fail.
>>
>> Are you expecting something more informative, like an error message
>> saying you have an unterminated emphasis marker or similar? If so, while
>> it might be possible, I suspect it would come at a high cost from a
>> performance perspective, especially in large org files. For example, at
>> what point do you decide the closing marker is missing rather than just
>> a little further along? At what point do you begin doing the checking -
>> after typing the first marker, after the first character, after the
>> first space (noting that all this checking comes at a performance cost)?
>>
>> What does org-lint tell you when you have such malformed markup in your
>> document? Would that be sufficient to track down issues when they occur?
>> If org-lint is not picking it up or is not providing enough detail to
>> help resolve the issue, perhaps tweaking it would be worthwhile.
>>
>> --
>> Tim Cross
>>
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

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

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> hi tim,
>
> it isn't malformed, so definitely not looking to be told it's
> malformed.  it is just text that is not emphasis.
>
> if you think the function works as expected by skipping the rest of
> the buffer, then never mind.
>
> i was, in that case, just emphasizing that the code floating around
> that is used to fontify the agenda is going to break.  so nm.
>

OK, that makes more sense. I guess you need to escape the * e.g. \* to
turn off its 'special' meaning or put it between = to make it a
'verbatim' value. To be honest, I've never run into this
issue, but I tend to not use '*' in my text unless it is for emphasis.

--
Tim Cross

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> to answer your question: i expected it to just skip the non-emphasis.
> not emphasizing the rest of the buffer seemed quite unusual.
>

I guess the problem is the same - how does org know when it is just a *
and when it is the beginning of some emphasis text? We could make it
that such markup only works on words, allowing the code to only consider
two * as emphasis if there are no spaces, otherwise treat as just a *,
but that would be inconvenient when you want to emphasis a phrase or a
couple of words. We could change the regexp to only consider it an
emphasis block if both markers are on the same line, but again,
potentially inconvenient and it would fail for those who use visual-line
mode where there paragraphs are just 1 long line.

In short, can understand what your saying, but not sure there is a
viable fix which doesn't have a heap of other consequences. Basically,
if you want to use the 'markup' characters as normal characters, you
need to either escape them or put them inside a verbatim directive.

--
Tim Cross

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

hi tim,

tanks for your replies.

1.  the same problem occurs without any * in the buffer.

2.  the emphasis regexps are supposed to be limited to a few lines.

3.  they are also supposed to not try to match dissimilar delimiiters.

the problem is that

hi =something

stops all emphasis of all types in the entire rest of hte bguffer even
if the buyffer contains many lines.  this sems unusual to me.

it does not break anything befofre it.

so i think your hypothesis of what i am talking about might possibly
not match what i am talking about at all.

i am limited in coputer ue and will have to stop.

tahnks for your replies.


On 2/16/21, Tim Cross <theophilusx@gmail.com> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> to answer your question: i expected it to just skip the non-emphasis.
>> not emphasizing the rest of the buffer seemed quite unusual.
>>
>
> I guess the problem is the same - how does org know when it is just a *
> and when it is the beginning of some emphasis text? We could make it
> that such markup only works on words, allowing the code to only consider
> two * as emphasis if there are no spaces, otherwise treat as just a *,
> but that would be inconvenient when you want to emphasis a phrase or a
> couple of words. We could change the regexp to only consider it an
> emphasis block if both markers are on the same line, but again,
> potentially inconvenient and it would fail for those who use visual-line
> mode where there paragraphs are just 1 long line.
>
> In short, can understand what your saying, but not sure there is a
> viable fix which doesn't have a heap of other consequences. Basically,
> if you want to use the 'markup' characters as normal characters, you
> need to either escape them or put them inside a verbatim directive.
>
> --
> Tim Cross
>


-- 
The Kafka Pandemic

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

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

to understant, perahsp try to look at the op and remove the line that says *hi*?


On 2/16/21, Samuel Wales <samologist@gmail.com> wrote:
> hi tim,
>
> tanks for your replies.
>
> 1.  the same problem occurs without any * in the buffer.
>
> 2.  the emphasis regexps are supposed to be limited to a few lines.
>
> 3.  they are also supposed to not try to match dissimilar delimiiters.
>
> the problem is that
>
> hi =something
>
> stops all emphasis of all types in the entire rest of hte bguffer even
> if the buyffer contains many lines.  this sems unusual to me.
>
> it does not break anything befofre it.
>
> so i think your hypothesis of what i am talking about might possibly
> not match what i am talking about at all.
>
> i am limited in coputer ue and will have to stop.
>
> tahnks for your replies.
>
>
> On 2/16/21, Tim Cross <theophilusx@gmail.com> wrote:
>>
>> Samuel Wales <samologist@gmail.com> writes:
>>
>>> to answer your question: i expected it to just skip the non-emphasis.
>>> not emphasizing the rest of the buffer seemed quite unusual.
>>>
>>
>> I guess the problem is the same - how does org know when it is just a *
>> and when it is the beginning of some emphasis text? We could make it
>> that such markup only works on words, allowing the code to only consider
>> two * as emphasis if there are no spaces, otherwise treat as just a *,
>> but that would be inconvenient when you want to emphasis a phrase or a
>> couple of words. We could change the regexp to only consider it an
>> emphasis block if both markers are on the same line, but again,
>> potentially inconvenient and it would fail for those who use visual-line
>> mode where there paragraphs are just 1 long line.
>>
>> In short, can understand what your saying, but not sure there is a
>> viable fix which doesn't have a heap of other consequences. Basically,
>> if you want to use the 'markup' characters as normal characters, you
>> need to either escape them or put them inside a verbatim directive.
>>
>> --
>> Tim Cross
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

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

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> hi tim,
>
> tanks for your replies.
>
> 1.  the same problem occurs without any * in the buffer.

It will occur with any of the markup special characters e.g. *, =, _, +, /

>
> 2.  the emphasis regexps are supposed to be limited to a few lines.

Are they? What is 'a few'? This also won't work if you use
visual-line-mode and don't use auto-fill (as your paragraphs are then
just one long line).

>
> 3.  they are also supposed to not try to match dissimilar delimiiters.
>

Not quite sure what you mean here.

> the problem is that
>
> hi =something
>
> stops all emphasis of all types in the entire rest of hte bguffer even
> if the buyffer contains many lines.  this sems unusual to me.
>
> it does not break anything befofre it.
>
> so i think your hypothesis of what i am talking about might possibly
> not match what i am talking about at all.
>

I'm not disagreeing with what your saying. I think the reason the rest
of the file doesn't get parsed correctly is because the single markup
character has made the syntax inconsistent and broken.

The problem is I don't think there is a good fix for this which doesn't
introduce other problems. If the regexp which does the matching is
supposed to limit its search to just a specific number of lines, then
perhaps it is broken. However, I'm not sure what 'a few lines' really
means (2?, 5?, 10?). I also know from past experience that trying to
define font-lock matches which work in such a way is complex, error
prone and often results in a considerable performance hit.

Bottom line, if you want to use the characters reserved for markup
purposes as just plain characters, you have to somehow quote them or
mark them as being 'verbatim' characters. I do think it would be useful
to have something in the manual on this under the markup section.

--
Tim Cross

Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis

[Samuel Wales]

still not what i am saying.  nefver mind.  thanks.

On 2/16/21, Tim Cross <theophilusx@gmail.com> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> hi tim,
>>
>> tanks for your replies.
>>
>> 1.  the same problem occurs without any * in the buffer.
>
> It will occur with any of the markup special characters e.g. *, =, _, +, /
>
>>
>> 2.  the emphasis regexps are supposed to be limited to a few lines.
>
> Are they? What is 'a few'? This also won't work if you use
> visual-line-mode and don't use auto-fill (as your paragraphs are then
> just one long line).
>
>>
>> 3.  they are also supposed to not try to match dissimilar delimiiters.
>>
>
> Not quite sure what you mean here.
>
>> the problem is that
>>
>> hi =something
>>
>> stops all emphasis of all types in the entire rest of hte bguffer even
>> if the buyffer contains many lines.  this sems unusual to me.
>>
>> it does not break anything befofre it.
>>
>> so i think your hypothesis of what i am talking about might possibly
>> not match what i am talking about at all.
>>
>
> I'm not disagreeing with what your saying. I think the reason the rest
> of the file doesn't get parsed correctly is because the single markup
> character has made the syntax inconsistent and broken.
>
> The problem is I don't think there is a good fix for this which doesn't
> introduce other problems. If the regexp which does the matching is
> supposed to limit its search to just a specific number of lines, then
> perhaps it is broken. However, I'm not sure what 'a few lines' really
> means (2?, 5?, 10?). I also know from past experience that trying to
> define font-lock matches which work in such a way is complex, error
> prone and often results in a considerable performance hit.
>
> Bottom line, if you want to use the characters reserved for markup
> purposes as just plain characters, you have to somehow quote them or
> mark them as being 'verbatim' characters. I do think it would be useful
> to have something in the manual on this under the markup section.
>
> --
> Tim Cross
>


-- 
The Kafka Pandemic

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