Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use abstract key codes in haskell-indentation.el #291

Closed
wants to merge 1 commit into from

Conversation

kini
Copy link
Contributor

@kini kini commented Jun 16, 2014

haskell-indentation rebinds the return, backspace, and delete keys by
looking up the raw key codes for those three keys. This commit instead
binds the more abstract key codes "RET", "DEL", and "<deletechar>".
This has a couple of benefits.

  1. It makes the bindings work in console Emacs, i.e. Emacs run in
    a terminal with emacs -nw. Raw key codes such as [?\r],
    [backspace], and [?\C-d] are only available when Emacs is running in
    an X environment, and by default Emacs translates them into
    UI-independent key codes such as "RET", "DEL", and "<deletechar>",
    unless something binds them directly.
  2. It makes haskell-indentation more compatible with evil-mode.
    Evil-mode doesn't expect other modes to rebind raw key codes because
    of the issue above.

In particular, evil-mode is supposed to treat backspace and return
as movement commands (left and down, respectively) when in the <N>
state, and release those keys back to the ambient keymap (in this
case, the one provided by haskell-mode and haskell-indentation) when
in the <I> state.

However, it is currently unable to grab the backspace and return
keys in <N> state because it waits for Emacs to translate the
X-specific raw key codes before it binds them, in order to respect
the abstraction there. If haskell-indentation binds the raw key
codes, evil-mode can't get to them first.

I reported this issue on the evil-mode mailing list back in September
2012 [1] but didn't get around to fixing it until today. Sorry for the
delay!

[1] http://thread.gmane.org/gmane.emacs.vim-emulation/1667

haskell-indentation rebinds the return, backspace, and delete keys by
looking up the raw key codes for those three keys.  This commit instead
binds the more abstract key codes `"RET"`, `"DEL"`, and
`"<deletechar>"`. This has a couple of benefits.

1.  It makes the bindings work in console Emacs, i.e. Emacs run in
    a terminal with `emacs -nw`.  Raw key codes such as `[?\r]`,
    `[backspace]`, and `[?\C-d]` are only available when Emacs is
    running in an X environment, and by default Emacs translates them
    into UI-independent key codes such as `"RET"`, `"DEL"`, and
    `"<deletechar>"`, unless something binds them directly.

2.  It makes haskell-indentation more compatible with evil-mode.
    Evil-mode doesn't expect other modes to rebind raw key codes because
    of the issue above.

    In particular, evil-mode is supposed to treat backspace and return
    as movement commands (left and down, respectively) when in the `<N>`
    state, and release those keys back to the ambient keymap (in this
    case, the one provided by haskell-mode and haskell-indentation) when
    in the `<I>` state.

    However, it is currently unable to grab the backspace and return
    keys in `<N>` state because it waits for Emacs to translate the
    X-specific raw key codes before it binds them, in order to respect
    the abstraction there.  If haskell-indentation binds the raw key
    codes, evil-mode can't get to them first.

I reported this issue on the evil-mode mailing list back in September
2012 [1] but didn't get around to fixing it until today.  Sorry for the
delay!

[1] http://thread.gmane.org/gmane.emacs.vim-emulation/1667
@chrisdone
Copy link
Member

Seems to make sense. Rebased and merged.

@chrisdone chrisdone closed this Jul 24, 2014
@kini kini deleted the abstract-bindings branch July 25, 2014 23:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants