[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Why is `C-x 8' limited to Latin-1 for search?

From: Drew Adams
Subject: RE: Why is `C-x 8' limited to Latin-1 for search?
Date: Mon, 10 Dec 2012 06:24:24 -0800

> To avoid code duplication, a new macro could be created
> with a name like `with-isearch-paused' and the body from 
> `isearch-edit-string' except the part that changes
> `isearch-new-string' and `isearch-new-message'.
> It could be used in a new command with a name like 
> `isearch-insert-char-by-name'.

FWIW, I did that yesterday in my own code (isearch+.el).
If Emacs adds this or similar then I won't need to do that. 

I named the macro `isearchp-use-new-search-string' and the new command
`isearchp-read-unicode-char'.  I bind `isearchp-read-unicode-char' to `C-x 8
RET' in `isearch-mode-map' and `insert-char' to `C-x 8 RET' in

The macro is passed a sexp that is evaluated to produce the new search string.
So for `isearchp-read-unicode-char', this is the call:

(defun isearchp-read-unicode-char ()
     (concat isearch-string
                "Unicode (name or hex): ")))))

And for `isearch-edit-string' the sexp passed is just the current
`read-from-minibuffer' sexp.

But I don't know what you mean by "except the part that changes
`isearch-new-string' and `isearch-new-message'.  I do change both, to reflect
the added char.  No doubt you had a slightly different macro in mind.  Anyway,
FWIW, the code I used is here:

Something else to consider perhaps is whether another (perhaps additional),
shorter key sequence should be bound for this.  My thinking was that `C-x 8 RET'
is enough, since (a) it is what users will remember for this, and (b) reading
the char name is anyway an interruption/slowdown, so it would not help much to
introduce the reading with a quick key sequence.

Another possibility, which I used at first but abandoned, would be to not bind
`enable-recursive-minibuffers' to non-nil systematically in the macro, but to
bind it to a value passed as an additional (optional) parameter.  For my use, at
least, I decided this was not necessary/useful - I just bind it to t.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]