I am using the following control sequence to set up that when I click in the command line in shell (BASH) in XTerm the cursor moves to the position. At least, it used to worked that way in my ancient Fedora 18 I used to have. (I tend to write very long pipelines and therefor this feature is splendid and quite crutial to me, because I got completely used to it during the years using it.)

What I do to enable the "click-to-go-to-position" function I do (usualy in PS1 BASH variable):


and to restore the original saved state (usualy in PS0 so that it does not influence the command to be run from the shell):


Here are aliases for experimenting:

alias tmouseon='printf -- '\''\e[2001;2002;2003;2004;2005;2006s\e[?2001;2002;2003h'\'''
alias tmouseoff='printf -- '\''\e[?2001;2002;2003;2004;2005;2006r'\'''

This is my XTerm configuration (some parts of it may be relevant to this issue but according to the XTerm's manual I was not able to find additional options or an option that may be causing the issue in my configuration; also note that I do not xrdb -merge my X resource file in my .xinitrc but just xrdb because I never liked the defaults from distributions and want to have full control of it and I've been using it this way for ages without any troubles):

! Init
XTerm.ptyInitialErase: true
XTerm.waitForMap:      true

! Buffers
XTerm.buffered:    true
XTerm.bufferedFPS: 100
XTerm.maxBufSize:  131072
XTerm.minBufSize:  8192


! Name
XTerm.VT100.termName: xterm-256color

! Session
XTerm.VT100.loginShell: true

! Features
XTerm.VT100.allowFontOps:   true
XTerm.VT100.allowMouseOps:  true
XTerm.VT100.allowTcapOps:   true
XTerm.VT100.allowTitleOps:  true
XTerm.VT100.allowWindowOps: true
XTerm.VT100.c132:           true

! Input
XTerm.VT100.backarrowKey:        true
XTerm.VT100.backarrowKeyIsErase: true

! Scrolling
XTerm.VT100.scrollBar:       false
XTerm.VT100.scrollTtyOutput: false
XTerm.VT100.allowScrollLock: true

! Screen buffer
XTerm.VT100.saveLines: 10000

! Alternate screen
XTerm.VT100.titeInhibit:  true
XTerm.VT100.tiXtraScroll: true

! Visual bell
XTerm.VT100.visualBell:      true
XTerm.VT100.visualBellLine:  true
XTerm.VT100.visualBellDelay: 150

! Pointer shape
XTerm.VT100.pointerShape: hand1

! Margin bell
XTerm.VT100.marginBell:  true
XTerm.VT100.nMarginBell: 8

! Cursor blinking
XTerm.VT100.cursorBlink:   true
XTerm.VT100.cursorOffTime: 250
XTerm.VT100.cursorOnTime:  750

! Selection
XTerm.VT100.charClass:          33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48
XTerm.VT100.highlightReverse:   false
XTerm.VT100.highlightSelection: true
XTerm.VT100.trimSelection:      true

(Colors settings omited...)

After I upgraded the very very outdated (I know, I know, but there was no need to while I use rather "spartan" environment and use common tools) Fedora 18 workstation to the recent Fedora 36, the feature of moving cursor in XTerm on a mouse-click stopped working and I really cannot find out the root cause of the issue. (I tried hard to solve it but failed completely.) I would like to get the functionality back. Can anyone help, please?

Does anyone have the same issue? How to analyze it?

I guess it may be something about TermInfo changed or something but I have no idea how to dig into it more further... Thanks for all your ideas on how to get it working again!

  • Well, I see there were some changes about mouse pointer etc. in XTerm during the years... invisible-island.net/xterm/xterm.log.html but not sure how it could influence this issue exactly...
    – mjf
    Commented Feb 1, 2023 at 13:38
  • 1
    I used dnf download --disablerepo=* --enablerepo=fedora --downloadonly --releasever=30 xterm to download several releases of the binary rpm, and did rpm2cpio | cpio -cdimB to unpack them locally, and strings usr/bin/xterm to look for "readline-button". It still appears in the fedora 30 binary, but has disappeared in the fedora 31 rpm. The code for this feature is still in the sources for fedora 36, so we need to find why fedora is not building with it. Perhaps it has to do with their move to wayland?
    – meuh
    Commented Feb 1, 2023 at 18:23
  • @meuh Thank you very much for such a useful finding! Now we know that at least something definitely changed. Btw, I never had the XTerm translation with readline-button() set up, and I am not sure if it was set up by default (which would be very weird and the left click worked without any extra key pressed). I still suspect that the whole issue can be unrelated to XTerm as such and could have more to do with some changes in, say, GNU Readline that may be involved or so. This is still hard to tell. I will try to go through changelogs of all libraries that may be related to the issue.
    – mjf
    Commented Feb 2, 2023 at 7:14

2 Answers 2


I'm leaving my other answer as it applies in general for other distributions. This answer explores why readline-button stopped working in Fedora 31 onwards.

I downloaded release 30 of the rpm, unpacked it locally, and looked for "readline-button" in the xterm binary.

rel=30; mkdir $rel; cd $rel
dnf download --disablerepo='*' --enablerepo=fedora --downloadonly \
 --releasever=$rel xterm
rpm2cpio xterm-*fc$rel.x86_64.rpm | cpio -cdimB
strings usr/bin/xterm | grep readline-button

It still appears in the Fedora 30 binary, but has disappeared in the Fedora 31 binary.

I downloaded the source rpms and unpacked them:

dnf download --disablerepo='*' --enablerepo=fedora-source \
 --source --releasever=$rel xterm
HOME=$PWD rpm -i xterm-*fc$rel.src.rpm 
HOME=$PWD rpmbuild -bp --nodeps rpmbuild/SPECS/xterm.spec
(cd rpmbuild/BUILD/; ln -s xterm-* xterm)

Comparing the sources show many changes, but this seems to be the pertinent one:

$ diff -wub {30,31}/rpmbuild/BUILD/xterm/ptyx.h
@@ -830,12 +845,6 @@
-/* OPT_PASTE64 uses logic from OPT_READLINE */
-#define OPT_READLINE 1

It is mentioned in the changes log file:

$ diff -wub {30,31}/rpmbuild/BUILD/xterm/xterm.log.html
+    <li>adjusted ifdef's so that the paste64 configure option does
+    not automatically enable the readline-mouse configure
+    option.</li>

which is under the heading Patch #338 - 2018/12/09. If we compare the rpm spec files, the only real difference is the move from xterm version 334 to 346, which includes this new patch:

$ diff -wub {30,31}/rpmbuild/SPECS/xterm.spec
-Version: 334
+Version: 346

There is a further clue here:

$ diff -wub {30,31}/rpmbuild/BUILD/xterm/INSTALL
   --enable-readline-mouse enable support for mouse in readline applications
-       Compile-in code to support experimental bracketed paste mode, i.e.,
+       Compile-in code to support predecessor to bracketed paste mode, i.e.,
        provide functions for setting/getting the selection data.  Essentially
        this puts xterm into a mode that sends special function-key strings to
        bracket the data.
-       (See --enable-paste64, which fits xterm's protocol better).
+       (The "paste64" feature, which fits xterm's protocol better, is
+       configured by default).

The spec file shows that --enable-readline-mouse was never used for the configuration, 31/rpmbuild/SPECS/xterm.spec:

%configure \
        --enable-meta-sends-esc \
        --disable-backarrow-key \
        --enable-256-color \
        --enable-exec-xterm \
        --enable-luit \
%{?with_trace: --enable-trace} \
        --enable-warnings \
        --enable-wide-chars \
        --with-app-defaults=%{x11_app_defaults_dir} \
        --with-icon-theme=hicolor \
        --with-icondir=%{_datadir}/icons \
        --with-utempter \
        --with-tty-group=tty \

Without this option, OPT_READLINE is defined as 0, and so the readline-button code is not compiled in, for example in 31/rpmbuild/BUILD/xterm-346/charproc.c:

    { "readline-button",        ReadLineButton },


Fedora does not build xterm with --enable-readline-mouse. Until release 30 inclusive, this did not matter as --enable-paste64 was enabled by default, and OPT_PASTE64 used to define OPT_READLINE. From release 31, and patch 338, this is no longer done, so we lose this functionality.

The solution is probably to add --enable-readline-mouse to the Fedora spec file.

  • 1
    The --enable-readline-mouse support will be added as soon as Thomas adds appropriate documentation in ctlseq.ms. I consider it as solved and will add your reply to the RedHat Bugzilla issue 2166860 where this is tracked. Many thanks for your tremendous effort!
    – mjf
    Commented Feb 8, 2023 at 8:11
  • 1
    Fixed in FEDORA-2023-d7cb43f7f0 advisory for F36.
    – mjf
    Commented Feb 10, 2023 at 11:40

I'm not acquainted with the escape sequences you give, but there is a feature in man xterm that might be useful:

readline-button() Supports the optional readline feature by echoing repeated cursor forward or backward control sequences on button release event, to request that the host application update its notion of the cursor's position to match the button event.

To use it add a suitable translation binding, or test it with -xrm:

xterm -xrm 'XTerm.VT100.translations:  #override\
 Mod4 <Btn1Down>: readline-button()\n'

For this example binding, when you click the mouse left button with the Meta (or Super) key over a character in an input line, xterm generates left or right keys until the cursor lines up.

Similarly, urxvt has a built-in perl extension (see man urxvt-readline), enabled by default, with a binding of Shift and left button.

  • 1
    Hello @meuh. Thank you, I've already tried that but I end up with: Warning: Actions not found: readline-button. May that mean xterm(1) on Fedora 36 does not have something compiled in?
    – mjf
    Commented Feb 1, 2023 at 13:12
  • What I "guess" is it can be either one (or combination) of: XTerm, GNU/Readline, TermInfo. XTerm may lack some library support compiled in on F36 or something may have changed in it's code or my configuration of it is wrong/unpleasant in some way, GNU/Readline may have some backward-incompatible changes, TermInfo database may have changed, etc., or it's some very ugly combination of all of them. It's really hard to tell without some sort of proper debugging. But where to start and exactly to use?
    – mjf
    Commented Feb 1, 2023 at 13:56
  • 1
    Also tracked in RedHat bugzilla 2166860.
    – mjf
    Commented Feb 3, 2023 at 9:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .