Bug 2166860 - Mouse click no longer position cursor in shell command line in XTerm after activation with control sequence
Summary: Mouse click no longer position cursor in shell command line in XTerm after ac...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: 36
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Tomas Korbar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-03 09:02 UTC by Matouš Jan Fialka
Modified: 2023-02-17 18:16 UTC (History)
3 users (show)

Fixed In Version: xterm-378-3.fc38 xterm-378-3.fc36 xterm-378-3.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-08 09:48:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Matouš Jan Fialka 2023-02-03 09:02:12 UTC
Description of problem:

Mouse left-click no longer position cursor in shell command line in XTerm after activation with control sequence.

Version-Release number of selected component (if applicable):

bash.x86_64     5.2.15-1.fc36
readline.x86_64 8.2-2.fc36
xterm.x86_64    375-1.fc36

How reproducible: very probably

Prerequisities to reproduce:

# first sequence saves state, the second sets tracking
alias tmouseon='printf -- '\''\e[2001;2002;2003;2004;2005;2006s\e[?2001;2002;2003h'\'''

# the sequence restores state saved by the previous tmouseon alias
alias tmouseoff='printf -- '\''\e[?2001;2002;2003;2004;2005;2006r'\'''

Steps to Reproduce:
1. open XTerm
2. run the tmouseon alias
3. start typing something and then left-click in the already typed text. You should see the cursor in the commandline be positioned/moved to the position of the mouse click. This is no longer the case. It worked pretty well on Fedora 18. After upgrade to Fedora 36 it does not work.

Actual results:

Mouse left-clicks are not working to position command line cursor after activation with proper control sequences.

Expected results:

It would be splendid if it worked again! I miss it a lot... I got used to it during the years and it is generally very useful, especially when you tend to write very very long pipelines...

Additional info:

I asked on Unix StackExchange too [1] and it seems something must definitely have changed, some dependency may not be compiled in etc. The disfunctionality may be caused by either of the components involved (XTerm, GNU/Readline, TermInfo, whatever...)

It's quite hard to get to the root cause of this issue. I mostly suspect XTerm
is now compiled without GNU/Readline support (also see [1] in the discussion) but I am not sure about it yet. I hope maintainers of the relevant packages would know/guess more. My common configuration of XTerm can also be seen in [1]. Thank you.

References:
- [1] https://unix.stackexchange.com/questions/733933/mouse-click-stopped-positioning-cursor-in-shell-readline-in-xterm-after-upgrad

Comment 1 Thomas E. Dickey 2023-02-07 00:56:33 UTC
The 2001-2006 codes are xterm features for bracketed-paste and readline.
The readline ones were not well-documented, as mentioned here:

    https://invisible-island.net/xterm/xterm-paste64.html#background

Fedora 18 would be early 2013, while Fedora 36 was mid-2022.
In between that, bash (readline) added support for bracketed-paste - in 2016:

    https://invisible-island.net/xterm/xterm-paste64.html#by_shells

You could be seeing bash interfering, which can be disabled

    bind 'set enable-bracketed-paste off'

However, except for the 2004 (bracketed paste),
the others have been a configure option of xterm since 2005,
which was never enabled by default (because of the documentation issue).

You can see the configure option here

    https://github.com/ThomasDickey/xterm-snapshots/blame/master/configure.in#L846

looking at the variable enable_readline_mouse

Assuming that

    https://src.fedoraproject.org/rpms/xterm

reflects the history of xterm in Fedora, I don't see that the option was ever used.

Given all of that, I suppose the xterm executable in Fedora 18 was recompiled to provide the readline feature.

Comment 2 Matouš Jan Fialka 2023-02-07 07:03:13 UTC
Hello.

Thank you for your detailed response... and I must say you are completely
right! :-)

Well, I feel ashamed. I still have the original disk image, so I inspected
it and realized that I must had recompiled XTerm. I found it in my
$HOME/bin directory that used to take precedence to the system-wide
directories using the $PATH setting (and forgot about it completely,
but the reason to re-compile it in $HOME may had been exactly the mouse
support for the readline).

So, as a workaround for now I will certainly recompile XTerm again
and hopefully get the feature back (and try to remember doing so this
time). ;-)

But from point of view as a user much better way would be to (finally) enable
the readline mouse support in the RPM package to let people to switch it on
freely if they need it without the need of recompiling. The feature is really
extremely helpful in some situations. Do you think this would be possible?

With regards,

-- 
mjf

Comment 3 Thomas E. Dickey 2023-02-07 23:25:16 UTC
yes - I added a to-do item to document the feature (in ctlseqs.ms of course).
If it's documented, changing the configure-script default would fix this issue.

Comment 4 Matouš Jan Fialka 2023-02-08 08:06:49 UTC
Hello.
That would be splendid! I'm looking forward to it.

With regards,

-- 
mjf

Comment 5 Matouš Jan Fialka 2023-02-08 08:15:21 UTC
Confirmation in [1] (see the accepted answer).

References:
- [1] https://unix.stackexchange.com/questions/733933/mouse-click-stopped-positioning-cursor-in-shell-readline-in-xterm-after-upgrad

Is there any chance that the we will see the re-configured XTerm in F36 as update for the XTerm package?

With regards,

-- 
mjf

Comment 6 Thomas E. Dickey 2023-02-08 08:38:06 UTC
F37 appears to be the current "stable" version, with F38 being branched off right now.
It's a configure option which the packager (not I) could easily apply in the spec-file at any point.

See https://src.fedoraproject.org/rpms/xterm

for the history and maintainers.

But for F36, I'd suppose that it isn't important enough for someone to apply.

Comment 7 Tomas Korbar 2023-02-08 09:33:54 UTC
Hi guys, this seems useful and from my point of view presents little to
no chance for regression, so i will commit changes to the package and
create updates for rawhide, f37 and f36.

Comment 8 Fedora Update System 2023-02-08 09:45:14 UTC
FEDORA-2023-39d89a37de has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-39d89a37de

Comment 9 Fedora Update System 2023-02-08 09:48:15 UTC
FEDORA-2023-39d89a37de has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2023-02-08 09:58:02 UTC
FEDORA-2023-385b0f0af5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-385b0f0af5

Comment 11 Fedora Update System 2023-02-08 11:08:57 UTC
FEDORA-2023-d7cb43f7f0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d7cb43f7f0

Comment 12 Fedora Update System 2023-02-09 09:34:16 UTC
FEDORA-2023-d7cb43f7f0 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d7cb43f7f0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d7cb43f7f0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2023-02-09 10:09:00 UTC
FEDORA-2023-385b0f0af5 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-385b0f0af5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-385b0f0af5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Matouš Jan Fialka 2023-02-10 11:36:22 UTC
Hello Tomas,

I confirm that
https://bodhi.fedoraproject.org/updates/FEDORA-2023-d7cb43f7f0
solves the issue for me on F36. Thank you!

-- 
mjf

Comment 15 Fedora Update System 2023-02-17 01:32:52 UTC
FEDORA-2023-d7cb43f7f0 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2023-02-17 18:16:07 UTC
FEDORA-2023-385b0f0af5 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.