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. > 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 > (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. 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
signature.asc
Description: Digital signature