Хоча прив'язки еволюціонували з часом, на сьогоднішній день, коли ви викликаєте ido-find-file
або ido-find-file-read-only
, ви можете використовувати такі прив'язки, доступні в конфігурації за замовчуванням:
- M-o викликає
ido-prev-work-file
- C-M-o викликає
ido-next-work-file
Крім цього , не будучи в ергономічно приємним , як M-pі M-nприв'язок я звик до перш ніж намагатися IDO , вони також повільно, і , як наслідок , мінібуфер балаканина відволікає і заплутаною. ido робить щось більше, ніж просто показує нещодавно відкрите ім'я файлу; він повідомляє, що це "Пошук" імені файлу "...", можливо, не бажаючи пропонувати ім'я для файлу, якого більше немає.
Повідомлення "Пошук" походить від функції ido-make-merged-file-list
. Читаючи джерело , я не бачу жодного способу відключити будь-яку магію цієї функції.
Ви можете розглянути можливість відновлення ido-prev-work-file
та ido-next-work-file
пари на щось більш природне, як-от C-M-pі C-M-n, або заміну поточних M-p( ido-prev-work-directory
) та M-n( ido-next-work-directory
) прив'язків для них.
Ось код Emacs Lisp для відновлення M-pта M-nпереходу останніх файлів, переміщення стандартних посилань, орієнтованих на каталог, C-M-pта C-M-nвідповідно:
(add-hook 'ido-setup-hook
(lambda ()
(let ((kmap ido-file-dir-completion-map))
(let ((key '(meta ?n)))
(define-key kmap (vector (cons 'control key))
(lookup-key kmap (vector key)))
(define-key kmap (vector key) 'ido-next-work-file))
(let ((key '(meta ?p)))
(define-key kmap (vector (cons 'control key))
(lookup-key kmap (vector key)))
(define-key kmap (vector key) 'ido-prev-work-file)))))