On Mon, May 17, 2010 at 08:30:53PM -0400, Thomas Dickey wrote: > 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. That would be helpful. >>> 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: Sorry for the trouble, yes, that does fix the problem. > 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. For me, scroll-lock is a bad metaphor for this feature. scroll-lock is a "system-wide" thing: it should apply to all terminals, or the whole "terminal" (x11 itself), not to individual terminals. Or if it would, it would need to flash on and off as you would focus in and out of windows, which seems a bit silly... I think that control-s does control flow much better and is "standard" enough for this feature to be unnecessary. Then again, if the resource defaults to false, I have absolutely no objection to it being present. And if it defaults to true, I guess I'll just need to add this to my ever growing needs of "tweaks necessary so that xterm works for me".. ;) Now up to: XTerm*metaSendsEscape: true XTerm*bellIsUrgent: true XTerm*visualBell: true XTerm*trimSelection: true XTerm*allowScrollLock: false Thanks for the quite efficient support... A.
Attachment:
signature.asc
Description: Digital signature