On jeu., 2011-11-17 at 13:19 -0800, Russ Allbery wrote:
> Yves-Alexis Perez <cor...@debian.org> writes:
> 
> > I've asked Xfce people about that, and they don't really remember why
> > -nocpp is passed. Looking a bit on Google, I found
> > http://mail.gnome.org/archives/gnomecc-list/2005-October/msg00024.html
> > and I think the command line was basically copied from Gnome, or
> > something like that.
> 
> It definitely makes sense to use -nocpp in these situations, where one is
> passing known input that isn't using the preprocessor.

Agreed :)
> 
> > So removing -nocpp might means slowing down the session start, which is
> > a bit unfortunate.
> 
> Well, hopefully one would only use the default behavior when loading the
> user's personal configuration (and maybe system-wide defaults), where cpp
> is part of the expected interface.

Well, it seems that -nocpp was used since a long time, so “expected
interface” doesn't really stand here.

>   My guess is that wouldn't lead to any
> visible slowdown, although I admit I've not tested.

Well, considering today's boxes, yeah. Unless people have really
long .Xressources, I'm not sure the difference will be visible. Here I
can't even do meaningful measures:

corsac@scapa: time xrdb -nocpp -merge .Xresources
0,00s real  0,00s user  0,00s system  0% xrdb -nocpp -merge .Xresources
corsac@scapa: time xrdb  -merge .Xresources
0,02s real  0,00s user  0,00s system  19% xrdb -merge .Xresources

it might make sense to do that on older machines.
 
> 
> > What puzzles me though, is that afaict the settings should have already
> > been applied by /etc/X11/Xsession.d/30x11-common_xresources and the call
> > in /etc/xdg/xfce4/xinitrc should only merge new stuff, not replace them.
> > How comes it doesn't work for you?
> 
> I have never understood exactly what xrdb -merge does in this sort of case
> where one is loading the same file twice and it's setting a single-valued
> resource.  The man page has always been ambiguous about that ("merged and
> lexicographically sorted with," which doesn't clearly say "the current
> value will be kept" or "the new value will be kept").
> 
> I did a brief experiment, changing a resource that was already set
> (XTerm*VT100.geometry) and then loading .Xresources again with xrdb -merge
> and the new setting overrode the previous setting after xrdb -merge.  So I
> think that at least in some cases the results of the second invocation
> will overwrite the first.

In fact, that makes sense, the second xrdb call sees that the “new”
Xressources (without preprocessing) is different from the current (with
preprocessing so it'll update it.

Regards,
-- 
Yves-Alexis

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to