Faces bug in org-indent-mode

Faces bug in org-indent-mode

[Jason F. McBrayer]

There's a little problem with faces in org-indent-mode.  Faces that
highlight to the end of the line (hl-line-face, org-level-faces if
org-fontify-whole-header-line is on, etc) get carried over to the start
of text on the next line.  Faces like that are pretty rare, but I
thought I'd go ahead and report this.
-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray@carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

Re: Faces bug in org-indent-mode

[Daniel Clemente]

I don't know if it's the same as what you report, but I can see the same behaviour also in this file:


* something
aaa =eee
* two= *iii
ooo* uuu


  Open/close/expand/contract as needed. In my Emacs 23 with latest org I see it wrongly highlighted just after opening it (headings contracted):
  What I see wrong is:
- the „code“ face comprises =eee \n* two=
- the „bold“ face comprises *iii\nooo*
( \n = ⏎ = line break ). So both span past the end of the line. This only happens if the next line is consecutive (with no blank lines).

-- Daniel



El dj, ago 20 2009 a les 15:07, Jason F. McBrayer va escriure:
> There's a little problem with faces in org-indent-mode.  Faces that
> highlight to the end of the line (hl-line-face, org-level-faces if
> org-fontify-whole-header-line is on, etc) get carried over to the start
> of text on the next line.  Faces like that are pretty rare, but I
> thought I'd go ahead and report this.

Re: Faces bug in org-indent-mode

[Carsten Dominik]

Hi,

that is an Emacs bug, not an Org-mode bug.

- Carsten

On Aug 20, 2009, at 2:07 PM, Jason F. McBrayer wrote:

> There's a little problem with faces in org-indent-mode.  Faces that
> highlight to the end of the line (hl-line-face, org-level-faces if
> org-fontify-whole-header-line is on, etc) get carried over to the  
> start
> of text on the next line.  Faces like that are pretty rare, but I
> thought I'd go ahead and report this.
> -- 
> +-----------------------------------------------------------+
> | Jason F. McBrayer                    jmcbray@carcosa.net  |
> | If someone conquers a thousand times a thousand others in |
> | battle, and someone else conquers himself, the latter one |
> | is the greatest of all conquerors.  --- The Dhammapada    |
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Faces bug in org-indent-mode

[Carsten Dominik]

On Aug 20, 2009, at 2:34 PM, Daniel Clemente wrote:

>
> I don't know if it's the same as what you report, but I can see the  
> same behaviour also in this file:
>
>
> * something
> aaa =eee
> * two= *iii
> ooo* uuu
>
>
>  Open/close/expand/contract as needed. In my Emacs 23 with latest  
> org I see it wrongly highlighted just after opening it (headings  
> contracted):
>  What I see wrong is:
> - the „code“ face comprises =eee \n* two=
> - the „bold“ face comprises *iii\nooo*
> ( \n = ⏎ = line break ). So both span past the end of the line.  
> This only happens if the next line is consecutive (with no blank  
> lines).

Yes, this is kind of hard to fix......  And a minor issue, I guess... ?

- Carsten


>
> -- Daniel
>
>
>
> El dj, ago 20 2009 a les 15:07, Jason F. McBrayer va escriure:
>> There's a little problem with faces in org-indent-mode.  Faces that
>> highlight to the end of the line (hl-line-face, org-level-faces if
>> org-fontify-whole-header-line is on, etc) get carried over to the  
>> start
>> of text on the next line.  Faces like that are pretty rare, but I
>> thought I'd go ahead and report this.
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Faces bug in org-indent-mode

[Daniel Clemente]

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]: "\\([ 	('`\"{]\\|^\\)\\(\\([*/_=~+]\\)\\([^ 	\r\n,\"']\\|[^ 	\r\n,\"'].*?\\(?:\n.*?\\)\\{0,1\\}[^ 	\r\n,\"']\\)\\3\\)\\([- 	.,:!?;'\")}\\]\\|$\\)"

[2]: "\\([ 	('`\"{]\\|^\\)\\(\\([*/_=~+]\\)\\([^ 	\r\n,\"']\\|[^ 	\r\n,\"'].*?\\(?:\n\\*+[^\n ].*?\\|\n[^\n*].*?\\)\\{0,1\\}[^ 	\r\n,\"']\\)\\3\\)\\([- 	.,:!?;'\")}\\]\\|$\\)"

Re: Faces bug in org-indent-mode

[Carsten Dominik]

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\\)\\([- 	.,:!?;'\")}\\]\\|$\\)"
>
>

Re: Faces bug in org-indent-mode

[Daniel Clemente]

El dt, ago 25 2009 a les 09:56, Carsten Dominik va escriure:

> thing will break.  The real solution for this would be to
> switch to a programmed solution instead of a regular
> expression search.
>
  Or many regular expressions, one for each context: table, heading, comment, text, …
  Based on the context, you choose one or another. To know the context, there may be some text property set at each point.
  If Emacs had a way to check for a text property (or even a face) inside a regexp, this could be easier. You could still use a single expression which would direct to the context-specific part, like in:  \p{heading}REGEXP_ONLY_FOR_HEADINGS\|\p{table}REGEXP_FOR_TABLES\|…   where \p{property} is the proposed addition to Emacs regexps.


  This was a minor issue, but making Emacs regexps more powerful would be nice.

-- Daniel

  

Re: Faces bug in org-indent-mode

[Carsten Dominik]

On Aug 26, 2009, at 1:42 PM, Daniel Clemente wrote:

> El dt, ago 25 2009 a les 09:56, Carsten Dominik va escriure:
>
>> thing will break.  The real solution for this would be to
>> switch to a programmed solution instead of a regular
>> expression search.
>>
>  Or many regular expressions, one for each context: table, heading,  
> comment, text, …
>  Based on the context, you choose one or another. To know the  
> context, there may be some text property set at each point.
>  If Emacs had a way to check for a text property (or even a face)  
> inside a regexp, this could be easier. You could still use a single  
> expression which would direct to the context-specific part, like  
> in:  \p{heading}REGEXP_ONLY_FOR_HEADINGS\|\p{table}REGEXP_FOR_TABLES 
> \|…   where \p{property} is the proposed addition to Emacs regexps.

All we would really need are positive and negative look-ahead
and look-behind assertions as the Perl regular expression allows them.

- Carsten