isearch-yank-char

isearch-yank-char

[Juri Linkov]

There is an inevitable need for a key binding for isearch-yank-char.

The current C-w key binding for isearch-yank-word-or-char tries
to decide whether the user wants a character or a word, but it
often fails, because it is impossible to predict what the user wants.

The need to grab a part of a word into search string is valid for many
languages, even for English, for example, to search all forms of a
word (e.g. singular and plural forms, inflected verbs, etc.) by
grabbing the word root from the buffer and omitting word endings
(such as "-s", "-ing", "-ed").

Another example where this key binding is needed is Emacs modes which
give word syntax to non-word characters.  For example, in Info mode
it is impossible to grab a function or variable name into search
string as a word, because it grabs the apostrophe character used
for quoting as part of the function name.

I guess that isearch-yank-char has no key binding yet, because it is
difficult to choose a good one.  I looked at all possible key bindings,
and it seems that the best key binding is C-f.  It is most suitable
semantically: normally, C-f runs forward-char, and isearch-yank-char
has a similar functionality by operating on characters.

But most importantly, C-f is the most backward compatible key binding,
because when the user types C-f without leaving isearch mode with the
intention to move the point right, nothing bad happens: the user
simply types RET or any other non-isearch key to finish isearch, and
the point remains exactly at the same position where the user wanted
to move it!  In other words, `C-s ...  C-f RET' is equivalent to
`C-s ...  RET C-f'.

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.226
diff -u -r1.226 isearch.el
--- lisp/isearch.el	4 Mar 2004 16:54:08 -0000	1.226
+++ lisp/isearch.el	26 Apr 2004 04:34:14 -0000
@@ -294,7 +294,8 @@
     (define-key map " " 'isearch-whitespace-chars)
     (define-key map [?\S-\ ] 'isearch-whitespace-chars)
 
-    (define-key map "\C-w" 'isearch-yank-word-or-char)
+    (define-key map "\C-f" 'isearch-yank-char)
+    (define-key map "\C-w" 'isearch-yank-word)
     (define-key map "\C-y" 'isearch-yank-line)
 
-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Karl Fogel]

Juri Linkov <juri@jurta.org> writes:
> There is an inevitable need for a key binding for isearch-yank-char.
> 
> The current C-w key binding for isearch-yank-word-or-char tries
> to decide whether the user wants a character or a word, but it
> often fails, because it is impossible to predict what the user wants.

For more of the history behind this, see

   http://mail.gnu.org/archive/html/emacs-devel/2001-04/threads.html#00001

The archive seems not to have caught every mail in the thread,
unfortunately.  For example, Richard Stallman sent this mail, but it
does not appear to be in the archive:

  | From: Richard Stallman <rms@gnu.org>
  | Subject: Re: isearch C-o patch (post-freeze resubmission)
  | To: storm@cua.dk
  | CC: kfogel@red-bean.com, emacs-devel@gnu.org
  | Date: Thu, 29 Nov 2001 12:18:25 -0700 (MST)
  | Reply-to: rms@gnu.org
  | 
  |     However, I would much rather change the behaviour of C-w so that it
  |     copies a `word' if it is on a `word character' and a single
  |     character otherwise.  Then I could C-w C-w C-w to copy
  |     word+= into the minibuffer (and use backspace if I got too much).
  | 
  | This seems like an idea worth trying.  Would you like to do it?

I don't know what else might be missing (haven't done a careful
survey), but anyway I think what's in the archive is complete enough
to give all relevant context.

> The need to grab a part of a word into search string is valid for many
> languages, even for English, for example, to search all forms of a
> word (e.g. singular and plural forms, inflected verbs, etc.) by
> grabbing the word root from the buffer and omitting word endings
> (such as "-s", "-ing", "-ed").

Yes.  At first, I thought having C-w be more sophisticated would be
enough, but in practice, finer-grained control is often necessary.

> I guess that isearch-yank-char has no key binding yet, because it is
> difficult to choose a good one.  I looked at all possible key bindings,
> and it seems that the best key binding is C-f.  It is most suitable
> semantically: normally, C-f runs forward-char, and isearch-yank-char
> has a similar functionality by operating on characters.

The original binding was C-o, but C-f seems like a better choice, for
the reasons you give.

> But most importantly, C-f is the most backward compatible key binding,
> because when the user types C-f without leaving isearch mode with the
> intention to move the point right, nothing bad happens: the user
> simply types RET or any other non-isearch key to finish isearch, and
> the point remains exactly at the same position where the user wanted
> to move it!  In other words, `C-s ...  C-f RET' is equivalent to
> `C-s ...  RET C-f'.

A thought: can we then bind C-b to *lose* a single character from the
search string?  The same logic applies to both C-f and C-b, and wow,
it sure would be convenient to have something finer than Backspace
(since Backspace usually loses too much!).

Of course, the patch for that would be a bit more complex than just
binding a key.  But if people think it is a good idea, I will be
happy to write it.

In any case, binding C-f to isearch-yank-char seems like a fine idea.

-Karl

Re: isearch-yank-char

[Karl Fogel]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> Juri Linkov <juri@jurta.org> writes:
> > There is an inevitable need for a key binding for isearch-yank-char.
> > 
> > The current C-w key binding for isearch-yank-word-or-char tries
> > to decide whether the user wants a character or a word, but it
> > often fails, because it is impossible to predict what the user wants.
> 
> For more of the history behind this, see
> 
>    http://mail.gnu.org/archive/html/emacs-devel/2001-04/threads.html#00001

In addition to the above, see this thread:

   http://mail.gnu.org/archive/html/emacs-devel/2001-11/threads.html#01034

The second thread explains why we don't (currently) have a keybinding
for isearch-yank-char.

With these two threads, the full history of the issue is visible.
Sorry I didn't find the second thread before sending my earlier reply.

-Karl

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> For more of the history behind this, see
>
>    http://mail.gnu.org/archive/html/emacs-devel/2001-04/threads.html#00001

Thanks, I've already looked at all related information,
even http://www.red-bean.com/kfogel/isearch-thread.html ;-)

> A thought: can we then bind C-b to *lose* a single character from the
> search string?  The same logic applies to both C-f and C-b, and wow,
> it sure would be convenient to have something finer than Backspace
> (since Backspace usually loses too much!).
>
> Of course, the patch for that would be a bit more complex than just
> binding a key.  But if people think it is a good idea, I will be
> happy to write it.

I think it is a good idea.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Richard Stallman]

    But most importantly, C-f is the most backward compatible key binding,
    because when the user types C-f without leaving isearch mode with the
    intention to move the point right, nothing bad happens: the user
    simply types RET or any other non-isearch key to finish isearch, and
    the point remains exactly at the same position where the user wanted
    to move it!

That is an idea worth thinking about.  We could try it.  However, it
could confuse people who are accustomed to assume that after typing
C-f they are out of the search.

Re: isearch-yank-char

[Stefan Monnier]

> +    (define-key map "\C-f" 'isearch-yank-char)

I think many bindings are available for isearch because in practice very
few normal bindings are used to exit isearch.  But I do think C-f is one of
those bindings that people use to exist isearch.


        Stefan

Re: isearch-yank-char

[Miles Bader]

On Mon, Apr 26, 2004 at 06:42:56PM -0400, Stefan Monnier wrote:
> > +    (define-key map "\C-f" 'isearch-yank-char)
> 
> I think many bindings are available for isearch because in practice very
> few normal bindings are used to exit isearch.  But I do think C-f is one of
> those bindings that people use to exist isearch.

Yeah .. and it's one of those things about which it's risky to make
judgements based on personal experience -- people seem to vary a _lot_ in the
way they use isearch (I'm always a bit surprised when I watch someone else
using it...).

It's a shame, because it would be nice to use more "normal" bindings in
isearch to do "isearchey variants", but it's probably necessary to be pretty
conservative.

-Miles
-- 
Would you like fries with that?

Re: isearch-yank-char

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
> Yeah .. and it's one of those things about which it's risky to make
> judgements based on personal experience -- people seem to vary a _lot_ in the
> way they use isearch (I'm always a bit surprised when I watch someone else
> using it...).
> 
> It's a shame, because it would be nice to use more "normal" bindings in
> isearch to do "isearchey variants", but it's probably necessary to be pretty
> conservative.

In this case, I wonder if we're not being overly conservative.

If people learn by experience that certain commands no longer exit
isearch as before, and instead cause isearch to behave in new ways,
this might be okay as long as the experiences aren't too painful.  And
I think these wouldn't be terribly painful.  The benefits (very useful
new functionality in isearch) are permanent, the costs are temporary
and probably not large.

I agree with the conservatism argument in general -- it nearly drove
me crazy when C-a's behavior in shell-mode changed -- but conservatism
is less important in situations that are unlikely to be reflexive
editing idioms for users.  While C-f (and C-b) are practically spinal
reflexes when used in a "normal" editing context, they are much less
likely to be reflexive *when used as isearch exiting methods*, because
isearch is much less frequented than regular editing modes, and
because everyone who is in isearch is already conscious that they're
in a "special" editing state.  People's minds are already a bit
prepared for something unusual to happen in isearch, so it's not as
bad when it does.

-Karl

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> Miles Bader <miles@gnu.org> writes:
>> It's a shame, because it would be nice to use more "normal" bindings in
>> isearch to do "isearchey variants", but it's probably necessary to be pretty
>> conservative.
>
> In this case, I wonder if we're not being overly conservative.

Here is an idea: to create a special mode, say, conservative-mode,
where default values and key bindings will never change from version
to version.  Users upset by constant changes will set it once and for
all in own .emacs and will not worry about further changes.  Users who
don't set this mode (as well as novices who have no preferences) will
be ready for changes, and Emacs development will not be restricted by
care for backward compatibility anymore.  So everyone will be happy.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Juri Linkov]

> Here is an idea: to create a special mode, say, conservative-mode,

It could be implemented as a single function, but with one requirement
that it should be maintained by Emacs developers.

Example:

(defun conservative-mode (&optional version)
  (interactive)

  (when (or (not version) (equal version "21.4"))
    ;; Restore old key bindings
    (define-key isearch-mode-map "\C-f" 'isearch-other-control-char)
    (define-key isearch-mode-map "\C-b" 'isearch-other-control-char))

    ...)

This really looks like the `Antinews' node of the Emacs manual :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> Karl Fogel <kfogel@floss.red-bean.com> writes:
> > Miles Bader <miles@gnu.org> writes:

> >> It's a shame, because it would be nice to use more "normal"
> >> bindings in isearch to do "isearchey variants", but it's probably
> >> necessary to be pretty conservative.
> >
> > In this case, I wonder if we're not being overly conservative.
> 
> Here is an idea: to create a special mode, say, conservative-mode,
> where default values and key bindings will never change from version
> to version.  Users upset by constant changes will set it once and
> for all in own .emacs and will not worry about further changes.
> Users who don't set this mode (as well as novices who have no
> preferences) will be ready for changes, and Emacs development will
> not be restricted by care for backward compatibility anymore.  So
> everyone will be happy.

That mode is already available: it is called "stop updating your
Emacs".  There is no need to provide it explicitly.  Our discussions
here are not for maintaining the old state: they are for striking a
balance between interfaces proven over time and new ideas.  A specific
mode that always provides the old things is redundant, as you can
always use an old Emacs.  The particular balance for conservative-mode
would still have to get agreed on.

I think we should rather strive to invest the time for these
considerations where they affect all users: all the people that are
discussing here are perfectly capable of configuring their Emacs to
behave like it did previously, with less effort than it takes them
leading those discussions.  They are still doing those discussions
because they care for more than just their personal preference.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-yank-char

[Karl Fogel]

I don't think a 'conservative-mode' is the direction to go.  Adding
more choices is not helpful.  Conservative-mode would be an endless
source of future decision avoidance.  For any given new feature or
binding, someone would say "Well, we can't figure out what to do, so
let's add the feature, but disable it in conservative-mode."  Is that
really what we want?

Anyone who knows enough about Emacs to know to look for and/or tweak a
hypothetical conservative-mode, knows enough to simply adjust their
isearch bindings directly.  The target audience for conservative mode
would not be helped in reality, because they'd probably never even
know the mode existed.

We should either do the new isearch bindings or not do them, instead
of growing Yet Another Choice Mechanism in Emacs.

-Karl

Re: isearch-yank-char

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> I think we should rather strive to invest the time for these
> considerations where they affect all users: all the people that are
> discussing here are perfectly capable of configuring their Emacs to
> behave like it did previously, with less effort than it takes them
> leading those discussions.  They are still doing those discussions
> because they care for more than just their personal preference.

It still would be good if Emacs developers provided the compatibility
code after every backward-incompatible change for maintainers of
external Emacs packages.  For example, the change in the interface
of the function `split-string' causes Emacs packages I'm maintaining
to fail.  I'm not against changes if they are for the better, but
I think that authors of these changes could write some kind of
function wrappers that will work the same for all Emacs versions
instead of forcing maintainers of external Emacs packages to invent
their own workarounds.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Karl Fogel]

This thread hasn't actually arrived at a decision yet; let's see if we
can reach one.  Proposal:

   1. Bind C-f in isearch-mode to 'isearch-yank-char'.
      (And while we're at it, fix isearch-yank-char's doc string to
      say "char" instead of "letter".)

   2. Bind C-b in isearch-mode to a function (name TBD) that loses
      one char from the search string.

I think this would be a good change on the whole, and would happy to
implement it.

If you agree or strongly object, please say so.  I'd like to make the
change soon, but don't want to do the work only to have it voted down,
of course.

The implementation details (such as the name of that new function)
aren't likely to be controversial, so let's just evaluate the proposal
on the basis of the user-visible change.  Details of the patch itself
can be worked out.

Retreats into the night, watching, waiting,...
-Karl

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> If you agree or strongly object, please say so.  I'd like to make the
> change soon, but don't want to do the work only to have it voted down,
> of course.

I don't understand what work are you speaking about.  It's trivial
5-line code.  Sorry, I've already done this yesterday ;-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Karl Fogel]

Juri Linkov <juri@jurta.org> writes:
> Karl Fogel <kfogel@floss.red-bean.com> writes:
> > If you agree or strongly object, please say so.  I'd like to make the
> > change soon, but don't want to do the work only to have it voted down,
> > of course.
> 
> I don't understand what work are you speaking about.  It's trivial
> 5-line code.  Sorry, I've already done this yesterday ;-)

Perhaps I can clarify, Juri:

The "work" I'm talking about is mostly not code.  It's testing and
checking for edge cases, searching for places where this should be
documented, writing that documentation, etc.  All this will take much
more effort than the code itself (though not a huge amount of effort
in absolute terms, of course).

Since you have not posted your patch, this mailing list has no way of
reviewing it.  However, there are very few truly 5-line patches to add
new functionality -- bugfixes, yes, but not user-visible new features.

-Karl

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> The "work" I'm talking about is mostly not code.  It's testing and
> checking for edge cases, searching for places where this should be
> documented, writing that documentation, etc.  All this will take much
> more effort than the code itself (though not a huge amount of effort
> in absolute terms, of course).

Since Richard suggested to try it, all developers can test it now,
not only you.  But it's too early to change documentation, because
if most developers will find it too inconvenient or confusing, it
might be reverted.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> Since Richard suggested to try it, all developers can test it now,
> not only you.

I like it a lot.  Let's keep it!

-- 
Romain Francoise <romain@orebokech.com> | Wait, stop, wait just hold on
it's a miracle -- http://orebokech.com/ | a minute.

Re: isearch-yank-char

[Karl Fogel]

Juri Linkov <juri@jurta.org> writes:
> Since Richard suggested to try it, all developers can test it now,
> not only you.  But it's too early to change documentation, because
> if most developers will find it too inconvenient or confusing, it
> might be reverted.

I'm confused -- I haven't actually seen this patch you're talking
about.  Did you post it and I just missed it?  (All the developers
need to be testing the same patch, for the testing to be useful.)

-Karl

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> I'm confused -- I haven't actually seen this patch you're talking
> about.  Did you post it and I just missed it?  (All the developers
> need to be testing the same patch, for the testing to be useful.)

The current implementation of C-b is:

(defun isearch-del-char ()
  "Discard last character and move point back.
If there is no previous character, just beep."
  (interactive)
  (if (equal isearch-string "")
      (ding)
    (setq isearch-string (substring isearch-string 0 -1)
          isearch-message (mapconcat 'isearch-text-char-description
                                     isearch-string "")))
  (isearch-search-and-update))

But you can change it if you find a better solution.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Karl Fogel]

Juri Linkov <juri@jurta.org> writes:
> The current implementation of C-b is:
> 
> (defun isearch-del-char ()
>   "Discard last character and move point back.
> If there is no previous character, just beep."
>   (interactive)
>   (if (equal isearch-string "")
>       (ding)
>     (setq isearch-string (substring isearch-string 0 -1)
>           isearch-message (mapconcat 'isearch-text-char-description
>                                      isearch-string "")))
>   (isearch-search-and-update))

Thanks!  I'll try it out.

Is this your full patch?  If there's more, post it & I'll test with
that (i.e., including the keybindings and anything else).

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> Thanks!  I'll try it out.
>
> Is this your full patch?  If there's more, post it & I'll test with
> that (i.e., including the keybindings and anything else).

The full patch is below:

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.226
retrieving revision 1.227
diff -c -r1.226 -r1.227
*** lisp/isearch.el	4 Mar 2004 16:54:08 -0000	1.226
--- lisp/isearch.el	29 Apr 2004 15:28:55 -0000	1.227
***************
*** 294,300 ****
      (define-key map " " 'isearch-whitespace-chars)
      (define-key map [?\S-\ ] 'isearch-whitespace-chars)
  
!     (define-key map "\C-w" 'isearch-yank-word-or-char)
      (define-key map "\C-y" 'isearch-yank-line)
  
      ;; Define keys for regexp chars * ? |.
--- 294,302 ----
      (define-key map " " 'isearch-whitespace-chars)
      (define-key map [?\S-\ ] 'isearch-whitespace-chars)
  
!     (define-key map "\C-b" 'isearch-del-char)
!     (define-key map "\C-f" 'isearch-yank-char)
!     (define-key map "\C-w" 'isearch-yank-word)
      (define-key map "\C-y" 'isearch-yank-line)
  
      ;; Define keys for regexp chars * ? |.
***************
*** 448,459 ****
  As you type characters, they add to the search string and are found.
  The following non-printing keys are bound in `isearch-mode-map'.
  
! Type \\[isearch-delete-char] to cancel characters from end of search string.
  Type \\[isearch-exit] to exit, leaving point at location found.
  Type LFD (C-j) to match end of line.
  Type \\[isearch-repeat-forward] to search again forward,\
   \\[isearch-repeat-backward] to search again backward.
! Type \\[isearch-yank-word-or-char] to yank word from buffer onto end of search\
   string and search for it.
  Type \\[isearch-yank-line] to yank rest of line onto end of search string\
   and search for it.
--- 450,464 ----
  As you type characters, they add to the search string and are found.
  The following non-printing keys are bound in `isearch-mode-map'.
  
! Type \\[isearch-delete-char] to cancel last input item from end of search string.
! Type \\[isearch-del-char] to cancel last character from end of search string.
  Type \\[isearch-exit] to exit, leaving point at location found.
  Type LFD (C-j) to match end of line.
  Type \\[isearch-repeat-forward] to search again forward,\
   \\[isearch-repeat-backward] to search again backward.
! Type \\[isearch-yank-char] to yank character from buffer onto end of search\
!  string and search for it.
! Type \\[isearch-yank-word] to yank word from buffer onto end of search\
   string and search for it.
  Type \\[isearch-yank-line] to yank rest of line onto end of search string\
   and search for it.
***************
*** 486,492 ****
  you want to use.
  
  The above keys, bound in `isearch-mode-map', are often controlled by
!  options; do M-x apropos on search-.* to find them.
  Other control and meta characters terminate the search
   and are then executed normally (depending on `search-exit-option').
  Likewise for function keys and mouse button events.
--- 491,497 ----
  you want to use.
  
  The above keys, bound in `isearch-mode-map', are often controlled by
!  options; do \\[apropos] on search-.* to find them.
  Other control and meta characters terminate the search
   and are then executed normally (depending on `search-exit-option').
  Likewise for function keys and mouse button events.
***************
*** 789,795 ****
  \\[isearch-ring-retreat-edit] to replace the search string with the previous item in the search ring.
  \\[isearch-complete-edit] to complete the search string using the search ring.
  \\<isearch-mode-map>
! If first char entered is \\[isearch-yank-word-or-char], then do word search instead."
  
    ;; This code is very hairy for several reasons, explained in the code.
    ;; Mainly, isearch-mode must be terminated while editing and then restarted.
--- 794,800 ----
  \\[isearch-ring-retreat-edit] to replace the search string with the previous item in the search ring.
  \\[isearch-complete-edit] to complete the search string using the search ring.
  \\<isearch-mode-map>
! If first char entered is \\[isearch-yank-word], then do word search instead."
  
    ;; This code is very hairy for several reasons, explained in the code.
    ;; Mainly, isearch-mode must be terminated while editing and then restarted.
***************
*** 1053,1058 ****
--- 1058,1073 ----
      (isearch-pop-state))
    (isearch-update))
  
+ (defun isearch-del-char ()
+   "Discard last character and move point back.
+ If there is no previous character, just beep."
+   (interactive)
+   (if (equal isearch-string "")
+       (ding)
+     (setq isearch-string (substring isearch-string 0 -1)
+           isearch-message (mapconcat 'isearch-text-char-description
+                                      isearch-string "")))
+   (isearch-search-and-update))
  
  (defun isearch-yank-string (string)
    "Pull STRING into search string."
***************
*** 1114,1120 ****
       (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))))
  
--- 1129,1135 ----
       (buffer-substring-no-properties (point) (funcall jumpform)))))
  
  (defun isearch-yank-char ()
!   "Pull next character from buffer into search string."
    (interactive)
    (isearch-yank-internal (lambda () (forward-char 1) (point))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Karl Fogel]

Juri Linkov <juri@jurta.org> writes:
> Karl Fogel <kfogel@floss.red-bean.com> writes:
> > Thanks!  I'll try it out.
> >
> > Is this your full patch?  If there's more, post it & I'll test with
> > that (i.e., including the keybindings and anything else).
> 
> The full patch is below:

Interesting!  This patch goes further, and changes C-w back to
'isearch-yank-word' (instead of 'isearch-yank-word-or-char').

I'm not sure whether it's good or bad.  Just wanted to point out that
this patch implements something slightly different from the proposal I
made.  (Nothing wrong with implementing a different proposal, as long
as people know what it is.)

Thanks for posting, I'm sure I won't be the only one testing this.

-Karl


> Index: lisp/isearch.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
> retrieving revision 1.226
> retrieving revision 1.227
> diff -c -r1.226 -r1.227
> *** lisp/isearch.el	4 Mar 2004 16:54:08 -0000	1.226
> --- lisp/isearch.el	29 Apr 2004 15:28:55 -0000	1.227
> ***************
> *** 294,300 ****
>       (define-key map " " 'isearch-whitespace-chars)
>       (define-key map [?\S-\ ] 'isearch-whitespace-chars)
>   
> !     (define-key map "\C-w" 'isearch-yank-word-or-char)
>       (define-key map "\C-y" 'isearch-yank-line)
>   
>       ;; Define keys for regexp chars * ? |.
> --- 294,302 ----
>       (define-key map " " 'isearch-whitespace-chars)
>       (define-key map [?\S-\ ] 'isearch-whitespace-chars)
>   
> !     (define-key map "\C-b" 'isearch-del-char)
> !     (define-key map "\C-f" 'isearch-yank-char)
> !     (define-key map "\C-w" 'isearch-yank-word)
>       (define-key map "\C-y" 'isearch-yank-line)
>   
>       ;; Define keys for regexp chars * ? |.
> ***************
> *** 448,459 ****
>   As you type characters, they add to the search string and are found.
>   The following non-printing keys are bound in `isearch-mode-map'.
>   
> ! Type \\[isearch-delete-char] to cancel characters from end of search string.
>   Type \\[isearch-exit] to exit, leaving point at location found.
>   Type LFD (C-j) to match end of line.
>   Type \\[isearch-repeat-forward] to search again forward,\
>    \\[isearch-repeat-backward] to search again backward.
> ! Type \\[isearch-yank-word-or-char] to yank word from buffer onto end of search\
>    string and search for it.
>   Type \\[isearch-yank-line] to yank rest of line onto end of search string\
>    and search for it.
> --- 450,464 ----
>   As you type characters, they add to the search string and are found.
>   The following non-printing keys are bound in `isearch-mode-map'.
>   
> ! Type \\[isearch-delete-char] to cancel last input item from end of search string.
> ! Type \\[isearch-del-char] to cancel last character from end of search string.
>   Type \\[isearch-exit] to exit, leaving point at location found.
>   Type LFD (C-j) to match end of line.
>   Type \\[isearch-repeat-forward] to search again forward,\
>    \\[isearch-repeat-backward] to search again backward.
> ! Type \\[isearch-yank-char] to yank character from buffer onto end of search\
> !  string and search for it.
> ! Type \\[isearch-yank-word] to yank word from buffer onto end of search\
>    string and search for it.
>   Type \\[isearch-yank-line] to yank rest of line onto end of search string\
>    and search for it.
> ***************
> *** 486,492 ****
>   you want to use.
>   
>   The above keys, bound in `isearch-mode-map', are often controlled by
> !  options; do M-x apropos on search-.* to find them.
>   Other control and meta characters terminate the search
>    and are then executed normally (depending on `search-exit-option').
>   Likewise for function keys and mouse button events.
> --- 491,497 ----
>   you want to use.
>   
>   The above keys, bound in `isearch-mode-map', are often controlled by
> !  options; do \\[apropos] on search-.* to find them.
>   Other control and meta characters terminate the search
>    and are then executed normally (depending on `search-exit-option').
>   Likewise for function keys and mouse button events.
> ***************
> *** 789,795 ****
>   \\[isearch-ring-retreat-edit] to replace the search string with the previous item in the search ring.
>   \\[isearch-complete-edit] to complete the search string using the search ring.
>   \\<isearch-mode-map>
> ! If first char entered is \\[isearch-yank-word-or-char], then do word search instead."
>   
>     ;; This code is very hairy for several reasons, explained in the code.
>     ;; Mainly, isearch-mode must be terminated while editing and then restarted.
> --- 794,800 ----
>   \\[isearch-ring-retreat-edit] to replace the search string with the previous item in the search ring.
>   \\[isearch-complete-edit] to complete the search string using the search ring.
>   \\<isearch-mode-map>
> ! If first char entered is \\[isearch-yank-word], then do word search instead."
>   
>     ;; This code is very hairy for several reasons, explained in the code.
>     ;; Mainly, isearch-mode must be terminated while editing and then restarted.
> ***************
> *** 1053,1058 ****
> --- 1058,1073 ----
>       (isearch-pop-state))
>     (isearch-update))
>   
> + (defun isearch-del-char ()
> +   "Discard last character and move point back.
> + If there is no previous character, just beep."
> +   (interactive)
> +   (if (equal isearch-string "")
> +       (ding)
> +     (setq isearch-string (substring isearch-string 0 -1)
> +           isearch-message (mapconcat 'isearch-text-char-description
> +                                      isearch-string "")))
> +   (isearch-search-and-update))
>   
>   (defun isearch-yank-string (string)
>     "Pull STRING into search string."
> ***************
> *** 1114,1120 ****
>        (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))))
>   
> --- 1129,1135 ----
>        (buffer-substring-no-properties (point) (funcall jumpform)))))
>   
>   (defun isearch-yank-char ()
> !   "Pull next character from buffer into search string."
>     (interactive)
>     (isearch-yank-internal (lambda () (forward-char 1) (point))))
> 
> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

Re: isearch-yank-char

[Juri Linkov]

Karl Fogel <kfogel@floss.red-bean.com> writes:
> Interesting!  This patch goes further, and changes C-w back to
> 'isearch-yank-word' (instead of 'isearch-yank-word-or-char').

Yes, I think that when `isearch-yank-char' has a key binding,
it's better to change 'isearch-yank-word' to C-w to give the user
a choice between adding a word or a character into the search string.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Karl Fogel <kfogel@floss.red-bean.com> writes:
> > Interesting!  This patch goes further, and changes C-w back to
> > 'isearch-yank-word' (instead of 'isearch-yank-word-or-char').

I noticed this too -- and although I think the new C-f binding is a
great thing (and love C-b even more), I still think that often
isearch-yank-word-or-char does a better job than isearch-yank-word
in cases like the following [] is the cursor location:

        fun1((abc-def-ghi[]));
        fun2(xyz);

But I'm obviously biased here (as the one who suggested the new C-w
binding :-)

> 
> Yes, I think that when `isearch-yank-char' has a key binding,
> it's better to change 'isearch-yank-word' to C-w to give the user
> a choice between adding a word or a character into the search string.

The question is: What is a "word" ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: isearch-yank-char

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> isearch-yank-word-or-char does a better job than isearch-yank-word
> in cases like the following [] is the cursor location:
>
>         fun1((abc-def-ghi[]));
>         fun2(xyz);
>
> But I'm obviously biased here (as the one who suggested the new C-w
> binding :-)

The main inconvenience of isearch-yank-word-or-char is that its
advancing isearch point is too slow when the user wants to move
the point by words (where the "word" has the same meaning as
in forward-word), or the point is moved too far when the user
wants to search for a part of a word.  But OTOH sometimes calling
isearch-yank-word-or-char repeatedly may be better than switching
between isearch-yank-word and isearch-yank-char.

And I'm still worried that new C-f and C-b key bindings can
be too intrusive for people who expect that they exit isearch.
Especially since I tried now to use old Emacs motion keys
instead of arrow keys, it really seems that they can confuse
if they do something different than exiting isearch.

So given all this, here is another idea:

    (define-key isearch-mode-map "\C-w"    'isearch-yank-word)
    (define-key isearch-mode-map "\C-\M-w" 'isearch-yank-word-or-char)
    (define-key isearch-mode-map "\C-\M-b" 'isearch-del-char)
    (define-key isearch-mode-map "\C-\M-f" 'isearch-yank-char)

These are less probable keys to exit isearch.

And if the goal is to retain backward compatibility as much as possible,
then the following key bindings will satisfy this requirement:

    (define-key isearch-mode-map "\C-w"    'isearch-yank-word-or-char)
    (define-key isearch-mode-map "\M-w"    'isearch-yank-word)
    (define-key isearch-mode-map "\C-\M-w" 'isearch-del-char)
    (define-key isearch-mode-map "\C-\M-y" 'isearch-yank-char)

or

    (define-key isearch-mode-map "\C-w"    'isearch-yank-word-or-char)
    (define-key isearch-mode-map "\M-w"    'isearch-del-char)
    (define-key isearch-mode-map "\C-\M-w" 'isearch-yank-char)
    (define-key isearch-mode-map "\C-\M-y" 'isearch-yank-word)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Robert J. Chassell]

I have been using the proposed new key bindings for isearch.el

    (define-key map "\C-b" 'isearch-del-char)
    (define-key map "\C-f" 'isearch-yank-char)

I really like the commands but find it almost impossible to remember
to stop the isearch before moving forward or back by character.

Perhaps `Meta-Control' bindings would be better, as was suggested.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: isearch-yank-char

[Richard Stallman]

I don't want C-f in isearch to be changed without polling the users.

Re: isearch-yank-char

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> I don't want C-f in isearch to be changed without polling the users.

Ah, okay, that's a showstopper (at least temporarily) for this change.

Is there a pre-existing mechanism by which such polls are normally
conducted, or do we improvise every time?

-Karl

Re: isearch-yank-char

[Richard Stallman]

    Is there a pre-existing mechanism by which such polls are normally
    conducted, or do we improvise every time?

There is no specific mechanism.  We create a mailing list that drops
mail into a file, we publish a message asking users to say what they
prefer *and why*, and we wait.

Files with results from previous polls should be in /com/archive,
and these files usually start with the posting to announce the poll.
Looking at a few of those, it should be possible to get a good idea
of how to write the posting.  I'd like someone to draft the posting,
then I will edit it and post it.

Re: isearch-yank-char

[Alan Mackenzie]

On 29 Apr 2004, Karl Fogel wrote:

>This thread hasn't actually arrived at a decision yet; let's see if we
>can reach one.  Proposal:

>   1. Bind C-f in isearch-mode to 'isearch-yank-char'.
>      (And while we're at it, fix isearch-yank-char's doc string to
>      say "char" instead of "letter".)

Excellent idea!  Let's do it!

>   2. Bind C-b in isearch-mode to a function (name TBD) that loses
>      one char from the search string.

NOT SO FAST!  Tell me, where does point get left after a C-b?  Normally,
one character backwards.  No problem.  But....

Where does point get left in a regexp-search after C-b?  Suppose that the
last character entered into the regexp search string was a closing
parenthesis (or whatever) that caused the the regexp search to backtrack,
moving point to an earlier position?  I can think of several ideas for
handling this, e.g.:

(i) Point moves _forward_ to where it was before the ] was entered, i.e.
C-b works just like <del> in this case;  However, the search string might
just have been extended by several characters at once (with M-y).  This
looks like getting hairy;

(ii) C-b only works in normal (non-regexp) search;

(iii) C-b is disallowed in regexp-search for quirky characters like );

(iv) C-b is disallowed in regexp-search whenever it would cause point to
jump forward;

(v) Point is left where it was, and the currently highlighted "match" is
no longer a match at all;

(vi) C-b in such circumstances acts like M-e, leaving the user directly
editing the search string.

I think it would be a good idea to resolve this issue before implementing
a C-b.  I'm not sure whether I'd rather do without C-b here than have
some ugly inconsistency, even if that inconsistency only appears in
marginal circumstances.

>Retreats into the night, watching, waiting,...
>-Karl

-- 
Alan Mackenzie (Munich, Germany)

Re: isearch-yank-char

[Juri Linkov]

Alan Mackenzie <acm@muc.de> writes:
> I think it would be a good idea to resolve this issue before implementing
> a C-b.  I'm not sure whether I'd rather do without C-b here than have
> some ugly inconsistency, even if that inconsistency only appears in
> marginal circumstances.

Relying on existing isearch functions guarantees its consistency,
i.e. when a character is removed from the end of isearch-string,
and isearch state is updated by the standard isearch function,
it produces good results: its state is updated according to
isearch-string without backtracking.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-yank-char

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> >   2. Bind C-b in isearch-mode to a function (name TBD) that loses
> >      one char from the search string.
> 
> NOT SO FAST!  Tell me, where does point get left after a C-b?  Normally,
> one character backwards.  No problem.  But....
> 
> Where does point get left in a regexp-search after C-b?

An obvious implementation might be:  Act exactly like `M-e DEL RET'.

However that's no good because M-e _always_ moves forward, even if
the search string got shorter, and I think that would surprise many
people -- who will expect C-b to act sort of like DEL but without
removing large chunks like those added by C-w.

Another idea might be:

   (1) Save the current search-string ORIG-SEARCH-STRING, with
       length LEN.

   (2) Backtrack like DEL until the length of the search-string is
       <= LEN - 1 (if you had done a C-w, then that's probably right
       before you did it).

   (3) Now start searching forward (or backward, if C-r) again from
       the point you backed up to, for the first LEN - 1 characters
       of ORIG-SEARCH-STRING.

This makes the assumption that you're probably typing C-b because
the current search string is too long and doesn't match what you
want, and thus any search history that includes it should be
removed.

It reflects what many people probably already do manually when C-w
adds slightly too much text:  they hit DEL until the text added by
C-w is gone, and then retype all but the unwanted text character by
character.

Even when you don't use C-w, the above behavior is a convenient way
to skip back to the last point where you actually added search
text, without having to hit DEL a bunch of times to backtrack first
(I want to do this quite often).

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: isearch-yank-char

[Karl Fogel]

Alan Mackenzie <acm@muc.de> writes:
> Excellent idea!  Let's do it!

Great!

> >   2. Bind C-b in isearch-mode to a function (name TBD) that loses
> >      one char from the search string.
> 
> NOT SO FAST!  Tell me, where does point get left after a C-b?  Normally,
> one character backwards.  No problem.  But....

That's what I was thinking.  It would be "just as if" you hadn't typed
the character just dropped from the search string in the first place.

> Where does point get left in a regexp-search after C-b?  Suppose that the
> last character entered into the regexp search string was a closing
> parenthesis (or whatever) that caused the the regexp search to backtrack,
> moving point to an earlier position?  I can think of several ideas for
> handling this, e.g.:

Oooh.  Glad you asked -- hadn't even thought about isearch-*-regexp,
since I rarely use them.

> (i) Point moves _forward_ to where it was before the ] was entered, i.e.
> C-b works just like <del> in this case;  However, the search string might
> just have been extended by several characters at once (with M-y).  This
> looks like getting hairy;
>
> (ii) C-b only works in normal (non-regexp) search;
> 
> (iii) C-b is disallowed in regexp-search for quirky characters like );
> 
> (iv) C-b is disallowed in regexp-search whenever it would cause point to
> jump forward;
> 
> (v) Point is left where it was, and the currently highlighted "match" is
> no longer a match at all;
> 
> (vi) C-b in such circumstances acts like M-e, leaving the user directly
> editing the search string.
> 
> I think it would be a good idea to resolve this issue before implementing
> a C-b.  I'm not sure whether I'd rather do without C-b here than have
> some ugly inconsistency, even if that inconsistency only appears in
> marginal circumstances.

Yes, we should figure out the desired behavior first.

I think it should drop the last (regexp-quoted) character inserted
into the search string, for consistency, and then the search string
would behave as it normally would if that character (or characters, if
it got regexp-quoted) were dropped.

In other words, your option (i), which is to behave almost like <del>,
except remember that <del> actually drops "last unit added".  I.e.,
del after C-w drops a word, and after C-y can drop even more.  But C-b
would always drop a character, plus any regexp quoting that got added
to that character when it was brought into the search string.

I think to flesh this proposal out, we'd have to look more into how
<del> behaves currently in the isearch-*-regexp functions.  I haven't
had time to do that yet, so please don't take the above as much more
than hand-waving :-).

-Karl

Re: isearch-yank-char

[Kim F. Storm]

Karl Fogel <kfogel@floss.red-bean.com> writes:

> In this case, I wonder if we're not being overly conservative.
> 
> If people learn by experience that certain commands no longer exit
> isearch as before, and instead cause isearch to behave in new ways,
> this might be okay as long as the experiences aren't too painful.  And
> I think these wouldn't be terribly painful.  The benefits (very useful
> new functionality in isearch) are permanent, the costs are temporary
> and probably not large.

I agree.  Giving C-f and C-b (the suggested) special meaning in
isearch would be a great enhancement to isearch, that I think even the
users who currently use C-f and C-b to exit isearch will appreciate.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: isearch-yank-char

[Juri Linkov]

>> +    (define-key map "\C-f" 'isearch-yank-char)
>
> I think many bindings are available for isearch because in practice very
> few normal bindings are used to exit isearch.  But I do think C-f is one of
> those bindings that people use to exist isearch.

C-f and C-b are ideal key bindings for this functionality because
they cause changes only in the visual appearance: for users typing
C-f with the intention to move the point, isearch may look "sticky",
but there is no harm: the point still moves to the intended position
and users can continue editing by typing other keys to exit isearch!

BTW, I can't find a function name for deleting a character better than
`isearch-del-char', because the suitable name `isearch-delete-char' is
already used by another function which doesn't do what its function name
says (it discards last input item, not character).

-- 
Juri Linkov
http://www.jurta.org/emacs/