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