I-search: Clicking in minibuf during I-search fails.

I-search: Clicking in minibuf during I-search fails.

[amicitas]

I have run across what appears to be a bug in emacs-22.

When i start an i-search (normal or regex) and try to click in the
minibuffer the minibuf closes, the window is split and the *message*
buffer is displayed.  There are no new messages desplayed in
*messages*.

I have not seen this behavior with the mini buffer in any other cases
(such as replace).

I cannot find any mention of this type of behavior online.

GNU Emacs 22.1.1 (i486-pc-linux-gnu, GTK+ Version 2.12.0)
 of 2007-10-04 on palmer, modified by Ubuntu
(22.1-0ubuntu5)

Running on Ubuntu 7.10 (2.6.22-14.41)

RE: I-search: Clicking in minibuf during I-search fails.

[Drew Adams]

> I have run across what appears to be a bug in emacs-22.
>
> When i start an i-search (normal or regex) and try to click in the
> minibuffer the minibuf closes, the window is split and the *message*
> buffer is displayed.  There are no new messages desplayed in
> *messages*.
>
> I have not seen this behavior with the mini buffer in any other cases
> (such as replace).
>
> I cannot find any mention of this type of behavior online.
>
> GNU Emacs 22.1.1 (i486-pc-linux-gnu, GTK+ Version 2.12.0)
>  of 2007-10-04 on palmer, modified by Ubuntu
> (22.1-0ubuntu5)
>
> Running on Ubuntu 7.10 (2.6.22-14.41)

Isearch does not in fact use the minibuffer. It uses the echo area, which
occupies the same screen real estate.

Starting with Emacs 22, anytime you click in the echo area (not the
minibuffer), buffer *Messages* is displayed.

See the Isearch doc for how to interact with Isearch, including how to edit
a search string (which is presumably why you tried to click there).

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    When i start an i-search (normal or regex) and try to click in the
    minibuffer the minibuf closes, the window is split and the *message*
    buffer is displayed.  There are no new messages desplayed in
    *messages*.

It is a feature, a way to see the *Messages* buffer.

What did you expect it to do?

Re: I-search: Clicking in minibuf during I-search fails.

[amicitas]

Ok I see.  What I expected was to be able to edit the search string.
Especially since middle clicking in the echo area does do a paste.
I will go read the Isearch docs as you suggest and try to avoid
clicking the echo area.

Thank you very much for your clarification on this. Sorry about the
bogus bug report.

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

> Ok I see.  What I expected was to be able to edit the search string.
> Especially since middle clicking in the echo area does do a paste.
> I will go read the Isearch docs as you suggest and try to avoid
> clicking the echo area.

Thank you for your report.  Your request is reasonable.  It is natural to
expect that clicking in the echo area where the search string is visible
will allow editing this search string.  This behavior is easily
implementable with the following patch:

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.303
diff -c -r1.303 isearch.el
*** lisp/isearch.el	29 Aug 2007 05:28:05 -0000	1.303
--- lisp/isearch.el	10 Oct 2007 23:44:04 -0000
***************
*** 1738,1743 ****
--- 1738,1747 ----
                   (isearch-back-into-window (eq ab-bel 'above) isearch-point)
                 (goto-char isearch-point)))
             (isearch-update))
+ 	  ((window-minibuffer-p (posn-window (event-start main-event)))
+ 	   ;; Swallow the up-event.
+ 	   (read-event)
+ 	   (isearch-edit-string))
  	  (search-exit-option
  	   (let (window)
               (isearch-unread-key-sequence keylist)

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    Thank you for your report.  Your request is reasonable.  It is natural to
    expect that clicking in the echo area where the search string is visible
    will allow editing this search string.  This behavior is easily
    implementable with the following patch:

If he says it gives good results, please install it.

Thanks.

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

>     Thank you for your report.  Your request is reasonable.  It is natural to
>     expect that clicking in the echo area where the search string is visible
>     will allow editing this search string.  This behavior is easily
>     implementable with the following patch:
>
> If he says it gives good results, please install it.

Installed since he said it gives what he wants.  A reported problem is
not caused by this change.

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

Re: I-search: Clicking in minibuf during I-search fails.

[amicitas]

That works well. I will definitely use this patch since I have been
clicking in that echo area during searches for years (and always
wishing that it did something).

There is some unwanted behavior with this patch.
 - On initially clicking into the bar the cursor is at the end of the
string, when then clicking into the middle of the string, the
minibuffer to the left of the cursor position is highlighted, and
therefore copied.  This would prevent me from say pasting into the
middle of a search string using the mouse.  There is no problem
however using the keyboard to navigate to the selected place in the
string and then pasting.

Thank you very much for the patch.  I really appreciate the help here.

Novimir Pablant

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

> That works well. I will definitely use this patch since I have been
> clicking in that echo area during searches for years (and always
> wishing that it did something).
>
> There is some unwanted behavior with this patch.
>  - On initially clicking into the bar the cursor is at the end of the
> string, when then clicking into the middle of the string, the
> minibuffer to the left of the cursor position is highlighted, and
> therefore copied.  This would prevent me from say pasting into the
> middle of a search string using the mouse.  There is no problem
> however using the keyboard to navigate to the selected place in the
> string and then pasting.

Actually this bug is not caused by my patch, but it exists in CVS.
It can be reproduced by typing `C-s string M-e' or `C-s RET',
and clicking mouse-1 in the minibuffer.  This makes the selection on
the minibuffer prompt instead of putting point to a different place.

This bug is caused by the hack in `isearch-edit-string' that uses

    (let ((cursor-in-echo-area t))
         (read-event))

before reading the search string in the minibuffer with
`read-from-minibuffer'.  When clicking mouse-1 in `read-event'
above, it incorrectly handles the mouse click.

This hack is used to start reading words after `C-s RET C-w' for word
search.  A simpler solution I think would be to bind `C-w' in
minibuffer-local-isearch-map to change the search type after typing
C-w in the minibuffer that read the search string, but it seems
it can't change the prompt from "I-search:" to "Word I-search:"
when the prompt is already displayed by read-from-minibuffer.

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    This bug is caused by the hack in `isearch-edit-string' that uses

	(let ((cursor-in-echo-area t))
	     (read-event))

    before reading the search string in the minibuffer with
    `read-from-minibuffer'.  When clicking mouse-1 in `read-event'
    above, it incorrectly handles the mouse click.

Why does this code handle the mouse-click at all?
It ought to just return the event, right?

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

>     This bug is caused by the hack in `isearch-edit-string' that uses
>
> 	(let ((cursor-in-echo-area t))
> 	     (read-event))
>
>     before reading the search string in the minibuffer with
>     `read-from-minibuffer'.  When clicking mouse-1 in `read-event'
>     above, it incorrectly handles the mouse click.
>
> Why does this code handle the mouse-click at all?
> It ought to just return the event, right?

It doesn't read the mouse button release event (mouse-1), so the mouse
release happens in the minibuffer after read-from-minibuffer activates it.
Thus, mouse-1 selects the region because read-from-minibuffer with the
pressed down-mouse-1 puts the mark to the beginning of the minibuffer
(before the prompt).

Below is the test case that emulates this problem in `isearch-edit-string':

(progn
  (message "Prompt: ")
  (let ((cursor-in-echo-area t))
    (read-event))
  (read-from-minibuffer "Prompt: "))

after evaluating you can try to press mouse-1 in the echo area,
and release it in the minibuffer.

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    It doesn't read the mouse button release event (mouse-1), so the mouse
    release happens in the minibuffer after read-from-minibuffer activates it.

I see.

It could detect that e is a down-event and reads the next event too,
then unreads both after.  Does that approach work?

If it does, we could make a subroutine to use instead of read-event,
which would take care of this, and would return a list of one or two
events.

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

>     It doesn't read the mouse button release event (mouse-1), so the mouse
>     release happens in the minibuffer after read-from-minibuffer activates it.
>
> I see.
>
> It could detect that e is a down-event and reads the next event too,
> then unreads both after.  Does that approach work?

It works, but there are still problems.  The recorded event has the
position of the beginning of the echo area, so after unreading this
event of clicking the button in the echo area, it puts point to the
beginning of the minibuffer before the prompt.

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    It works, but there are still problems.  The recorded event has the
    position of the beginning of the echo area,

Is that the wrong position?  If so, in what way is it wrong?

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

>     It works, but there are still problems.  The recorded event has the
>     position of the beginning of the echo area,
>
> Is that the wrong position?  If so, in what way is it wrong?

The beginning of the minibuffer is the wrong position to put point,
because the prompt is read-only, and to start editing the user needs to
move point to the editable area.  The right position is where the mouse
was clicked, or at least in the end of the minibuffer where point is
placed after calling isearch-edit-string.

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    The beginning of the minibuffer is the wrong position to put point,
    because the prompt is read-only, and to start editing the user needs to
    move point to the editable area.  The right position is where the mouse
    was clicked,

Ok, now I understand you.  Indeed, that is the right position.

So why does the event have the wrong position in it?

Re: I-search: Clicking in minibuf during I-search fails.

[Juri Linkov]

>     The beginning of the minibuffer is the wrong position to put point,
>     because the prompt is read-only, and to start editing the user needs to
>     move point to the editable area.  The right position is where the mouse
>     was clicked,
>
> Ok, now I understand you.  Indeed, that is the right position.
>
> So why does the event have the wrong position in it?

I guess this is because clicking mouse button with the code

(let ((cursor-in-echo-area t))
    (read-event))

always returns an event where the buffer position is 1.

PS: I already suggested trying an alternative solution that gets rid of
using `read-event', and binds C-w to a new command in the minibuffer
for editing the search string.

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

Re: I-search: Clicking in minibuf during I-search fails.

[Richard Stallman]

    > So why does the event have the wrong position in it?

    I guess this is because clicking mouse button with the code

    (let ((cursor-in-echo-area t))
	(read-event))

    always returns an event where the buffer position is 1.

What about the horizontal and vertical positions?  Are they correct?
If so, this code could find the character in the minibuffer that they
correspond to, and put that position into the event.  Does that fix it?

    PS: I already suggested trying an alternative solution that gets rid of
    using `read-event', and binds C-w to a new command in the minibuffer
    for editing the search string.

That approach might be a good one.  However, I expect we will have to
fix a few bugs before it fully works.  So I think that the other
approach is likely to be easier, and I recommend trying it first.