[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Writing a command that assumes control of the keyboard, like isearch
From: |
Alan Mackenzie |
Subject: |
Re: Writing a command that assumes control of the keyboard, like isearch does |
Date: |
Tue, 27 Apr 2010 08:33:22 +0000 (UTC) |
User-agent: |
tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386)) |
Sean McAfee <eefacm@gmail.com> wrote:
> I want to write a command that assumes control of the keyboard until it
> returns, highlighting and modifying the current buffer in the meantime,
> like the isearch family of commands do.
> Specifically, I have some text that is the output from an OCR process,
> in which the spaces between words have sometimes been lost; for example:
> GNUEmacsisanextensible,customizabletexteditor?andmore.
> I want to write a command that will wait for me to type a letter, then
> advance the cursor to that letter and provisionally insert a space
> after it, highlighting the passed-over text (the provisional word, that
> is). If I then type a space, I confirm the provisional word; if I type
> another letter, the provisional space is removed, and the cursor skips
> to the newer letter I typed and inserts another provisional space.
> Therefore, I could break the words in the sample text above with this
> key sequence:
> u SPC s SPC s SPC n SPC e e SPC e SPC t t SPC r SPC d SPC
> Some kind of special handling would probably be needed for punctuation,
> but I can resolve those details later. And I suppose RET would
> probably terminate the command.
> Since the behavior I want to implement broadly resembles what isearch
> does, I went and read the source code, but found it unsuitable for
> casual reading. I did note this command near the beginning:
isearch.el is worth studying at a deeper level.
> ;; For programmed use of isearch-mode, e.g. calling (isearch-forward),
> ;; isearch-mode behaves modally and does not return until the search
> ;; is completed. It uses a recursive-edit to behave this way.
> So, does that mean it *doesn't* use a recursive edit when called
> interactively? What does it do in that case? Not very illuminating.
Interactively, isearch mode switches on a minor mode, and most
importantly, sets the `overriding-terminal-local-map' to the keymap
isearch-mode-map. isearch-mode-map has the keybinding
isearch-printing-char (which increments the search string) for all
printing characters, and suitable commands are bound to C-s, M-r, ....,
and so on. Random control sequences are bound to
isearch-other-control-char, which typically exits isearch mode by
clearing `overriding-terminal-local-map'.
> Browsing the manual, it seems that I might be able to write my own mini
> event loop using read-char, but I can't help but feel that there must be
> an easier way. As best I can express it right now, I want to
> temporarily install a keymap where every key that normally calls
> self-insert-command calls a routine of my choice instead; SPC and RET
> have the special meanings described above; and any other key sequence
> exits my command and has its normal effect (again, like isearch).
I think that is indeed what you want to do. Don't forget C-g!
> Any pointers to get me on the right track, or even just references to
> the appropriate places in the manual that I might have missed, would be
> greatly appreciated.
Study isearch.el more thoroughly. The stuff you want to emulate is
indeed there.
--
Alan Mackenzie (Nuremberg, Germany).