Хотя привязки развивались с течением времени, на сегодняшний день, когда вы вызываете 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)))))