unofficial mirror of emacs-orgmode@gnu.org
 help / color / mirror / Atom feed
* [bug] org-do-emphasis-faces breaks with incomplete emphasis
@ 2021-02-16 22:47 Samuel Wales
  2021-02-16 22:59 ` Tim Cross
  0 siblings, 1 reply; 10+ messages in thread
From: Samuel Wales @ 2021-02-16 22:47 UTC (permalink / raw)
  To: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-16 22:47 [bug] org-do-emphasis-faces breaks with incomplete emphasis Samuel Wales
@ 2021-02-16 22:59 ` Tim Cross
  2021-02-16 23:53   ` Samuel Wales
  0 siblings, 1 reply; 10+ messages in thread
From: Tim Cross @ 2021-02-16 22:59 UTC (permalink / raw)
  To: emacs-orgmode


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-16 22:59 ` Tim Cross
@ 2021-02-16 23:53   ` Samuel Wales
  2021-02-16 23:57     ` Samuel Wales
  2021-02-16 23:57     ` Tim Cross
  0 siblings, 2 replies; 10+ messages in thread
From: Samuel Wales @ 2021-02-16 23:53 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-16 23:53   ` Samuel Wales
@ 2021-02-16 23:57     ` Samuel Wales
  2021-02-17  0:09       ` Tim Cross
  2021-02-16 23:57     ` Tim Cross
  1 sibling, 1 reply; 10+ messages in thread
From: Samuel Wales @ 2021-02-16 23:57 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-16 23:53   ` Samuel Wales
  2021-02-16 23:57     ` Samuel Wales
@ 2021-02-16 23:57     ` Tim Cross
  1 sibling, 0 replies; 10+ messages in thread
From: Tim Cross @ 2021-02-16 23:57 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-16 23:57     ` Samuel Wales
@ 2021-02-17  0:09       ` Tim Cross
  2021-02-17  0:59         ` Samuel Wales
  0 siblings, 1 reply; 10+ messages in thread
From: Tim Cross @ 2021-02-17  0:09 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-17  0:09       ` Tim Cross
@ 2021-02-17  0:59         ` Samuel Wales
  2021-02-17  1:01           ` Samuel Wales
  2021-02-17  1:06           ` Tim Cross
  0 siblings, 2 replies; 10+ messages in thread
From: Samuel Wales @ 2021-02-17  0:59 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-17  0:59         ` Samuel Wales
@ 2021-02-17  1:01           ` Samuel Wales
  2021-02-17  1:06           ` Tim Cross
  1 sibling, 0 replies; 10+ messages in thread
From: Samuel Wales @ 2021-02-17  1:01 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-17  0:59         ` Samuel Wales
  2021-02-17  1:01           ` Samuel Wales
@ 2021-02-17  1:06           ` Tim Cross
  2021-02-17  2:42             ` Samuel Wales
  1 sibling, 1 reply; 10+ messages in thread
From: Tim Cross @ 2021-02-17  1:06 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
  2021-02-17  1:06           ` Tim Cross
@ 2021-02-17  2:42             ` Samuel Wales
  0 siblings, 0 replies; 10+ messages in thread
From: Samuel Wales @ 2021-02-17  2:42 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-02-17  2:43 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-16 22:47 [bug] org-do-emphasis-faces breaks with incomplete emphasis Samuel Wales
2021-02-16 22:59 ` Tim Cross
2021-02-16 23:53   ` Samuel Wales
2021-02-16 23:57     ` Samuel Wales
2021-02-17  0:09       ` Tim Cross
2021-02-17  0:59         ` Samuel Wales
2021-02-17  1:01           ` Samuel Wales
2021-02-17  1:06           ` Tim Cross
2021-02-17  2:42             ` Samuel Wales
2021-02-16 23:57     ` Tim Cross

unofficial mirror of emacs-orgmode@gnu.org

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/orgmode/0 orgmode/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 orgmode orgmode/ https://yhetil.org/orgmode \
		emacs-orgmode@gnu.org
	public-inbox-index orgmode

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git