OS X / nextstep port: Loss of keyboard events

OS X / nextstep port: Loss of keyboard events

[Harald Hanche-Olsen]

Once in a while, some frame stops receiving keyboard events. It keeps
receiving mouse events, so I can move the cursor around and so forth,
but typing into the frame has no effect.

Apparently, if I just keep typing random junk into the frame, the
problem will resolve itself, with most of the input lost. (This is a
new observation, not yet thoroughly confirmed. Previously, I would
just kill the frame and open a new one.) In any case, the problem
only affects one frame, and other frames work as usual.

This is happening on OS X, --with-ns, recent builds from trunk. I
think the problem has been around for quite a while (i.e., weeks), but
I just haven't gotten around to reporting it until now.

I'd file a bug report, but the problem is that I have no idea how to
reproduce the problem. It just happens at random times.

Do other OS X users see this? Can you suggest something I could try to
get more information next time it happens? I gather that the event
loop is notoriously hard to debug, however.

- Harald

Re: OS X / nextstep port: Loss of keyboard events

[Achim Gratz]

Harald Hanche-Olsen writes:
> Do other OS X users see this? Can you suggest something I could try to
> get more information next time it happens? I gather that the event
> loop is notoriously hard to debug, however.

There's one just today on the org-mode mailing list.  Seems to only
affect trunk?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: OS X / nextstep port: Loss of keyboard events

[Ivan Andrus]

On Jan 7, 2013, at 6:36 PM, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:

> Once in a while, some frame stops receiving keyboard events. It keeps
> receiving mouse events, so I can move the cursor around and so forth,
> but typing into the frame has no effect.
> 
> Apparently, if I just keep typing random junk into the frame, the
> problem will resolve itself, with most of the input lost. (This is a
> new observation, not yet thoroughly confirmed. Previously, I would
> just kill the frame and open a new one.) In any case, the problem
> only affects one frame, and other frames work as usual.
> 
> This is happening on OS X, --with-ns, recent builds from trunk. I
> think the problem has been around for quite a while (i.e., weeks), but
> I just haven't gotten around to reporting it until now.
> 
> I'd file a bug report, but the problem is that I have no idea how to
> reproduce the problem. It just happens at random times.
> 
> Do other OS X users see this? Can you suggest something I could try to
> get more information next time it happens? I gather that the event
> loop is notoriously hard to debug, however.

I have noticed this too.  For me the problem "goes away" when I press a letter.  In other words only control or meta (or hyper probably) keys don't work. When I press a regular letter then it inputs that character and I am able to type control characters as normal.

Sadly, I can't offer any advice on how to debug it, but thought this extra data point might be useful.  I haven't noticed any clues as to what might cause it, and it's rather rare.

-Ivan

Re: OS X / nextstep port: Loss of keyboard events

[Paul Michael Reilly]

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

I see somewhat similar behavior as well.  I thought it might be related to
autosave but have no verification yet.  I did confirm the behavior using
emacs -q and will gladly go after the problem with gdb but I would very
much appreciate some suggestions.  I rebuilt twice in the past week using
the latest bazaar changes and saw the behavior in both builds.  My previous
build is about 3 months old and does not show the bad behavior, fwiw.

-pmr


On Mon, Jan 7, 2013 at 2:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:

> On Jan 7, 2013, at 6:36 PM, Harald Hanche-Olsen <hanche@math.ntnu.no>
> wrote:
>
> > Once in a while, some frame stops receiving keyboard events. It keeps
> > receiving mouse events, so I can move the cursor around and so forth,
> > but typing into the frame has no effect.
> >
> > Apparently, if I just keep typing random junk into the frame, the
> > problem will resolve itself, with most of the input lost. (This is a
> > new observation, not yet thoroughly confirmed. Previously, I would
> > just kill the frame and open a new one.) In any case, the problem
> > only affects one frame, and other frames work as usual.
> >
> > This is happening on OS X, --with-ns, recent builds from trunk. I
> > think the problem has been around for quite a while (i.e., weeks), but
> > I just haven't gotten around to reporting it until now.
> >
> > I'd file a bug report, but the problem is that I have no idea how to
> > reproduce the problem. It just happens at random times.
> >
> > Do other OS X users see this? Can you suggest something I could try to
> > get more information next time it happens? I gather that the event
> > loop is notoriously hard to debug, however.
>
> I have noticed this too.  For me the problem "goes away" when I press a
> letter.  In other words only control or meta (or hyper probably) keys don't
> work. When I press a regular letter then it inputs that character and I am
> able to type control characters as normal.
>
> Sadly, I can't offer any advice on how to debug it, but thought this extra
> data point might be useful.  I haven't noticed any clues as to what might
> cause it, and it's rather rare.
>
> -Ivan
>

[-- Attachment #2: Type: text/html, Size: 2778 bytes --]

Re: OS X / nextstep port: Loss of keyboard events

[Jan Djärv]

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

Hello.

Does this patch help:

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2012-12-10 02:00:42 +0000
+++ src/nsterm.m	2013-01-08 09:21:58 +0000
@@ -5170,6 +5170,7 @@
   if (NS_KEYLOG)
     NSLog (@"doCommandBySelector: %@", NSStringFromSelector (aSelector));
 
+  processingCompose = NO;
   if (aSelector == @selector (deleteBackward:))
     {
       /* happens when user backspaces over an ongoing composition:


	Jan D.

8 jan 2013 kl. 03:29 skrev Paul Michael Reilly <pmr@pajato.com>:

> I see somewhat similar behavior as well.  I thought it might be related to autosave but have no verification yet.  I did confirm the behavior using emacs -q and will gladly go after the problem with gdb but I would very much appreciate some suggestions.  I rebuilt twice in the past week using the latest bazaar changes and saw the behavior in both builds.  My previous build is about 3 months old and does not show the bad behavior, fwiw.
> 
> -pmr
> 
> 
> On Mon, Jan 7, 2013 at 2:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:
> On Jan 7, 2013, at 6:36 PM, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
> 
> > Once in a while, some frame stops receiving keyboard events. It keeps
> > receiving mouse events, so I can move the cursor around and so forth,
> > but typing into the frame has no effect.
> >
> > Apparently, if I just keep typing random junk into the frame, the
> > problem will resolve itself, with most of the input lost. (This is a
> > new observation, not yet thoroughly confirmed. Previously, I would
> > just kill the frame and open a new one.) In any case, the problem
> > only affects one frame, and other frames work as usual.
> >
> > This is happening on OS X, --with-ns, recent builds from trunk. I
> > think the problem has been around for quite a while (i.e., weeks), but
> > I just haven't gotten around to reporting it until now.
> >
> > I'd file a bug report, but the problem is that I have no idea how to
> > reproduce the problem. It just happens at random times.
> >
> > Do other OS X users see this? Can you suggest something I could try to
> > get more information next time it happens? I gather that the event
> > loop is notoriously hard to debug, however.
> 
> I have noticed this too.  For me the problem "goes away" when I press a letter.  In other words only control or meta (or hyper probably) keys don't work. When I press a regular letter then it inputs that character and I am able to type control characters as normal.
> 
> Sadly, I can't offer any advice on how to debug it, but thought this extra data point might be useful.  I haven't noticed any clues as to what might cause it, and it's rather rare.
> 
> -Ivan
> 


[-- Attachment #2: Type: text/html, Size: 4095 bytes --]

Re: OS X / nextstep port: Loss of keyboard events

[Ivan Andrus]

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

I haven't seen the problem since including this patch.  But it was always rather rare for me.  Or rather I would go a long time without seeing it, and then it would happen a lot and I would restart Emacs.  So, although I can't definitely say it's fixed, it does seem to be.

-Ivan

On Jan 8, 2013, at 10:22 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> Does this patch help:
> 
> === modified file 'src/nsterm.m'
> --- src/nsterm.m	2012-12-10 02:00:42 +0000
> +++ src/nsterm.m	2013-01-08 09:21:58 +0000
> @@ -5170,6 +5170,7 @@
>    if (NS_KEYLOG)
>      NSLog (@"doCommandBySelector: %@", NSStringFromSelector (aSelector));
>  
> +  processingCompose = NO;
>    if (aSelector == @selector (deleteBackward:))
>      {
>        /* happens when user backspaces over an ongoing composition:
> 
> 
> 	Jan D.
> 
> 8 jan 2013 kl. 03:29 skrev Paul Michael Reilly <pmr@pajato.com>:
> 
>> I see somewhat similar behavior as well.  I thought it might be related to autosave but have no verification yet.  I did confirm the behavior using emacs -q and will gladly go after the problem with gdb but I would very much appreciate some suggestions.  I rebuilt twice in the past week using the latest bazaar changes and saw the behavior in both builds.  My previous build is about 3 months old and does not show the bad behavior, fwiw.
>> 
>> -pmr
>> 
>> 
>> On Mon, Jan 7, 2013 at 2:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:
>> On Jan 7, 2013, at 6:36 PM, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
>> 
>> > Once in a while, some frame stops receiving keyboard events. It keeps
>> > receiving mouse events, so I can move the cursor around and so forth,
>> > but typing into the frame has no effect.
>> >
>> > Apparently, if I just keep typing random junk into the frame, the
>> > problem will resolve itself, with most of the input lost. (This is a
>> > new observation, not yet thoroughly confirmed. Previously, I would
>> > just kill the frame and open a new one.) In any case, the problem
>> > only affects one frame, and other frames work as usual.
>> >
>> > This is happening on OS X, --with-ns, recent builds from trunk. I
>> > think the problem has been around for quite a while (i.e., weeks), but
>> > I just haven't gotten around to reporting it until now.
>> >
>> > I'd file a bug report, but the problem is that I have no idea how to
>> > reproduce the problem. It just happens at random times.
>> >
>> > Do other OS X users see this? Can you suggest something I could try to
>> > get more information next time it happens? I gather that the event
>> > loop is notoriously hard to debug, however.
>> 
>> I have noticed this too.  For me the problem "goes away" when I press a letter.  In other words only control or meta (or hyper probably) keys don't work. When I press a regular letter then it inputs that character and I am able to type control characters as normal.
>> 
>> Sadly, I can't offer any advice on how to debug it, but thought this extra data point might be useful.  I haven't noticed any clues as to what might cause it, and it's rather rare.
>> 
>> -Ivan
>> 
> 


[-- Attachment #2: Type: text/html, Size: 4821 bytes --]