On Mon, 17 May 2010, The Anarcat wrote:
On Thu, May 13, 2010 at 07:44:57PM -0400, Thomas Dickey wrote:
(by the way, patch #258 simply plugs a hole which seems that it should
have appeared in #256 or before, the changes in this bug report come from #257)
(Yes, I have marked 256 as not affected because it's the version I know
as working, 257 may also be affected by the bug, I haven't tested it.)
This report sounds like two bugs:
a) patch #257 introduces a binding for Scroll_Lock. While I did make the
feature
configurable (a compile-time ifdef could remove it entirely, or a resource
can
disable most of the feature), I overlooked the fact that other people would
be
using this orphaned key as well.
I see.
yes... if I'd considered that aspect, I'd have defaults the resource to
false.
For a quick workaround - if you set allowScrollOps resource to false, is the
intercept of the key still interfering with your use of it?
Yes, that doesn't fix the problem:
XTerm*allowScrollOps: false
UXTerm*allowScrollOps: false
sorry for the confusion - I did correct my typo in a followup.
The resource is allowScrollLock:
allowScrollLock (class AllowScrollLock)
Specifies whether control sequences that set/query the Scroll
Lock key should be allowed, as well as whether the Scroll Lock
key responds to user's keypress. The default is "true."
(if it is still interfering, I'll have to make the feature configurability
different, e.g., by deciding whether to add it to the translations
dynamically).
(I'm not sure what the "translations" are, but I feel this should be
fixed in the next release, regardless of the way of doing it. removing
it entirely until a better fix is found would be the option I would
suggest, but then I am in a rather biased position. :P I would say
however that I'll switch away from xterm if this issue isn't fixed. As
things stand, I run the older version because the situation is rather
intolerable. :)
I noticed something else with the bug. Hitting scroll lock doesn't
"unfreeze" the terminal (it doesn't remove the lock). But focusing out
of the window, hitting scroll lock, and focusing back again *does* fix
the issue. So it's as if the scroll lock status was read only when
focusing in our out of the window. This seems like the wrong way to do
things in my opinion: xterm should just catch "keydown" events on that
key.
I agree that if it did that, then you probably would not see the problem
at all, since your keyboard configuration is apparently not passing the
keypresses.
The focus aspect came about because if there is more than one terminal on
the screen, it's unclear (otherwise) to which terminal the scroll lock
applies. (In development I considered instead clearing the scroll lock
when exiting a window, but found this to work inconsistently). But
sensing the LED light on entry to the window seems to work well enough.
On the other hand, the focus aspect is supposed to go away when the
resource is false.
xterm would still be passed an event (which it discards) when the resource
is false. I'm uncertain whether this event would interfere with your use
of the ScrollLock key - which is why I asked about the workaround.
Arguably, if Xorg is handling scroll lock through XKB, it shouldn't let
that keypress propagate further either...
b) the scroll-lock feature doesn't work with fast-scrolling.
Fixing this may take more time than (a), so I'm inclined to focus on being
able
to enable/disable the feature with low impact.
I would like this issue to be processed in a seperate bug report, as it
is unrelated to this one, AFAIK.
A.
--
La nature n'a cr?? ni ma?tres ni esclaves
Je ne veux ni donner ni recevoir de lois.
- Denis Diderot
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
