Re: Faces bug in org-indent-mode

[Carsten Dominik <carsten.dominik@gmail.com>]

Hi Daniel,

thanks for looking deeper into the issue.

As you have noticed yourself, your proposal fixes only half of
the problem.  Doing this emphasis with a regular expression
is really hard, and each time you change something, another
thing will break.  The real solution for this would be to
switch to a programmed solution instead of a regular
expression search.

Your proposed change does fix a problem, but it also breaks
the structure of how the emphasis regexp is constructed.  BODY
is supposed to match a character that should be emphasized.  Maybe
it can be re-written so that this does not have to be part of the BODY.

Also, there are similar issues with this in tables: Try

   | *h | h  |
   | h  | h* |

or also with comments:

  Some text *h mamma mia
# terminate bold in comment*

So I will out this on the back burner and try to get myself
to implement programmed emphasis at some point.

Sorry.

- Carsten


On Aug 21, 2009, at 1:03 PM, Daniel Clemente wrote:

> El dj, ago 20 2009 a les 21:57, Carsten Dominik va escriure:
>>>
>>> * something
>>> aaa =eee
>>> * two= *iii
>>> ooo* uuu
>>>
>> Yes, this is kind of hard to fix......  And a minor issue, I  
>> guess... ?
>>
>
>  Yes, it's a minor issue. I like minor issues :-)
>
>  There are two display problems here:
> - a face defined before a heading enters the heading (like the =eee…=)
> - a face defined in a heading goes on past the heading (like the  
> *iii…)
>
>  I did some tests with org-emph-re (original value: [1]); the  
> interesting part is \\(?:\n.*?\\)\\{0,1\\} because it is the one  
> that allows the face to extend up to 1 line below.
>  The .*? from there comes from the so-called body in org-emphasis- 
> regexp-components, body="."
>  I have done some tests and I think that body="\\(?:\\*+[^\n ]\\|[^ 
> \n*]\\)." fixes the first problem. The expression represents a non- 
> heading line: anything not starting by * (except when the initial *  
> precedes a word) and then many other characters (a "*?" at the end  
> will be added by org-set-emph-re)
>  Final value: [2]
>
>  Is this added complexity worth it? The bug is unpleasant (headings  
> aren't coloured as headings) and performance shouldn't be much  
> affected in the common case because ^\\* fails early. Only visually  
> it is a complex regexp.
>
>  I don't know how to detect the other problem inside a regular  
> expression. Maybe there's some way to ask „don't cross boundaries  
> between headings and content“.
>
>
> -- Daniel
>
> [1]: "\\([ 	('`\"{]\\|^\\)\\(\\([*/_=~+]\\)\\([^ 	
> \n,\"']\\|[^ 	
> \n,\"'].*?\\(?:\n.*?\\)\\{0,1\\}[^ 	
> \n,\"']\\)\\3\\)\\([- 	.,:!?;'\")}\\]\\|$\\)"
>
> [2]: "\\([ 	('`\"{]\\|^\\)\\(\\([*/_=~+]\\)\\([^ 	
> \n,\"']\\|[^ 	
> \n,\"'].*?\\(?:\n\\*+[^\n ].*?\\|\n[^\n*].*?\\)\\{0,1\\}[^ 	
> \n,\"']\\)\\3\\)\\([- 	.,:!?;'\")}\\]\\|$\\)"
>
>