Can't paste text or type blind keys when mouse is out of the window

Can't paste text or type blind keys when mouse is out of the window

[Paul Maier]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Hi,

when xterm has keyboard focus, but mouse pointer is outside of the window (or
even on Window's blue title bar):


- all blind keys are ignored:

  o  instead of 'à' (key '`' then 'a') you get just a normal 'a'

  o  can't type '^' character (on a German keyboard done with blind '^' key then space)
     -> you will just get the space instead

  o  same with '`' or '´': all blind keys are affected

- can't paste text with the mouse

- all other keys work as expected


Effect:

- While working and not noticing that the mouse pointer slowly left the window,
  in vi you want to jump to mark a (typing `a).
  '`' is ignored and the 'a' brings vi into append mode!

- typing something like ":%s/^xxx/yyy/" is annoying, because you can't type ^,
  until you reposition the mouse pointer inside the window


100 % reproducable.

When the mouse pointer is inside the xterm, everything works fine:
you get à or ^ and can paste text.

It makes no difference whether I use XWin.20110803-git-a493c0465e56ce0b or
XWin.exe from the release.


Logs of xev and XWin.log (with -logverbose 3) are in the attachment.

The XWin.logs are the same regardless if mouse is inside or outside,
but I notice a small difference in xev's output.


Thanks & regards,
  Paul


[-- Attachment #2: mouseOutside-xev.txt --]
[-- Type: text/plain, Size: 1114 bytes --]

KeyPress event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0x0, time 6034149, (-65,-31), root:(1064,196),
    state 0x0, keycode 49 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0x0, time 6034243, (-65,-31), root:(1064,196),
    state 0x0, keycode 49 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0x0, time 6035631, (-65,-31), root:(1064,196),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0x0, time 6035741, (-65,-31), root:(1064,196),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

[-- Attachment #3: mouseOutside-XWin.log.txt --]
[-- Type: text/plain, Size: 500 bytes --]

[  5642.306] winTranslateKey: wParam 000000dc lParam 00290001
[  5642.306] winSendKeyEvent: dwKey: 41, fDown: 1, nEvents 2
[  5642.353] winTranslateKey: wParam 000000dc lParam c0290001
[  5642.353] winSendKeyEvent: dwKey: 41, fDown: 0, nEvents 2
[  5643.944] winTranslateKey: wParam 00000020 lParam 00390001
[  5643.944] winSendKeyEvent: dwKey: 57, fDown: 1, nEvents 2
[  5644.053] winTranslateKey: wParam 00000020 lParam c0390001
[  5644.053] winSendKeyEvent: dwKey: 57, fDown: 0, nEvents 2

[-- Attachment #4: mouseInside-xev.txt --]
[-- Type: text/plain, Size: 1128 bytes --]


KeyPress event, serial 20, synthetic NO, window 0xa00001,
    root 0x101, subw 0xa00002, time 6030249, (49,37), root:(1178,264),
    state 0x0, keycode 49 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0xa00002, time 6030359, (49,37), root:(1178,264),
    state 0x0, keycode 49 (keysym 0xfe52, dead_circumflex), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0xa00002, time 6031638, (49,37), root:(1178,264),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0xa00001,
    root 0x101, subw 0xa00002, time 6031747, (49,37), root:(1178,264),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

[-- Attachment #5: mouseInside-XWin.log.txt --]
[-- Type: text/plain, Size: 502 bytes --]

[  5627.268] winTranslateKey: wParam 000000dc lParam 00290001
[  5627.268] winSendKeyEvent: dwKey: 41, fDown: 1, nEvents 2
[  5627.346] winTranslateKey: wParam 000000dc lParam c0290001
[  5627.346] winSendKeyEvent: dwKey: 41, fDown: 0, nEvents 2
[  5628.968] winTranslateKey: wParam 00000020 lParam 00390001
[  5628.984] winSendKeyEvent: dwKey: 57, fDown: 1, nEvents 2
[  5629.093] winTranslateKey: wParam 00000020 lParam c0390001
[  5629.093] winSendKeyEvent: dwKey: 57, fDown: 0, nEvents 2


[-- Attachment #6: Type: text/plain, Size: 223 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: Can't paste text or type blind keys when mouse is out of the window

[Jon TURNEY]

On 07/08/2011 10:05, Paul Maier wrote:
> when xterm has keyboard focus, but mouse pointer is outside of the window (or
> even on Window's blue title bar):
>
>
> - all blind keys are ignored:
>
>    o  instead of 'à' (key '`' then 'a') you get just a normal 'a'
>
>    o  can't type '^' character (on a German keyboard done with blind '^' key then space)
>       ->  you will just get the space instead
>
>    o  same with '`' or '´': all blind keys are affected
>
> - can't paste text with the mouse
>
> - all other keys work as expected

Thanks for reporting this issue and the clear reproduction step.

I can reproduce this problem.  I can also reproduce it under XWin in windowed 
mode with twm, but not on Xorg on Linux, so this seems to be XWin specific, 
but not related to multiwindow mode WM, which is a real puzzler.

I assume that you see the same behavior with other X applications, i.e. it's 
not xterm-specific?

> The XWin.logs are the same regardless if mouse is inside or outside,
> but I notice a small difference in xev's output.

Yes, it looks like the events are delivered to the top window of xterm's 
hierarchy when the mouse is on the non-client area of the window or the 
desktop, but to the bottom window of the xterm hierarchy when the mouse is 
over the xterm window.

I also note that if you type a deadkey with the mouse in the client area, then 
move the mouse over the frame, type a key, it is passed straight though, then 
move the mouse back over the client area, and type a key, it is modified by 
the previous deadkey.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: Can't paste text or type blind keys when mouse is out of the window

[Paul Maier]

> -----Ursprüngliche Nachricht-----
> On 07/08/2011 10:05, Paul Maier wrote:
> > when xterm has keyboard focus, but mouse pointer is outside of the window (or
> > even on Window's blue title bar):
> >
> >
> > - all blind keys are ignored:
> >
> >    o  instead of 'à' (key '`' then 'a') you get just a normal 'a'
> >
> >    o  can't type '^' character (on a German keyboard done with blind '^' key then space)
> >       ->  you will just get the space instead
> >
> >    o  same with '`' or '´': all blind keys are affected
> >
> > - can't paste text with the mouse
> >
> > - all other keys work as expected
> 
> Thanks for reporting this issue and the clear reproduction step.
> 
> I can reproduce this problem.  I can also reproduce it under XWin in windowed
> mode with twm, but not on Xorg on Linux, so this seems to be XWin specific,
> but not related to multiwindow mode WM, which is a real puzzler.
> 
> I assume that you see the same behavior with other X applications, i.e. it's
> not xterm-specific?
> 
> > The XWin.logs are the same regardless if mouse is inside or outside,
> > but I notice a small difference in xev's output.
> 
> Yes, it looks like the events are delivered to the top window of xterm's
> hierarchy when the mouse is on the non-client area of the window or the
> desktop, but to the bottom window of the xterm hierarchy when the mouse is
> over the xterm window.
> 
> I also note that if you type a deadkey with the mouse in the client area, then
> move the mouse over the frame, type a key, it is passed straight though, then
> move the mouse back over the client area, and type a key, it is modified by
> the previous deadkey.


Hi Jon,

welcome back from your holiday.
 
> I assume that you see the same behavior with other X applications, i.e. it's
> not xterm-specific?

No, at least xedit works fine on my PC, with blind keys and with mouse text pasting, 
no matter if the mouse pointer is really inside or on blue window frame or
(for blind keys:) really outside.

Mouse pointer on blue window frame comes from a typical use case: when clicking focus to the window.
Then the mouse pointer stays there. The window has the focus but you can't paste inside xterm before
moving the mouse really inside. With xedit that works.

Paul.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: Can't paste text or type blind keys when mouse is out of the window

[Jon TURNEY]

>> I assume that you see the same behavior with other X applications, i.e. it's
>> not xterm-specific?
>
> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
> no matter if the mouse pointer is really inside or on blue window frame or
> (for blind keys:) really outside.
>
> Mouse pointer on blue window frame comes from a typical use case: when clicking focus to the window.
> Then the mouse pointer stays there. The window has the focus but you can't paste inside xterm before
> moving the mouse really inside. With xedit that works.

Actually, maybe this is an xterm problem?

It seems to be somehow related to the xterm's --enable-toolbar configuration 
(which is turned on in the cygwin package).  If I rebuild xterm with that 
disabled, the problem goes away, and I can also reproduce the problem on F15 
under twm if I build xterm with --enable-toolbar there (which is not enabled 
in the distro supplied package)

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Paul Maier]

> >> I assume that you see the same behavior with other X applications, i.e. it's
> >> not xterm-specific?
> >
> > No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
> > no matter if the mouse pointer is really inside or on blue window frame or
> > (for blind keys:) really outside.
> >
> 
> Actually, maybe this is an xterm problem?
> 
> It seems to be somehow related to the xterm's --enable-toolbar configuration
> (which is turned on in the cygwin package).  If I rebuild xterm with that
> disabled, the problem goes away, and I can also reproduce the problem on F15
> under twm if I build xterm with --enable-toolbar there (which is not enabled
> in the distro supplied package)


Hi Jon,

maybe it's a workaround to include two xterm builds in the cygwin release:
one xterm compiled with --enable-toolbar and the other having it disabled.

I don't use the toolbar, so I would have the blind keys working fine at zero cost.

Paul



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Thomas Dickey]

On Mon, 3 Oct 2011, Paul Maier wrote:

>
>>>> I assume that you see the same behavior with other X applications, i.e. it's
>>>> not xterm-specific?
>>>
>>> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
>>> no matter if the mouse pointer is really inside or on blue window frame or
>>> (for blind keys:) really outside.
>>>
>>
>> Actually, maybe this is an xterm problem?
>>
>> It seems to be somehow related to the xterm's --enable-toolbar configuration
>> (which is turned on in the cygwin package).  If I rebuild xterm with that
>> disabled, the problem goes away, and I can also reproduce the problem on F15
>> under twm if I build xterm with --enable-toolbar there (which is not enabled
>> in the distro supplied package)

hmm - I'm not clear on precisely what a "blind key" is.  Sounds like a 
compose sequence - and if so, it's puzzling that passing key-presses from 
different levels in the widget hierarchy would interfere with that.

The main difference with the toolbar configuration is that xterm's using a 
form to contain the toolbar and the vt100 window.  The buttons take care 
of themselves, but that area to the right of the buttons is dead.

To make it somewhat friendlier, xterm adds the actions used for the vt100 
window (except for the ones related to the mouse) to the toolbar area.

I omitted the mouse-related ones since it seems that they'd interfere with 
the menus.  I also did the same for the scrollbar widget (since keystrokes 
there used to be lost - it would seem that you could reproduce your 
problem also by looking at the behaviour around the scrollbar).


-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Paul Maier]

> >>>> I assume that you see the same behavior with other X applications, i.e. it's
> >>>> not xterm-specific?
> >>>
> >>> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
> >>> no matter if the mouse pointer is really inside or on blue window frame or
> >>> (for blind keys:) really outside.
> >>>
> >>
> >> Actually, maybe this is an xterm problem?
> >>
> >> It seems to be somehow related to the xterm's --enable-toolbar configuration
> >> (which is turned on in the cygwin package).  If I rebuild xterm with that
> >> disabled, the problem goes away, and I can also reproduce the problem on F15
> >> under twm if I build xterm with --enable-toolbar there (which is not enabled
> >> in the distro supplied package)
> 
> hmm - I'm not clear on precisely what a "blind key" is.  Sounds like a
> compose sequence - and if so, it's puzzling that passing key-presses from
> different levels in the widget hierarchy would interfere with that.
> 
> The main difference with the toolbar configuration is that xterm's using a
> form to contain the toolbar and the vt100 window.  The buttons take care
> of themselves, but that area to the right of the buttons is dead.
> 
> To make it somewhat friendlier, xterm adds the actions used for the vt100
> window (except for the ones related to the mouse) to the toolbar area.
> 
> I omitted the mouse-related ones since it seems that they'd interfere with
> the menus.  I also did the same for the scrollbar widget (since keystrokes
> there used to be lost - it would seem that you could reproduce your
> problem also by looking at the behaviour around the scrollbar).


Hi Thomas,

yes, with mouse over the scrollbar the problem is reproducable.

A blind key is a key that needs to be followed by another key to produce something.

The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
you need to enter `a, that is in keystrokes
1. blind key `
2. space
3. letter a,
the bug will drop the `, so you will not end up with the cursor at mark "a, but
you will move the cursor one character forward and there enter append mode.
Which is something totally different than the intention.

Or if you type :%s/^x/y/
You will really get :%s/ x/y

Hopefully you notice it before pressing Enter ...

Exaples refer to a German keyboard layout.

Thank you for looking into this.

Regards,
  Paul



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Thomas Dickey]

On Wed, 5 Oct 2011, Paul Maier wrote:

>
>>>>>> I assume that you see the same behavior with other X applications, i.e. it's
>>>>>> not xterm-specific?
>>>>>
>>>>> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
>>>>> no matter if the mouse pointer is really inside or on blue window frame or
>>>>> (for blind keys:) really outside.
>>>>>
>>>>
>>>> Actually, maybe this is an xterm problem?
>>>>
>>>> It seems to be somehow related to the xterm's --enable-toolbar configuration
>>>> (which is turned on in the cygwin package).  If I rebuild xterm with that
>>>> disabled, the problem goes away, and I can also reproduce the problem on F15
>>>> under twm if I build xterm with --enable-toolbar there (which is not enabled
>>>> in the distro supplied package)
>>
>> hmm - I'm not clear on precisely what a "blind key" is.  Sounds like a
>> compose sequence - and if so, it's puzzling that passing key-presses from
>> different levels in the widget hierarchy would interfere with that.
>>
>> The main difference with the toolbar configuration is that xterm's using a
>> form to contain the toolbar and the vt100 window.  The buttons take care
>> of themselves, but that area to the right of the buttons is dead.
>>
>> To make it somewhat friendlier, xterm adds the actions used for the vt100
>> window (except for the ones related to the mouse) to the toolbar area.
>>
>> I omitted the mouse-related ones since it seems that they'd interfere with
>> the menus.  I also did the same for the scrollbar widget (since keystrokes
>> there used to be lost - it would seem that you could reproduce your
>> problem also by looking at the behaviour around the scrollbar).
>
>
> Hi Thomas,
>
> yes, with mouse over the scrollbar the problem is reproducable.
>
> A blind key is a key that needs to be followed by another key to produce something.
>
> The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
> moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
> you need to enter `a, that is in keystrokes

That seems to be what I was referring to as "compose sequence".
I'll experiment to see if I can reproduce this effect with my environment.

thanks for the detailed explanation.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Jon TURNEY]

On 05/10/2011 01:51, Paul Maier wrote:
>>>>>> I assume that you see the same behavior with other X applications, i.e. it's
>>>>>> not xterm-specific?
>>>>>
>>>>> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting,
>>>>> no matter if the mouse pointer is really inside or on blue window frame or
>>>>> (for blind keys:) really outside.
>>>>
>>>> Actually, maybe this is an xterm problem?
>>>>
>>>> It seems to be somehow related to the xterm's --enable-toolbar configuration
>>>> (which is turned on in the cygwin package).  If I rebuild xterm with that
>>>> disabled, the problem goes away, and I can also reproduce the problem on F15
>>>> under twm if I build xterm with --enable-toolbar there (which is not enabled
>>>> in the distro supplied package)
>>
>> hmm - I'm not clear on precisely what a "blind key" is.  Sounds like a
>> compose sequence - and if so, it's puzzling that passing key-presses from
>> different levels in the widget hierarchy would interfere with that.
>>
>> The main difference with the toolbar configuration is that xterm's using a
>> form to contain the toolbar and the vt100 window.  The buttons take care
>> of themselves, but that area to the right of the buttons is dead.
>>
>> To make it somewhat friendlier, xterm adds the actions used for the vt100
>> window (except for the ones related to the mouse) to the toolbar area.
>>
>> I omitted the mouse-related ones since it seems that they'd interfere with
>> the menus.  I also did the same for the scrollbar widget (since keystrokes
>> there used to be lost - it would seem that you could reproduce your
>> problem also by looking at the behaviour around the scrollbar).
>
>
> yes, with mouse over the scrollbar the problem is reproducable.
>
> A blind key is a key that needs to be followed by another key to produce something.

I think this is usually called a 'dead key'

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Paul Maier]

>>>> It seems to be somehow related to the xterm's --enable-toolbar configuration
>>>> (which is turned on in the cygwin package).  If I rebuild xterm with that
>>>> disabled, the problem goes away, and I can also reproduce the problem on F15
>>>> under twm if I build xterm with --enable-toolbar there (which is not enabled
>>>> in the distro supplied package)

>> The main difference with the toolbar configuration is that xterm's using a
>> form to contain the toolbar and the vt100 window.  The buttons take care
>> of themselves, but that area to the right of the buttons is dead.
>>
>> To make it somewhat friendlier, xterm adds the actions used for the vt100
>> window (except for the ones related to the mouse) to the toolbar area.
>>
>> I omitted the mouse-related ones since it seems that they'd interfere with
>> the menus.  I also did the same for the scrollbar widget (since keystrokes
>> there used to be lost - it would seem that you could reproduce your
>> problem also by looking at the behaviour around the scrollbar).

> > yes, with mouse over the scrollbar the problem is reproducable.

> > The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
> > moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
> > you need to enter `a, that is in keystrokes
> 

> I'll experiment to see if I can reproduce this effect with my environment.
> thanks for the detailed explanation.


Hi Thomas,

yes, I'm talking about dead keys = compose sequences.

Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe 
then press letter "a" while the mouse pointer is over the scrollbar area of an xterm?

Please let me know in case you need more information or in case you want me to run
some test.

Thank you very much for looking into this.

Regards,
  Paul



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window

[Thomas Dickey]

On Sun, 30 Oct 2011, Paul Maier wrote:
>>> The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
>>> moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
>>> you need to enter `a, that is in keystrokes
>>
>
>> I'll experiment to see if I can reproduce this effect with my environment.
>> thanks for the detailed explanation.
>
>
> Hi Thomas,
>
> yes, I'm talking about dead keys = compose sequences.
>
> Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe
> then press letter "a" while the mouse pointer is over the scrollbar area of an xterm?

yes - I can reproduce it.  Actually once I was made aware of the issue,
I could see in my mind where the problem might lie.  But I just verified
it since you reminded me (on one of my Linux machines).

My idea about the problem is that since xterm has setup translations 
(which capture the input) on more than one widget (without appearing to 
address this special case), that it might be that there's a better point 
in the widget to attach the translations to.

This was discussed a little late in the #277 cycle to want to hold that 
up, so I had in mind to spend some time investigating a solution for it
during #278.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

AW: AW: AW: AW: AW: Can't paste text or type dead keys when mouse is out of the window

[Paul Maier]

> >>> The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
> >>> moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
> >>> you need to enter `a, that is in keystrokes
> >>
> >
> >> I'll experiment to see if I can reproduce this effect with my environment.
> >> thanks for the detailed explanation.
> >
> >
> > Hi Thomas,
> >
> > yes, I'm talking about dead keys = compose sequences.
> >
> > Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe
> > then press letter "a" while the mouse pointer is over the scrollbar area of an xterm?
> 
> yes - I can reproduce it.  Actually once I was made aware of the issue,
> I could see in my mind where the problem might lie.  But I just verified
> it since you reminded me (on one of my Linux machines).
> 
> My idea about the problem is that since xterm has setup translations
> (which capture the input) on more than one widget (without appearing to
> address this special case), that it might be that there's a better point
> in the widget to attach the translations to.
> 
> This was discussed a little late in the #277 cycle to want to hold that
> up, so I had in mind to spend some time investigating a solution for it
> during #278.
> 


Hi Thomas,

I would like to report, that above problem still exists.
I tested against xterm-281.

Regards,
  Paul



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: AW: AW: AW: AW: AW: Can't paste text or type dead keys when mouse is out of the window

[Thomas Dickey]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

On Sun, Jul 22, 2012 at 02:26:06AM +0200, Paul Maier wrote:
> 
> 
> > >>> The problem here is, when running vi in an xterm and the mouse slowly (unnoticed)
> > >>> moves over the scrollbar or out of the xterm, and you want to jump to mark "a,
> > >>> you need to enter `a, that is in keystrokes
> > >>
> > >
> > >> I'll experiment to see if I can reproduce this effect with my environment.
> > >> thanks for the detailed explanation.
> > >
> > >
> > > Hi Thomas,
> > >
> > > yes, I'm talking about dead keys = compose sequences.
> > >
> > > Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe
> > > then press letter "a" while the mouse pointer is over the scrollbar area of an xterm?
> > 
> > yes - I can reproduce it.  Actually once I was made aware of the issue,
> > I could see in my mind where the problem might lie.  But I just verified
> > it since you reminded me (on one of my Linux machines).
> > 
> > My idea about the problem is that since xterm has setup translations
> > (which capture the input) on more than one widget (without appearing to
> > address this special case), that it might be that there's a better point
> > in the widget to attach the translations to.
> > 
> > This was discussed a little late in the #277 cycle to want to hold that
> > up, so I had in mind to spend some time investigating a solution for it
> > during #278.
> > 
> 
> 
> Hi Thomas,
> 
> I would like to report, that above problem still exists.
> I tested against xterm-281.

yes (I spent some time investigating this, but did not yet find a solution)

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]