colours lost

colours lost

[Madhu]

* [posted on gnu.emacs.help 2019-01-06]
  <m3ef9psumc.fsf@leonis4.robolove.meer.net>

I'm running an X toolkit build (master from around november) and very
recently I am losing all colours both under X and tty. Typically I start
emacs via --daemon and attach to it via both X and tty.

What I mean is eg. M-x list-colors-display shows a buffer in which all
the the lines are displayed with foreground colour set to the default
foreground, background colour to the default background, and font set to
the default-font.  Same with happens M-x list-faces-display.  colours
set via font-lock still work.  Emacs starts off ok but somewhere this
gets triggered and I can't think of what I've been doing recently that
causes this.  Where do I start looking for the code which handles this?
---Madhu

Re: colours lost

[Eli Zaretskii]

> From: Madhu <enometh@net.meer>
> Date: Thu, 14 Feb 2019 12:40:58 +0530
> 
> I'm running an X toolkit build (master from around november) and very
> recently I am losing all colours both under X and tty. Typically I start
> emacs via --daemon and attach to it via both X and tty.
> 
> What I mean is eg. M-x list-colors-display shows a buffer in which all
> the the lines are displayed with foreground colour set to the default
> foreground, background colour to the default background, and font set to
> the default-font.  Same with happens M-x list-faces-display.  colours
> set via font-lock still work.  Emacs starts off ok but somewhere this
> gets triggered and I can't think of what I've been doing recently that
> causes this.  Where do I start looking for the code which handles this?

Does "M-x list-faces-display" also show all the faces the same, both
colors and fonts?  If so, it sounds like something is redefining all
the faces, and you should look at your customizations related to
faces.

Thinking a bit more about this: if all the colors are suddenly lost,
you should see it happening immediately, and so the last thing you did
is a good starting point for looking for the culprit.

Re: colours lost

[Madhu]

* Eli Zaretskii <83pnruo2ub.fsf@gnu.org> :
Wrote on Thu, 14 Feb 2019 16:35:08 +0200:

>> From: Madhu <enometh@net.meer>
>> Date: Thu, 14 Feb 2019 12:40:58 +0530
>>
>> I'm running an X toolkit build (master from around november) and very
>> recently I am losing all colours both under X and tty. Typically I start
>> emacs via --daemon and attach to it via both X and tty.
>>
>> What I mean is eg. M-x list-colors-display shows a buffer in which all
>> the the lines are displayed with foreground colour set to the default
>> foreground, background colour to the default background, and font set to
>> the default-font.  Same with happens M-x list-faces-display.  colours
>> set via font-lock still work.  Emacs starts off ok but somewhere this
>> gets triggered and I can't think of what I've been doing recently that
>> causes this.  Where do I start looking for the code which handles this?
>
> Does "M-x list-faces-display" also show all the faces the same, both
> colors and fonts?

Yes

> If so, it sounds like something is redefining all the faces, and you
> should look at your customizations related to faces.
>
> Thinking a bit more about this: if all the colors are suddenly lost,
> you should see it happening immediately, and so the last thing you did
> is a good starting point for looking for the culprit.

I haven't figured out what triggers the problem yet, but the clue is it
is related to global-font-lock-mode.

When the problem described occurs, global-font-lock-mode is t.

C-u C-x = on a piece of text which shows the bold face in the *Faces*
buffer shows:
,----
| There are text properties here:
|   button               (t)
|   category             help-face-button
|   fontified            t
|   help-args            (bold)
|   read-face-name       bold
`----

After setting (global-font-lock-mode -1) and reverting *Faces* restores
the list-faces-display as expected.

Now C-u C-x = shows
,----
| There are text properties here:
|   button               (t)
|   category             help-face-button
|   face                 bold
|   help-args            (bold)
|   read-face-name       bold
`----

So When the problem occurs all text is "fontified" and faces seem to
be ignored.

Still looking for another clue..
---Madhu

Re: colours lost

[Noam Postavsky]

On Wed, 15 May 2019 at 09:15, Madhu <enometh@meer.net> wrote:

> I haven't figured out what triggers the problem yet, but the clue is it
> is related to global-font-lock-mode.
>
> When the problem described occurs, global-font-lock-mode is t.
>
> C-u C-x = on a piece of text which shows the bold face in the *Faces*
> buffer shows:
> ,----
> | There are text properties here:
> |   button               (t)
> |   category             help-face-button
> |   fontified            t
> |   help-args            (bold)
> |   read-face-name       bold
> `----
>
> After setting (global-font-lock-mode -1) and reverting *Faces* restores
> the list-faces-display as expected.
>
> Now C-u C-x = shows
> ,----
> | There are text properties here:
> |   button               (t)
> |   category             help-face-button
> |   face                 bold
> |   help-args            (bold)
> |   read-face-name       bold
> `----
>
> So When the problem occurs all text is "fontified" and faces seem to
> be ignored.

Sounds like it could be another instance of Bug#35481. Maybe you are
enabling some minor mode which calls font-lock-add-keywords or
similar?

See https://debbugs.gnu.org/35481 and also https://debbugs.gnu.org/35044.

Re: colours lost

[Madhu]

* Noam Postavsky  <CAM-tV-9rsqFrrX31dB66m=h6cfW7HrawvhUCLXMtUUqYos78=g@mail.gmail.com> :
Wrote on Wed, 15 May 2019 09:31:42 -0400:

> On Wed, 15 May 2019 at 09:15, Madhu <enometh@meer.net> wrote:
>
>> I haven't figured out what triggers the problem yet, but the clue is
>> it is related to global-font-lock-mode.
>>
>> When the problem described occurs, global-font-lock-mode is t.
>>
>> C-u C-x = on a piece of text which shows the bold face in the *Faces*
>> buffer shows:
>> ,----
>> | There are text properties here:
>> |   button               (t)
>> |   category             help-face-button
>> |   fontified            t
>> |   help-args            (bold)
>> |   read-face-name       bold
>> `----
>>
>> After setting (global-font-lock-mode -1) and reverting *Faces* restores
>> the list-faces-display as expected.
>>
>> Now C-u C-x = shows
>> ,----
>> | There are text properties here:
>> |   button               (t)
>> |   category             help-face-button
>> |   face                 bold
>> |   help-args            (bold)
>> |   read-face-name       bold
>> `----
>>
>> So When the problem occurs all text is "fontified" and faces seem to
>> be ignored.
>
> Sounds like it could be another instance of Bug#35481. Maybe you are
> enabling some minor mode which calls font-lock-add-keywords or
> similar?
>
> See https://debbugs.gnu.org/35481 and also https://debbugs.gnu.org/35044.

I've extracted one twisted test case from my .emacs and it is something
of a mystery.

;; Put this form in a file, say f.el

(eval-after-load 'gnus-sum
  '(progn
     (defadvice gnus-summary-save-article (after rmail-label-prompter-advice activate)
       (if (eq gnus-default-article-saver 'gnus-summary-save-in-rmail)
	   (message "foo")
	 (message "bar"))) ))

Then open a file which does not autoload org-mode but which can be
converted to org-mode. For example I use hyperbole's DEMO file:

emacs -Q -eval '(list-colors-display)' -l f.el ~/elisp/pkg/hyperbole/DEMO

Then with DEMO as the current buffer, do M-x org-mode

Then M-x list-colors-display shows my colours are gone.

(gnus-default-article-saver is a variable defined n gnus-art and may not
be defined when gnus-sum is loaded.)

[Unrelated notes]

1 Although this mailing list is being propagated to the usenet group, the
posts on the usenet group do not seem to make it to the mailing list.

2 Setting mail-user-agent to message-user-agent instead of
sendmail-user-agent drops all the References headers when replying to a
mail from a gnus summary buffer.

-- 

Re: colours lost

[Madhu]

I'm curious if anyone was able to reproduce this.  Maybe some more
changes in the emacs custom mechanism will push the bug away..


* Madhu <mailman.339.1562429193.2688.help-gnu-emacs@gnu.org> :
> I've extracted one twisted test case from my .emacs and it is something
> of a mystery.
>
> ;; Put this form in a file, say f.el
>
> (eval-after-load 'gnus-sum
>   '(progn
>      (defadvice gnus-summary-save-article (after rmail-label-prompter-advice activate)
>        (if (eq gnus-default-article-saver 'gnus-summary-save-in-rmail)
> 	   (message "foo")
> 	 (message "bar"))) ))
>
> Then open a file which does not autoload org-mode but which can be
> converted to org-mode. For example I use hyperbole's DEMO file:
>
> emacs -Q -eval '(list-colors-display)' -l f.el ~/elisp/pkg/hyperbole/DEMO
>
> Then with DEMO as the current buffer, do M-x org-mode
>
> Then M-x list-colors-display shows my colours are gone.
>
> (gnus-default-article-saver is a variable defined n gnus-art and may not
> be defined when gnus-sum is loaded.)
>
> [Unrelated notes]
>
> 1 Although this mailing list is being propagated to the usenet group, the
> posts on the usenet group do not seem to make it to the mailing list.
>
> 2 Setting mail-user-agent to message-user-agent instead of
> sendmail-user-agent drops all the References headers when replying to a
> mail from a gnus summary buffer.

> I've extracted one twisted test case from my .emacs and it is something
> of a mystery.
>
> ;; Put this form in a file, say f.el
>
> (eval-after-load 'gnus-sum
>   '(progn
>      (defadvice gnus-summary-save-article (after rmail-label-prompter-advice activate)
>        (if (eq gnus-default-article-saver 'gnus-summary-save-in-rmail)
> 	   (message "foo")
> 	 (message "bar"))) ))
>
> Then open a file which does not autoload org-mode but which can be
> converted to org-mode. For example I use hyperbole's DEMO file:
>
> emacs -Q -eval '(list-colors-display)' -l f.el ~/elisp/pkg/hyperbole/DEMO
>
> Then with DEMO as the current buffer, do M-x org-mode
>
> Then M-x list-colors-display shows my colours are gone.
>
> (gnus-default-article-saver is a variable defined n gnus-art and may not
> be defined when gnus-sum is loaded.)