bug#13668: 24.2.93; strike-through in org mode

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

visit the following org file with emacs -Q

cat > foo.org <<EOF
* foo
  bar (+.2 to .5)
  baz (+.2 to .5)

  bar (+.2 to .5)
  baz  +.2 to .5)
EOF

Why are part of the second and third line striked through?
According to the org info pages there is some regexp-based feature
of that kind. But it appears to me that this feature could use a
more sophisticated regexp matcher. Note that the 5th and 6th line
are not striked through.

Also, as an occassional org mode user without a need for very fancy
things, I am wondering whether I can simply switch off such
structural markup elements. The org info node on structural markup
elements does not mention such a possibility. I would prefer if, as a
general strategy, the default values for such features were less
aggressive.


In GNU Emacs 24.2.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2013-02-07 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
System Description:	Ubuntu 10.04.4 LTS

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

Hi Roland,

"Roland Winkler" <winkler@gnu.org> writes:

> visit the following org file with emacs -Q
>
> cat > foo.org <<EOF
> * foo
>   bar (+.2 to .5)
>   baz (+.2 to .5)
>
>   bar (+.2 to .5)
>   baz  +.2 to .5)
> EOF
>
> Why are part of the second and third line striked through?

Because "+" tries to add fontification.

> According to the org info pages there is some regexp-based feature
> of that kind. 

Yes, see `org-emphasis-regexp-components'.

> But it appears to me that this feature could use a
> more sophisticated regexp matcher. Note that the 5th and 6th line
> are not striked through.

Because the space isn't allowed within +...+ fontified constructs.

> Also, as an occassional org mode user without a need for very fancy
> things, I am wondering whether I can simply switch off such
> structural markup elements. 

(setq org-fontify-emphasized-text nil)

> The org info node on structural markup
> elements does not mention such a possibility. 

Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
FAQ for this.

> I would prefer if, as a
> general strategy, the default values for such features were less
> aggressive.

We try to not make them agressive.  But the text you quoted above
looks like an example that could be in fixed-with block like this :

:  bar (+.2 to .5)
:  baz (+.2 to .5)

:  bar (+.2 to .5)
:  baz  +.2 to .5)

or in another block where *...* constructs are not fontified.

Thanks,

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> > But it appears to me that this feature could use a
> > more sophisticated regexp matcher. Note that the 5th and 6th line
> > are not striked through.
> 
> Because the space isn't allowed within +...+ fontified constructs.

There are spaces both between the 2nd and 3rd line, and between the
5th and 6th line. -- Possibly, the regexp matcher could distinguish
in a smarter way between  word constituents and no word constituents.

> (setq org-fontify-emphasized-text nil)

Thanks, I'll use that.

> > The org info node on structural markup
> > elements does not mention such a possibility. 
> 
> Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
> FAQ for this.

Why put this in a separate FAQ? Aren't the info pages the first
source of information for such things?

Roland

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> > But it appears to me that this feature could use a
> > more sophisticated regexp matcher. Note that the 5th and 6th line
> > are not striked through.
> 
> Because the space isn't allowed within +...+ fontified constructs.

There are spaces both between the 2nd and 3rd line, and between the
5th and 6th line. -- Possibly, the regexp matcher could distinguish
in a smarter way between  word constituents and no word constituents.

> (setq org-fontify-emphasized-text nil)

Thanks, I'll use that.

> > The org info node on structural markup
> > elements does not mention such a possibility. 
> 
> Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
> FAQ for this.

Why put this in a separate FAQ? Aren't the info pages the first
source of information for such things?

Roland

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

Hi Roland,

"Roland Winkler" <winkler@gnu.org> writes:

> There are spaces both between the 2nd and 3rd line, and between the
> 5th and 6th line. -- Possibly, the regexp matcher could distinguish
> in a smarter way between  word constituents and no word constituents.

Sorry I wasn't clear: by default, space is not allowed after the first
"*" and before the second "*".

But yes, `org-emphasis-regexp-components' is perhaps too complex and
we have been thinking of implementing this another way.  Stay tuned.

>> (setq org-fontify-emphasized-text nil)
>
> Thanks, I'll use that.
>
>> > The org info node on structural markup
>> > elements does not mention such a possibility. 
>> 
>> Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
>> FAQ for this.
>
> Why put this in a separate FAQ? Aren't the info pages the first
> source of information for such things?

Depends.  We try to keep the info manual readable, and it's already
quite long.  If you can find a good place in the manual, please send
a patch.

Thanks,

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> > Why put this in a separate FAQ? Aren't the info pages the first
> > source of information for such things?
> 
> Depends.  We try to keep the info manual readable, and it's already
> quite long.  If you can find a good place in the manual, please send
> a patch.

I do not find the info nodes on "Structural markup elements"
particularly overloaded. The node "Emphasis and monospace" is just
one short paragraph, and org-fontify-emphasized-text could esily be
mentioned there -- unless this variable also affects other things,
so that it should be mentioned higher up in the node hierarchy.

If such things get distributed among different places, an info
manual plus a separate FAQ, they get yet more confusing, in
particular for casual users of org mode. Many users will not even
know (or expect) that the info manual does not give them the full
story, but they need to consult other sources, too.

Take the elisp manual: it's pretty big. But I like it because its
authors are pretty good in making it an *efficient* and *reliable*
source of information. (Here I'd like to put these words in bold,
because I really appreciate this!)

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

"Roland Winkler" <winkler@gnu.org> writes:

> I do not find the info nodes on "Structural markup elements"
> particularly overloaded. The node "Emphasis and monospace" is just
> one short paragraph, and org-fontify-emphasized-text could esily be
> mentioned there -- unless this variable also affects other things,
> so that it should be mentioned higher up in the node hierarchy.

Please provide a patch.

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> Please provide a patch.

I'd much appreciate if the org developers could do that. I have
enough such things on my own emacs agenda,

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

"Roland Winkler" <winkler@gnu.org> writes:

> On Sun Feb 10 2013 Bastien wrote:
>> Please provide a patch.
>
> I'd much appreciate if the org developers could do that. I have
> enough such things on my own emacs agenda,

Done in Org's git repository, thanks.

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

"Roland Winkler" <winkler@gnu.org> writes:

> On Sun Feb 10 2013 Bastien wrote:
>> Please provide a patch.
>
> I'd much appreciate if the org developers could do that. I have
> enough such things on my own emacs agenda,

Done in Org's git repository, thanks.

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> Please provide a patch.

I'd much appreciate if the org developers could do that. I have
enough such things on my own emacs agenda,

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

"Roland Winkler" <winkler@gnu.org> writes:

> I do not find the info nodes on "Structural markup elements"
> particularly overloaded. The node "Emphasis and monospace" is just
> one short paragraph, and org-fontify-emphasized-text could esily be
> mentioned there -- unless this variable also affects other things,
> so that it should be mentioned higher up in the node hierarchy.

Please provide a patch.

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Roland Winkler]

On Sun Feb 10 2013 Bastien wrote:
> > Why put this in a separate FAQ? Aren't the info pages the first
> > source of information for such things?
> 
> Depends.  We try to keep the info manual readable, and it's already
> quite long.  If you can find a good place in the manual, please send
> a patch.

I do not find the info nodes on "Structural markup elements"
particularly overloaded. The node "Emphasis and monospace" is just
one short paragraph, and org-fontify-emphasized-text could esily be
mentioned there -- unless this variable also affects other things,
so that it should be mentioned higher up in the node hierarchy.

If such things get distributed among different places, an info
manual plus a separate FAQ, they get yet more confusing, in
particular for casual users of org mode. Many users will not even
know (or expect) that the info manual does not give them the full
story, but they need to consult other sources, too.

Take the elisp manual: it's pretty big. But I like it because its
authors are pretty good in making it an *efficient* and *reliable*
source of information. (Here I'd like to put these words in bold,
because I really appreciate this!)

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

Hi Roland,

"Roland Winkler" <winkler@gnu.org> writes:

> There are spaces both between the 2nd and 3rd line, and between the
> 5th and 6th line. -- Possibly, the regexp matcher could distinguish
> in a smarter way between  word constituents and no word constituents.

Sorry I wasn't clear: by default, space is not allowed after the first
"*" and before the second "*".

But yes, `org-emphasis-regexp-components' is perhaps too complex and
we have been thinking of implementing this another way.  Stay tuned.

>> (setq org-fontify-emphasized-text nil)
>
> Thanks, I'll use that.
>
>> > The org info node on structural markup
>> > elements does not mention such a possibility. 
>> 
>> Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
>> FAQ for this.
>
> Why put this in a separate FAQ? Aren't the info pages the first
> source of information for such things?

Depends.  We try to keep the info manual readable, and it's already
quite long.  If you can find a good place in the manual, please send
a patch.

Thanks,

-- 
 Bastien

bug#13668: 24.2.93; strike-through in org mode

[Bastien]

Hi Roland,

"Roland Winkler" <winkler@gnu.org> writes:

> visit the following org file with emacs -Q
>
> cat > foo.org <<EOF
> * foo
>   bar (+.2 to .5)
>   baz (+.2 to .5)
>
>   bar (+.2 to .5)
>   baz  +.2 to .5)
> EOF
>
> Why are part of the second and third line striked through?

Because "+" tries to add fontification.

> According to the org info pages there is some regexp-based feature
> of that kind. 

Yes, see `org-emphasis-regexp-components'.

> But it appears to me that this feature could use a
> more sophisticated regexp matcher. Note that the 5th and 6th line
> are not striked through.

Because the space isn't allowed within +...+ fontified constructs.

> Also, as an occassional org mode user without a need for very fancy
> things, I am wondering whether I can simply switch off such
> structural markup elements. 

(setq org-fontify-emphasized-text nil)

> The org info node on structural markup
> elements does not mention such a possibility. 

Mhh.. yes, I'll perhaps update the manual, or just add a Worg 
FAQ for this.

> I would prefer if, as a
> general strategy, the default values for such features were less
> aggressive.

We try to not make them agressive.  But the text you quoted above
looks like an example that could be in fixed-with block like this :

:  bar (+.2 to .5)
:  baz (+.2 to .5)

:  bar (+.2 to .5)
:  baz  +.2 to .5)

or in another block where *...* constructs are not fontified.

Thanks,

-- 
 Bastien