Bug: Invalid face reference

Bug: Invalid face reference

[Wanrong Lin]

Hi,

I found something really strange:

Whenever I do a search (either "tags-todo" search, or "todo" search), as 
long as the search result contains an entry with tags, the "*Messages*" 
buffer will generate a message like this:

Invalid face reference: nil [164 times]

The number "164" above is just an example. What actually happens is that 
the number keeps increasing (sometimes to over a thousand) and then 
stops. But if I move the cursor (in the search result buffer) to a line 
that has a tag, the number will increase again.

I remember months ago I had trouble using "htmlize.el" on a tag search 
result buffer because of some "invalid face" error, and somebody on this 
mailing list gave me a workaround  like this:

(eval-after-load "htmlize"
  '(progn
     (defadvice htmlize-faces-in-buffer (after org-no-nil-faces activate)
       "Make sure there are no nil faces"
       (setq ad-return-value (delq nil ad-return-value)))))

That does work for htmlize, but I think based on my above observation, 
the problem has nothing to do with "htmlize.el" and something probably 
is wrong in org itself. I am using org 5.22a.

Thanks if someone can look into it.

Wanrong

Re: Bug: Invalid face reference

[Bastien]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> I found something really strange:
>
> Whenever I do a search (either "tags-todo" search, or "todo" search),
> as long as the search result contains an entry with tags, the
> "*Messages*" buffer will generate a message like this:
>
> Invalid face reference: nil [164 times]

I see you're using Windows.  
What version of Emacs are you running on it? 

-- 
Bastien

Re: Bug: Invalid face reference

[Wanrong Lin]

Bastien wrote:
> Wanrong Lin <wanrong.lin@gmail.com> writes:
>
>   
>> I found something really strange:
>>
>> Whenever I do a search (either "tags-todo" search, or "todo" search),
>> as long as the search result contains an entry with tags, the
>> "*Messages*" buffer will generate a message like this:
>>
>> Invalid face reference: nil [164 times]
>>     
>
> I see you're using Windows.  
> What version of Emacs are you running on it? 
>
>   

I am using Emacs 22.1. Actually I also tested on Linux (with Emacs 22.1 
too), and I saw the same thing.

Re: Bug: Invalid face reference

[Wanrong Lin]

>>>     
>>
>> I see you're using Windows.  What version of Emacs are you running on 
>> it?
>>   
>
> I am using Emacs 22.1. Actually I also tested on Linux (with Emacs 
> 22.1 too), and I saw the same thing.
>

Just some update:

I called (org-restart-font-lock) function inside my tag search result 
buffer, and I can see a new "Invalid face reference: nil [X times]" 
message is generated in the "*Messages*" buffer, with "X" keeps 
increasing. I have "jit-lock-mode" (Just in time font locking) enabled 
in my emacs config, so I guess that ticking "X" number is from the 
background font locking process.

It seems something is wrong with font locking for tags. But this only 
happens in tag search result buffer. It does not happen in regular 
agenda buffer.

I don't know how to proceed to pin-point this. Can any of you guys also 
reproduce this? Any suggestions?  Thank you.

Wanrong

Re: Bug: Invalid face reference

[Wanrong Lin]

More update:

In a tag search result buffer, I move the cursor to a tag, and eval 
(get-text-property (point) 'face),  and I get: (org-tag nil). So this 
"nil" is causing the problem, but I don't know where it is sneaked in.

Wanrong

> Just some update:
>
> I called (org-restart-font-lock) function inside my tag search result 
> buffer, and I can see a new "Invalid face reference: nil [X times]" 
> message is generated in the "*Messages*" buffer, with "X" keeps 
> increasing. I have "jit-lock-mode" (Just in time font locking) enabled 
> in my emacs config, so I guess that ticking "X" number is from the 
> background font locking process.
>
> It seems something is wrong with font locking for tags. But this only 
> happens in tag search result buffer. It does not happen in regular 
> agenda buffer.
>
> I don't know how to proceed to pin-point this. Can any of you guys 
> also reproduce this? Any suggestions?  Thank you.
>
> Wanrong
>
>

Re: Re: Bug: Invalid face reference

[Bastien]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> In a tag search result buffer, I move the cursor to a tag, and eval
> (get-text-property (point) 'face),  and I get: (org-tag nil). So this
> "nil" is causing the problem, but I don't know where it is sneaked in.

Thanks for the update.

Here I get (org-tag org-level-1) when I fetch the 'face property in a
tag at a headline on the first level.  

So it looks like the headline face is not properly set.  I first thought
it might be because of `org-level-color-stars-only' being nil, but then
the value for the 'face property in a tag is (org-tag), which is okay.

I still cannot reproduce the problem, but I guess we're getting close to
the solution.  

Maybe something weirdness happens because `org-get-level-face' does not
behave the same in your version of Emacs.  Just a wild guess.

-- 
Bastien

Re: Bug: Invalid face reference

[Wanrong Lin]

Found the bug and fixed it as following (see the comment line marked 
with <WL>)
-------------
(defun org-agenda-align-tags (&optional line)
  "Align all tags in agenda items to `org-agenda-tags-column'."
  (let ((inhibit-read-only t) l c)
    (save-excursion
      (goto-char (if line (point-at-bol) (point-min)))
      (while (re-search-forward (org-re "\\([ 
\t]+\\)\\(:[[:alnum:]_@:]+:\\)[ \t]*$")
                (if line (point-at-eol) nil) t)
    (add-text-properties
     (match-beginning 2) (match-end 2)
     ;; <WL>: bug fix against 5.22a
     (list 'face (delq nil (list 'org-tag (get-text-property
                                           (match-beginning 2) 'face)))))
    (setq l (- (match-end 2) (match-beginning 2))
          c (if (< org-agenda-tags-column 0)
            (- (abs org-agenda-tags-column) l)
          org-agenda-tags-column))
    (delete-region (match-beginning 1) (match-end 1))
    (goto-char (match-beginning 1))
    (insert (org-add-props
            (make-string (max 1 (- c (current-column))) ?\ )
            (text-properties-at (point))))))))


Wanrong Lin wrote:
> More update:
>
> In a tag search result buffer, I move the cursor to a tag, and eval 
> (get-text-property (point) 'face),  and I get: (org-tag nil). So this 
> "nil" is causing the problem, but I don't know where it is sneaked in.
>
> Wanrong
>
>> Just some update:
>>
>> I called (org-restart-font-lock) function inside my tag search result 
>> buffer, and I can see a new "Invalid face reference: nil [X times]" 
>> message is generated in the "*Messages*" buffer, with "X" keeps 
>> increasing. I have "jit-lock-mode" (Just in time font locking) 
>> enabled in my emacs config, so I guess that ticking "X" number is 
>> from the background font locking process.
>>
>> It seems something is wrong with font locking for tags. But this only 
>> happens in tag search result buffer. It does not happen in regular 
>> agenda buffer.
>>
>> I don't know how to proceed to pin-point this. Can any of you guys 
>> also reproduce this? Any suggestions?  Thank you.
>>
>> Wanrong
>>
>>
>
>

Re: Bug: Invalid face reference

[Wanrong Lin]

Also, I found the following htmlize workaound in org.el, so seems the 
workround is already built-in in org-mode. Hopefully with the bug fix 
this can be removed.

-----
;; Fix a bug in htmlize where there are text properties (face nil)
(eval-after-load "htmlize"
  '(progn
     (defadvice htmlize-faces-in-buffer (after org-no-nil-faces activate)
       "Make sure there are no nil faces"
       (setq ad-return-value (delq nil ad-return-value)))))


Wanrong Lin wrote:
> Found the bug and fixed it as following (see the comment line marked 
> with <WL>)
> -------------
> (defun org-agenda-align-tags (&optional line)
>  "Align all tags in agenda items to `org-agenda-tags-column'."
>  (let ((inhibit-read-only t) l c)
>    (save-excursion
>      (goto-char (if line (point-at-bol) (point-min)))
>      (while (re-search-forward (org-re "\\([ 
> \t]+\\)\\(:[[:alnum:]_@:]+:\\)[ \t]*$")
>                (if line (point-at-eol) nil) t)
>    (add-text-properties
>     (match-beginning 2) (match-end 2)
>     ;; <WL>: bug fix against 5.22a
>     (list 'face (delq nil (list 'org-tag (get-text-property
>                                           (match-beginning 2) 'face)))))
>    (setq l (- (match-end 2) (match-beginning 2))
>          c (if (< org-agenda-tags-column 0)
>            (- (abs org-agenda-tags-column) l)
>          org-agenda-tags-column))
>    (delete-region (match-beginning 1) (match-end 1))
>    (goto-char (match-beginning 1))
>    (insert (org-add-props
>            (make-string (max 1 (- c (current-column))) ?\ )
>            (text-properties-at (point))))))))
>
>
> Wanrong Lin wrote:
>> More update:
>>
>> In a tag search result buffer, I move the cursor to a tag, and eval 
>> (get-text-property (point) 'face),  and I get: (org-tag nil). So this 
>> "nil" is causing the problem, but I don't know where it is sneaked in.
>>
>> Wanrong
>>
>>> Just some update:
>>>
>>> I called (org-restart-font-lock) function inside my tag search 
>>> result buffer, and I can see a new "Invalid face reference: nil [X 
>>> times]" message is generated in the "*Messages*" buffer, with "X" 
>>> keeps increasing. I have "jit-lock-mode" (Just in time font locking) 
>>> enabled in my emacs config, so I guess that ticking "X" number is 
>>> from the background font locking process.
>>>
>>> It seems something is wrong with font locking for tags. But this 
>>> only happens in tag search result buffer. It does not happen in 
>>> regular agenda buffer.
>>>
>>> I don't know how to proceed to pin-point this. Can any of you guys 
>>> also reproduce this? Any suggestions?  Thank you.
>>>
>>> Wanrong
>>>
>>>
>>
>>
>
>

Re: Re: Bug: Invalid face reference

[Carsten Dominik]

I am taking this patch thanks!

This might indeed make the advice for htmlize unnecessary - could you  
please
remove it your own setup and test this for a long while?  And then
report back?

Thanks!

- Carsten

On Feb 29, 2008, at 7:41 PM, Wanrong Lin wrote:

> Found the bug and fixed it as following (see the comment line marked  
> with <WL>)
> -------------
> (defun org-agenda-align-tags (&optional line)
> "Align all tags in agenda items to `org-agenda-tags-column'."
> (let ((inhibit-read-only t) l c)
>   (save-excursion
>     (goto-char (if line (point-at-bol) (point-min)))
>     (while (re-search-forward (org-re "\\([ \t]+\\)\\(:[[:alnum:]_@:] 
> +:\\)[ \t]*$")
>               (if line (point-at-eol) nil) t)
>   (add-text-properties
>    (match-beginning 2) (match-end 2)
>    ;; <WL>: bug fix against 5.22a
>    (list 'face (delq nil (list 'org-tag (get-text-property
>                                          (match-beginning 2)  
> 'face)))))
>   (setq l (- (match-end 2) (match-beginning 2))
>         c (if (< org-agenda-tags-column 0)
>           (- (abs org-agenda-tags-column) l)
>         org-agenda-tags-column))
>   (delete-region (match-beginning 1) (match-end 1))
>   (goto-char (match-beginning 1))
>   (insert (org-add-props
>           (make-string (max 1 (- c (current-column))) ?\ )
>           (text-properties-at (point))))))))
>
>
> Wanrong Lin wrote:
>> More update:
>>
>> In a tag search result buffer, I move the cursor to a tag, and eval  
>> (get-text-property (point) 'face),  and I get: (org-tag nil). So  
>> this "nil" is causing the problem, but I don't know where it is  
>> sneaked in.
>>
>> Wanrong
>>
>>> Just some update:
>>>
>>> I called (org-restart-font-lock) function inside my tag search  
>>> result buffer, and I can see a new "Invalid face reference: nil [X  
>>> times]" message is generated in the "*Messages*" buffer, with "X"  
>>> keeps increasing. I have "jit-lock-mode" (Just in time font  
>>> locking) enabled in my emacs config, so I guess that ticking "X"  
>>> number is from the background font locking process.
>>>
>>> It seems something is wrong with font locking for tags. But this  
>>> only happens in tag search result buffer. It does not happen in  
>>> regular agenda buffer.
>>>
>>> I don't know how to proceed to pin-point this. Can any of you guys  
>>> also reproduce this? Any suggestions?  Thank you.
>>>
>>> Wanrong
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> 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: Re: Bug: Invalid face reference

[Wanrong Lin]

I already did so. So far there is no problem. If I don't report 
anything, I think you can assume in the next release that I have no 
problem at all with the htmlize advice removed.

Wanrong

Carsten Dominik wrote:
> I am taking this patch thanks!
>
> This might indeed make the advice for htmlize unnecessary - could you 
> please
> remove it your own setup and test this for a long while?  And then
> report back?
>
> Thanks!
>
> - Carsten
>
> On Feb 29, 2008, at 7:41 PM, Wanrong Lin wrote:
>
>> Found the bug and fixed it as following (see the comment line marked 
>> with <WL>)
>> -------------
>> (defun org-agenda-align-tags (&optional line)
>> "Align all tags in agenda items to `org-agenda-tags-column'."
>> (let ((inhibit-read-only t) l c)
>>   (save-excursion
>>     (goto-char (if line (point-at-bol) (point-min)))
>>     (while (re-search-forward (org-re "\\([ 
>> \t]+\\)\\(:[[:alnum:]_@:]+:\\)[ \t]*$")
>>               (if line (point-at-eol) nil) t)
>>   (add-text-properties
>>    (match-beginning 2) (match-end 2)
>>    ;; <WL>: bug fix against 5.22a
>>    (list 'face (delq nil (list 'org-tag (get-text-property
>>                                          (match-beginning 2) 'face)))))
>>   (setq l (- (match-end 2) (match-beginning 2))
>>         c (if (< org-agenda-tags-column 0)
>>           (- (abs org-agenda-tags-column) l)
>>         org-agenda-tags-column))
>>   (delete-region (match-beginning 1) (match-end 1))
>>   (goto-char (match-beginning 1))
>>   (insert (org-add-props
>>           (make-string (max 1 (- c (current-column))) ?\ )
>>           (text-properties-at (point))))))))
>>
>>
>> Wanrong Lin wrote:
>>> More update:
>>>
>>> In a tag search result buffer, I move the cursor to a tag, and eval 
>>> (get-text-property (point) 'face),  and I get: (org-tag nil). So 
>>> this "nil" is causing the problem, but I don't know where it is 
>>> sneaked in.
>>>
>>> Wanrong
>>>
>>>> Just some update:
>>>>
>>>> I called (org-restart-font-lock) function inside my tag search 
>>>> result buffer, and I can see a new "Invalid face reference: nil [X 
>>>> times]" message is generated in the "*Messages*" buffer, with "X" 
>>>> keeps increasing. I have "jit-lock-mode" (Just in time font 
>>>> locking) enabled in my emacs config, so I guess that ticking "X" 
>>>> number is from the background font locking process.
>>>>
>>>> It seems something is wrong with font locking for tags. But this 
>>>> only happens in tag search result buffer. It does not happen in 
>>>> regular agenda buffer.
>>>>
>>>> I don't know how to proceed to pin-point this. Can any of you guys 
>>>> also reproduce this? Any suggestions?  Thank you.
>>>>
>>>> Wanrong
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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: Re: Bug: Invalid face reference

[Carsten Dominik]

OK, thanks.

- Carsten

On Feb 29, 2008, at 9:44 PM, Wanrong Lin wrote:

>
> I already did so. So far there is no problem. If I don't report  
> anything, I think you can assume in the next release that I have no  
> problem at all with the htmlize advice removed.
>
> Wanrong
>
> Carsten Dominik wrote:
>> I am taking this patch thanks!
>>
>> This might indeed make the advice for htmlize unnecessary - could  
>> you please
>> remove it your own setup and test this for a long while?  And then
>> report back?
>>
>> Thanks!
>>
>> - Carsten
>>
>> On Feb 29, 2008, at 7:41 PM, Wanrong Lin wrote:
>>
>>> Found the bug and fixed it as following (see the comment line  
>>> marked with <WL>)
>>> -------------
>>> (defun org-agenda-align-tags (&optional line)
>>> "Align all tags in agenda items to `org-agenda-tags-column'."
>>> (let ((inhibit-read-only t) l c)
>>>  (save-excursion
>>>    (goto-char (if line (point-at-bol) (point-min)))
>>>    (while (re-search-forward (org-re "\\([ \t]+\\)\\(: 
>>> [[:alnum:]_@:]+:\\)[ \t]*$")
>>>              (if line (point-at-eol) nil) t)
>>>  (add-text-properties
>>>   (match-beginning 2) (match-end 2)
>>>   ;; <WL>: bug fix against 5.22a
>>>   (list 'face (delq nil (list 'org-tag (get-text-property
>>>                                         (match-beginning 2)  
>>> 'face)))))
>>>  (setq l (- (match-end 2) (match-beginning 2))
>>>        c (if (< org-agenda-tags-column 0)
>>>          (- (abs org-agenda-tags-column) l)
>>>        org-agenda-tags-column))
>>>  (delete-region (match-beginning 1) (match-end 1))
>>>  (goto-char (match-beginning 1))
>>>  (insert (org-add-props
>>>          (make-string (max 1 (- c (current-column))) ?\ )
>>>          (text-properties-at (point))))))))
>>>
>>>
>>> Wanrong Lin wrote:
>>>> More update:
>>>>
>>>> In a tag search result buffer, I move the cursor to a tag, and  
>>>> eval (get-text-property (point) 'face),  and I get: (org-tag  
>>>> nil). So this "nil" is causing the problem, but I don't know  
>>>> where it is sneaked in.
>>>>
>>>> Wanrong
>>>>
>>>>> Just some update:
>>>>>
>>>>> I called (org-restart-font-lock) function inside my tag search  
>>>>> result buffer, and I can see a new "Invalid face reference: nil  
>>>>> [X times]" message is generated in the "*Messages*" buffer, with  
>>>>> "X" keeps increasing. I have "jit-lock-mode" (Just in time font  
>>>>> locking) enabled in my emacs config, so I guess that ticking "X"  
>>>>> number is from the background font locking process.
>>>>>
>>>>> It seems something is wrong with font locking for tags. But this  
>>>>> only happens in tag search result buffer. It does not happen in  
>>>>> regular agenda buffer.
>>>>>
>>>>> I don't know how to proceed to pin-point this. Can any of you  
>>>>> guys also reproduce this? Any suggestions?  Thank you.
>>>>>
>>>>> Wanrong
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> _______________________________________________
> 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