placing cursor at *start* of match in incremental search

placing cursor at *start* of match in incremental search

[Maciej Kalisiak]

When I'm doing incremental search using C-s, is there some variable I can tweak
to get Emacs to place the cursor at the *start* of the match, as opposed to the
end, as is the default?

-- 
Maciej Kalisiak | <mac at dgp.toronto.edu> | http://www.dgp.toronto.edu/~mac
PGP->finger|www; (0x39AC36F5) 9F BB 9E 11 F0 1E 5D 20  0B 31 3D 37 47 D0 67 C7

Re: placing cursor at *start* of match in incremental search

[Stefan Monnier <foo@acm.com>]

>>>>> "Maciej" == Maciej Kalisiak <mac@die.spammer.die.dgp.toronto.edu> writes:
> When I'm doing incremental search using C-s, is there some variable I can
> tweak to get Emacs to place the cursor at the *start* of the match, as
> opposed to the end, as is the default?

I think the simplest is to use C-r.


        Stefan

Re: placing cursor at *start* of match in incremental search

[Kevin Rodgers]

Maciej Kalisiak wrote:

> When I'm doing incremental search using C-s, is there some variable I can tweak
> to get Emacs to place the cursor at the *start* of the match, as opposed to the
> end, as is the default?


Do you mean like


C-s this is what I'm searching for C-r RET

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: placing cursor at *start* of match in incremental search

[Adrian Kubala]

mac@die.spammer.die.dgp.toronto.edu (Maciej Kalisiak) writes:

> When I'm doing incremental search using C-s, is there some variable
> I can tweak to get Emacs to place the cursor at the *start* of the
> match, as opposed to the end, as is the default?

Here's what I use:

;;; Isearch should always put point at the start of the match.
(defadvice isearch-exit (after my-goto-match-beginning activate)
  "Go to beginning of match."
  (when isearch-forward (goto-char isearch-other-end)))

Re: placing cursor at *start* of match in incremental search

[Greg Hill]

At 3:24 PM +0000 1/16/03, Maciej Kalisiak wrote:
>When I'm doing incremental search using C-s, is there some variable 
>I can tweak
>to get Emacs to place the cursor at the *start* of the match, as 
>opposed to the
>end, as is the default?

Put this in your .emacs:

(add-hook 'isearch-mode-end-hook
     (function (lambda () (goto-char (match-beginning 0)))))

--Greg

Re: placing cursor at *start* of match in incremental search

[David Robinow]

(Maciej Kalisiak) wrote in message news:<slrnb2djm9.9kl.mac@mac.dgp.toronto.edu>...
> When I'm doing incremental search using C-s, is there some variable I can tweak
> to get Emacs to place the cursor at the *start* of the match, as opposed to the
> end, as is the default?

It's not clear why you want to do this, but why not just type C-r ?

Re: placing cursor at *start* of match in incremental search

[Maciej Kalisiak]

* David Robinow <drobinow@yahoo.com>:
>  (Maciej Kalisiak) wrote in message news:<slrnb2djm9.9kl.mac@mac.dgp.toronto.edu>...
> > When I'm doing incremental search using C-s, is there some variable I can
> > tweak to get Emacs to place the cursor at the *start* of the match, as
> > opposed to the end, as is the default?
>  
>  It's not clear why you want to do this, but why not just type C-r ?

Oh, to save a keystroke, of course.  From past experience I have observed that
every time I do C-s and find what I was looking for, I always end up moving the
cursor to the match beginning.  Hence I want that behaviour automatically by
default.

-- 
Maciej Kalisiak | <mac@dgp.toronto.edu> | http://www.dgp.toronto.edu/~mac [McQ]
PGP->finger|www; (0x39AC36F5) 9F BB 9E 11 F0 1E 5D 20  0B 31 3D 37 47 D0 67 C7
GE/CS d- s++:+ a- C++(+++) ULAI++ P+++ L+++ E+++ W++ N- o? K? !w--- O- M- V--
PS PE+ Y+ PGP+ t+ 5 !X-- R+ tv-- b+>++++ DI+ G+ e>+++>++++(*) h--- r+++ y? 

Re: placing cursor at *start* of match in incremental search

[Maciej Kalisiak]

* Greg Hill <ghill@synergymicro.com>:
>  Put this in your .emacs:
>  
>  (add-hook 'isearch-mode-end-hook
>       (function (lambda () (goto-char (match-beginning 0)))))

Ah, perfect!  Thanks.

Is this approach better, or Adrian's method of using "advice"? (I have only
limited elisp knowledge, and not much experience with advice functions)

-- 
Maciej Kalisiak | <mac@dgp.toronto.edu> | http://www.dgp.toronto.edu/~mac [McQ]
PGP->finger|www; (0x39AC36F5) 9F BB 9E 11 F0 1E 5D 20  0B 31 3D 37 47 D0 67 C7
GE/CS d- s++:+ a- C++(+++) ULAI++ P+++ L+++ E+++ W++ N- o? K? !w--- O- M- V--
PS PE+ Y+ PGP+ t+ 5 !X-- R+ tv-- b+>++++ DI+ G+ e>+++>++++(*) h--- r+++ y? 

Re: placing cursor at *start* of match in incremental search

[Greg Hill]

At 6:35 PM +0000 1/17/03, Maciej Kalisiak wrote:
>* Greg Hill <ghill@synergymicro.com>:
>>   Put this in your .emacs:
>> 
>>   (add-hook 'isearch-mode-end-hook
>>        (function (lambda () (goto-char (match-beginning 0)))))
>
>Ah, perfect!  Thanks.
>
>Is this approach better, or Adrian's method of using "advice"? (I have only
>limited elisp knowledge, and not much experience with advice functions)

A question like that could probably start a "religious war," which 
I'll stay out of.

--Greg

Re: placing cursor at *start* of match in incremental search

[* Tong *]

Maciej Kalisiak <mac@die.spammer.die.dgp.toronto.edu> writes:

> > > When I'm doing incremental search using C-s, is there some variable I can
> > > tweak to get Emacs to place the cursor at the *start* of the match, as
> > > opposed to the end, as is the default?
> >  
> >  It's not clear why you want to do this, but why not just type C-r ?
> 
> Oh, to save a keystroke, of course.  From past experience I have observed that
> every time I do C-s and find what I was looking for, I always end up moving the
> cursor to the match beginning.  Hence I want that behaviour automatically by
> default.

second to that. I wish I know how to twist it also.

-- 
Tong (remove underscore(s) to reply)
  *niX Power Tools Project: http://xpt.sourceforge.net/
  - All free contribution & collection

Re: placing cursor at *start* of match in incremental search

[Kevin Rodgers]

Maciej Kalisiak wrote:

> * Greg Hill <ghill@synergymicro.com>:
> 
>> Put this in your .emacs:
>> 
>> (add-hook 'isearch-mode-end-hook
>>      (function (lambda () (goto-char (match-beginning 0)))))
>>
> 
> Ah, perfect!  Thanks.
> 
> Is this approach better, or Adrian's method of using "advice"? (I have only
> limited elisp knowledge, and not much experience with advice functions)


I'm a big fan of defadvice, but I think it should only be used when there's no

other way to get the behavior you want.  If there's a hook available, use that;
and better yet, if there's a user option, use that.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: placing cursor at *start* of match in incremental search

[Maciej Kalisiak]

* Kevin Rodgers <kevin.rodgers@ihs.com>:
>  Maciej Kalisiak wrote:
>  
> > * Greg Hill <ghill@synergymicro.com>:
> > 
> >> Put this in your .emacs:
> >> 
> >> (add-hook 'isearch-mode-end-hook
> >>      (function (lambda () (goto-char (match-beginning 0)))))
> >>
> > 
> > Ah, perfect!  Thanks.
> > 
> > Is this approach better, or Adrian's method of using "advice"? (I have only
> > limited elisp knowledge, and not much experience with advice functions)
>  
>  
>  I'm a big fan of defadvice, but I think it should only be used when there's
>  no other way to get the behavior you want.  If there's a hook available, use
>  that; and better yet, if there's a user option, use that.

Played around a bit with both approaches, and it seems the "defadvice" method
is the better of the two, at least as presented so far.  The probelm with the
hook method, as shown above, is that it breaks the behaviour of an isearch
abortion.  Usually, on a C-g the cursor goes back to where it was when C-s was
pressed; with the hook form above it is placed at the first character of the
match... seems the hook is called on *all* methods of ending an isearch.  OTOH,
the defadvice form works properly.

Can the hook form be somehow coaxed to do abortion properly?

-- 
Maciej Kalisiak | <mac@dgp.toronto.edu> | http://www.dgp.toronto.edu/~mac [McQ]
PGP->finger|www; (0x39AC36F5) 9F BB 9E 11 F0 1E 5D 20  0B 31 3D 37 47 D0 67 C7

Re: placing cursor at *start* of match in incremental search

[Kevin Rodgers]

Maciej Kalisiak wrote:

> Played around a bit with both approaches, and it seems the "defadvice" method
> is the better of the two, at least as presented so far.  The probelm with the
> hook method, as shown above, is that it breaks the behaviour of an isearch
> abortion.  Usually, on a C-g the cursor goes back to where it was when C-s was
> pressed; with the hook form above it is placed at the first character of the
> match... seems the hook is called on *all* methods of ending an isearch.  OTOH,
> the defadvice form works properly.
> 
> Can the hook form be somehow coaxed to do abortion properly?


Use the source:

`C-g' is bound in isearch-mode-map to isearch-abort, which sets
isearch-success to nil before calling isearch-done, which is what runs
isearch-mode-end-hook.  So you could check isearch-success before
calling goto-char in the hook function.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: placing cursor at *start* of match in incremental search

[Greg Hill]

At 10:22 AM -0700 1/22/03, Kevin Rodgers wrote:
<snip>
>Use the source:


Good "advice" :) for those of us who can make heads or tails of it. 
But it's probably a bit much to ask of someone like Maciej who isn't 
really a lisp programmer.


>`C-g' is bound in isearch-mode-map to isearch-abort, which sets
>isearch-success to nil before calling isearch-done, which is what runs
>isearch-mode-end-hook.  So you could check isearch-success before
>calling goto-char in the hook function.

i.e., for someone who isn't a lisp programmer:

    (add-hook 'isearch-mode-end-hook
          (function (lambda ()
               (if isearch-success (goto-char (match-beginning 0))))))

Seems to work.  Thanks, Kevin.

Incidentally, Maciej, when you are experimenting with different 
versions of anonymous (lambda) functions as hooks in the same Emacs 
session, don't forget to explicitly remove any old versions of the 
function from the hook variable, or you will end up executing more 
that one version and wondering why the new one you just added doesn't 
seem to work the way it should.

For example, after

    (add-hook 'isearch-mode-end-hook
          (function (lambda ()
               (goto-char (match-beginning 0)))))

you should either

    (setq isearch-mode-end-hook nil)

which will remove ALL functions from that hook, or

    (remove-hook 'isearch-mode-end-hook
          (function (lambda ()
               (goto-char (match-beginning 0)))))

which will specifically remove just that one function, before you

    (add-hook 'isearch-mode-end-hook
          (function (lambda ()
               (if isearch-success (goto-char (match-beginning 0))))))

In case you didn't know, the *scratch* buffer, which uses 
lisp-interaction-mode, is the right place to do stuff like that.  I 
don't remember what source I used to learn about how to use 
lisp-interaction mode.  The versions I have of the GNU Emacs Manual 
and the GNU Emacs Lisp Reference Manual don't seem to be much help; 
but there really isn't much to it.  Perhaps someone else can point 
you to a geed tutorial.

--Greg

Re: placing cursor at *start* of match in incremental search

[Stefan Monnier <foo@acm.com>]

>>>>> "Greg" == Greg Hill <ghill@synergymicro.com> writes:
> Incidentally, Maciej, when you are experimenting with different versions of
> anonymous (lambda) functions as hooks in the same Emacs session, don't
> forget to explicitly remove any old versions of the function from the hook
> variable, or you will end up executing more that one version and wondering
> why the new one you just added doesn't seem to work the way it should.

To avoid the problem, I recommend to use a non-anonymous function:

  (defun my-i-s-e-h ()
    (blabla))
  (add-hook 'isearch-mode-end-hook 'my-i-s-e-h)

> In case you didn't know, the *scratch* buffer, which uses
> lisp-interaction-mode, is the right place to do stuff like that.

I think the .emacs file is better since that's where you'll want the
code to be in the end anyway.
Otherwise M-x ielm gives you another interface which some people find
more friendly than lisp-interaction-mode.


        Stefan

Re: placing cursor at *start* of match in incremental search

[Kevin Rodgers]

Greg Hill wrote:

>    (add-hook 'isearch-mode-end-hook
>          (function (lambda ()
>               (if isearch-success (goto-char (match-beginning 0))))))


I think you could replace (match-beginning 0) with isearch-other-end,
although that will also leave the cursor at the end of a successful
backward incremental search (instead of at the beginning).

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: placing cursor at *start* of match in incremental search

[Ittay Dror]

On Wed, 2003-01-22 at 16:41, Maciej Kalisiak wrote:
> Played around a bit with both approaches, and it seems the "defadvice" method
> is the better of the two, at least as presented so far.  The probelm with the
> hook method, as shown above, is that it breaks the behaviour of an isearch
> abortion.  Usually, on a C-g the cursor goes back to where it was when C-s was
> pressed; with the hook form above it is placed at the first character of the
> match... seems the hook is called on *all* methods of ending an isearch.  OTOH,
> the defadvice form works properly.
> 
> Can the hook form be somehow coaxed to do abortion properly?

here are my 2c:
(defadvice isearch-search (after put-cursor-at-beginning last act)
  (if isearch-success (goto-char (match-beginning 0))))

(defadvice isearch-repeat (before put-cursor-at-end first act)
  (goto-char  (match-end 0)))

this will put the cursor at the start of the search *while* searching.
seems less confusing to me.

-- 
===================================
Ittay Dror (ittay@qlusters.com)
User Space Team, R&D
Qlusters Inc.
+972-3-6081976 Fax: +972-3-6081841

Re: placing cursor at *start* of match in incremental search

[Maciej Kalisiak]

On Thu, Jan 23, 2003 at 07:58:46AM +0200, Ittay Dror wrote:
> here are my 2c:
> (defadvice isearch-search (after put-cursor-at-beginning last act)
>   (if isearch-success (goto-char (match-beginning 0))))
> 
> (defadvice isearch-repeat (before put-cursor-at-end first act)
>   (goto-char  (match-end 0)))
> 
> this will put the cursor at the start of the search *while* searching.
> seems less confusing to me.

Very cool!  This is now my favourite. :) Although, is there any way to prevent
the flashing when typing in more letters?  As I add additional characters to
the search, after each one all the current matches are erased, and after a
small, but quite visible delay, the new ones show up... the default isearch
doesn't do that.  Minor point, but I might as well ask since I'm getting such
excellent suggestions. :)

-- 
"If A equals success, then the formula is: A=X+Y+Z. X is work. 
 Y is play. Z is keep your mouth shut." 
 					-- Albert Einstein

Re: placing cursor at *start* of match in incremental search

[Ittay Dror]

On Thu, 2003-01-23 at 15:58, Maciej Kalisiak wrote:
> On Thu, Jan 23, 2003 at 07:58:46AM +0200, Ittay Dror wrote:
> > here are my 2c:
> > (defadvice isearch-search (after put-cursor-at-beginning last act)
> >   (if isearch-success (goto-char (match-beginning 0))))
> > 
> > (defadvice isearch-repeat (before put-cursor-at-end first act)
> >   (goto-char  (match-end 0)))
> > 
> > this will put the cursor at the start of the search *while* searching.
> > seems less confusing to me.
> 
> Very cool!  This is now my favourite. :) Although, is there any way to prevent
> the flashing when typing in more letters?  As I add additional characters to
> the search, after each one all the current matches are erased, and after a
> small, but quite visible delay, the new ones show up... the default isearch
> doesn't do that.  Minor point, but I might as well ask since I'm getting such
> excellent suggestions. :)
this is the behavior of isearch even before my hack is applied. it is
because the highlighting of matches is done in a 'lazy' loop. try
setting isearch-lazy-highlight-initial-delay to 0 and increasing
isearch-lazy-highlight-max-at-a-time (you can also customize-group
isearch-lazy-highlight)

hope it helps,
ittay
-- 
===================================
Ittay Dror (ittay@qlusters.com)
User Space Team, R&D
Qlusters Inc.
+972-3-6081976 Fax: +972-3-6081841

Re: placing cursor at *start* of match in incremental search

[Ittay Dror]

On Sun, 2003-01-26 at 08:28, Ittay Dror wrote:
> On Thu, 2003-01-23 at 15:58, Maciej Kalisiak wrote:
> > On Thu, Jan 23, 2003 at 07:58:46AM +0200, Ittay Dror wrote:
> > > here are my 2c:
> > > (defadvice isearch-search (after put-cursor-at-beginning last act)
> > >   (if isearch-success (goto-char (match-beginning 0))))
> > > 
> > > (defadvice isearch-repeat (before put-cursor-at-end first act)
> > >   (goto-char  (match-end 0)))
> > > 
> > > this will put the cursor at the start of the search *while* searching.
> > > seems less confusing to me.
> > 
> > Very cool!  This is now my favourite. :) Although, is there any way to prevent
> > the flashing when typing in more letters?  As I add additional characters to
> > the search, after each one all the current matches are erased, and after a
> > small, but quite visible delay, the new ones show up... the default isearch
> > doesn't do that.  Minor point, but I might as well ask since I'm getting such
> > excellent suggestions. :)
> this is the behavior of isearch even before my hack is applied. it is
> because the highlighting of matches is done in a 'lazy' loop. try
> setting isearch-lazy-highlight-initial-delay to 0 and increasing
> isearch-lazy-highlight-max-at-a-time (you can also customize-group
> isearch-lazy-highlight)

well, after some investigation. the problem is that the lazy highlight
loop deletes the old overlays (from before the last key press) before
creating a new highlight loop. this can be fixed somewhat by saving the
old overlays and deleting them after creating the new one. although,
this will create an instance where the old overlays are still visible.
another slowdown is that the overlays creation is done inside a loop
that searches the buffer. i think that if the mattches will be
accumulated inside the loop and only after it is finished will the
overlays be created it will speedup things.

if/when i have time i'll do it.

ittay
> 
> hope it helps,
> ittay
-- 
===================================
Ittay Dror (ittay@qlusters.com)
User Space Team, R&D
Qlusters Inc.
+972-3-6081976 Fax: +972-3-6081841

Re: placing cursor at *start* of match in incremental search

[Ittay Dror]

On Sun, 2003-01-26 at 11:47, Ittay Dror wrote:
> On Sun, 2003-01-26 at 08:28, Ittay Dror wrote:
> > On Thu, 2003-01-23 at 15:58, Maciej Kalisiak wrote:
> > > On Thu, Jan 23, 2003 at 07:58:46AM +0200, Ittay Dror wrote:
> > > > here are my 2c:
> > > > (defadvice isearch-search (after put-cursor-at-beginning last act)
> > > >   (if isearch-success (goto-char (match-beginning 0))))
> > > > 
> > > > (defadvice isearch-repeat (before put-cursor-at-end first act)
> > > >   (goto-char  (match-end 0)))
> > > > 
> > > > this will put the cursor at the start of the search *while* searching.
> > > > seems less confusing to me.
> > > 
well i found a bug there. the problem is that the match changes between
the calls to the two functions (probably the lazy highlight loop). so
here is the (very simple) fix:
(defvar isearch-match-end "Match end of current isearch" 0)

(defadvice isearch-search (after put-cursor-at-beginning last act)
  (if isearch-success
	  (progn
		(setq isearch-match-end (point))
		(goto-char (match-beginning 0))
		)))

(defadvice isearch-repeat (before put-cursor-at-end first act)
  (goto-char  isearch-match-end))

-- 
===================================
Ittay Dror (ittay@qlusters.com)
User Space Team, R&D
Qlusters Inc.
+972-3-6081976 Fax: +972-3-6081841