On Tue, Nov 16, 2010 at 4:02 PM, smcho <[email protected]> wrote: > I don't know if this is a bug or not, but this is what I found.
It's definitely a bug, and potentially a very hard bug to fix. The following notes are for @bool swap_mac_keys = False, which is, according to the notes, the recommended setting. > C-a move the cursor to the start of line, but C-e seems to move the > cursor the first of the next line, which is the end of last line + 1. > If the line is the final one, C-e moves the cursor to the end of line > as there's no next line. Neither c-a nor c-e is being passed to eventFilter, which means that as far as Leo concerned these keys have never been pressed! The situation on the Mac is dire, as far as keystrokes go. For example, Ctrl-h apparently minimizes the window without any chance of intercepting the stroke. Moreover, the alt key on Mac-specific keyboards generates a Alt character, but the alt key on Microsoft keyboards generates the Meta character (!!). Apparently, Leo doesn't handle the Meta character as it should, which makes it impossible to type Alt-x. It gets worse. There appears to be no way to activate the Leo menus from the keyboard at present. I'm not sure whether MacOS is involved in this problem or not. I'm not sure there is anything Leo can do about MacOS intercepting various keystrokes, but now is the time to do some investigating. Ideally, it would be good to get rid of the eventFilter method (and all its odious helpers), replacing them all with "harder" bindings set at init time. Of course, these would have to be "late" bindings, created after the various settings files have been created. It's time for some experiments on a simple prototype... Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
