* OS X / nextstep port: Loss of keyboard events
@ 2013-01-07 17:36 Harald Hanche-Olsen
2013-01-07 18:16 ` Achim Gratz
2013-01-07 19:01 ` Ivan Andrus
0 siblings, 2 replies; 6+ messages in thread
From: Harald Hanche-Olsen @ 2013-01-07 17:36 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OS X / nextstep port: Loss of keyboard events
2013-01-07 17:36 OS X / nextstep port: Loss of keyboard events Harald Hanche-Olsen
@ 2013-01-07 18:16 ` Achim Gratz
2013-01-07 19:01 ` Ivan Andrus
1 sibling, 0 replies; 6+ messages in thread
From: Achim Gratz @ 2013-01-07 18:16 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OS X / nextstep port: Loss of keyboard events
2013-01-07 17:36 OS X / nextstep port: Loss of keyboard events Harald Hanche-Olsen
2013-01-07 18:16 ` Achim Gratz
@ 2013-01-07 19:01 ` Ivan Andrus
2013-01-08 2:29 ` Paul Michael Reilly
1 sibling, 1 reply; 6+ messages in thread
From: Ivan Andrus @ 2013-01-07 19:01 UTC (permalink / raw)
To: Harald Hanche-Olsen, emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OS X / nextstep port: Loss of keyboard events
2013-01-07 19:01 ` Ivan Andrus
@ 2013-01-08 2:29 ` Paul Michael Reilly
2013-01-08 9:22 ` Jan Djärv
0 siblings, 1 reply; 6+ messages in thread
From: Paul Michael Reilly @ 2013-01-08 2:29 UTC (permalink / raw)
To: Ivan Andrus; +Cc: Harald Hanche-Olsen, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OS X / nextstep port: Loss of keyboard events
2013-01-08 2:29 ` Paul Michael Reilly
@ 2013-01-08 9:22 ` Jan Djärv
2013-01-15 20:55 ` Ivan Andrus
0 siblings, 1 reply; 6+ messages in thread
From: Jan Djärv @ 2013-01-08 9:22 UTC (permalink / raw)
To: Paul Michael Reilly; +Cc: Ivan Andrus, Harald Hanche-Olsen, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OS X / nextstep port: Loss of keyboard events
2013-01-08 9:22 ` Jan Djärv
@ 2013-01-15 20:55 ` Ivan Andrus
0 siblings, 0 replies; 6+ messages in thread
From: Ivan Andrus @ 2013-01-15 20:55 UTC (permalink / raw)
To: emacs-devel@gnu.org discussions, Jan Djärv
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-15 20:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-07 17:36 OS X / nextstep port: Loss of keyboard events Harald Hanche-Olsen
2013-01-07 18:16 ` Achim Gratz
2013-01-07 19:01 ` Ivan Andrus
2013-01-08 2:29 ` Paul Michael Reilly
2013-01-08 9:22 ` Jan Djärv
2013-01-15 20:55 ` Ivan Andrus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).