From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Subject: Re: kind of -geometry wxh+x+y for a new screen
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
	<WARSAW.93Jan26153002@anthem.nlm.nih.gov>
	<9301280922.AA05037@thalidomide.lucid>
Date: 28 Jan 93 18:19:31 GMT


    me> Jamie, maybe you can add a lisp function x-reread-resources???

    Jamie> This could be done, but it would be slightly non-portable,
    Jamie> since I believe there's no advertised way to read the
    Jamie> resource db; all of the directory- searching magic is built
    Jamie> into Xt.  Also, it would leak like mad, since I'm pretty
    Jamie> sure resource dbs are never freed.

You could read the resources via the Xrm functions right?  Ah, I see
the problem.  Its getting *Xt* to use the new resources.  I'm not up
on Xt stuff so I'm gathering there's no way to re-init Xt's view of
the resource db.  I wouldn't expect existing screens to change their
attributes when I evaled x-reread-resources -- I'd be satisfied if new
screens came up with the new attribute values.  Oh well, either way,
ain't no big thang since I don't expect to be changing attributes that
often.  The nice thing is that you can play with the attributes in
lisp until you're pretty happy with them, then fold them into your
.Xdefault for long-term use.

    me> 2. I can't seem to find a way to specify different initial
    me> screens.  -name switch doesn't seem to work.

I meant to say, "different initial screen attributes".
                                          ^^^^^^^^^^

    Jamie> -name works, but maybe it doesn't do what you think it
    Jamie> does.  For resource- lookup purposes, it effectively
    Jamie> changes what argv[0] is.  This doesn't have anything to do
    Jamie> with screen names, which are a level down in the hierarchy
    Jamie> from that.

This is what I really want, and what I just can't seem to make work.
Let me give a concrete example and perhaps you can tell me what I'm
doing wrong (I *know* I'm missing something obvious somewhere).

warsaw@anthem[10]% xrdb -query | grep background | grep -i emacs
Emacs*background:	LightYellow             <=== background for class
Emacs*QUICK.background:	PaleGoldenRod
Emacs*WIDE.background:	gainsboro
emacs1*background:	#dcc8aa
emacs2*background:	PaleGoldenRod
emacs3*background:	LightYellow
emacs4*background:	PeachPuff
emacs5*background:	Peru
emacs6*background:	SandyBrown
emacs7*background:	LightSeaGreen
emacs8*background:	Sienna
emacs9*background:	Bisque
emacs10*background:	Wheat                   <=== background for instance

warsaw@anthem[12]% lemacs -name emacs10

Background of this new lemacs is LightYellow, the value of the
attribute for class Emacs, not Wheat, the value of the attribute for
instance emacs10.  Is my understanding that this should have come up
in Wheat incorrect??  Perhaps the argv[0] name is not overriding the
class name of Emacs when both are specified?  This just doesn't seem
right.

Note that I can do:

warsaw@anthem[13]% xterm -name emacs10
warsaw@anthem[14]% editres -name emacs10

And both xterm and editres come up with backgrounds of Wheat, as
expected, even when there are XTerm*background and Editres*background
specifications in the database.  So at the very least, lemacs seems
inconsistent with editres, which is also an Xt based app, right?

    me> Maybe there should be a -screen switch to specify the
    me> screen-name of the initial screen???

    Jamie> That'd be easy; just have that switch set
    Jamie> `default-screen-name'.

I may try to hack that in, especially if the behavior lemacs is now
exhibiting is not a bug, but proper behavior.

-Barry
Newsgroups: alt.lucid-emacs.help