From: Ivan Andrus <darthandrus@gmail.com>
To: "emacs-devel@gnu.org discussions" <emacs-devel@gnu.org>,
"Jan Djärv" <jan.h.d@swipnet.se>
Subject: Re: OS X / nextstep port: Loss of keyboard events
Date: Tue, 15 Jan 2013 21:55:31 +0100 [thread overview]
Message-ID: <6B0C48AE-E75A-42AF-B93E-CA0E74CE31D2@gmail.com> (raw)
In-Reply-To: <CBE0D7D8-6C97-4330-8FAA-C284B96B09FF@swipnet.se>
[-- 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 --]
prev parent reply other threads:[~2013-01-15 20:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6B0C48AE-E75A-42AF-B93E-CA0E74CE31D2@gmail.com \
--to=darthandrus@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=jan.h.d@swipnet.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.