Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg <embe8573@student.uu.se>]

Dan Espen <despen@verizon.net> writes:

> #if ( HEIGHT == 900 )     /* Traditional Sparc */
> Rxvt.geometry: 80x55
> #elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
> Rxvt.geometry: 80x65
> #elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
> Rxvt.geometry: 80x47
> #else                     /* I have no idea... */
> Rxvt.geometry: 80x40
> #endif

I did some research on this, and put it a short article.

I will probably send it to some Linux aficionados and their
publications, so I made an effort to be more pedagogical in tone,
than I usually am. Anyway, suggestions how to improve are welcome.

But this post is also a continuation of this very discussion, so
don't worry!

Xdefaults vs. Xresources

The old solution was: Whenever an X ("Xlib" - ?) application is
invoked, it looks in ~/.Xdefaults for settings, and then
executes. The file had to be on the same filesystem, in the user's
HOME.

The "new" solution is: Whenever an X application is invoked, it
looks for settings in RESOURCE_MANAGER (XA_RESOURCE_MANAGER - ?)
in the root window of screen 0. Settings are there, if xrdb has
been run since the start of X. If not, the *fallback* is to look
for settings in Xdefaults (every time, for every application,
exactly as the old solution).

xrdb doesn't have to read ~/.Xresources, that's a convention. It
can read any file, even ~/.Xdefaults. (Note that xrdb *has* to be
used - some say ~/.Xresources is ignored because of GNOME and GDM
- this is not the case - even with xinit or startx, xrdb has to be
used.)

Xresources makes for flexibility, as any user can use, or not use,
xrdb, and use it on any file.

Xresources makes for mobility, as ~/.Xdefaults has to be in the
user's HOME folder, on the same file system. To test the enhanced
mobility, after reading resources with xrdb, do the following:

1. In X, and a WM (e.g., Openbox), and a terminal (e.g., urxvt),
ssh to a remote system with the -Y option. There, start xterm, or
any other application that you have configured on your local
system, but not on the system, to which you ssh'd. Then, do the
same on you local system: start xterm. They look the same!

2. Now, on your local system, run 'xrdb -remove'. Again, start
xterm on both the remote and the local system - again, they look
the same, only now, they aren't configured.

3. Last, to demonstrate the limited scope of Xdefaults, without
using xrdb since step 2, on you local system, run 'cp
~/.Xresources ~/.Xdefaults' (after salvaging anything of value
from Xdefaults), then run xterm on both remote and local
system. The remote xterm is unconfigured, but the local xterm is -
only, this time, from Xdefaults.

Notes:

The #1 Google hit on this issue recommends making ~/.xinitrc an
executable, with 'chmod +x' - this is not needed.

Also, the same article exemplifies the use of xrdb in .xinitrc
with a trailing '&', making xrdb a background process. This isn't
right, as the next program run from .xinitrc may use the very same
settings, that xrdb is in the process of setting up, and that must
be completed before any application that depends on it can be
run. Simple cure: remove the '&'.

Some xterm settings useful for testing:

xterm*autoWrap:        true
xterm*pointerMode:     2
xterm*geometry:        77x28
xterm*background:      black
xterm*foreground:      green4
xterm*faceName:        default
xterm*metaSendsEscape: true

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573