8

After starting to use Arch I switched to xterm and urxvt terminal and enjoyed the flexibility of them (esp. scaleHeight resource). However, I don't understand why sometimes configs work with Xterm and sometimes with xterm or XTerm (lower vs upper case x and t).

For example, I have this odd config that is working on Ubuntu:

XTerm*faceName: terminus
XTerm*faceSize: 11
XTerm*saveLines: 16384
XTerm*loginShell: true
XTerm*charClass: 33:48,35:48,37:48,43:48,45-47:48,64:48,95:48,126:48
XTerm*termName: xterm-color
XTerm*eightBitInput: false
xterm*VT100.geometry: 100x80    ! <------ this line would not work with "Xterm" or "XTerm"
XTerm*scaleHeight: 1.3          ! <----- but all others work with "XTerm"

However, my Arch box runs on "xterm" fine. The same is true for URxvt terminal: I can't simply port my Arch .Xresources to Ubuntu14 work box because parts of it stop working, and I get different setups after running:

xrdb -merge .Xresources

X.org on xterm did not have any examples (searching for "xterm*" did not return anything on that page). I see examples with Xterm, xterm and XTerm online... It baffles me that the config above works since it is syntactically off. Why is this the case? Does it maybe have something to do with new or old resources in X? Thanks!

xterm on ubuntu is Xterm(297). I don't have access to my Arch box at the moment, but it would be pretty up-to-date. I don't know how to tell Xterm version from Arch's repos, but maybe this: https://www.archlinux.org/packages/extra/i686/xterm/ So, if that link is right, then yes, I am running different Xterm versions.

I tried upgrading xterm, but it is still 297.

apt-get update && apt-get install --only-upgrade xterm

I can't do it now, but I might try to recompile the latest version to see if the issue is there.

Following the suggestions by ILMostro_7 below I tried XTerm.vt100.geometry, which still did not work. This is Xterm (297) on Ubuntu14. So basically, . or * it seems to only work with little xt.

Result of appres XTerm xterm | grep geometry thanks to Gilles. I did not think to look up what exactly xrdb -merge does which resulted in this mess. So my guess is that one of these takes precedence over everything else?

xterm.VT100.geometry:   100x100
xterm*VT100.geometry:   100x80
xterm*VT100*geometry:   50x50
xterm.vt100.geometry:   160x40
xterm*vt100.geometry:   100x20
xterm.geometry: 5x5
xterm*geometry: 100x20
XTerm.VT100.geometry:   100x100
XTerm*VT100.geometry:   50x50
XTerm*VT100*geometry:   20x10
XTerm.vt100.geometry:   100x5
XTerm*vt100.geometry:   40x40
XTerm*geometry: 50x50

In fact it looks like xterm.vt100.geometry: 160x40 takes precedence over other ones since that the instance I keep getting. Also, I somehow managed to completely screw up Xterm menues (Ctrl+mouse click) - they show up as a small yellow line. Hehe

Serge Poele
  • 115
  • 1
    This page suggests that the client class part (XTerm in your case) is case-sensitive. I don't know how Xresources works, but some speculation: Maybe you're running different versions of xterm between your boxes somehow? (Post xterm -version?) Maybe different distros call the xterm program different class names? (I don't know how to check for this. – Anko Jul 17 '15 at 13:05
  • That's probably because you may be missing the specified font and/or it's misconfigured. Try it with a font you know is properly installed on that system. – ILMostro_7 Jul 17 '15 at 13:30
  • 1
    @ILMostro_7 faceName resource is not a problem. Terminus font is successfully installed and used by all X applications (including Xterm and Rxvt) on both Arch and Ubuntu. – Serge Poele Jul 17 '15 at 13:34
  • Yea, sry I misunderstood the question for a moment – ILMostro_7 Jul 17 '15 at 13:50
  • Did you try changing the xterm*vt100.geometry to XTerm.vt100.geometry? – ILMostro_7 Jul 17 '15 at 13:57
  • 1
    Thank you @ILMostro_7. I just tried that and it still does not work. But if I try xterm.vt100.geometry (lower case "xt") again - it works. :) This is Xterm (297) on Ubuntu14. So basically, "." or "*" it seems to only work with little "xt". I will update the post with this test. – Serge Poele Jul 17 '15 at 14:07

2 Answers2

12

X11 resources have a name which consists of a series of components separated by a dot, such as xterm.vt100.geometry. The first component is the name of the application, the second component is a widget in that application, and the last component is a property of the widget. Widgets can be nested, so there can be more than three components, or just two for a property of the application.

Specifications of X resources can apply to a single resource or to a set of resources matching a pattern. There are two ways to make a specification apply to multiple resources.

  • You can use a class name instead of an instance name for any component. Conventionally, instance names start with a lowercase letter while class names start with a capital letter.

    • At the application level, the class name is usually fixed for a given application, typically to the capitalized application name, and sometimes other letters are also in uppercase, e.g. XTerm, XCalc, GV, NetHack, ... Applications using the X toolkit support an option -class to set the class name, as well -name to set the instance name (which defaults to the base name of the executable). For example XTerm.vt100.geometry sets a value of the geometry property for the vt100 widget of any instance of the XTerm class; it applies to xterm -name foo but not to xterm -class Foo.
    • At the widget level, there can be multiple widgets with the same class, for example multiple buttons in the same window. Xterm has a single widget of class VT100, called vt100, which is the terminal emulator part that covers the whole window. Other widgets include the menus mainMenu, fontMenu and vtMenu of class SimpleMenu.
  • There are wildcards: ? means “any widget”, and * means “any widget sequence”. For example xterm*background defines a background for absolutely everything inside the Xterm window.

You can explore the resource tree of an application that supports the editres protocol with editres. Few applications support this protocol, but Xterm is one of them.

It's possible for a given resource to be matched by multiple patterns. In this case, precedence rules apply. See the manual for the full rules.

In your case, it's likely that there's another entry somewhere that is a closer match for xterm.vt100.geometry than xterm*VT100.geometry, and that match is overriding your setting. The others have no other setting so whatever you do wins.

Gilles 'SO- stop being evil'
  • 829,060
  • 1
    This is such a beautiful and unique answer. There are so many .Xresources posts on SO, but nothing touches upon classes and instances of X applications. Thank you so much for this; this brings a whole new understanding of X apps configuration. Thank you so much Gilles. Following your discussion I found the link to X programmer documentation that expands on the terminology you provided here (see below and also "Creating a widget").

    http://www.x.org/releases/X11R7.7/doc/libXaw/libXaw.html#Terminology

     – Serge Poele Jul 21 '15 at 12:46
  • What I still don't understand is this. I added this line: XTerm*geometry: 40x40 and made sure I don't have any other geometry lines in files except URxvt*geometry: 20x20. From your explanation, "XTerm" should set "geometry" field for every instance of XTerm class, which means every new XTerm instance should be 40x40. However, URxvt responds to that: I get a 20x20 instance every time I launch it, but Xterm does not. I understand that I haven't specified the widget like so: XTerm*vt100*geometry:40x40. But you said XTerm*geometry should mean "any widget sequence" which would include vt100? – Serge Poele Jul 21 '15 at 12:52
  • @SergePoele I think that happens because there's a system-level setting for some specification that has precedence over XTerm*geometry, such as XTerm.VT100.geometry. – Gilles 'SO- stop being evil' Jul 21 '15 at 18:49
  • Thanks again. I think that makes sense: on my Mint laptop I can probably speculate that there are some configurations that are set by Mint developers. On my Arch box there is nothing in terms of configurations that runs in X that was set by Arch developers, so nothing is overriding XTerm*geometry setting. However, this is an educated guess, and can't really prove this somehow. Nevertheless, thanks for all answers. I am definitely sticking to Xterm and Urxvt now that I learnt more about configuration. – Serge Poele Jul 21 '15 at 22:45
  • @SergePoele What's the output of appres XTerm xterm |grep geometry ? – Gilles 'SO- stop being evil' Jul 21 '15 at 23:03
  • Spot on Gilles! What I did not think of is to try to understand what exactly "xrdb -merge" does to the X database. Look at this horror show (posted in the original post)

    This is "wild" guess, but it probably not supposed to look like this. Hehe

     – Serge Poele Jul 22 '15 at 16:40
  • @SergePoele xterm.vt100.geometry trumps everything. You can't remove an entry from the resource database (WHY? Beats me.), you have to dump it, remove the lines you don't want, and call xrdb -load. – Gilles 'SO- stop being evil' Jul 22 '15 at 18:35
  • Thanks! It is strange that you can't remove an entry from the db. I did the following: cp /dev/null .Xresources. Then xrdb .Xresources to overwrite with nothing. Then appres XTerm xterm returned none of my configs and XTerm looks like it does on clean build. Grep'ing geometry also returned nothing. Then I added a new geometry entry that worked according to the plan. Heh. I guess I could write a script that would automate this, but it not good that it takes so many steps. Ah, well, I still like xterm. – Serge Poele Jul 22 '15 at 20:52
  • But just to be clear I get it: xterm.vt100.geometry: 160x40 trumps everything because with this line I specify and instance name and a widget name, which is essentially a default instance of XTerm, right? That's why it takes precedence over other settings. This would explain why Xterm -name foo gave me different geometry. Is that correct? – Serge Poele Jul 22 '15 at 20:57
  • @SergePoele Yes, xterm.vt100.geometry is the most specific way to specify a resource: no wildcards, and only instances, no class. – Gilles 'SO- stop being evil' Jul 22 '15 at 20:59
  • @Gilles Thank you. This was a good thread. Heh – Serge Poele Jul 23 '15 at 11:40
4

Some of the comments, etc., are not accurate. By the way, the description of X resources is in the X(7) manual page, in the section titled Resources. That's the best place to start reading, and there's little point in repeating it here.

Here's some points overlooked:

  • resource names are case-sensitive: XTerm is not the same as Xterm is not the same as xterm, etc.
  • conventionally X resource names use a leading capital letter for class name.
  • when the first letter of the class name is X, there's a convention to make the second letter capitalized. So we get XTerm. Other examples include XCalc, XClock, XConsole, XLoad, XLogo.
  • on the other hand, we have Xedit (lowercase e), Xfd, Xmag, Xman, Xmessage, Xvidtune. So the convention is not a rule.
  • X Toolkit applications (such as xterm) use XtOpenApplication or XtAppInitialize to initialize their application-resources. Those calls take an instance and class name.
  • conventionally, the instance name is the actual name of the program (its filename). If you happen to rename the program (as happens occasionally, e.g., xterm.real) that changes the name. The program doesn't have to do this, but it's done often. xterm does it.
  • usually the class name is a constant. It is not in xterm, because it expects one of two classes: XTerm or UXTerm (3 leading capitals). The latter is used for the uxterm script, simplifying the way the fonts are specified. This dates from 2000, making it about midway in X's history. A quick check of the 30 programs in the X source tree from the early/mid-2000's which use XtAppInitialize doesn't show any other programs using a variable for the class name.
  • the -class option is xterm-specific. Actually dbedizzy accepts a -class option, for the visual class. That's different. X Toolkit has no such option. There's a list of the common options for X Toolkit in the X(7) manual page in Options. The xterm manual presents those in more detail, in X Toolkit Options.
  • editres, as its manual page indicates, works for any program using the X Toolkit. There's 36 programs in the X source-tree using one or the other of the two initialization calls mentioned, so it's not "few programs" to which this would apply.
  • on the other hand, xterm is one of the few for which editres is not very useful. It has too many resource settings.

The app-defaults files which are installed for xterm and other applications conventionally specify their resource-settings beginning with asterisk (*). That makes them independent of the instance name. An asterisk matches any number of levels of the widget hierarchy, which is often a source of confusion, e.g., the xterm FAQ Why are the menus tiny?, where it is possible for a geometry resource intended for the VT100 widget to be (mis)applied to the menus. There are similar problems with too-generous matching applied to the font resource. The fix for both is to use more-specific matches, referring to the VT100 widget (specific), using dot (.), etc.

Because the app-defaults files avoid unnecessary use of '.', they are relatively easy to override in your own configuration. If you have trouble getting a resource such as

xterm*VT100.geometry: 100.80

to apply, there's only a few places to look:

  • if you used that pattern before, it's already used, and setting it again (later in your resource-files) will not affect the value used.
  • a more-specific setting such as xterm.VT100.geometry overrides less-specific ones using wildcards * and ?.
Thomas Dickey
  • 76,765