help-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Bob Proulx
Subject: Re: Sanest way to make emacs behave on a Solaris OS
Date: Mon, 5 Aug 2013 14:04:30 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

Emanuel Berg wrote:
> Bob Proulx writes:
> > Use of .Xdefaults is rather superseded by the .Xresources file.
> > The difference between the two is subtle.  But .Xresources tends
> > to be preferred because of the way that it is applied.  The
> > .Xresources is applied to the $DISPLAY through xrdb.  The
> > .Xdefaults is applied through the presence in the $HOME
> > directory, but only if the xrdb is empty.  So once you have a
> > .Xresources the .Xdefaults is no longer used.
> 
> That's interesting. On my school's Solaris/SunOS, in my home
> directory, there wasn't any .Xresources to begin with, but there
> was an .Xdefaults. It would have been interesting to examine the
> the contents of that file, but I was so eager to try the
> .Xresources solution that I just deleted the .Xdefaults, to be
> sure it didn't influence in any way. And now, you're saying that
> was unnecessary, because it is only applied if there isn't a
> populated xrdb/.Xresources. You live, you learn.

The difference is a little subtle if you are not in a situation to
notice how they are different from each other.  Let me give an
example.

You and I are both working on a server machine for some task using a
shared login.  (Let's not debate the shared login aspect.  Much of
this was set up decades ago.  At one time on local private friendly
networks that was very commonly done.  And this also applies to a
single user with different device displays too.)

You log into the machine and either tunnel X with ssh -X or you set
DISPLAY and allow it to forward raw to your desktop display.  I do the
same.  Say that I like white on black text and you like black on white
text.  However this could be any given customization.  It is only
important that we like different things.  We both start up the same
graphics application for the purposes of the shared task.

An alternative difference could be that you are working on a very
large widescreen monitor and want to set sizes, fonts, dpi, to match
your large screen.  I am working off of a 7 inch tablet and wish to
set sizes, fonts, dpi, to match my more limited work space.  Just for
another example.

Using $HOME/.Xdefaults on the server then we both share the same
customization.  I edit the file and make it my way.  I am happy and
you are unhappy.  You edit the file and make it your way.  You are
happy and I am unhappy.  The use of .Xdefaults works after a fashion
but it is limited and unable to make both of us happy at the same
time.  We can really only keep personalized copies of the .Xdefaults
file and switch by copying or linking it into place when we are
running and hope we are never running at the same time.

Due to this problem it is learned that these types of customization
problems are properties of the display and not of the user.  They
should be attached to the $DISPLAY and not to the $HOME.  Attaching
properties to the $DISPLAY instead of $HOME is the distinction between
using .Xresources and .Xdefaults.

Enter xrdb and the ability to set DISPLAY properties.  You have on
your desktop, not the server, a .Xresources file.  I have the same.
You put your customizations in your file and I put my customizations
in my file.  You load the contents into your $DISPLAY and I load my
contents into my $DISPLAY.  X graphical applications will look for
resources there first.  If that database exists and is available then
those will apply and no $HOME/.Xdefaults will be loaded.  Using this
strategy customization is a property of the $DISPLAY and not $HOME.

This also allows a single user to have a small screen tablet with one
set of customization and a large screen desktop with a different set
of customization because each will have a different $DISPLAY.  So it
applies generically to more than just shared logins between different
users.  It also applies to shared logins of the same user on different
displays.

In the case of a single user on a single device everything is
collapsed into a single case and it would be hard to tell the
difference.  But if you have several devices sharing an account, even
if it is the same user, then the difference allows customization to be
different for each display device.

I hope this explanation makes sense and is useful.

Bob



reply via email to

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