[PATCH] Use font-lock-face property in org-src-font-lock-fontify-block?

[PATCH] Use font-lock-face property in org-src-font-lock-fontify-block?

[Takafumi Arakaki]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Hi,

I am trying to use org-src.el bundled in org-mode to support syntax
highlighgint for multiple languages in my IPython notebook client in
Emacs (EIN) [1].  It works very well but I need to patch (please see the
attached file) it to use. The problem is that fontification is gone when I
edit the buffer.  I found that I can workaround this problem by
putting font-lock-face property instead of face property.

When the fontification vanishes,

    (text-properties-at (point))

returns

    (font-lock-fontified t fontified t)

Before the fontification vanishes (before inserting a cell),

    (text-properties-at (point))

returns this at the same point:

    (font-lock-multiline t face font-lock-keyword-face
font-lock-fontified t fontified t)

I couldn't reproduce this problem outside of EIN (in org-mode or
other plain buffers).


I am thinking about including my version of
org-src-font-lock-fontify-block in EIN, but Dan Davison suggested to
ask in this ML because it could be a problem in org-mode too.
Does anyone know what is happening here?  Could this happen in
org-mode too?


See [2] for the original discussion.

[1] https://github.com/tkf/emacs-ipython-notebook/
[2] https://github.com/tkf/emacs-ipython-notebook/issues/2

[-- Attachment #2: org-src.patch --]
[-- Type: application/octet-stream, Size: 548 bytes --]

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 496dafe..1e3a1d8 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -796,7 +796,7 @@ fontification of code blocks see `org-src-fontify-block' and
        (setq pos (point-min))
        (while (setq next (next-single-property-change pos 'face))
          (put-text-property
-          (+ start (1- pos)) (+ start next) 'face
+          (+ start (1- pos)) (+ start next) 'font-lock-face
           (get-text-property pos 'face) org-buffer)
          (setq pos next)))
      (add-text-properties

Re: [PATCH] Use font-lock-face property in org-src-font-lock-fontify-block?

[Bastien]

Hi Takafumi,

Takafumi Arakaki <aka.tkf@gmail.com> writes:

> I am thinking about including my version of
> org-src-font-lock-fontify-block in EIN, but Dan Davison suggested to
> ask in this ML because it could be a problem in org-mode too.

I'm not sure I understand the problem you are trying to fix for your own
code here but things work fine here in Org.

> Does anyone know what is happening here? 

Not really.   Do you always need this or is it just for some modes?
Maybe those modes use `font-lock-face' while other modes use `face'
and highlighting in Src Blocks would need to add `font-lock-face' in 
the first case while just adding `face' in  the second one.

Perhaps adding both is some extra security...  but I'd rather wait
for a real bug in Org :)

Thanks anyway for reporting this,

-- 
 Bastien

Re: [PATCH] Use font-lock-face property in org-src-font-lock-fontify-block?

[Takafumi Arakaki]

Hi Bastien,

Thanks. I will bundle my version of the function in my module while
watching development of org-src.el.  I will report again if I find
something.

Takafumi


On Fri, Sep 28, 2012 at 8:53 AM, Bastien <bzg@altern.org> wrote:
> Hi Takafumi,
>
> Takafumi Arakaki <aka.tkf@gmail.com> writes:
>
>> I am thinking about including my version of
>> org-src-font-lock-fontify-block in EIN, but Dan Davison suggested to
>> ask in this ML because it could be a problem in org-mode too.
>
> I'm not sure I understand the problem you are trying to fix for your own
> code here but things work fine here in Org.
>
>> Does anyone know what is happening here?
>
> Not really.   Do you always need this or is it just for some modes?
> Maybe those modes use `font-lock-face' while other modes use `face'
> and highlighting in Src Blocks would need to add `font-lock-face' in
> the first case while just adding `face' in  the second one.
>
> Perhaps adding both is some extra security...  but I'd rather wait
> for a real bug in Org :)
>
> Thanks anyway for reporting this,
>
> --
>  Bastien