emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macosx(carbon): slow keyboard responsiveness bug fix


From: Dan Nicolaescu
Subject: Re: macosx(carbon): slow keyboard responsiveness bug fix
Date: Tue, 20 Nov 2007 09:58:48 -0800

Stefan Monnier <address@hidden> writes:

  > >> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
  > >> It shouldn't be difficult (because even though the generic Emacs code
  > >> then supports multiple keyboards, the Mac OS X part of the code can
  > >> still choose to only create a single keyboard and work the same as
  > >> before).

I removed the MULTI_KBOARD define, it was set like that by mistake when
I did the initial multi-tty port to Carbon, and nobody has touched it
much since. Given that now the Carbon port warns that it is non
functional, if anybody wants to get this working, it should be done the
right way.

  > > Hmm, it turns out easy. Just enable it, then works fairly well. :P 
  > 
  > I didn't dare to suggest that it might work ;-)
  > 
  > > Well, there's one problem. Some special keys become undefined, like tab,
  > > return, esc. Do you have an idea what might cause this? The following is
  > > a workaround for this: 
  > 
  > > ,----
  > > | (global-set-key (kbd "<return>") (kbd "RET"))
  > > | (global-set-key (kbd "<tab>") (kbd "TAB"))
  > > `----
  > 
  > These should be set up in function-key-map (or local-function-key-map).
  > I think the problem might be that mac-win.el sets them up in
  > local-function-key-map directly from the file's top-level whereas it
  > should probably do it from the mac-initialize-window-system function.

It's not at the top level, it's in x-setup-function-keys. 
It's confusing because the function is not indented. When I did the
initial multi-tty port I didn't want to make unnecessary changes that
would make merging harder. There's more stuff that needs to be properly
indented in the file, but that would make the unicode-2 merge harder.

  > Take a look at how x-win.el does it: it defines a x-alternatives-map and
  > then activates it in x-initialize-window-system.  mac-win.el should do
  > the same (search for "[return]" in both files to see where/how the
  > binding is created).

I changed it to be similar to what w32-win.el does.

None of these is tested, I don't have access to a mac machine.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]