home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: alt.lucid-emacs.help
- Path: sparky!uunet!UB.com!pacbell.com!sgiblab!darwin.sura.net!lhc!lhc!warsaw
- From: warsaw@nlm.nih.gov (Barry A. Warsaw)
- Subject: Re: kind of -geometry wxh+x+y for a new screen
- In-Reply-To: jwz@lucid.com's message of 28 Jan 93 09:22:35 GMT
- Message-ID: <WARSAW.93Jan28131931@anthem.nlm.nih.gov>
- Lines: 80
- Sender: news@nlm.nih.gov
- Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
- Organization: Century Computing, Inc.
- References: <1993Jan26.185113.169699@eratu.rz.uni-konstanz.de>
- <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
-