xterm manpage question, on translation resources
Eli the Bearded
------ cut 8<------
Below is a sample how of the keymap() action is used to add special
keys for entering commonly-typed works:
*VT100.Translations: #override <Key>F13: keymap(dbx)
*VT100.dbxKeymap.translations: \
<Key>F14: keymap(None) \n\
<Key>F17: string("next") string(0x0d) \n\
<Key>F18: string("step") string(0x0d) \n\
<Key>F19: string("continue") string(0x0d) \n\
<Key>F20: string("print ") insert-selection(PRIMARY, CUT_BUFFER0)
------>8 cut ------
If it matters:
$ echo $XTERM_VERSION
XTerm(268)
$
My question is, what is "dbx" and "dbxkeymap"? This example is the
only place in the manpage those appear.
I'm also curious about "#override" which isn't documented in the
xterm manpage and is critical (not a comment) I've found from some
translations. Without it, it seems the translations listed are
the *only* keypresses that work.
Elijah
------
trying to use xterm more effectively
Aaron W. Hsu
programming in general. There is some documentation to be had in how these
work in the Motif programming manuals, but the Xlib and Xt manuals might
also provide more details. Basically, translations are an integral part of
the X11 system, and are used all over the place. They are not unique or
special to Xterm(1). They were more widely recognized back in the day
though, and fewer people hack with them now, so it's not surprising that
the information seems unavailable.
Basically, every widget has a set of translations to map key presses into
actions of some sort. For example, in Motif's Text widget, you can
override certain key presses to do certain actions, such as insert a
newline or copy some text. The override keyword says that you only want to
change things, but not replace the entire keymap. I don't deal with these
on a daily basis, so you're best off reading the manuals. They're a bit
crufty, but very helpful in these respects.
Aaron W. Hsu
--
Programming is just another word for the lost Art of Thinking.
Alan Curry
>
>------ cut 8<------
>Below is a sample how of the keymap() action is used to add special
>keys for entering commonly-typed works:
>
> *VT100.Translations: #override <Key>F13: keymap(dbx)
> *VT100.dbxKeymap.translations: \
> <Key>F14: keymap(None) \n\
> <Key>F17: string("next") string(0x0d) \n\
> <Key>F18: string("step") string(0x0d) \n\
> <Key>F19: string("continue") string(0x0d) \n\
> <Key>F20: string("print ") insert-selection(PRIMARY, CUT_BUFFER0)
>------>8 cut ------
when it was written, but are obscure now. Besides the things you mentioned,
the high-numbered F-keys are a nice touch.
>
>My question is, what is "dbx" and "dbxkeymap"? This example is the
>only place in the manpage those appear.
man page, under ACTIONS:
keymap(name)
This action dynamically defines a new translation table whose
resource name is name with the suffix Keymap (case is signifi-
cant). The name None restores the original translation table.
In the first part of the example, F13 is mapped to the action keymap(dbx).
The dbx is the "name" parameter to keymap(). So the example is dynamically
creating a new translation table whose resources name is dbxKeymap. As far as
xterm is concernced, "dbx" here is just an user-defined string with no
built-in meaning.
The second thing you're missing is that dbx is the old Unix debugger, a
predecessor of gdb. If you want to know anything else about it, go ask
Wikipedia. The point of this example is the creation of some keyboard
shortcuts for interacting with dbx. F13 will enable them, and F14 will
disable them, returning all the keys (except F13) to normal operation.
>
>I'm also curious about "#override" which isn't documented in the
>xterm manpage and is critical (not a comment) I've found from some
>translations. Without it, it seems the translations listed are
>the *only* keypresses that work.
X Toolkit Intrinsics (a.k.a. libXt) documentation. Look for a file called
intrinsics.txt or intrinsics.ps and also skim Chapter 10, which is mostly
about the C programming interface for translation tables but may contain
useful background information.
It's a shame that this high level, flexible user interface infrastructure
never got documented separately from the nuts and bolts of the underlying C
library.
We could submit a bug report to modernize this example. It would be nice if
we had a better one to replace it with. Since people aren't running dbx in
their xterms anymore, what would be a good example of an application that
could be run in xterm, that lots of users would recognize, and that you could
invent a few keyboard shortcuts for?
--
Alan Curry
Eli the Bearded
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> Here's a fragment of the xterm man page in my system:
> Oh what a fun example. Full of things that would have been easily understood
> when it was written, but are obscure now. Besides the things you mentioned,
> the high-numbered F-keys are a nice touch.
Yes, I noticed those. It's been a long time since I've typed on a
keyboard that went beyond F12.
>> My question is, what is "dbx" and "dbxkeymap"? This example is the
>> only place in the manpage those appear.
> In the first part of the example, F13 is mapped to the action keymap(dbx).
> The dbx is the "name" parameter to keymap(). So the example is dynamically
> creating a new translation table whose resources name is dbxKeymap. As far as
> xterm is concernced, "dbx" here is just an user-defined string with no
> built-in meaning.
Hmmm. Sounds like it could be very useful.
> The second thing you're missing is that dbx is the old Unix debugger, a
> predecessor of gdb. If you want to know anything else about it, go ask
> Wikipedia.
I missed out on that one. I went from adb to gdb. But now that you mention
it, I have dim recollections of reading about it.
>> I'm also curious about "#override" which isn't documented in the
>> xterm manpage and is critical (not a comment) I've found from some
>> translations. Without it, it seems the translations listed are
>> the *only* keypresses that work.
> The syntax of the translation table is tucked away in Appendix B of the
> X Toolkit Intrinsics (a.k.a. libXt) documentation. Look for a file called
> intrinsics.txt or intrinsics.ps and also skim Chapter 10, which is mostly
> about the C programming interface for translation tables but may contain
> useful background information.
Found it. .../X11-4.4.0/build/doc/hardcopy/Xt/intrinsics.PS.gz
An old build tree, but I doubt it has changed much. I have two of the
brick-like O'Reilly books, and I think Xt Intrinsics is one of them.
> It's a shame that this high level, flexible user interface infrastructure
> never got documented separately from the nuts and bolts of the underlying C
> library.
It seems to me that a whole lot of the X11 way of doing things is lost
to newer X11 developers.
> We could submit a bug report to modernize this example. It would be nice if
> we had a better one to replace it with. Since people aren't running dbx in
> their xterms anymore, what would be a good example of an application that
> could be run in xterm, that lots of users would recognize, and that you could
> invent a few keyboard shortcuts for?
Well, gdb might work. Maybe compilation examples, too. Some untested ideas.
! f12 enter buildthings mode
! f11 exit buildthings mode
! f10 run "./configure" then "make" if successful
! f9 extract a perl module in the primary selection buffer, cd to
! it's directory, run the perl makefile and then make and test
! f8 do a complete rebuild
*VT100.Translations: #override <Key>F12: keymap(buildthings)
*VT100.buildthingsKeymap.translations: \
<Key>F11: keymap(None) \n\
<Key>F10: string("./configure && make") string(0x0d) \n\
<Key>F9: string("gzcat ") insert-selection(PRIMARY, CUT_BUFFER0) \
string(".gz | tar xf - && cd ") \
insert-selection(PRIMARY, CUT_BUFFER0) \
string(" && perl Makefile.PL && make test") \
string(0x0d) \n\
<Key>F8: string("make clean && make") string(0x0d)
I tested these ones.
! f1 open primary selection buffer with firefox
! f2 open primary selection buffer with eye-of-gnome (image viewer)
! f3 open primary selection buffer with user's editor of choice
! f4 open primary selection buffer with man (man page viewer)
*VT100.Translations: #override \n\
<Key>F1: string("firefox ") insert-selection(PRIMARY, CUT_BUFFER0) \
string(0x0d) \n\
<Key>F2: string("eog ") insert-selection(PRIMARY, CUT_BUFFER0) \
string(0x0d) \n\
<Key>F3: string("$EDITOR ") insert-selection(PRIMARY, CUT_BUFFER0) \
string(0x0d) \n\
<Key>F4: string("man ") insert-selection(PRIMARY, CUT_BUFFER0) \
string(0x0d)
and found that there are issues with these. Sometimes the selection seems
to be preceeded by a newline, so you end up with "man \nprintf\n" even
when a middle button click (or a shift-insert) would not have the newline.
That bug seems reproducible. If the xterm I'm pasting to owns the selection,
it works right. If it is in a different xterm it does not. Ideas?
Elijah
------
having fun now
Alan Curry
I don't see an extra newline. What I see is the one that should be on the end
moving to the middle. Here's what seems to be happening: the actions are
appearing out of order because insert-selection(PRIMARY) only initiates an
asynchronous request, and the results can come in at any later time. It
becomes more obvious if you bind a key to:
string("XXX")insert-selection(PRIMARY)string("YYY")
This should probably be conisdered a bug, and might even be fixable. It
doesn't seem to occur if you forget about PRIMARY and just use CUT_BUFFER0.
But I suppose there are reasons not to do that.
When the selection is coming from the same process, somehow the timing is
different. (Maybe the library is smart enough to short-circuit the round trip
to the X server and just return the answer directly?)
--
Alan Curry
Eli the Bearded
>> and found that there are issues with these. Sometimes the selection seems
>> to be preceeded by a newline, so you end up with "man \nprintf\n" even
>> when a middle button click (or a shift-insert) would not have the newline.
>
> moving to the middle. Here's what seems to be happening: the actions are
Ah, yes. I miswrote.
> appearing out of order because insert-selection(PRIMARY) only initiates an
> asynchronous request, and the results can come in at any later time. It
> becomes more obvious if you bind a key to:
>
> string("XXX")insert-selection(PRIMARY)string("YYY")
Probably, yes. I've observed that happening while typing and pasting.
The example in the manpage for the dbx "print" command used
"insert-selection(PRIMARY, CUT_BUFFER0)", which is why I copied it.
> This should probably be conisdered a bug, and might even be fixable. It
> doesn't seem to occur if you forget about PRIMARY and just use CUT_BUFFER0.
> But I suppose there are reasons not to do that.
Yes, well, I did post here because I was looking for more detail to
the examples from the manpage.
Elijah
------
has seen T. E. Dickey, a listed xterm author, post here in the past