F10 turn to [21~ in terminal on mac #72

Closed
qzi opened this Issue Mar 14, 2013 · 17 comments

Comments

Projects
None yet
4 participants

qzi commented Mar 14, 2013

F10 turn to [21~ in terminal on mac.

Owner

purcell commented Mar 16, 2013

Hmm, I can confirm this, but currently don't have time to help figure out the issue. F1 works correctly in both Terminal and iTerm, but higher function keys are indeed a problem.

qzi commented Apr 5, 2013

;; Paredit && ;;(ido-ubiquitous-mode t)

Contributor

mattfidler commented Oct 19, 2013

This should be simple,

(when (eq system-type 'darwin) (define-key key-translation-map "\e[21~" [f10]))

The teminal information for a mac may be different than other terminals, so to be save only define the translation on a mac.

I'm not sure if this is useful though. Doesn't the mac define F10 to do something in the system.

@purcell do you have to put your startup in .emacs.d? or can it be put elsewhere. Just wondering, was going to try it out too.

@mattfidler mattfidler added a commit to mattfidler/emacs.d that referenced this issue Oct 19, 2013

@mattfidler mattfidler Update init-osx-keys.el
F10 in terminal should work now.  See Issue #72
d368f2e
Owner

purcell commented Oct 19, 2013

@mlf176f2 Yes, OS X grabs the F10 by default. I'll see if I can turn that off, though, to give this fix a try - thanks!

Regarding the location of the startup files, I'm not sure if any other directory name would work: there doesn't seem to be an Emacs command line arg for the init dir, and I use user-emacs-directory in various parts of the config, assuming it will be the directory containing init.el.

@osener osener pushed a commit to osener/emacs.d that referenced this issue Jan 4, 2014

@mattfidler mattfidler Update init-osx-keys.el
F10 in terminal should work now.  See Issue #72
d2e3e95

kongfy commented May 26, 2014

Seems this issue still exist, I can't use any higher function keys than F4 in C++ mode with iTerm.
Can somebody help me?

Contributor

mattfidler commented May 26, 2014

I don't work on a mac, but pressing the f5 key, etc should give some sequence of characters. Bunting \e[ to the f kr u in the translation map should fix the problem.

kongfy commented May 26, 2014

but all the function keys work fine when I'm not in C/C++ mode, and I tried the translation map, it didn't help.

Owner

purcell commented May 26, 2014

@kongfy Enter C-h k and then press F5. What does Emacs report, if anything?

kongfy commented May 26, 2014

with GUI this just got " is undefined"
but in iTerm I got the screen shot below:
a2aadd6e-1fd5-4af8-b03d-a6e938c8c953
does this means it may caused by paredit?

Owner

purcell commented May 26, 2014

Well, no -- it means that after being translated, it looks like M-[ to Emacs.

Note that in init-osx-keys I have

(define-key key-translation-map "\e[21~" [f10])

for some reason, and perhaps further mappings are needed for the other function keys. It might also be dependent on the terminal emulator, e.g. Terminal vs. iTerm.

Here are the settings I have in my iTerm, but I don't know if these are standard, or if Terminal sends the same keys:

screen shot 2014-05-26 at 16 07 33

Unfortunately I don't have time to investigate just now, but I'll do my best to circle back round do it.

Contributor

mattfidler commented May 26, 2014

It's also likely that M-[ is bound to something in C mode, or you are using
helm that binds M-[. One way to test is to remove that binding in C.
On May 26, 2014 10:09 AM, "Steve Purcell" notifications@github.com wrote:

Well, no -- it means that after being translated, it looks like M-[ to
Emacs.

Note that in init-osx-keys I have

(define-key key-translation-map "\e[21~" [f10])

for some reason, and perhaps further mappings are needed for the other
function keys. It might also be dependent on the terminal emulator, e.g.
Terminal vs. iTerm.

Here are the settings I have in my iTerm, but I don't know if these are
standard, or if Terminal sends the same keys:

[image: screen shot 2014-05-26 at 16 07 33]https://cloud.githubusercontent.com/assets/5636/3083710/824e8322-e4e7-11e3-83d8-847296180d8f.PNG

Unfortunately I don't have time to investigate just now, but I'll do my
best to circle back round do it.


Reply to this email directly or view it on GitHubhttps://github.com/purcell/emacs.d/issues/72#issuecomment-44196892
.

Owner

purcell commented Jun 4, 2014

Yes, M-[ is bound to paredit-open-square. So is it generally the case that M-[ is indistinguishable from \e[ in the terminal? If so, I can remove this binding.

Contributor

mattfidler commented Jun 4, 2014

Yes. It is indistinguishable.

You could remove it, but you can also do something more fancy

emacs-helm/helm@83b089a

(defvar mlf-paredit-open-square-delay 0.02)
(defun mlf-paredit-open-square-delay (&optional N)
  "Delay to allow M-[ to work in the terminal."
  (interactive "P")
  (if window-system
      (paredit-open-square-delay N)
    (let ((current-keys (key-description (this-command-keys)))
          (next-key (with-timeout (mlf-paredit-open-square-delay  nil)
                      (eval (macroexpand `(key-description [,(read-key)]))))))
      (cond
       (next-key
        (setq unread-command-events
              (listify-key-sequence
               (read-kbd-macro (concat current-keys " " next-key)))))
       (t
        (paredit-open-square-delay N))))))

This basically says that if the next key is pressed within 0.02 miliseconds, it is a function key or something similar and waits for the next key. Otherwise it executes the function.

Its a hack, and may not work if you are sshing into a terminal session.

kongfy commented Jun 5, 2014

Every function key works fine after I diable paredit in C mode by comment out

(add-hook 'prog-mode-hook 'paredit-everywhere-mode)

in init-paredit.el, and the following line in init-osx-keys.el can be removed without any damage:

(define-key key-translation-map "\e[21~" [f10])
Owner

purcell commented Jun 5, 2014

Thanks guys.

Every function key works fine after I diable paredit in C mode by comment out

(add-hook 'prog-mode-hook 'paredit-everywhere-mode)

I've stopped paredit-everywhere-mode from binding M-[, so this problem should go away when the corresponding updated package is installed.

in init-paredit.el, and the following line in init-osx-keys.el can be removed without any damage:

(define-key key-translation-map "\e[21~" [f10])

Hmmm, @mlf176f2 contributed that line at some point: can you confirm it's not needed, Matthew?

Contributor

mattfidler commented Jun 5, 2014

I never attempted the fix. It's based on the error description.

I'm not sure if the original person tried it or not. I don't think it has any consequences for most users either way.

Contributor

mattfidler commented Jun 5, 2014

As a note. M-O and ESC have similar issues. I believe prelude has this problem too sine it bind M-O

@edunonnn edunonnn pushed a commit to edunonnn/emacs.d that referenced this issue Oct 1, 2014

@purcell purcell + Sherman Hsu Drop superfluous translation-map entry (see #72) 679e2e3

@vickyyu vickyyu pushed a commit to vickyyu/emacs.d that referenced this issue Oct 13, 2014

@purcell purcell + vicky_yu Drop superfluous translation-map entry (see #72) 0625b2d

@XiaoLiuAI XiaoLiuAI pushed a commit to XiaoLiuAI/purcell that referenced this issue Oct 26, 2014

@purcell purcell Drop superfluous translation-map entry (see #72) 98cf66a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment