23.0.50; face-problems with multy-tty

23.0.50; face-problems with multy-tty

[Tassilo Horn]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Since multi-tty has been merged, I start emacs as a detached server with
screen.  Here's the command line I use to reproduce the problem:

  screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
         -Q -l foo.el --funcall server-start

The file foo.el contains my custom-set-faces:

--8<---------------cut here---------------start------------->8---
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(circe-highlight-all-nicks-face ((t (:foreground "blue"))))
 '(circe-highlight-nick-face ((t (:background "grey" :foreground "blue" :weight bold))))
 '(circe-my-message-face ((t (:background "grey"))))
 '(circe-originator-face ((t (:weight bold))))
 '(company-pseudo-tooltip-face ((t (:inherit default :background "yellow" :foreground "black"))))
 '(diff-added ((t (:inherit diff-changed :background "green"))))
 '(diff-changed ((nil (:background "lightblue"))))
 '(diff-removed ((t (:inherit diff-changed :background "orange"))))
 '(diredp-exec-priv ((t (:background "LightSteelBlue" :foreground "black"))))
 '(diredp-no-priv ((t (:background "LightGray" :foreground "black"))))
 '(diredp-read-priv ((t (:background "MediumAquamarine" :foreground "black"))))
 '(diredp-write-priv ((t (:background "Orchid" :foreground "black"))))
 '(emms-browser-album-face ((((class color) (background light)) (:inherit org-level-2))))
 '(emms-browser-artist-face ((((class color) (background light)) (:inherit org-level-1))))
 '(emms-browser-track-face ((((class color) (background light)) (:inherit org-level-3 :weight normal))))
 '(font-lock-string-face ((((class color) (min-colors 88) (background light)) (:foreground "RosyBrown4"))))
 '(gnus-group-mail-3 ((t (:foreground "magenta" :weight bold))))
 '(gnus-group-mail-3-empty ((nil (:inherit gnus-group-mail-3 :weight normal))))
 '(gnus-group-news-3 ((t (:foreground "blue" :weight bold))))
 '(gnus-group-news-3-empty ((nil (:inherit gnus-group-news-3 :weight normal))))
 '(gnus-server-denied ((t (:foreground "red" :weight bold))))
 '(gnus-signature ((t (:foreground "blue" :slant italic))))
 '(header-line ((default nil) (((class color grayscale) (background light)) (:background "grey90" :foreground "grey20" :box nil))))
 '(hl-line ((t (:inherit highlight :background "#BEFFBE"))))
 '(message-header-name ((nil (:inherit gnus-header-name))))
 '(mode-line ((nil (:background "black" :foreground "grey80" :height 0.8 :family "helvetica"))))
 '(mode-line-buffer-id ((t (:background "grey10" :foreground "grey90" :weight bold))))
 '(mode-line-inactive ((default (:inherit mode-line :background "grey80" :foreground "grey20")) (((class color) (min-colors 88) (background light)) (:weight light))))
 '(newsticker-feed-face ((t (:inherit org-level-1 :underline t))))
 '(newsticker-immortal-item-face ((t (:inherit newsticker-new-item-face :foreground "blue"))))
 '(newsticker-new-item-face ((t (:foreground "black" :weight normal))))
 '(newsticker-obsolete-item-face ((t (:inherit newsticker-new-item-face :strike-through t))))
 '(newsticker-old-item-face ((t (:inherit newsticker-new-item-face :foreground "grey60"))))
 '(org-level-1 ((t (:foreground "Blue1" :weight bold))))
 '(org-level-2 ((t (:foreground "DarkGoldenrod" :weight bold))))
 '(org-level-3 ((t (:foreground "Purple" :weight bold))))
 '(org-level-4 ((t (:foreground "Firebrick" :weight bold))))
 '(org-level-5 ((t (:foreground "ForestGreen" :weight bold))))
 '(org-level-6 ((t (:foreground "CadetBlue" :weight bold))))
 '(org-level-7 ((t (:foreground "Orchid" :weight bold))))
 '(org-level-8 ((t (:foreground "RosyBrown" :weight bold))))
 '(outline-1 ((t (:inherit org-level-1))))
 '(outline-2 ((t (:inherit org-level-2))))
 '(outline-3 ((t (:inherit org-level-3))))
 '(outline-4 ((t (:inherit org-level-4))))
 '(outline-5 ((t (:inherit org-level-5))))
 '(outline-6 ((t (:inherit org-level-6))))
 '(outline-7 ((t (:inherit org-level-7))))
 '(outline-8 ((t (:inherit org-level-8))))
 '(region ((t (:background "paleturquoise"))))
 '(tooltip ((((class color)) (:inherit variable-pitch :background "lightblue" :foreground "black" :family "fixed"))))
 '(trailing-whitespace ((nil (:background "grey80"))))
 '(window-number-face ((((type x w32 mac)) (:foreground "red" :weight bold)))))
--8<---------------cut here---------------end--------------->8---

Now I connect to that server with

    emacsclient -s test

which opens a new X11 frame.  Now all faces whose value doesn't start
with t or nil use the default face, e.g. all strings ("foo") in an elisp
file are simply black on white.  If I do `M-x customize-face RET RET' on
one of them, I see that `font-lock-string-face' has no customizations at
all (no checked boxes or inherited faces).  But ((class color)
(min-colors 88) (background light)) applies to this X11 frame.  It has a
white background and supports far more than 88 colors.

If I hit `C-x C-e' after the (custom-set-faces ...) section, all faces
work as expected again.

Ah, and the face of the buttons in the customize interface doesn't use
boxes, it's only underlined (Custom Button Unraised), because
`custom-raised-buttons' is nil.  IMHO in an X11 frame client it should
default to t, so that there are no user-visible differences between a
client using a X11 frame and a normal X11 emacs instance.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.0.50/etc/DEBUG for instructions.


In GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty)
 of 2007-09-06 on baldur
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' '--without-carbon' '--with-sound' '--with-x' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-xpm' '--with-rsvg' '--with-x-toolkit=gtk' '--without-hesiod' '--with-gpm' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i686 -mtune=prescott -O2 -pipe''

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  partial-completion-mode: t
  iswitchb-mode: t
  window-number-meta-mode: t
  window-number-mode: t
  savehist-mode: t
  exec-abbrev-cmd-mode: t
  show-paren-mode: t
  global-hl-line-mode: t
  which-function-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> <backspace> <backspace> . e m C-g <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
C-x b d i <return> <up> <up> <up> C-x k <return> C-x 
b <return> M-x g n u s <return> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <return> 
<return> q <down> <down> <return> <return> <down> <return> 
<down> <return> <down> <return> <down> <return> <down> 
<return> <down> <return> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <down> 
<return> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> c C-x 1 l s M-x r e p o r <tab> b u g <r
eturn>

Recent messages:
Loading bbdb-gui...done
20070906T082748.212> Exiting summary buffer and applying spam rules
20070906T082748.257> nnimap: Setting marks in INBOX.mailinglists.emacs-devel...
20070906T082748.454> nnimap: Setting marks in INBOX.mailinglists.emacs-devel...done
Wrote /home/heimdall/.bbdb
(No changes need to be saved)
20070906T082751.238> Saving /home/heimdall/.newsrc.eld...
Wrote /home/heimdall/.newsrc.eld
20070906T082751.295> Saving /home/heimdall/.newsrc.eld...done
Loading emacsbug...done

-- 
Früher haben wir vor dem Essen  immer gebetet, aber jetzt hat meine Frau
einen Kochkurs gemacht.

Re: 23.0.50; face-problems with multy-tty

[Dan Nicolaescu]

Tassilo Horn <thorn+news@fastmail.fm> writes:

  > Since multi-tty has been merged, I start emacs as a detached server with
  > screen.  Here's the command line I use to reproduce the problem:
  > 
  >   screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
  >          -Q -l foo.el --funcall server-start
  > 
  > The file foo.el contains my custom-set-faces:
  > 
  > --8<---------------cut here---------------start------------->8---
  > (custom-set-faces
  >   ;; custom-set-faces was added by Custom.
  >   ;; If you edit it by hand, you could mess it up, so be careful.
  >   ;; Your init file should contain only one such instance.
  >   ;; If there is more than one, they won't work right.
  >  '(circe-highlight-all-nicks-face ((t (:foreground "blue"))))
  >  '(circe-highlight-nick-face ((t (:background "grey" :foreground "blue" :weight bold))))
  >  '(circe-my-message-face ((t (:background "grey"))))
  >  '(circe-originator-face ((t (:weight bold))))
  >  '(company-pseudo-tooltip-face ((t (:inherit default :background "yellow" :foreground "black"))))
  >  '(diff-added ((t (:inherit diff-changed :background "green"))))
  >  '(diff-changed ((nil (:background "lightblue"))))
  >  '(diff-removed ((t (:inherit diff-changed :background "orange"))))
  >  '(diredp-exec-priv ((t (:background "LightSteelBlue" :foreground "black"))))
  >  '(diredp-no-priv ((t (:background "LightGray" :foreground "black"))))
  >  '(diredp-read-priv ((t (:background "MediumAquamarine" :foreground "black"))))
  >  '(diredp-write-priv ((t (:background "Orchid" :foreground "black"))))
  >  '(emms-browser-album-face ((((class color) (background light)) (:inherit org-level-2))))
  >  '(emms-browser-artist-face ((((class color) (background light)) (:inherit org-level-1))))
  >  '(emms-browser-track-face ((((class color) (background light)) (:inherit org-level-3 :weight normal))))
  >  '(font-lock-string-face ((((class color) (min-colors 88) (background light)) (:foreground "RosyBrown4"))))
  >  '(gnus-group-mail-3 ((t (:foreground "magenta" :weight bold))))
  >  '(gnus-group-mail-3-empty ((nil (:inherit gnus-group-mail-3 :weight normal))))
  >  '(gnus-group-news-3 ((t (:foreground "blue" :weight bold))))
  >  '(gnus-group-news-3-empty ((nil (:inherit gnus-group-news-3 :weight normal))))
  >  '(gnus-server-denied ((t (:foreground "red" :weight bold))))
  >  '(gnus-signature ((t (:foreground "blue" :slant italic))))
  >  '(header-line ((default nil) (((class color grayscale) (background light)) (:background "grey90" :foreground "grey20" :box nil))))
  >  '(hl-line ((t (:inherit highlight :background "#BEFFBE"))))
  >  '(message-header-name ((nil (:inherit gnus-header-name))))
  >  '(mode-line ((nil (:background "black" :foreground "grey80" :height 0.8 :family "helvetica"))))
  >  '(mode-line-buffer-id ((t (:background "grey10" :foreground "grey90" :weight bold))))
  >  '(mode-line-inactive ((default (:inherit mode-line :background "grey80" :foreground "grey20")) (((class color) (min-colors 88) (background light)) (:weight light))))
  >  '(newsticker-feed-face ((t (:inherit org-level-1 :underline t))))
  >  '(newsticker-immortal-item-face ((t (:inherit newsticker-new-item-face :foreground "blue"))))
  >  '(newsticker-new-item-face ((t (:foreground "black" :weight normal))))
  >  '(newsticker-obsolete-item-face ((t (:inherit newsticker-new-item-face :strike-through t))))
  >  '(newsticker-old-item-face ((t (:inherit newsticker-new-item-face :foreground "grey60"))))
  >  '(org-level-1 ((t (:foreground "Blue1" :weight bold))))
  >  '(org-level-2 ((t (:foreground "DarkGoldenrod" :weight bold))))
  >  '(org-level-3 ((t (:foreground "Purple" :weight bold))))
  >  '(org-level-4 ((t (:foreground "Firebrick" :weight bold))))
  >  '(org-level-5 ((t (:foreground "ForestGreen" :weight bold))))
  >  '(org-level-6 ((t (:foreground "CadetBlue" :weight bold))))
  >  '(org-level-7 ((t (:foreground "Orchid" :weight bold))))
  >  '(org-level-8 ((t (:foreground "RosyBrown" :weight bold))))
  >  '(outline-1 ((t (:inherit org-level-1))))
  >  '(outline-2 ((t (:inherit org-level-2))))
  >  '(outline-3 ((t (:inherit org-level-3))))
  >  '(outline-4 ((t (:inherit org-level-4))))
  >  '(outline-5 ((t (:inherit org-level-5))))
  >  '(outline-6 ((t (:inherit org-level-6))))
  >  '(outline-7 ((t (:inherit org-level-7))))
  >  '(outline-8 ((t (:inherit org-level-8))))
  >  '(region ((t (:background "paleturquoise"))))
  >  '(tooltip ((((class color)) (:inherit variable-pitch :background "lightblue" :foreground "black" :family "fixed"))))
  >  '(trailing-whitespace ((nil (:background "grey80"))))
  >  '(window-number-face ((((type x w32 mac)) (:foreground "red" :weight bold)))))
  > --8<---------------cut here---------------end--------------->8---
  > 
  > Now I connect to that server with
  > 
  >     emacsclient -s test
  > 
  > which opens a new X11 frame.  Now all faces whose value doesn't start
  > with t or nil use the default face, e.g. all strings ("foo") in an elisp
  > file are simply black on white.  If I do `M-x customize-face RET RET' on
  > one of them, I see that `font-lock-string-face' has no customizations at
  > all (no checked boxes or inherited faces).  But ((class color)
  > (min-colors 88) (background light)) applies to this X11 frame.  It has a
  > white background and supports far more than 88 colors.
  > 
  > If I hit `C-x C-e' after the (custom-set-faces ...) section, all faces
  > work as expected again.
  > 
  > Ah, and the face of the buttons in the customize interface doesn't use
  > boxes, it's only underlined (Custom Button Unraised), because
  > `custom-raised-buttons' is nil.  IMHO in an X11 frame client it should
  > default to t, so that there are no user-visible differences between a
  > client using a X11 frame and a normal X11 emacs instance.

Can you please try to run "make maintainer-clean" and then configure
and make bootstrap? I have seen a very similar problem that was fixed
that way.

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

Dan Nicolaescu <dann@ics.uci.edu> writes:

Hi Dan,

> Can you please try to run "make maintainer-clean" and then configure
> and make bootstrap? I have seen a very similar problem that was fixed
> that way.

I use the gentoo emacs-cvs ebuild.  That checks out into a separate
directory, copies that to a work directory and compiles there.  The
checkout directory won't ever see a ./configure or a make, so every
build is a clean install from scratch.

Bye,
Tassilo

Re: 23.0.50; face-problems with multy-tty

[Dan Nicolaescu]

Tassilo Horn <thorn+news@fastmail.fm> writes:

  > Please write in English if possible, because the Emacs maintainers
  > usually do not have translators to read other languages for them.
  > 
  > Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
  > 
  > Please describe exactly what actions triggered the bug
  > and the precise symptoms of the bug:
  > 
  > Since multi-tty has been merged, I start emacs as a detached server with
  > screen.  Here's the command line I use to reproduce the problem:
  > 
  >   screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
  >          -Q -l foo.el --funcall server-start
  > 
  > The file foo.el contains my custom-set-faces:

Here a simplified test case:

set TERM to vt100 (so that the frame background is considered to be 'dark by default)

Save this as test.el: 
(custom-set-faces
 '(font-lock-string-face ((((class color) (min-colors 88) (background light)) (:foreground "RosyBrown4")))))

run:
emacs -nw -q -l test.el 
M-x server-start RET

Now run:

emacsclient 

look in the emacsclient frame at font-lock-string face, the foreground
will be nil.

Somehow the faces are not initialized correctly. My suspicion is that
when the faces are computed the background mode might no be set
correctly.

Can somebody that knows how these things are supposed to work take a
look ?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Here a simplified test case:
>
> set TERM to vt100 (so that the frame background is considered to be 'dark by default)
>
> Save this as test.el: 
> (custom-set-faces
>  '(font-lock-string-face ((((class color) (min-colors 88) (background light)) (:foreground "RosyBrown4")))))
>
> run:
> emacs -nw -q -l test.el 
> M-x server-start RET
>
> Now run:
>
> emacsclient 
>
> look in the emacsclient frame at font-lock-string face, the foreground
> will be nil.
>
> Somehow the faces are not initialized correctly. My suspicion is that
> when the faces are computed the background mode might no be set
> correctly.
>
> Can somebody that knows how these things are supposed to work take a
> look ?

Is this the right fix?

--- cus-face.el	29 Aug 2007 16:12:24 +0200	1.48
+++ cus-face.el	07 Sep 2007 02:55:49 +0200	
@@ -342,7 +342,8 @@
 		(unless (facep face)
 		  (make-empty-face face))
 		(put face 'face-comment comment)
-		(face-spec-set face spec))
+		(dolist (frame (frame-list))
+		  (face-spec-set face spec frame)))
 	    (setq args (cdr args)))
 	;; Old format, a plist of FACE SPEC pairs.
 	(let ((face (nth 0 args))


-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

Hi Johan,

> Is this the right fix?
>
> --- cus-face.el	29 Aug 2007 16:12:24 +0200	1.48
> +++ cus-face.el	07 Sep 2007 02:55:49 +0200	
> @@ -342,7 +342,8 @@
>  		(unless (facep face)
>  		  (make-empty-face face))
>  		(put face 'face-comment comment)
> -		(face-spec-set face spec))
> +		(dolist (frame (frame-list))
> +		  (face-spec-set face spec frame)))
>  	    (setq args (cdr args)))
>  	;; Old format, a plist of FACE SPEC pairs.
>  	(let ((face (nth 0 args))

No, still I have to C-x C-e after the custom-set-faces to get the
correct faces.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Tassilo Horn <tassilo@member.fsf.org> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
> Hi Johan,
>
>> Is this the right fix?
>> [...]

> No, still I have to C-x C-e after the custom-set-faces to get the
> correct faces.

Did you rebuild Emacs (or load the changed file)?

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

Hi Johan,

>>> Is this the right fix?
>>> [...]
>
>> No, still I have to C-x C-e after the custom-set-faces to get the
>> correct faces.
>
> Did you rebuild Emacs (or load the changed file)?

Very strange.  I edited the source and byte-compiled cus-face.el anew.
That didn't work, so I deleted the byte-compiled file and restarted
again.  It still didn't work.

Now I made an CVS update, applied the patch and rebuild emacs from
scratch and now it works. :-)

Thanks a lot,
Tassilo

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Tassilo Horn <tassilo@member.fsf.org> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
>> Did you rebuild Emacs (or load the changed file)?
>
> Very strange. I edited the source and byte-compiled cus-face.el anew.
> That didn't work, so I deleted the byte-compiled file and restarted
> again. It still didn't work.

Some standard Lisp libraries are preloaded, meaning that the code was
incorporated into the Emacs executable at build time ("dumping").
Changing one of these files has no effect (unless you load it manually).

See (info "(elisp)Building Emacs")

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

Hi Johan,

>>> Did you rebuild Emacs (or load the changed file)?
>>
>> Very strange. I edited the source and byte-compiled cus-face.el anew.
>> That didn't work, so I deleted the byte-compiled file and restarted
>> again. It still didn't work.
>
> Some standard Lisp libraries are preloaded, meaning that the code was
> incorporated into the Emacs executable at build time ("dumping").
> Changing one of these files has no effect (unless you load it
> manually).
>
> See (info "(elisp)Building Emacs")

Ok, I didn't know that.  Thanks a lot for the fast fix.

Bye,
Tassilo

Re: 23.0.50; face-problems with multy-tty

[Romain Francoise]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> --- cus-face.el	29 Aug 2007 16:12:24 +0200	1.48
> +++ cus-face.el	07 Sep 2007 02:55:49 +0200	
> @@ -342,7 +342,8 @@
>  		(unless (facep face)
>  		  (make-empty-face face))
>  		(put face 'face-comment comment)
> -		(face-spec-set face spec))
> +		(dolist (frame (frame-list))
> +		  (face-spec-set face spec frame)))
>  	    (setq args (cdr args)))
>  	;; Old format, a plist of FACE SPEC pairs.
>  	(let ((face (nth 0 args))

Could you provide a ChangeLog entry for this so that we can install
it?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Romain Francoise <romain@orebokech.com> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
>> --- cus-face.el	29 Aug 2007 16:12:24 +0200	1.48
>> +++ cus-face.el	07 Sep 2007 02:55:49 +0200	
>> @@ -342,7 +342,8 @@
>>  		(unless (facep face)
>>  		  (make-empty-face face))
>>  		(put face 'face-comment comment)
>> -		(face-spec-set face spec))
>> +		(dolist (frame (frame-list))
>> +		  (face-spec-set face spec frame)))
>>  	    (setq args (cdr args)))
>>  	;; Old format, a plist of FACE SPEC pairs.
>>  	(let ((face (nth 0 args))
>
> Could you provide a ChangeLog entry for this so that we can install
> it?

2007-09-07  Johan Bockgård  <bojohan@gnu.org>

	* cus-face.el (custom-theme-set-faces): Set face attributes
	locally for each frame.

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Romain Francoise]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> 2007-09-07  Johan Bockgård  <bojohan@gnu.org>

> 	* cus-face.el (custom-theme-set-faces): Set face attributes
> 	locally for each frame.

Thanks, installed.

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    > 2007-09-07  Johan Bockgård  <bojohan@gnu.org>

    > 	* cus-face.el (custom-theme-set-faces): Set face attributes
    > 	locally for each frame.

    Thanks, installed.

Please revert that change, then ack.

I already explained why it isn't really correct, and someone else said
it did not fix the problem.

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     > 2007-09-07  Johan Bockgård  <bojohan@gnu.org>
>
>     > 	* cus-face.el (custom-theme-set-faces): Set face attributes
>     > 	locally for each frame.
>
>     Thanks, installed.
>
> Please revert that change, then ack.
>
> I already explained why it isn't really correct, and someone else said
> it did not fix the problem.

It fixed the problem, but I had to recompile emacs, not only the single
file.  Johan explained why that's needed.

Bye,
Tassilo

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    -		(face-spec-set face spec))
    +		(dolist (frame (frame-list))
    +		  (face-spec-set face spec frame)))

face-spec-set is supposed to operate on all frames
when the FRAME argument is nil.  If it doesn't,
then either its code or its documentation needs to be changed.

We had better decide whether its current behavior is wrong
before deciding to work around it.

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     -		(face-spec-set face spec))
>     +		(dolist (frame (frame-list))
>     +		  (face-spec-set face spec frame)))
>
> face-spec-set is supposed to operate on all frames
> when the FRAME argument is nil.  If it doesn't,
> then either its code or its documentation needs to be changed.

It does "operate on all frames". The problem is that it sets the same
attributes everywhere.

There is a similar loop in custom-declare-face, btw.

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    > face-spec-set is supposed to operate on all frames
    > when the FRAME argument is nil.  If it doesn't,
    > then either its code or its documentation needs to be changed.

    It does "operate on all frames". The problem is that it sets the same
    attributes everywhere.

Is that a bug in face-spec-set?  It sounds like one.

If it is, the thing to do is fix it, not work around it.
Would you like to look for the right fix?

Meanwhile, does this change fix the observed problem or not?
I thought the O.P. said it did not.

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     > face-spec-set is supposed to operate on all frames when the
>     > FRAME argument is nil.  If it doesn't, then either its code or
>     > its documentation needs to be changed.
>
>     It does "operate on all frames". The problem is that it sets the
>     same attributes everywhere.
>
> Is that a bug in face-spec-set?  It sounds like one.
>
> If it is, the thing to do is fix it, not work around it.
> Would you like to look for the right fix?
>
> Meanwhile, does this change fix the observed problem or not?

Yes, it fixed the problem.

> I thought the O.P. said it did not.

I only applied the patch, recompiled cus-face.el and restarted emacs.
But a complete rebuild was needed to let the change have an effect.
That was why I first said it didn't fix the problem.

Bye,
Tassilo

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     > face-spec-set is supposed to operate on all frames
>     > when the FRAME argument is nil.  If it doesn't,
>     > then either its code or its documentation needs to be changed.
>
>     It does "operate on all frames". The problem is that it sets the same
>     attributes everywhere.
>
> Is that a bug in face-spec-set?  It sounds like one.

I can't answer that question.

> If it is, the thing to do is fix it, not work around it.
> Would you like to look for the right fix?

The old code boiled down to calling `set-face-attribute' with a null
FRAME argument. This sets a new frame default that is the same for all
frames (via face-new-frame-defaults). That is not what we want.

The new code calls set-face-attribute locally for each frame. It does
not set a default in face-new-frame-defaults. This DTRT unless a default
exists in face-new-frame-defaults (or an X resource exists for the
face).

What is needed is something like what `C-M-x' does on `defface' forms.
It removes the global default (in face-new-frame-defaults) before
setting the specs. But it doesn't do the right thing if a face has been
set via X resources (cf. Re: can't set both mode-line color and default
frame font?).

(E.g the X resource setting "Emacs.foo.attributeForeground: blue" can't
be overridden by <C-M-x> on

    (defface foo
      '((t :foreground "red"))
      "")
)



I think it comes down to this code in face-set-after-frame-default

    ;; Initialize faces from face specs and X resources.  The
    ;; condition-case prevents invalid specs from causing frame
    ;; creation to fail.
    (dolist (face (delq 'default (face-list)))
      (condition-case ()
          (progn
            (face-spec-set face (face-user-default-spec face) frame) ; (1)
            (if (memq (window-system frame) '(x w32 mac))
                (make-face-x-resource-internal face frame))          ; (2)
            (internal-merge-in-global-face face frame))              ; (3)
        (error nil)))

We want `custom-set-faces' to use frame local specs (1).

This requires clearing the global definition (3) (in
face-new-frame-defaults, using face-spec-reset-face)

But we also need to override the X resource definition for new frames
(2), without using the same global definition everywhere (which is what
(3) does). What would be a good way to do that?

-- 
Johan Bockgård

can't set both mode-line color and default frame font?

[Chris Moore]

[-- Attachment #1.1: Type: text/plain, Size: 367 bytes --]

My .emacs says:

(custom-set-faces '(mode-line ((nil (:background "yellow")))))
(custom-set-variables '(default-frame-alist '((font . "10x20"))))

but the mode line isn't yellow.

If I remove the 2nd line, the mode line is yellow.

Setting the font shouldn't stop me setting the mode-line face, should it?

This was working fine until a day or two ago, in CVS trunk.

[-- Attachment #1.2: Type: text/html, Size: 449 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: can't set both mode-line color and default frame font?

[Chris Moore]

[-- Attachment #1.1: Type: text/plain, Size: 815 bytes --]

On 9/9/07, Chris Moore <dooglus@gmail.com> wrote:
>
> My .emacs says:
>
> (custom-set-faces '(mode-line ((nil (:background "yellow")))))
> (custom-set-variables '(default-frame-alist '((font . "10x20"))))
>
> but the mode line isn't yellow.
>
> If I remove the 2nd line, the mode line is yellow.
>
> Setting the font shouldn't stop me setting the mode-line face, should it?
>
> This was working fine until a day or two ago, in CVS trunk.


I was a little hasty there - I just switched from GNOME to XFCE4 and my
.emacs is working again.  I hardly ever use GNOME, so maybe this hasn't
changed in the last few days at all.

Evaluating the (custom-set-faces ...) s-expression once inside Emacs does
set the mode-line to yellow in GNOME.  It just doesn't work from .emacs if I
have the other line in my .emacs as well.

[-- Attachment #1.2: Type: text/html, Size: 1181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: can't set both mode-line color and default frame font?

[Richard Stallman]

Would someone please DTRT, then ack?


Date: Sun, 9 Sep 2007 20:34:16 +0200
From: "Chris Moore" <christopher.ian.moore@gmail.com>
To: emacs-pretest-bug@gnu.org
In-Reply-To: <a9691ee20709091114j14206881q26e35e7eef47c8d@mail.gmail.com>
MIME-Version: 1.0
Cc: 
Subject: Re: can't set both mode-line color and default frame font?
Content-Type: multipart/mixed; boundary="===============0892060137=="

--===============0892060137==
Content-Type: multipart/alternative; 
	boundary="----=_Part_8012_22611638.1189362856504"

------=_Part_8012_22611638.1189362856504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/9/07, Chris Moore <dooglus@gmail.com> wrote:
>
> My .emacs says:
>
> (custom-set-faces '(mode-line ((nil (:background "yellow")))))
> (custom-set-variables '(default-frame-alist '((font . "10x20"))))
>
> but the mode line isn't yellow.
>
> If I remove the 2nd line, the mode line is yellow.
>
> Setting the font shouldn't stop me setting the mode-line face, should it?
>
> This was working fine until a day or two ago, in CVS trunk.


I was a little hasty there - I just switched from GNOME to XFCE4 and my
.emacs is working again.  I hardly ever use GNOME, so maybe this hasn't
changed in the last few days at all.

Evaluating the (custom-set-faces ...) s-expression once inside Emacs does
set the mode-line to yellow in GNOME.  It just doesn't work from .emacs if I
have the other line in my .emacs as well.

------=_Part_8012_22611638.1189362856504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/9/07, <b class="gmail_sendername">Chris Moore</b> &lt;<a href="mailto:dooglus@gmail.com">dooglus@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My .emacs says:<br><br>(custom-set-faces &#39;(mode-line ((nil (:background &quot;yellow&quot;)))))<br>(custom-set-variables &#39;(default-frame-alist &#39;((font . &quot;10x20&quot;))))<br><br>but the mode line isn&#39;t yellow.
<br><br>If I remove the 2nd line, the mode line is yellow.<br><br>Setting the font shouldn&#39;t stop me setting the mode-line face, should it?<br><br>This was working fine until a day or two ago, in CVS trunk.</blockquote>
<div><br>I was a little hasty there - I just switched from GNOME to XFCE4 and my .emacs is working again.&nbsp; I hardly ever use GNOME, so maybe this hasn&#39;t changed in the last few days at all.<br><br>Evaluating the (custom-set-faces ...) s-expression once inside Emacs does set the mode-line to yellow in GNOME.&nbsp; It just doesn&#39;t work from .emacs if I have the other line in my .emacs as well.
<br></div><br></div><br>

------=_Part_8012_22611638.1189362856504--



--===============0892060137==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
--===============0892060137==--

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Richard Stallman skrev:
> Would someone please DTRT, then ack?

This is partly due to the known gnome-settings bug/feature.

Do
% xrdb -query|grep mode

and you will find something like:

Emacs.mode-line.attributeBackground:    #efebe7
Emacs.mode-line.attributeForeground:    #101010

The gnome settings daemon puts those values in there.

Bt why Emacs re-reads those values for the mode-line face when the
default-frame-alist is modifyed, I don't know.

I think it has to with this:

2007-09-07  Johan Bockgård  <bojohan@gnu.org>

        * cus-face.el (custom-theme-set-faces): Set face attributes
        locally for each frame.

	Jan D.

> 
> 
> Date: Sun, 9 Sep 2007 20:34:16 +0200
> From: "Chris Moore" <christopher.ian.moore@gmail.com>
> To: emacs-pretest-bug@gnu.org
> In-Reply-To: <a9691ee20709091114j14206881q26e35e7eef47c8d@mail.gmail.com>
> MIME-Version: 1.0
> Cc: 
> Subject: Re: can't set both mode-line color and default frame font?
> Content-Type: multipart/mixed; boundary="===============0892060137=="
> 
> --===============0892060137==
> Content-Type: multipart/alternative; 
> 	boundary="----=_Part_8012_22611638.1189362856504"
> 
> ------=_Part_8012_22611638.1189362856504
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> On 9/9/07, Chris Moore <dooglus@gmail.com> wrote:
>> My .emacs says:
>>
>> (custom-set-faces '(mode-line ((nil (:background "yellow")))))
>> (custom-set-variables '(default-frame-alist '((font . "10x20"))))
>>
>> but the mode line isn't yellow.
>>
>> If I remove the 2nd line, the mode line is yellow.
>>
>> Setting the font shouldn't stop me setting the mode-line face, should it?
>>
>> This was working fine until a day or two ago, in CVS trunk.
> 
> 
> I was a little hasty there - I just switched from GNOME to XFCE4 and my
> .emacs is working again.  I hardly ever use GNOME, so maybe this hasn't
> changed in the last few days at all.
> 
> Evaluating the (custom-set-faces ...) s-expression once inside Emacs does
> set the mode-line to yellow in GNOME.  It just doesn't work from .emacs if I
> have the other line in my .emacs as well.
> 
> ------=_Part_8012_22611638.1189362856504
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> On 9/9/07, <b class="gmail_sendername">Chris Moore</b> &lt;<a href="mailto:dooglus@gmail.com">dooglus@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> My .emacs says:<br><br>(custom-set-faces &#39;(mode-line ((nil (:background &quot;yellow&quot;)))))<br>(custom-set-variables &#39;(default-frame-alist &#39;((font . &quot;10x20&quot;))))<br><br>but the mode line isn&#39;t yellow.
> <br><br>If I remove the 2nd line, the mode line is yellow.<br><br>Setting the font shouldn&#39;t stop me setting the mode-line face, should it?<br><br>This was working fine until a day or two ago, in CVS trunk.</blockquote>
> <div><br>I was a little hasty there - I just switched from GNOME to XFCE4 and my .emacs is working again.&nbsp; I hardly ever use GNOME, so maybe this hasn&#39;t changed in the last few days at all.<br><br>Evaluating the (custom-set-faces ...) s-expression once inside Emacs does set the mode-line to yellow in GNOME.&nbsp; It just doesn&#39;t work from .emacs if I have the other line in my .emacs as well.
> <br></div><br></div><br>
> 
> ------=_Part_8012_22611638.1189362856504--
> 
> 
> 
> --===============0892060137==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> --===============0892060137==--
> 
> 
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: 23.0.50; face-problems with multy-tty

[Drew Adams]

> What is needed is something like what `C-M-x' does on `defface' forms.

I haven't been following this thread, but, FWIW, I asked for a programmatic way to do exactly that in thread "need a way to override defface" (2007-07-14):

> "something analogous to what `setq' does for `defvar' and `defcustom'.
> Something, for instance, that a user can put in .emacs to override a
> predefined `defface'.

I got no replies to that request, but perhaps your need will bring that or something similar about?

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    > "something analogous to what `setq' does for `defvar' and `defcustom'.
    > Something, for instance, that a user can put in .emacs to override a
    > predefined `defface'.

    I got no replies to that request, but perhaps your need will bring that or something similar about?

I am in favor of it.

overriding a face [was: 23.0.50; face-problems with multy-tty]

[Drew Adams]

> From: Richard Stallman Sent: Friday, September 14, 2007 12:05 AM
> Subject: Re: 23.0.50; face-problems with multy-tty
>
>     > "something analogous to what `setq' does for `defvar' and
>     > `defcustom'. Something, for instance, that a user can put in
>     > .emacs to override a predefined `defface'.
>
> I am in favor of it.

Maybe something like this would be a start?

(defmacro set-face (face spec &optional doc &rest args)
  "Set the spec for face symbol FACE to SPEC.
If FACE is a face, then FACE and SPEC are passed
 to `face-spec-set'.
Otherwise, all arguments are passed to `defface'."
  `(if (facep ',face)
       (face-spec-set ',face ,spec)
     (defface ,face ,spec ,(or doc "REPLACE ME") ,@args)))

Perhaps that's not entirely correct, but maybe it will stimulate someone who
knows about this sort of thing to correct it.

That seems to do what I was asking, in any case.  The idea is that a user or
Lisp code could use (set-face face spec) to define a new face or to override
the definition of an existing face.

But maybe this would be taken care of by Richard's proposed change to
`face-spec-set'? (I don't fully understand that.)

Re: overriding a face [was: 23.0.50; face-problems with multy-tty]

[Richard Stallman]

    Maybe something like this would be a start?

    (defmacro set-face (face spec &optional doc &rest args)
      `(if (facep ',face)
	   (face-spec-set ',face ,spec)
	 (defface ,face ,spec ,(or doc "REPLACE ME") ,@args)))

This seems like an incoherent combination of two different constructs,
like a conditional choice between set and setq.  I don't think it is
a good idea.

We might want to make `set-face' an alias for `face-spec-set'.

RE: overriding a face [was: 23.0.50; face-problems with multy-tty]

[Drew Adams]

>     Maybe something like this would be a start?
>
>     (defmacro set-face (face spec &optional doc &rest args)
>       `(if (facep ',face)
> 	   (face-spec-set ',face ,spec)
> 	 (defface ,face ,spec ,(or doc "REPLACE ME") ,@args)))
>
> This seems like an incoherent combination of two different constructs,
> like a conditional choice between set and setq.  I don't think it is
> a good idea.

I don't understand. To me, it is only like `setq'. If the face exists, it
replaces its current definition (assuming `face-spec-set' does that);
otherwise, it creates it. How is this in any way like `set'?

This seems to work as I hoped. In any case, I'm looking for this
functionality (which you said you were in favor of), regardless of how it is
implemented.

> We might want to make `set-face' an alias for `face-spec-set'.

What would be gained by that?

What I'm asking for is something that will _create or replace_ a face
definition, the same way `setq' creates a new variable or replaces an
existing variable's value.

Re: overriding a face [was: 23.0.50; face-problems with multy-tty]

[Richard Stallman]

    What I'm asking for is something that will _create or replace_ a face
    definition, the same way `setq' creates a new variable or replaces an
    existing variable's value.

I had no idea that is what you wanted to do.

The way to do that is to call make-face, then face-spec-set.
We could make a simple way to do both, if it is useful often enough
to be worth its weight in paper in the manual.

RE: overriding a face [was: 23.0.50; face-problems with multy-tty]

[Drew Adams]

>     What I'm asking for is something that will _create or replace_ a face
>     definition, the same way `setq' creates a new variable or replaces an
>     existing variable's value.
>
> I had no idea that is what you wanted to do.

Hmm, I explained it just that way twice. Out of curiosity, what was it that
you were saying you were in favor of?

> The way to do that is to call make-face, then face-spec-set.

OK, thanks. I had forgotten that make-face is a no-op for an existing face.

> We could make a simple way to do both, if it is useful often enough
> to be worth its weight in paper in the manual.

Please do. Its name alone (`set-face' or whatever) would be helpful - it
wasn't obvious to me, at least, how to do that. It would require only one or
two lines of space in the manual.

Re: overriding a face [was: 23.0.50; face-problems with multy-tty]

[Richard Stallman]

    > We could make a simple way to do both, if it is useful often enough
    > to be worth its weight in paper in the manual.

    Please do. Its name alone (`set-face' or whatever) would be helpful - it

I will do this if I see it is useful enough.
To me it does not seem worth adding, but other facts
could change my mind.

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    The old code boiled down to calling `set-face-attribute' with a null
    FRAME argument. This sets a new frame default that is the same for all
    frames (via face-new-frame-defaults). That is not what we want.

    The new code calls set-face-attribute locally for each frame. It does
    not set a default in face-new-frame-defaults. This DTRT unless a default
    exists in face-new-frame-defaults (or an X resource exists for the
    face).

You are basically right.  It's just that I think the change you made
really needs to be inside face-spec-set.  That way, face-spec-set will
DTRT _also_.

I made that change.

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     The old code boiled down to calling `set-face-attribute' with a null
>     FRAME argument. This sets a new frame default that is the same for all
>     frames (via face-new-frame-defaults). That is not what we want.
>
>     The new code calls set-face-attribute locally for each frame. It does
>     not set a default in face-new-frame-defaults. This DTRT unless a default
>     exists in face-new-frame-defaults (or an X resource exists for the
>     face).
>
> You are basically right.  It's just that I think the change you made
> really needs to be inside face-spec-set.

Ok, I agree.

> That way, face-spec-set will DTRT _also_.

This still isn't quite the right thing:

    (set-face-attribute 'font-lock-string-face nil :foreground "yellow")

    (custom-set-faces
     '(font-lock-string-face
       ((((class color) (background light)) (:foreground "red"))
        (((class color) (background dark)) (:foreground "blue")))))

    ;; `C-x 5 2' uses a yellow font-lock-string-face.

I think custom-set-faces (and face-spec-set?) should clear the new-frame
default.

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

	(set-face-attribute 'font-lock-string-face nil :foreground "yellow")

	(custom-set-faces
	 '(font-lock-string-face
	   ((((class color) (background light)) (:foreground "red"))
	    (((class color) (background dark)) (:foreground "blue")))))

	;; `C-x 5 2' uses a yellow font-lock-string-face.

I am not convinced that is a bug.

The new-frame default face attributes override customizations because
they are usually set by programs during a session, whereas
customizations are usually set semipermanently.  In that kind of case,
it is right for the default face attributes to take precedence.

Customizations can also be made within a session.  In that case, it is
not clear which should take precedence.

Thus, the current precedence order seems better, overall, than the
opposite order.

As long as we stick with this order, we should do it consistently.
So the init file you showed should produce the results it produces.
If you don't like it, don't do that.

Another consistent possibility is that the new-frame default face
attributes and face customizations have the same precedence.  But the
only consistent way to do that is if each one erases the other, so you
can only have one of them.  So if you customize the face, that clears
out all new-frame default face attributes, and if you set a new-frame
default face attribute, that clears the customization.

I cannot see any other consistent way to handle them both.  If face
customization did not have conditionals, if all it did was specify a
value for each attribute, then the customizations would be
commensurable with the face attributes, and they could both set the
same values in a simple way.  But that is impossible with the
conditional face customizations that we have.

Does anyone else have any ideas about this?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

> 	(set-face-attribute 'font-lock-string-face nil :foreground "yellow")
>
> 	(custom-set-faces
> 	 '(font-lock-string-face
> 	   ((((class color) (background light)) (:foreground "red"))
> 	    (((class color) (background dark)) (:foreground "blue")))))
>
> 	;; `C-x 5 2' uses a yellow font-lock-string-face.
>
> I am not convinced that is a bug.
>
> The new-frame default face attributes override customizations because
> they are usually set by programs during a session, whereas
> customizations are usually set semipermanently.  In that kind of case,
> it is right for the default face attributes to take precedence.

I'm not convinced. The behavior that "new-frame default face attributes
override customizations" is only two weeks old. It didn't use to work
like that (see below).

> Customizations can also be made within a session. In that case, it is
> not clear which should take precedence.
>
> Thus, the current precedence order seems better, overall, than the
> opposite order.
>
> As long as we stick with this order, we should do it consistently.
> So the init file you showed should produce the results it produces.
> If you don't like it, don't do that.

It wasn't an example of a real init file. The case I'm worried about is
when you want to reset the faces from the init file with `C-x C-e' on
the custom-set-faces form (or by loading the file).

> Another consistent possibility is that the new-frame default face
> attributes and face customizations have the same precedence.  But the
> only consistent way to do that is if each one erases the other, so you
> can only have one of them.  So if you customize the face, that clears
> out all new-frame default face attributes, and if you set a new-frame
> default face attribute, that clears the customization.

Note that this is how it already worked before the recent changes.
custom-set-faces used to operate by changing the new-frame defaults. The
problem is that that doesn't distinguish between different kinds of
frames. Now custom-set-faces sets the attributes per frame (via
face-spec-set), but it needs to clear the new-frame defaults too.

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Mon, 24 Sep 2007 02:00:21 +0200
> 
> The case I'm worried about is when you want to reset the faces from
> the init file with `C-x C-e' on the custom-set-faces form (or by
> loading the file).

Nobody said that C-x C-e on a custom-set-faces form should do what you
want.  A custom-set-faces form is not a regular Lisp form, as far as
its effects are concerned.  Custom's normal modus operandi is through
"M-x customize-face".

> Note that this is how it already worked before the recent changes.
> custom-set-faces used to operate by changing the new-frame defaults.

Which I think was correct behavior, as far as I understand the issue.

> The problem is that that doesn't distinguish between different kinds
> of frames.

What different kinds of frames are those?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
>
>> Note that this is how it already worked before the recent changes.
>> custom-set-faces used to operate by changing the new-frame defaults.
>
> Which I think was correct behavior, as far as I understand the issue.

That assumes that all frames are alike. custom-set-faces used to look at
the current frame and set the same attributes everywhere.

>> The problem is that that doesn't distinguish between different kinds
>> of frames.
>
> What different kinds of frames are those?

class color/grayscale/mono; background light/dark; type x/tty/...

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Mon, 24 Sep 2007 15:06:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> >
> >> Note that this is how it already worked before the recent changes.
> >> custom-set-faces used to operate by changing the new-frame defaults.
> >
> > Which I think was correct behavior, as far as I understand the issue.
> 
> That assumes that all frames are alike. custom-set-faces used to look at
> the current frame and set the same attributes everywhere.

Sorry, I still cannot understand what is the complaint.  It sounds
like the last sentence above:

  custom-set-faces used to look at
  the current frame and set the same attributes everywhere.

Says the same as what I said was the correct behavior:

> >> Note that this is how it already worked before the recent changes.
> >> custom-set-faces used to operate by changing the new-frame defaults.
> >
> > Which I think was correct behavior, as far as I understand the issue.

What am I missing?

> >> The problem is that that doesn't distinguish between different kinds
> >> of frames.
> >
> > What different kinds of frames are those?
> 
> class color/grayscale/mono; background light/dark; type x/tty/...

You mean, even though there are different customizations for light and
dark background, say, only one of them is used for both background
modes?  Can you show a short recipe to reproduce that?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, even though there are different customizations for light and
> dark background, say, only one of them is used for both background
> modes?  Can you show a short recipe to reproduce that?

Yes.

Try this in Emacs 21, or in CVS Emacs older than 2007-09-06.

$ emacs -q -bg white

(global-font-lock-mode 1)

(custom-set-faces
 '(font-lock-string-face
   ((((class color) (background light)) (:foreground "red"))
    (((class color) (background dark)) (:foreground "blue")))))

(make-frame '((background-color . "black")))

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    It wasn't an example of a real init file. The case I'm worried about is
    when you want to reset the faces from the init file with `C-x C-e' on
    the custom-set-faces form (or by loading the file).

I see why that might be useful, but I am not sure we can expect it to
work.  This is overconstrained.

     The
    problem is that that doesn't distinguish between different kinds of
    frames. Now custom-set-faces sets the attributes per frame (via
    face-spec-set), but it needs to clear the new-frame defaults too.

Does this definition give good results?  This clears the new-frame
defaults for ALL attributes, which seems like the right thing in
principle, but it may not work well in all cases.


(defun face-spec-set (face spec &optional frame)
  "Set FACE's attributes according to the first matching entry in SPEC.
FRAME is the frame whose frame-local face is set.  FRAME nil means
do it on all frames.  See `defface' for information about SPEC.
If SPEC is nil, do nothing."
  (let ((attrs (face-spec-choose spec frame)))
	(when spec
	  (face-spec-reset-face face frame))
	(while attrs
	  (let ((attribute (car attrs))
		(value (car (cdr attrs))))
	    ;; Support some old-style attribute names and values.
	    (case attribute
	      (:bold (setq attribute :weight value (if value 'bold 'normal)))
	      (:italic (setq attribute :slant value (if value 'italic 'normal)))
	      ((:foreground :background)
	       ;; Compatibility with 20.x.  Some bogus face specs seem to
	       ;; exist containing things like `:foreground nil'.
	       (if (null value) (setq value 'unspecified)))
	      (t (unless (assq attribute face-x-resources)
		   (setq attribute nil))))
	    (when attribute
	      (set-face-attribute face frame attribute value)))
	  (setq attrs (cdr (cdr attrs)))))
    ;; When we reset the face based on its spec, then it is unmodified
    ;; as far as Custom is concerned.
    (put (or (get face 'face-alias) face) 'face-modified nil)
    ;; Clear all the new-frame defaults for this face.
    (dolist (attribute '(:family :width :height :weight :slant :foreground
			 :background :underline :overline :strike-through
			 :box :inverse-video))
      (set-face-attribute face nil attribute nil))
    ;; Set each frame according to the rules implied by SPEC.
    (dolist (frame (frame-list))
      (face-spec-set face spec frame)))

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     ;; Clear all the new-frame defaults for this face.
>     (dolist (attribute '(:family :width :height :weight :slant :foreground
> 			 :background :underline :overline :strike-through
> 			 :box :inverse-video))

face-attribute-name-alist could be used here (cf. face-spec-reset-face).

>       (set-face-attribute face nil attribute nil))

But nil is not a valid option for many of the attributes

(set-face-attribute 'highlight nil :family nil)
  => Wrong type argument: stringp, nil

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    But nil is not a valid option for many of the attributes

    (set-face-attribute 'highlight nil :family nil)
      => Wrong type argument: stringp, nil

You are right.  Does  :unspecified work?

Re: 23.0.50; face-problems with multy-tty

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     But nil is not a valid option for many of the attributes
>
>     (set-face-attribute 'highlight nil :family nil)
>       => Wrong type argument: stringp, nil
>
> You are right.  Does  :unspecified work?

No (this is just what face-spec-reset-face does, btw). A value of
`unspecified' given to set-face-attribute is replaced with
:ignore-defface in face-new-frame-defaults.

   (set-face-attribute 'highlight nil :family 'unspecified)

   =>

   face-new-frame-defaults
      = (... (highlight . [face :ignore-defface unspecified ...]) ...)
                                ^^^^^^^^^^^^^^^

This does not have the right effect (`unspecified' means "no global
definition", whereas :ignore-defface means "the global definition is
`unspecified'").

See

2005-11-20  Chong Yidong  <cyd@stupidchicken.com>

	* xfaces.c (Finternal_set_lisp_face_attribute):
	Use :ignore-defface for new frame defaults when `unspecified' is
	supplied.
	(Finternal_get_lisp_face_attribute): Hide :ignore-defface.
	(merge_face_vectors): Don't do :ignore-defface overwriting here.
	(Finternal_merge_in_global_face): Do it here.

The change was made in response to

Re: problems with face-spec-reset-face and set-face-attribute
<E1ETqhs-0003Xo-7s@fencepost.gnu.org>
http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-10/msg00208.html


AFAICS, there's currently no way to get a value of `unspecified' into
face-new-frame-defaults using set-face-attribute (set-face-attribute
accepts both `unspecified' and :ignore-defface but they both mean the
latter). (Attributes can be reset to `unspecified' in
face-new-frame-defaults with (internal-make-lisp-face FACE), but that is
kind of ugly.)

-- 
Johan Bockgård

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

Does this patch fix it?


*** faces.el	23 Sep 2007 05:07:20 -0400	1.377
--- faces.el	28 Sep 2007 10:55:28 -0400	
***************
*** 1446,1453 ****
  FRAME is the frame whose frame-local face is set.  FRAME nil means
  do it on all frames.  See `defface' for information about SPEC.
  If SPEC is nil, do nothing."
!   (if frame
!       (let ((attrs (face-spec-choose spec frame)))
  	(when spec
  	  (face-spec-reset-face face frame))
  	(while attrs
--- 1446,1452 ----
  FRAME is the frame whose frame-local face is set.  FRAME nil means
  do it on all frames.  See `defface' for information about SPEC.
  If SPEC is nil, do nothing."
!   (let ((attrs (face-spec-choose spec frame)))
  	(when spec
  	  (face-spec-reset-face face frame))
  	(while attrs
***************
*** 1469,1474 ****
--- 1468,1478 ----
      ;; When we reset the face based on its spec, then it is unmodified
      ;; as far as Custom is concerned.
      (put (or (get face 'face-alias) face) 'face-modified nil)
+     ;; Clear all the new-frame defaults for this face.
+     (let ((facevec (cdr (assq face face-new-frame-defaults))))
+       (dotimes (i (length facevec))
+ 	(unless (= i 0)
+ 	  (aset facevec i 'unspecified))))
      ;; Set each frame according to the rules implied by SPEC.
      (dolist (frame (frame-list))
        (face-spec-set face spec frame))))

RE: 23.0.50; face-problems with multy-tty

[Drew Adams]

> 	(set-face-attribute 'font-lock-string-face nil :foreground "yellow")
>
> 	(custom-set-faces
> 	 '(font-lock-string-face
> 	   ((((class color) (background light)) (:foreground "red"))
> 	    (((class color) (background dark)) (:foreground "blue")))))
>
> 	;; `C-x 5 2' uses a yellow font-lock-string-face.
>
> Another consistent possibility is that the new-frame default face
> attributes and face customizations have the same precedence.  But the
> only consistent way to do that is if each one erases the other, so you
> can only have one of them.  So if you customize the face, that clears
> out all new-frame default face attributes, and if you set a new-frame
> default face attribute, that clears the customization.

That way would seem correct (natural) to me. Why should either prevent the
effect of the other, if the other comes later? Why would set-face-attribute
have higher priority?

Are there rules defined for this, or is this the first discussion? I'd say
keep it simple: the latest modification wins, however it is made.

[I did not follow the whole thread, so ignore if I'm missing something.]

Re: 23.0.50; face-problems with multy-tty

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 23 Sep 2007 17:55:03 -0400
> Cc: emacs-devel@gnu.org
> 
> Does anyone else have any ideas about this?

I cannot make up my mind because this discussion was very long with
several sub-threads, and the problem is not concisely described in any
of the messages.  Also, the original problem report used very complex
customizations.  Dan posted a simplified example, but then no one else
used that to argue.

Could someone please post a concise explanation of what the problem is
using Dan's example (or a similarly small one)?  TIA

Re: 23.0.50; face-problems with multy-tty

[Glenn Morris]

Richard Stallman wrote:

> Does anyone else have any ideas about this?

I also don't really know what "this" is, but I posted 5 days ago
("recent faces.el change", no responses) that face-spec-set with no
FRAME argument no longer sets the default for new frames. This is due
to your 2007-09-17 change to faces.el. Isn't that just a bug? It
certainly breaks all my face settings in my .emacs file.

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    I also don't really know what "this" is, but I posted 5 days ago
    ("recent faces.el change", no responses) that face-spec-set with no
    FRAME argument no longer sets the default for new frames. This is due
    to your 2007-09-17 change to faces.el. Isn't that just a bug?

Maybe it is.  I ought to investigate it but I have not had time.

Re: 23.0.50; face-problems with multy-tty

[Glenn Morris]

Richard Stallman wrote:

>     I also don't really know what "this" is, but I posted 5 days ago
>     ("recent faces.el change", no responses) that face-spec-set with no
>     FRAME argument no longer sets the default for new frames. This is due
>     to your 2007-09-17 change to faces.el. Isn't that just a bug?
>
> Maybe it is.  I ought to investigate it but I have not had time.


How about this:


diff -c -c -w -r1.377 faces.el
*** faces.el	21 Sep 2007 07:23:03 -0000	1.377
--- faces.el	9 Oct 2007 01:18:28 -0000
***************
*** 1444,1455 ****
  (defun face-spec-set (face spec &optional frame)
    "Set FACE's attributes according to the first matching entry in SPEC.
  FRAME is the frame whose frame-local face is set.  FRAME nil means
! do it on all frames.  See `defface' for information about SPEC.
! If SPEC is nil, do nothing."
!   (if frame
        (let ((attrs (face-spec-choose spec frame)))
  	(when spec
! 	  (face-spec-reset-face face frame))
  	(while attrs
  	  (let ((attribute (car attrs))
  		(value (car (cdr attrs))))
--- 1444,1454 ----
  (defun face-spec-set (face spec &optional frame)
    "Set FACE's attributes according to the first matching entry in SPEC.
  FRAME is the frame whose frame-local face is set.  FRAME nil means
! do it on all frames (and change the default for new frames).
! See `defface' for information about SPEC.  If SPEC is nil, do nothing."
    (let ((attrs (face-spec-choose spec frame)))
      (when spec
!       (face-spec-reset-face face (or frame t)))
      (while attrs
        (let ((attribute (car attrs))
  	    (value (car (cdr attrs))))
***************
*** 1464,1471 ****
  	      (t (unless (assq attribute face-x-resources)
  		   (setq attribute nil))))
  	    (when attribute
! 	      (set-face-attribute face frame attribute value)))
  	  (setq attrs (cdr (cdr attrs)))))
      ;; When we reset the face based on its spec, then it is unmodified
      ;; as far as Custom is concerned.
      (put (or (get face 'face-alias) face) 'face-modified nil)
--- 1463,1473 ----
  	      (t (unless (assq attribute face-x-resources)
  		   (setq attribute nil))))
  	(when attribute
! 	  ;; If frame is nil, set the default for new frames.
! 	  ;; Existing frames are handled below.
! 	  (set-face-attribute face (or frame t) attribute value)))
        (setq attrs (cdr (cdr attrs)))))
+   (unless frame
      ;; When we reset the face based on its spec, then it is unmodified
      ;; as far as Custom is concerned.
      (put (or (get face 'face-alias) face) 'face-modified nil)

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

Your patch looks plausible.  If people report it works right,
please install it.

Re: 23.0.50; face-problems with multy-tty

[Davis Herring]

> The new-frame default face attributes override customizations because
> they are usually set by programs during a session, whereas
> customizations are usually set semipermanently.  In that kind of case,
> it is right for the default face attributes to take precedence.

Programs don't usually (to my knowledge) set new-frame (or other) face
attributes except as static defaults which are of infinite duration.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

    Programs don't usually (to my knowledge) set new-frame (or other) face
    attributes except as static defaults which are of infinite duration.

If a program wants a static default, it should use defface.

If it is true that the only uses of set-face-attribute
are places that ought to use defface instead, perhaps
we should make it obsolete to get those programs' developers
to fix them.

What are some programs you have seen using set-face-attribute?

Re: 23.0.50; face-problems with multy-tty

[Juri Linkov]

>     Programs don't usually (to my knowledge) set new-frame (or other) face
>     attributes except as static defaults which are of infinite duration.
>
> If a program wants a static default, it should use defface.
>
> If it is true that the only uses of set-face-attribute
> are places that ought to use defface instead, perhaps
> we should make it obsolete to get those programs' developers
> to fix them.
>
> What are some programs you have seen using set-face-attribute?

This function is useful in .emacs to fix attributes of multiple faces
programmatically (not using the customization interface).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Richard Stallman skrev:

> Unfortunately, I don't see any way to distinguish settings made
> by the GNOME settings demon from those made by the user.
> 
> I know that X stores resources in various places.  Perhaps
> some of these places should have higher priority than others.
> 
> The file xrdb.c, which I have never really understood, seems
> to try to merge X resources from various places.  Perhaps
> that points a way to such a solution.
> 
> Would someone like to study xrdb.c and report on what is possible?
> 

xrdb.c merges resources from various sources.  They are read in this order 
(which is what X11 recommends):

- builtin
- system application file (.../X11/app-defaults/Emacs)
- user application file (XUSERFILESEARCHPATH is searched)
- user database (RESOURCE_MANAGER property or ~/.Xdefaults, and screen
                  specific property SCREEN_RESOURCES)
- file pointed to by environment variable XENVIRONMENT
- command line (-xrm)

Nowdays the users X resources (~/.Xdefaults) are more often than not merged 
into the RESOURCE_MANAGER property of the root X window (see 
XResourceManagerString).  This is what you see if you do xrdb -query.  The 
Gnome settings daemon also puts stuff here.

That is, resources from the users .Xdefaults/.Xresources and the resources 
from the Gnome settings daemon are not possible to distinguish.

To further complicate matters, system and application files can be set with 
the environment variables XFILESEARCHPATH, XAPPLRESDIR and XUSERFILESEARCHPATH.

So it is practically impossible to know the source for an individual resource, 
except perhaps the command line.

	Jan D.

Re: can't set both mode-line color and default frame font?

[Richard Stallman]

    So it is practically impossible to know the source for an individual resource, 
    except perhaps the command line.

That is a screw.

Is there any way Emacs can reliably detect that it's on a system
where certain X resources are made by the GNOME settings manager?

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Richard Stallman skrev:
>     So it is practically impossible to know the source for an individual resource, 
>     except perhaps the command line.
> 
> That is a screw.
> 
> Is there any way Emacs can reliably detect that it's on a system
> where certain X resources are made by the GNOME settings manager?

Not reliably, i.e. 100% correct all the time, but we can make a good guess. 
The resources set by the GNOME settings manager are quite specific (like 
Emacs.scroll-bar.attributeBackground, Emacs.scroll-bar.attributeForeground) 
and it it unlikely a user sets those.  So if we find that those resources the 
Gnome settings manager sets are set, we can with some confidence conclude that 
the user did not set them.

But what should we do then?  Ignore mode-line resources?

	Jan D.

Re: can't set both mode-line color and default frame font?

[Richard Stallman]

    Not reliably, i.e. 100% correct all the time, but we can make a good guess. 
    The resources set by the GNOME settings manager are quite specific (like 
    Emacs.scroll-bar.attributeBackground, Emacs.scroll-bar.attributeForeground) 
    and it it unlikely a user sets those.  So if we find that those resources the 
    Gnome settings manager sets are set, we can with some confidence conclude that 
    the user did not set them.

    But what should we do then?  Ignore mode-line resources?

We would not want to simply ignore them, but we might want to
give them different priority compared with other kinds of color
specifications.

However, if we always give face customization precedence over
X resources, then we don't need to disinguish GNOME's X resources
from other X resources.

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> However, if we always give face customization precedence over
> X resources, then we don't need to disinguish GNOME's X resources
> from other X resources.

I don't have an opinion about this, and I'm usually on Windows, which has no
X resources.

It sounded logical to me when I read that customization should take
precedence over X resources. However, it just occurred to me that it might
also be useful for it to be the other way around.

A user might have the same `custom-file' on different platforms, and
different X resources for various platforms would then modulate the
behavior, if they took precedence over the `custom-file' settings.
Otherwise, to get the same effect, the user would need different
`custom-file's.

Just a thought.

Re: can't set both mode-line color and default frame font?

[Jason Rumney]

Drew Adams wrote:
> It sounded logical to me when I read that customization should take
> precedence over X resources. However, it just occurred to me that it might
> also be useful for it to be the other way around.
>   

As useful as it might sound, customization within Emacs should always
take priority over the external environment. I am surprised that it is
not that way already. Perhaps the parsing of Xresources needs to be
moved earlier in the startup sequence (after site-start.el would be OK,
but it should certainly be before .emacs)

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> customization within Emacs should always
> take priority over the external environment.

"should always" - hmm

I'm not necessarily arguing against such a rule, but your supporting reason
for it is...?

Emacs already takes the context ("external environment") into account in
many ways - from your locale settings to your environment variables. Those
existing behaviors argue against your blanket statement. Unless they are all
wrong also.

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> > customization within Emacs should always
> > take priority over the external environment.
>
> "should always" - hmm
>
> I'm not necessarily arguing against such a rule, but your
> supporting reason for it is...?
>
> Emacs already takes the context ("external environment") into account in
> many ways - from your locale settings to your environment variables. Those
> existing behaviors argue against your blanket statement. Unless
> they are all wrong also.

Let me correct what I wrote before you do :-).

You did not of course say to not take the environment into account at all;
you were speaking only about precedence in case of conflict. So my examples
are not very pertinent.

Still, I'd like to hear the reason for the inside-out precedence rule.
(Again, I'm not arguing against it.)

RE: can't set both mode-line color and default frame font?

[Davis Herring]

> I'm not necessarily arguing against such a rule, but your supporting
> reason
> for it is...?

It belongs to no one but me, but my supporting reason is that Emacs is
much more intelligent than other configuration systems.  If need be, one
can base a color scheme on a traveling salesman solution for your
preferred colors and the system defaults, or whatever else.  True, Custom
can't make this easy for you (perhaps, for common cases like "different on
different hostnames", the idea of composable custom files could be made to
work), but .Xdefaults can't do it at all.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> > I'm not necessarily arguing against such a rule, but your supporting
> > reason for it is...?
>
> It belongs to no one but me, but my supporting reason is that Emacs is
> much more intelligent than other configuration systems.  If need be, one
> can base a color scheme on a traveling salesman solution for your
> preferred colors and the system defaults, or whatever else.  True, Custom
> can't make this easy for you (perhaps, for common cases like "different on
> different hostnames", the idea of composable custom files could be made to
> work), but .Xdefaults can't do it at all.

OK, but that argues that .emacs or `custom-file' is generally a better place
to customize than X resources, because it is more flexible/powerful. I'm not
sure that argument speaks to the question of precedence when multiple
customization sources are employed. It is not uncommon to have a less
flexible decision mechanism assume higher precedence/priority.

I'm just trying to flush out the reasons here, so we can understand the
issues better. I have no real opinion (yet) on how such customization
conflicts should be handled. On the face of it, it sounds good to me that
`custom-file' should take precedence, but I'm not sure why it sounds good to
me ;-).

RE: can't set both mode-line color and default frame font?

[Davis Herring]

> OK, but that argues that .emacs or `custom-file' is generally a better
> place to customize than X resources, because it is more flexible/powerful.
> I'm not sure that argument speaks to the question of precedence when
> multiple customization sources are employed. It is not uncommon to have a
> less flexible decision mechanism assume higher precedence/priority.

Emacs Lisp can also choose not to customize something at all.  So if it
does choose to do so, that has greater weight than the opinion of
something which only ever has one.

We could of course use that power/flexibility to define ways of specifying
customizations that did and others that did not override X resources (or
whatever other source), or simply provide a way to (perhaps in the middle
of some Lisp customizations) reapply the X resources as desired.  These
would be more complicated than a fixed precedence, but they might be
simpler than trying to make one mechanism dodge out of the way of the
other.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> > OK, but that argues that .emacs or `custom-file' is generally a better
> > place to customize than X resources, because it is more
> > flexible/powerful. I'm not sure that argument speaks to the question
> > of precedence when multiple customization sources are employed. It is
> > not uncommon to have a less flexible decision mechanism assume higher
> > precedence/priority.
>
> Emacs Lisp can also choose not to customize something at all.  So if it
> does choose to do so, that has greater weight than the opinion of
> something which only ever has one.

Only if you say it does ;-). That's just repeating the assertion that
`custom-file' (Emacs Lisp) should take precedence over X resource. The
question is "why should it?".

And what do you mean by "choose not to customize"? If a `custom-file' does
not customize some face, and there is an X-resource setting for it, are you
saying that the lack of customization in `custom-file' is "choosing not to
customize", so the X-resource setting should be overridden (ignored)?

In that case, we might as well throw away X resources for Emacs: they are
overridden if the same thing is customized in `custom-file', and they are
overridden (to restore the default) if they are not customized in
`custom-file'.

Maybe I've misunderstood you. I'm not trying to be cute, so correct me if
you meant something different by "choose not to customize".

> We could of course use that power/flexibility to define ways of specifying
> customizations that did and others that did not override X resources (or
> whatever other source), or simply provide a way to (perhaps in the middle
> of some Lisp customizations) reapply the X resources as desired.  These
> would be more complicated than a fixed precedence, but they might be
> simpler than trying to make one mechanism dodge out of the way of the
> other.

Please elaborate. I don't follow.

RE: can't set both mode-line color and default frame font?

[Davis Herring]

>> Emacs Lisp can also choose not to customize something at all.  So if it
>> does choose to do so, that has greater weight than the opinion of
>> something which only ever has one.
>
> Maybe I've misunderstood you. I'm not trying to be cute, so correct me if
> you meant something different by "choose not to customize".

You have -- but not that phrase.  I meant that if Lisp does choose -to-
customize, that should take precedence because it is a choice (there's
your reason).

> Please elaborate. I don't follow.

There's nothing stopping us from supporting any or all of these:

(customize-face-override-resources 'default '((:background ...)))
(customize-face-defer-to-resources 'default '((:foreground ...)))
;; or
(customize-face 'default '((:stipple ...))) ; always overrides resources
(load-resources here)                       ; ok, now we override customize
(customize-face 'fringe '((:box ...)))      ; this overrides them again

The question is whether that's better or worse (I said "complicated" as
the metric) than doing something clever in a custom-file (or .emacs) or in
C when loading these preferences.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> I meant that if Lisp does choose -to- customize, that should
> take precedence because it is a choice (there's your reason).

And setting a face preference via an X resource is _not_ choosing?

I still don't see an argument (a reason) that applies only to `custom-file'
and not to X resources. Flip it around, and it makes just as much sense
(little).

> There's nothing stopping us from supporting any or all of these:
>
> (customize-face-override-resources 'default '((:background ...)))
> (customize-face-defer-to-resources 'default '((:foreground ...)))
> ;; or
> (customize-face 'default '((:stipple ...))) ; always overrides resources
> (load-resources here)                       ; ok, now we override
> customize
> (customize-face 'fringe '((:box ...)))      ; this overrides them again
>
> The question is whether that's better or worse (I said "complicated" as
> the metric) than doing something clever in a custom-file (or .emacs) or in
> C when loading these preferences.

AFAICT, instead of an argument _why_ Lisp (.emacs or `custom-file') should
take precedence over X resources, you've assumed that it does, and then
shown that we could code some Lisp that controls (implements) precedence.
That assumes that that Lisp code is in control.

Anyway, I doubt we're going to get anywhere with this tack. I was hoping
someone had a good reason for such a precedence choice, but it doesn't
matter. As I said, I see no special reason against it.

Re: can't set both mode-line color and default frame font?

[Stefan Monnier]

>> I meant that if Lisp does choose -to- customize, that should
>> take precedence because it is a choice (there's your reason).

> And setting a face preference via an X resource is _not_ choosing?

> I still don't see an argument (a reason) that applies only to `custom-file'
> and not to X resources. Flip it around, and it makes just as much sense
> (little).

You're right.  Which implies that there's no absolutely always 100%
superior solution.  So we can choose between the two based on other
considerations.  E.g. the fact that Custom settings are only ever set by the
user for Emacs, whereas X resources may just as well be set by some global
application such as Gnome and may apply to many more applications than just
Emacs, so they're *in general* less specific.


        Stefan

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> >> I meant that if Lisp does choose -to- customize, that should
> >> take precedence because it is a choice (there's your reason).
>
> > And setting a face preference via an X resource is _not_ choosing?
>
> > I still don't see an argument (a reason) that applies only to
> `custom-file'
> > and not to X resources. Flip it around, and it makes just as much sense
> > (little).
>
> You're right.  Which implies that there's no absolutely always 100%
> superior solution.  So we can choose between the two based on other
> considerations.

Just what I was getting at: what those considerations might be.

> E.g. the fact that Custom settings are only ever
> set by the user for Emacs, whereas X resources may just as well be
> set by some global application such as Gnome and may apply to many
> more applications than just
> Emacs, so they're *in general* less specific.

That sounds like a good reason to me - give precedence to what we are pretty
sure are individual user preferences over what might not be.

RE: can't set both mode-line color and default frame font?

[Davis Herring]

>> I meant that if Lisp does choose -to- customize, that should
>> take precedence because it is a choice (there's your reason).
>
> And setting a face preference via an X resource is _not_ choosing?
>
> I still don't see an argument (a reason) that applies only to
> `custom-file'
> and not to X resources. Flip it around, and it makes just as much sense
> (little).

I'm having wretched luck writing clearly here.  It is true, of course,
that the user may choose to put something in an X resource.  (The session
manager may also do so, which is what started this.)  But no mechanism I
know of for setting X resources -itself- may make such choices; that is,
it must be all-or-nothing, and cannot be adaptive, deferent, or flexible. 
Personifying those mechanisms, they are dumb: they can do what they are
told, but cannot make decisions or analyze situations.  Lisp is, of
course, not dumb, although making it at all smart may be beyond the skills
of an Emacs novice.

If we say that X resources take priority, knowing that they are asserted
by simpletons (the files holding the settings, not the users!), we lose
the ability to use X resources and yet be smart about it.  If we say that
Lisp takes priority, then we have not restricted ourselves: the resources
may be used, or -- if the smart Lisp decides -- they may be
ignored/overridden.  That is my argument: that one precedence order
provides a less powerful way of specifying preferences than the other.  A
user who chooses to set X resources and wants them used is of course also
capable of not setting overriding preferences in Lisp.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: can't set both mode-line color and default frame font?

[Richard Stallman]

    Only if you say it does ;-). That's just repeating the assertion that
    `custom-file' (Emacs Lisp) should take precedence over X resource. The
    question is "why should it?".

There is no general theoretical reason why Emacs face customizations
should take precedence over X resources.  Sometimes users want that.
Sometimes thy want the opposite.  But nobody has seen any general rule
for figuring out which one the user would prefer.  Unless we add
another complex feature for specifying which -- and that doesn't seem
worth while -- we must adopt and document one choice or the other.

Of the two choices, having face customization settings take precedence
seems better.

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Jason Rumney skrev:
> Drew Adams wrote:
>> It sounded logical to me when I read that customization should take
>> precedence over X resources. However, it just occurred to me that it might
>> also be useful for it to be the other way around.
>>   
> 
> As useful as it might sound, customization within Emacs should always
> take priority over the external environment. I am surprised that it is
> not that way already. Perhaps the parsing of Xresources needs to be
> moved earlier in the startup sequence (after site-start.el would be OK,
> but it should certainly be before .emacs)
> 

It is inconsistent.  .emacs takes precedence over X resources for things that 
go in default/initial-frame-alist (tool bar, menu bar, font, geometry), so to 
make that a global policy would be good.

	Jan D.

Re: can't set both mode-line color and default frame font?

[Stefan Monnier]

>> However, if we always give face customization precedence over
>> X resources, then we don't need to disinguish GNOME's X resources
>> from other X resources.

> I don't have an opinion about this, and I'm usually on Windows, which has no
> X resources.

> It sounded logical to me when I read that customization should take
> precedence over X resources. However, it just occurred to me that it might
> also be useful for it to be the other way around.

> A user might have the same `custom-file' on different platforms, and
> different X resources for various platforms would then modulate the
> behavior, if they took precedence over the `custom-file' settings.
> Otherwise, to get the same effect, the user would need different
> `custom-file's.

Note that the ordering only matters when there are settings to the same data
in both places.  The user is free to choose whether to place settings in
custom-file, so if she wants to use Xresources, she can simply refrain from
putting the settings on custom-file.


        Stefan

RE: can't set both mode-line color and default frame font?

[Drew Adams]

> > A user might have the same `custom-file' on different platforms, and
> > different X resources for various platforms would then modulate the
> > behavior, if they took precedence over the `custom-file' settings.
> > Otherwise, to get the same effect, the user would need different
> > `custom-file's.
>
> Note that the ordering only matters when there are settings to
> the same data in both places.  The user is free to choose whether
> to place settings in custom-file, so if she wants to use Xresources,
> she can simply refrain from putting the settings on custom-file.

Yes, the question is how to handle a conflict between competing
customization sources for some user option/face.

What I was alluding to was having a stock `custom-file' that specifies the
preferences you want in most cases, and have a few X-resource settings that
override some of those `custom-file' settings on some platform.

You would still want the rest of the `custom-file' to be used on that
platform, and you would still want the `custom-file' to be used, even for
those overridden preferences, on other platforms (where they are not
overridden).

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Drew Adams skrev:
>> However, if we always give face customization precedence over
>> X resources, then we don't need to disinguish GNOME's X resources
>> from other X resources.

I think Emacs reads "X resources" from the registry in W32 (w32reg.c).

> 
> I don't have an opinion about this, and I'm usually on Windows, which has no
> X resources.
> 
> It sounded logical to me when I read that customization should take
> precedence over X resources. However, it just occurred to me that it might
> also be useful for it to be the other way around.
> 
> A user might have the same `custom-file' on different platforms, and
> different X resources for various platforms would then modulate the
> behavior, if they took precedence over the `custom-file' settings.
> Otherwise, to get the same effect, the user would need different
> `custom-file's.

This is a very unlikely scenario.  Much easier to just customize faces in 
Emacs on each platform.

	Jan D.

Re: can't set both mode-line color and default frame font?

[Jan Djärv]

Richard Stallman skrev:
>     Not reliably, i.e. 100% correct all the time, but we can make a good guess. 
>     The resources set by the GNOME settings manager are quite specific (like 
>     Emacs.scroll-bar.attributeBackground, Emacs.scroll-bar.attributeForeground) 
>     and it it unlikely a user sets those.  So if we find that those resources the 
>     Gnome settings manager sets are set, we can with some confidence conclude that 
>     the user did not set them.
> 
>     But what should we do then?  Ignore mode-line resources?
> 
> We would not want to simply ignore them, but we might want to
> give them different priority compared with other kinds of color
> specifications.
> 
> However, if we always give face customization precedence over
> X resources, then we don't need to disinguish GNOME's X resources
> from other X resources.

That seems like a good approach.

		Jan D.

Re: can't set both mode-line color and default frame font?

[Stefan Monnier]

> * All-frames face attribute settings
> * X resources.
> * User face customizations
> * The defface.

Why should X resources take precedence over user face customizations?
It seems swapping the two would make a lot more sense (by removing the
inconsistency being discussed and by giving precedence by customization made
"the Emacs way" over customizations made in some more system-wide style, as
is usually the tradition in Emacs).


        Stefan

Re: can't set both mode-line color and default frame font?

[Richard Stallman]

    Why should X resources take precedence over user face customizations?

I did not distinguish enough cases.  I was thinking of face
customizations saved in .emacs.  It makes sense for X resources which
you set up in a session to take precedence over those, because the
latter are semipermanent.

However, X resources can also be meant as semipermanent, and user face
customization can be done within a session.  Thus, either ordering
can be wrong.

    It seems swapping the two would make a lot more sense (by removing the
    inconsistency being discussed and by giving precedence by customization made
    "the Emacs way" over customizations made in some more system-wide style, as
    is usually the tradition in Emacs).

It is starting to seem like the best course of action.

Re: 23.0.50; face-problems with multy-tty

[Tassilo Horn]

Tassilo Horn <thorn+news@fastmail.fm> writes:

Hi,

what's with this?

> Ah, and the face of the buttons in the customize interface doesn't use
> boxes, it's only underlined (Custom Button Unraised), because
> `custom-raised-buttons' is nil.  IMHO in an X11 frame client it should
> default to t, so that there are no user-visible differences between a
> client using a X11 frame and a normal X11 emacs instance.

Bye,
Tassilo