[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

-xrm resources ignored on display other than first

From: Todd Allen
Subject: -xrm resources ignored on display other than first
Date: Sun, 10 Jun 2001 21:58:26 -0600 (MDT)

The -xrm resource string appears to be used correctly on the initial
frame, and on any frames subsequently created on the same display, but
is ignored on frames created on any other display.  Here's an example
sequence.  Start emacs like this:

   emacs --no-init-file -xrm '*Background: orange' 

The first frame will have an orange background.  Inside the emacs session,
issue the following command:

   M-x make-frame-on-display 

and then whatever *other* display you have handy.  I've tried it on a
completely separate X server, and on the other head of a 2-head setup, and I
don't get the orange background in either case.


   emacs --no-init-file -bg orange

followed by:

   M-x make-frame-on-display 

and the same displays does produce an orange background.

A little debugging lead me to the conclusion that the path followed by
make-frame-on-display eventually called x_display_info_for_name() on
the new display, and it did:

  dpyinfo = x_term_init (name, (unsigned char *)0,
                         (char *) XSTRING (Vx_resource_name)->data);

which ignores the xrm_string, sure enough.  Probably the xrm_string
ought to be referenced here as a new global variable (ick), unless you
want to implement a solution that passes it around through all the
callers of x_display_info_for_name().

In the meantime, I've been using the following kludge in my .emacs:

   (defun x-create-frame-with-faces-and-xrm-string (&optional parameters)
      (let ((display-name (or (cdr (assq 'display parameters))
                              (cdr (assq 'display default-frame-alist)))))
         (if (and display-name (not (member display-name (x-display-list))))
            (x-open-connection display-name x-command-line-resources)
      (x-create-frame-with-faces parameters)
   (setq frame-creation-function 'x-create-frame-with-faces-and-xrm-string)

I suppose something like it could be turned into a long-term solution, but I
worry that it would just be sweeping the problem under a bigger rug.  That
is, I worry that there would be other paths capable of reaching
x_display_info_for_name(), so that frames could still be created ignoring the
-xrm strings.

Todd Allen
Concurrent Computer Corporation

reply via email to

[Prev in Thread] Current Thread [Next in Thread]