Re: [PATCH] better isearch support for complex input methods

[Karl Fogel]

Trying to sum up a lot of discussion here, as I think a good course of
action emerges now:

Kenichi Handa and Miles Bader have made it clear that:

   - Treating all ideographic chars as words for the purpose of
     `isearch-yank-word' is not good.  Although it worked for me in
     Chinese, it is apparently not winning in Japanese.  They suggest
     that there will be occasions where `isearch-yank-word' should
     grab slightly less than `forward-word' would supply.

   - For similar reasons, simply using category `|' (the
     okay-to-break-here-when-filling category) is the boundary is not
     always right either.

And I would like to add that:

   - Having `isearch-yank-word' grab a little less sometimes is okay,
     and will become even more tolerable after we add the C-o binding
     to grab a single char at a time.  (That binding is already in the
     patch, just deferred until after feature freeze.)

   - Independently of any isearch improvements, `forward-word'
     probably still needs to be improved.  At least in Chinese, it
     currently treats consecutive characters as one word, stopping at
     whitespace or punctuation (which, linguistically, may be many
     words away from point).  Unless this behavior is deliberate?
     Perhaps someone on this list knows about the decision history
     here.  It's true that "fixing" it would cause it to behave almost
     the same as `forward-char' in ideographic text -- the fix would
     really most help mixed language text.

     One quick route to this fix is to make scan_words() in syntax.c
     be aware of the `|' category.  This probably does not cover all
     cases perfectly, but it gets most of them.

So there are two independent changes here.

One is to make `isearch-yank-word' grab more sensitively.  This can be
done entirely in lisp.

The other is to (maybe?) fix the behavior of `forward-word' for
certain non-European character sets.  If we do this, it's probably
best done in C, in syntax.c:scan_words().

The patch below is only about the first change.  Right now it just
behaves as before, but gives us a place to get more sophisticated (see
`isearch-forward-word').

2001-04-25  Karl Fogel  <address@hidden>

        * isearch.el (isearch-mode-map): Bind C-o in isearch to yank the
        next letter from the buffer into the search string.
        (isearch-forward-word): New function, grabs just enough.
        (isearch-yank-internal): New helper function, contains common
        internals of next three.
        (isearch-yank-char): New function.
        (isearch-yank-word): Rewrite to use isearch-yank-internal.
        (isearch-yank-line): Rewrite to use isearch-yank-internal.

Index: isearch.el
===================================================================
RCS file: /cvs/emacs/lisp/isearch.el,v
retrieving revision 1.188
diff -u -r1.188 isearch.el
--- isearch.el  2001/02/05 17:13:28     1.188
+++ isearch.el  2001/04/25 15:03:03
@@ -286,6 +286,7 @@
     (define-key map " " 'isearch-whitespace-chars)
     (define-key map [?\S-\ ] 'isearch-whitespace-chars)
     
+    (define-key map "\C-o" 'isearch-yank-char)
     (define-key map "\C-w" 'isearch-yank-word)
     (define-key map "\C-y" 'isearch-yank-line)
 
@@ -1057,24 +1058,42 @@
        (isearch-yank-x-selection)
       (mouse-yank-at-click click arg))))
 
-(defun isearch-yank-word ()
-  "Pull next word from buffer into search string."
-  (interactive)
+(defun isearch-forward-word ()
+  "Move point forward one word to add to an incremental search string.  
+Sometimes this is the same distance as `forward-word', but under
+certain circumstances it is a smaller distance, because grabbing too
+little is preferable to grabbing too much.  For example, in
+Japanese... [Kenichi Handa or Miles Bader, please insert explanation
+here.]"
+  ;; Temporary implementation, until we figure out what to do
+  (forward-word 1))
+
+(defun isearch-yank-internal (jumpform)
+  "Pull the text from point to the point reached by JUMPFORM.
+JUMPFORM is a lambda expression that takes no arguments and returns a
+buffer position, possibly having moved point to that position.  For
+example, it might move point forward by a word and return point, or it
+might return the position of the end of the line."
   (isearch-yank-string
    (save-excursion
      (and (not isearch-forward) isearch-other-end
          (goto-char isearch-other-end))
-     (buffer-substring-no-properties
-      (point) (progn (forward-word 1) (point))))))
+     (buffer-substring-no-properties (point) (funcall jumpform)))))
 
+(defun isearch-yank-char ()
+  "Pull next letter from buffer into search string."
+  (interactive)
+  (isearch-yank-internal (lambda () (forward-char 1) (point))))
+
+(defun isearch-yank-word ()
+  "Pull next word from buffer into search string."
+  (interactive)
+  (isearch-yank-internal (lambda () (isearch-forward-word) (point))))
+
 (defun isearch-yank-line ()
   "Pull rest of line from buffer into search string."
   (interactive)
-  (isearch-yank-string
-   (save-excursion
-     (and (not isearch-forward) isearch-other-end
-         (goto-char isearch-other-end))
-     (buffer-substring-no-properties (point) (line-end-position)))))
+  (isearch-yank-internal (lambda () (line-end-position))))
 
 
 (defun isearch-search-and-update ()




"Stefan Monnier" <monnier+gnu/address@hidden> writes:
> > Andreas Schwab <address@hidden> writes:
> > > |> For C-w while searching, I wouldn't mind so much, because there it's
> > > |> usually better to grab too little than too much (as you can't easily
> > > |> delete small overruns).
> > > 
> > > Grabbing too much isn't actually so bad, now that we have M-e
> > > (isearch-edit-string).
> > 
> > Well, perhaps, but I don't really think that's a great solution --
> > going into edit mode, although it's nice when you need it, really
> > interrupts the flow; it's much easier to just hit C-w a bunch of times
> > (and DEL to correct).
> 
> All we need is to change DEL so that it never deletes more than one char.
> I always hated the fact that C-s C-s DEL ends up with an empty search string.
> I currently use a simple hack:
> 
> (defun my-isearch-delete-char ()
>   (interactive)
>   (setq isearch-string (substring isearch-string 0 -1))
>   (setq isearch-message
>       (mapconcat 'isearch-text-char-description isearch-string ""))
>   (isearch-update))
> (define-key isearch-mode-map "\C-?" 'my-isearch-delete-char)
> 
> but the "backtracking" behavior of the current DEL is also desirable.
> 
> 
>       Stefan
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel