Isearch in dired

Isearch in dired

[Richard M. Stallman]

It would be useful for isearch in a dired buffer to match only file
names by default.  I think this would be a good feature -- if we can
come up with a natural way to request ordinary search of the entire
buffer.

Can anyone think of one?

Re: Isearch in dired

[Juri Linkov]

> It would be useful for isearch in a dired buffer to match only file
> names by default.  I think this would be a good feature -- if we can
> come up with a natural way to request ordinary search of the entire
> buffer.
>
> Can anyone think of one?

I think the most convenient default behavior would be context-dependent,
i.e. match only file names when point is on the file name column - where
point stays most of the time: after opening a dired buffer and through
dired operations including navigation.  So it would be natural to do the
same for isearch - never let point leave the file name column.

To search of the entire buffer, the user can move point outside the
file name column.  Since this need is very rare, there's no hassle.

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

Re: Isearch in dired

[Lennart Borgman]

On Sat, Nov 8, 2008 at 11:59 AM, Juri Linkov <juri@jurta.org> wrote:
>> It would be useful for isearch in a dired buffer to match only file
>> names by default.  I think this would be a good feature -- if we can
>> come up with a natural way to request ordinary search of the entire
>> buffer.
>>
>> Can anyone think of one?
>
> I think the most convenient default behavior would be context-dependent,
> i.e. match only file names when point is on the file name column - where
> point stays most of the time: after opening a dired buffer and through
> dired operations including navigation.  So it would be natural to do the
> same for isearch - never let point leave the file name column.
>
> To search of the entire buffer, the user can move point outside the
> file name column.  Since this need is very rare, there's no hassle.

It is a nice idea if you know what is going on, but how do you tell
the user what is going on? Changing the prompt is one possibility, but
it is maybe not enough?

(This reminds me again of that the search part of the menus in Emacs
should include all search commands that comes with Emacs. And there
should be an easy way to add other search commands there too.)

Re: Isearch in dired

[Alan Mackenzie]

On Sat, Nov 08, 2008 at 12:33:34PM +0100, Lennart Borgman wrote:
> On Sat, Nov 8, 2008 at 11:59 AM, Juri Linkov <juri@jurta.org> wrote:
> >> It would be useful for isearch in a dired buffer to match only file
> >> names by default.  I think this would be a good feature -- if we can
> >> come up with a natural way to request ordinary search of the entire
> >> buffer.

> >> Can anyone think of one?

> > I think the most convenient default behavior would be context-dependent,
> > i.e. match only file names when point is on the file name column - where
> > point stays most of the time: after opening a dired buffer and through
> > dired operations including navigation.  So it would be natural to do the
> > same for isearch - never let point leave the file name column.

> > To search of the entire buffer, the user can move point outside the
> > file name column.  Since this need is very rare, there's no hassle.

..., except you'd have to move point into that column to start.

> It is a nice idea if you know what is going on, but how do you tell
> the user what is going on? Changing the prompt is one possibility, but
> it is maybe not enough?

How about highlighting the file column (or lowlighting the rest of the
window) when you press C-\(M-\)?[rs]?

> (This reminds me again of that the search part of the menus in Emacs
> should include all search commands that comes with Emacs. And there
> should be an easy way to add other search commands there too.)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Isearch in dired

[Lennart Borgman]

On Sat, Nov 8, 2008 at 1:23 PM, Alan Mackenzie <acm@muc.de> wrote:
>> It is a nice idea if you know what is going on, but how do you tell
>> the user what is going on? Changing the prompt is one possibility, but
>> it is maybe not enough?
>
> How about highlighting the file column (or lowlighting the rest of the
> window) when you press C-\(M-\)?[rs]?

Sounds like a good idea.

Re: Isearch in dired

[Juri Linkov]

>> > I think the most convenient default behavior would be context-dependent,
>> > i.e. match only file names when point is on the file name column - where
>> > point stays most of the time: after opening a dired buffer and through
>> > dired operations including navigation.  So it would be natural to do the
>> > same for isearch - never let point leave the file name column.
>
>> > To search of the entire buffer, the user can move point outside the
>> > file name column.  Since this need is very rare, there's no hassle.
>
> ..., except you'd have to move point into that column to start.

Most of the time point already is on file names, and moving it away is
very easy.

>> It is a nice idea if you know what is going on, but how do you tell
>> the user what is going on? Changing the prompt is one possibility, but
>> it is maybe not enough?

Changing the prompt is not a bad idea.  We can display the prompt as e.g.

    Filename I-search:

> How about highlighting the file column (or lowlighting the rest of the
> window) when you press C-\(M-\)?[rs]?

This will cause almost the same horrible visual effect as typing `C-M-s .'
;-)

>> (This reminds me again of that the search part of the menus in Emacs
>> should include all search commands that comes with Emacs. And there
>> should be an easy way to add other search commands there too.)

Maybe in a dired buffer the `Search' menu should duplicate search-related
menu items from `Operate' and `Immediate' submenus.

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

Re: Isearch in dired

[Richard M. Stallman]

    I think the most convenient default behavior would be context-dependent,
    i.e. match only file names when point is on the file name column - where
    point stays most of the time: after opening a dired buffer and through
    dired operations including navigation.  So it would be natural to do the
    same for isearch - never let point leave the file name column.

    To search of the entire buffer, the user can move point outside the
    file name column.  Since this need is very rare, there's no hassle.

That sounds quite convenient.  If the prompt says "File name Isearch"
when appropriate, people will understand what's going on.

Re: Isearch in dired

[Juri Linkov]

>     I think the most convenient default behavior would be context-dependent,
>     i.e. match only file names when point is on the file name column - where
>     point stays most of the time: after opening a dired buffer and through
>     dired operations including navigation.  So it would be natural to do the
>     same for isearch - never let point leave the file name column.
>
>     To search of the entire buffer, the user can move point outside the
>     file name column.  Since this need is very rare, there's no hassle.
>
> That sounds quite convenient.  If the prompt says "File name Isearch"
> when appropriate, people will understand what's going on.

While this change is still under discussion, the patch below at least
implements the prompt that says "File name Isearch".  It adds two new
variables isearch-message-prefix and isearch-message-suffix to insert
search-specific text before and after the stardard isearch messages.

However, I think that one word would be better to understand in
the isearch message, because other indications are all one word:
"failing", "wrapped", "regexp".  Please compare which is more readble:

  Failing wrapped File name regexp I-search:

  Failing wrapped Filename regexp I-search:

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.180
diff -c -r1.180 dired-aux.el
*** lisp/dired-aux.el	22 Oct 2008 20:21:21 -0000	1.180
--- lisp/dired-aux.el	9 Nov 2008 21:54:14 -0000
***************
*** 2355,2368 ****
  (defun dired-isearch-filenames ()
    "Search for a string using Isearch only in file names in the Dired buffer."
    (interactive)
!   (let ((dired-isearch-filenames t))
      (isearch-forward)))
  
  ;;;###autoload
  (defun dired-isearch-filenames-regexp ()
    "Search for a regexp using Isearch only in file names in the Dired buffer."
    (interactive)
!   (let ((dired-isearch-filenames t))
      (isearch-forward-regexp)))
  
  \f
--- 2355,2370 ----
  (defun dired-isearch-filenames ()
    "Search for a string using Isearch only in file names in the Dired buffer."
    (interactive)
!   (let ((dired-isearch-filenames t)
! 	(isearch-message-prefix "File name "))
      (isearch-forward)))
  
  ;;;###autoload
  (defun dired-isearch-filenames-regexp ()
    "Search for a regexp using Isearch only in file names in the Dired buffer."
    (interactive)
!   (let ((dired-isearch-filenames t)
! 	(isearch-message-prefix "File name "))
      (isearch-forward-regexp)))
  
  \f

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.331
diff -c -r1.331 isearch.el
*** lisp/isearch.el	19 Oct 2008 22:33:17 -0000	1.331
--- lisp/isearch.el	9 Nov 2008 21:54:47 -0000
***************
*** 532,537 ****
--- 532,539 ----
  
  (defvar isearch-string "")  ; The current search string.
  (defvar isearch-message "") ; text-char-description version of isearch-string
+ (defvar isearch-message-prefix nil)
+ (defvar isearch-message-suffix nil)
  
  (defvar isearch-success t)	; Searching is currently successful.
  (defvar isearch-error nil)	; Error message for failed search.
***************
*** 2144,2149 ****
--- 2162,2168 ----
  			      (< (point) isearch-opoint)))
  		       "over")
  		   (if isearch-wrapped "wrapped ")
+ 		   (or isearch-message-prefix "")
  		   (if isearch-word "word " "")
  		   (if isearch-regexp "regexp " "")
  		   (if multi-isearch-next-buffer-current-function "multi " "")
***************
*** 2160,2166 ****
    (concat (if c-q-hack "^Q" "")
  	  (if isearch-error
  	      (concat " [" isearch-error "]")
! 	    "")))
  
  \f
  ;; Searching
--- 2179,2186 ----
    (concat (if c-q-hack "^Q" "")
  	  (if isearch-error
  	      (concat " [" isearch-error "]")
! 	    "")
! 	  (or isearch-message-suffix "")))
  
  \f
  ;; Searching

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

Re: Isearch in dired

[Alan Mackenzie]

Morning, Richard!

On Sat, Nov 08, 2008 at 04:56:52AM -0500, Richard M. Stallman wrote:
> It would be useful for isearch in a dired buffer to match only file
> names by default.  I think this would be a good feature -- if we can
> come up with a natural way to request ordinary search of the entire
> buffer.

> Can anyone think of one?

This doesn't have to be a special dired thing.  Surely it should be a
major mode dependent hook:

(defvar isearch-in-valid-region-p nil
  "If non-nil, a function which returns non-nil if the current isearch 
match is acceptable.  It is given two parameters, the beginning and end
of the match.")

There are already several toggle keys in isearch-mode: M-r (toggle
regexp), M-c (toggle case sensitivity), .....  So, how about C-M-z
(toggle validation funtion)?

It's not that brilliant - in fact, it's pretty bad, but it doesn't
shadow a useful function in the Emacs core (is C-M-z bound anywhere at
all?) and it's no worse than C-M-w.  ;-(

Come on, Richard, tell us what your best effort at thinking up a key
binding was.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Isearch in dired

[Juri Linkov]

> This doesn't have to be a special dired thing.  Surely it should be a
> major mode dependent hook:
>
> (defvar isearch-in-valid-region-p nil
>   "If non-nil, a function which returns non-nil if the current isearch
> match is acceptable.  It is given two parameters, the beginning and end
> of the match.")

except that such a hook already exists.  Its name is `isearch-success-function'.

> There are already several toggle keys in isearch-mode: M-r (toggle
> regexp), M-c (toggle case sensitivity), .....  So, how about C-M-z
> (toggle validation funtion)?

Currently in dired the toggle key is the same as the key that activates
filename isearch, i.e. `M-s f'.

> It's not that brilliant - in fact, it's pretty bad, but it doesn't
> shadow a useful function in the Emacs core (is C-M-z bound anywhere at
> all?) and it's no worse than C-M-w.  ;-(

`C-M-z' looks like a good more general alternative.

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

Re: Isearch in dired

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> It would be useful for isearch in a dired buffer to match only file
> names by default.  I think this would be a good feature -- if we can
> come up with a natural way to request ordinary search of the entire
> buffer.

Emacs 23 has the M-s f C-s (dired-isearch-filenames) command which does
just that, and the variable dired-isearch-filename which can be changed
to non-nil to make C-s do the same as M-s f C-s.

Re: Isearch in dired

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> It would be useful for isearch in a dired buffer to match only file
>> names by default.  I think this would be a good feature -- if we can
>> come up with a natural way to request ordinary search of the entire
>> buffer.
>
> Emacs 23 has the M-s f C-s (dired-isearch-filenames) command which does
> just that, and the variable dired-isearch-filename which can be changed
> to non-nil to make C-s do the same as M-s f C-s.

Sounds nice!

I would also like to point out that searching for filenames is somewhat
similar to searching for function names. That is, the buffer is parsed
and you search for semantic entities of some kind.

It so happens that Cedet, which is slated for inclusion, contains a tool
called Senator which does this.

>
-- 
Joakim Verona

Re: Isearch in dired

[Juri Linkov]

> I would also like to point out that searching for filenames is somewhat
> similar to searching for function names. That is, the buffer is parsed
> and you search for semantic entities of some kind.
>
> It so happens that Cedet, which is slated for inclusion, contains a tool
> called Senator which does this.

We are all waiting for inclusion of Cedet to Emacs, but I want to note
that Isearch in Emacs now has much cleaner infrastructure for searching
function names, where everything is necessary to do is just to define
a hook like:

(set (make-local-variable 'isearch-success-function)
     (lambda (mb me)
       (save-match-data
	 (let ((re (cdr (assoc nil imenu-generic-expression))))
	   (and (save-excursion (beginning-of-line) (looking-at (car re)))
		(>= mb (match-beginning (cadr re)))
		(<= me (match-end (cadr re))))))))

The only problem is to find a good keybinding to start function name isearch.
Maybe take the same keybinding as used by Senator, or the same keybinding used
by Dired filename isearch `M-s f C-s' where `f' could mean `function name'?

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

Re: Isearch in dired

[Juri Linkov]

>> It would be useful for isearch in a dired buffer to match only file
>> names by default.  I think this would be a good feature -- if we can
>> come up with a natural way to request ordinary search of the entire
>> buffer.
>
> Emacs 23 has the M-s f C-s (dired-isearch-filenames) command which does
> just that, and the variable dired-isearch-filename which can be changed
> to non-nil to make C-s do the same as M-s f C-s.

When the variable `dired-isearch-filenames' is non-nil then it is not
possible to search the entire buffer because both `C-s' and `M-s f C-s'
start filename isearch.

The following patch changes `M-s f C-s' to start a non-default isearch,
i.e. isearch opposite (filenames vs entire buffer) to the value of
`dired-isearch-filenames' (that affects isearch started via `C-s'):

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.180
diff -u -r1.180 dired-aux.el
--- lisp/dired-aux.el	22 Oct 2008 20:21:21 -0000	1.180
+++ lisp/dired-aux.el	8 Nov 2008 17:16:27 -0000
@@ -2355,14 +2355,14 @@
 (defun dired-isearch-filenames ()
   "Search for a string using Isearch only in file names in the Dired buffer."
   (interactive)
-  (let ((dired-isearch-filenames t))
+  (let ((dired-isearch-filenames (not dired-isearch-filenames)))
     (isearch-forward)))
 
 ;;;###autoload
 (defun dired-isearch-filenames-regexp ()
   "Search for a regexp using Isearch only in file names in the Dired buffer."
   (interactive)
-  (let ((dired-isearch-filenames t))
+  (let ((dired-isearch-filenames (not dired-isearch-filenames)))
     (isearch-forward-regexp)))
 
 \f

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

Re: Isearch in dired

[Richard M. Stallman]

    > It would be useful for isearch in a dired buffer to match only file
    > names by default.  I think this would be a good feature -- if we can
    > come up with a natural way to request ordinary search of the entire
    > buffer.

    Emacs 23 has the M-s f C-s (dired-isearch-filenames) command which does
    just that,

It was reading about M-s f C-s that led me to raise this issue.
That interface is inconvenient, and most people won't remember it exists.

That's why I'm suggesting we look fo a cleaner and simpler interface.
And we now have a good suggestion.

Lazy Isearch in dired

[Juri Linkov]

There is a bug in Isearch in dired.  When Isearch is narrowed to only
file names, Lazy Isearch highlights matches outside of the Isearch scope.
This is very confusing since C-s and C-r will never visit them.

The following patch fixes this by using a loop like the loop in the
function `isearch-search'.  The docstring of isearch-lazy-highlight-search
says: "Attempt to do the search exactly the way the pending isearch would.",
so no changes in the docstring are needed, because this patch makes it
more similar to the main search function.  It also calls isearch-success-function
to skip the matches outside the current Isearch scope.  By default this
function skips invisible matches that are useless for lazy highlighting.
This also requires setting search-invisible to nil to not match
invisible text.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.331
diff -c -r1.331 isearch.el
*** lisp/isearch.el	19 Oct 2008 22:33:17 -0000	1.331
--- lisp/isearch.el	8 Nov 2008 21:55:38 -0000
***************
*** 2598,2620 ****
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (let ((case-fold-search isearch-lazy-highlight-case-fold-search)
! 	(isearch-regexp isearch-lazy-highlight-regexp)
! 	(search-spaces-regexp isearch-lazy-highlight-space-regexp))
!     (condition-case nil
! 	(isearch-search-string
! 		 isearch-lazy-highlight-last-string
! 		 (if isearch-forward
! 		     (min (or isearch-lazy-highlight-end-limit (point-max))
  			  (if isearch-lazy-highlight-wrapped
! 			      isearch-lazy-highlight-start
! 			    (window-end)))
! 		   (max (or isearch-lazy-highlight-start-limit (point-min))
! 			(if isearch-lazy-highlight-wrapped
! 			    isearch-lazy-highlight-end
! 			  (window-start))))
! 		 t)
!       (error nil))))
  
  (defun isearch-lazy-highlight-update ()
    "Update highlighting of other matches for current search."
--- 2608,2639 ----
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (condition-case nil
!       (let ((case-fold-search isearch-lazy-highlight-case-fold-search)
! 	    (isearch-regexp isearch-lazy-highlight-regexp)
! 	    (search-spaces-regexp isearch-lazy-highlight-space-regexp)
! 	    (search-invisible nil)	; don't match invisible text
! 	    (retry t)
! 	    (success nil)
! 	    (bound (if isearch-forward
! 		       (min (or isearch-lazy-highlight-end-limit (point-max))
! 			    (if isearch-lazy-highlight-wrapped
! 				isearch-lazy-highlight-start
! 			      (window-end)))
! 		     (max (or isearch-lazy-highlight-start-limit (point-min))
  			  (if isearch-lazy-highlight-wrapped
! 			      isearch-lazy-highlight-end
! 			    (window-start))))))
! 	;; Use a loop similar to the loop in `isearch-search'
! 	(while retry
! 	  (setq success (isearch-search-string
! 			 isearch-lazy-highlight-last-string bound t))
! 	  (if (or (not success)
! 		  (funcall isearch-success-function
! 			   (match-beginning 0) (match-end 0)))
! 	      (setq retry nil)))
! 	success)
!     (error nil)))
  
  (defun isearch-lazy-highlight-update ()
    "Update highlighting of other matches for current search."

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

recursive-edit in Isearch

[Juri Linkov]

Commentary in isearch.el:

  ;; For programmed use of isearch-mode, e.g. calling (isearch-forward),
  ;; isearch-mode behaves modally and does not return until the search
  ;; is completed.  It uses a recursive-edit to behave this way.

This causes a few problems.  The call to `exit-recursive-edit' in
`isearch-done' terminates the execution of the calling Lisp function,
so that `isearch-clean-overlays' in `isearch-exit' located after
`isearch-done' will never get executed.  What is worse is that the rest
of code after `isearch-done' in the commands `isearch-query-replace' and
`isearch-highlight-regexp' doesn't get executed, so these commands fail
when called programmatically via (isearch-forward) which is used when
searching file names in Dired.

Unless there is a better solution, I propose the following patch to fix
these problems in `isearch-query-replace' and `isearch-highlight-regexp'.

It binds `isearch-recursive-edit' to nil, thus preventing `isearch-done'
from calling `exit-recursive-edit' that terminates the execution of
these commands.  `exit-recursive-edit' gets called explicitly at the end
of these commands.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.331
diff -c -r1.331 isearch.el
*** lisp/isearch.el	19 Oct 2008 22:33:17 -0000	1.331
--- lisp/isearch.el	9 Nov 2008 20:50:37 -0000
***************
*** 1347,1354 ****
    (let ((case-fold-search isearch-case-fold-search)
  	;; set `search-upper-case' to nil to not call
  	;; `isearch-no-upper-case-p' in `perform-replace'
! 	(search-upper-case nil))
!     (isearch-done)
      (isearch-clean-overlays)
      (if (and isearch-other-end
  	     (< isearch-other-end (point))
--- 1347,1359 ----
    (let ((case-fold-search isearch-case-fold-search)
  	;; set `search-upper-case' to nil to not call
  	;; `isearch-no-upper-case-p' in `perform-replace'
! 	(search-upper-case nil)
! 	;; Set `isearch-recursive-edit' to nil to prevent calling
! 	;; `exit-recursive-edit' in `isearch-done' that terminates
! 	;; the execution of this command when it is non-nil.
! 	;; We call `exit-recursive-edit' explicitly at the end below.
! 	(isearch-recursive-edit nil))
!     (isearch-done nil t)
      (isearch-clean-overlays)
      (if (and isearch-other-end
  	     (< isearch-other-end (point))
***************
*** 1369,1375 ****
        isearch-regexp)
       t isearch-regexp (or delimited isearch-word) nil nil
       (if (and transient-mark-mode mark-active) (region-beginning))
!      (if (and transient-mark-mode mark-active) (region-end)))))
  
  (defun isearch-query-replace-regexp (&optional delimited)
    "Start `query-replace-regexp' with string to replace from last search string.
--- 1374,1381 ----
        isearch-regexp)
       t isearch-regexp (or delimited isearch-word) nil nil
       (if (and transient-mark-mode mark-active) (region-beginning))
!      (if (and transient-mark-mode mark-active) (region-end))))
!   (and isearch-recursive-edit (exit-recursive-edit)))
  
  (defun isearch-query-replace-regexp (&optional delimited)
    "Start `query-replace-regexp' with string to replace from last search string.
***************
*** 1401,1408 ****
  argument from the last search regexp or a quoted search string,
  and reads its face argument using `hi-lock-read-face-name'."
    (interactive)
!   (isearch-done)
!   (isearch-clean-overlays)
    (require 'hi-lock nil t)
    (let ((string (cond (isearch-regexp isearch-string)
  		      ((if (and (eq isearch-case-fold-search t)
--- 1411,1424 ----
  argument from the last search regexp or a quoted search string,
  and reads its face argument using `hi-lock-read-face-name'."
    (interactive)
!   (let (
! 	;; Set `isearch-recursive-edit' to nil to prevent calling
! 	;; `exit-recursive-edit' in `isearch-done' that terminates
! 	;; the execution of this command when it is non-nil.
! 	;; We call `exit-recursive-edit' explicitly at the end below.
! 	(isearch-recursive-edit nil))
!     (isearch-done nil t)
!     (isearch-clean-overlays))
    (require 'hi-lock nil t)
    (let ((string (cond (isearch-regexp isearch-string)
  		      ((if (and (eq isearch-case-fold-search t)
***************
*** 1420,1426 ****
  			      (regexp-quote s))))
  			isearch-string ""))
  		      (t (regexp-quote isearch-string)))))
!     (hi-lock-face-buffer string (hi-lock-read-face-name))))
  
  \f
  (defun isearch-delete-char ()
--- 1436,1443 ----
  			      (regexp-quote s))))
  			isearch-string ""))
  		      (t (regexp-quote isearch-string)))))
!     (hi-lock-face-buffer string (hi-lock-read-face-name)))
!   (and isearch-recursive-edit (exit-recursive-edit)))
  
  \f
  (defun isearch-delete-char ()

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

Occur in Word Isearch

[Juri Linkov]

`M-s w word M-s o' displays a *Occur* buffer with wrong matches because
it takes no care about word boundaries.  The following patch should fix this.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.331
diff -c -r1.331 isearch.el
*** lisp/isearch.el	19 Oct 2008 22:33:17 -0000	1.331
--- lisp/isearch.el	9 Nov 2008 21:07:54 -0000
***************
*** 1384,1390 ****
  string.  NLINES has the same meaning as in `occur'."
    (interactive
     (list
!     (if isearch-regexp isearch-string (regexp-quote isearch-string))
      (if current-prefix-arg (prefix-numeric-value current-prefix-arg))))
    (let ((case-fold-search isearch-case-fold-search)
  	;; set `search-upper-case' to nil to not call
--- 1390,1399 ----
  string.  NLINES has the same meaning as in `occur'."
    (interactive
     (list
!     (cond
!      (isearch-word (concat "\\b" (regexp-quote isearch-string) "\\b"))
!      (isearch-regexp isearch-string)
!      (t (regexp-quote isearch-string)))
      (if current-prefix-arg (prefix-numeric-value current-prefix-arg))))
    (let ((case-fold-search isearch-case-fold-search)
  	;; set `search-upper-case' to nil to not call

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

Re: Occur in Word Isearch

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> `M-s w word M-s o' displays a *Occur* buffer with wrong matches because
> it takes no care about word boundaries.  The following patch should fix this.

Looks OK, please install it.

Re: Lazy Isearch in dired

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> There is a bug in Isearch in dired.  When Isearch is narrowed to only
> file names, Lazy Isearch highlights matches outside of the Isearch scope.
> This is very confusing since C-s and C-r will never visit them.
>
> The following patch fixes this by using a loop like the loop in the
> function `isearch-search'.  The docstring of isearch-lazy-highlight-search
> says: "Attempt to do the search exactly the way the pending isearch would.",
> so no changes in the docstring are needed, because this patch makes it
> more similar to the main search function.  It also calls isearch-success-function
> to skip the matches outside the current Isearch scope.  By default this
> function skips invisible matches that are useless for lazy highlighting.
> This also requires setting search-invisible to nil to not match
> invisible text.

Hmm, your patch looks reasonable, but I'm not sure.  Could it possibly
lead to slowdowns in some buffers from the additional search loop?
Maybe we should hold this till after the release.

Re: Lazy Isearch in dired

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> The following patch fixes this by using a loop like the loop in the
>> function `isearch-search'.  The docstring of isearch-lazy-highlight-search
>> says: "Attempt to do the search exactly the way the pending isearch would.",
>> so no changes in the docstring are needed, because this patch makes it
>> more similar to the main search function.  It also calls isearch-success-function
>> to skip the matches outside the current Isearch scope.  By default this
>> function skips invisible matches that are useless for lazy highlighting.
>> This also requires setting search-invisible to nil to not match
>> invisible text.
>
> Hmm, your patch looks reasonable, but I'm not sure.  Could it possibly
> lead to slowdowns in some buffers from the additional search loop?
> Maybe we should hold this till after the release.

Ah, I see you already installed it.  That's OK.

Could you do some quick testing to make sure there isn't a slowdown?
(e.g., try searching in a buffer in a way that generates lots of lazy
highlights).

Re: Lazy Isearch in dired

[Juri Linkov]

>>> The following patch fixes this by using a loop like the loop in the
>>> function `isearch-search'.  The docstring of isearch-lazy-highlight-search
>>> says: "Attempt to do the search exactly the way the pending isearch would.",
>>> so no changes in the docstring are needed, because this patch makes it
>>> more similar to the main search function.  It also calls isearch-success-function
>>> to skip the matches outside the current Isearch scope.  By default this
>>> function skips invisible matches that are useless for lazy highlighting.
>>> This also requires setting search-invisible to nil to not match
>>> invisible text.
>>
>> Hmm, your patch looks reasonable, but I'm not sure.  Could it possibly
>> lead to slowdowns in some buffers from the additional search loop?
>> Maybe we should hold this till after the release.
>
> Ah, I see you already installed it.  That's OK.

In normal cases there is no slowdown because the new additional
loop gets executed only once.  And in cases with a restricted search
(with invisible matches or matches outside of the search space)
there is really a speedup instead of slowdown because unnecessary
overlays for lazy highlights never get created - these places are
skipped with a new loop.

> Could you do some quick testing to make sure there isn't a slowdown?
> (e.g., try searching in a buffer in a way that generates lots of lazy
> highlights).

The quickest way to test is to open the etc/NEWS file and

1. expand all outlines with `C-c C-a' and type `C-M-s .'
   the time required to highlight all matched is the same as before;

2. hide everything but the top levels with `C-1 C-c C-q' and type `C-M-s .'
   then highlighting now is much faster than before because it now
   doesn't create unnecessary overlays on matches in hidden regions.

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

Re: Lazy Isearch in dired

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> In normal cases there is no slowdown because the new additional
> loop gets executed only once.  And in cases with a restricted search
> (with invisible matches or matches outside of the search space)
> there is really a speedup instead of slowdown because unnecessary
> overlays for lazy highlights never get created - these places are
> skipped with a new loop.

I see.  Thanks.

Re: Isearch in dired

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> It would be useful for isearch in a dired buffer to match only file
> names by default.  I think this would be a good feature -- if we can
> come up with a natural way to request ordinary search of the entire
> buffer.
>
> Can anyone think of one?

Although it's likely that the user wants to match the filename parts of
the Dired buffer, there are two things to note:

 (1) There is a significant probability that the user might want to
     match the non-file parts.  For instance, the user may want to find
     all files modified on a certain date.

 (2) For most files, the chances of a filename search string matching
     the non-file parts of the Dired buffer are very low.  Basically,
     this happens only for corner cases, e.g. if the user wants to find
     a file name "1".

Given that, I don't think it's reasonable to change the behavior of key
sequences like C-s from their defaults.

However, one possibility is to define a standard "dwim search" key
binding, and try to use that key binding everywhere we want a command
that tries to guess where the user wants to search.  Then we can make a
"dwim search" in Dired mean searching filenames.

Re: Isearch in dired

[Stefan Monnier]

> However, one possibility is to define a standard "dwim search" key
> binding, and try to use that key binding everywhere we want a command
> that tries to guess where the user wants to search.  Then we can make a
> "dwim search" in Dired mean searching filenames.

That might work indeed.  In the case of dired we could use a heuristic
either based on the start column, or based on "if the string matches
a filename, then treat it as a filename search, and if no filename
matches the string, then search over the whole buffer".


        Stefan

Re: Isearch in dired

[Juri Linkov]

> Although it's likely that the user wants to match the filename parts of
> the Dired buffer, there are two things to note:
>
>  (1) There is a significant probability that the user might want to
>      match the non-file parts.  For instance, the user may want to find
>      all files modified on a certain date.

Using isearch to find files with a certain date is not the easiest way
to accomplish this task, especially when the date format is not ISO.
There are better tools like M-( dired-mark-sexp and find-dired
with -mtime and -mmin options.  However, isearching dates and other parts
of a dired buffer will still be possible even with context-dependent
isearch - when point initially is not a file name.

>  (2) For most files, the chances of a filename search string matching
>      the non-file parts of the Dired buffer are very low.  Basically,
>      this happens only for corner cases, e.g. if the user wants to find
>      a file name "1".

The false matches also include owner and group names, month names in non-ISO
formats, and sometimes even file permissions.

> Given that, I don't think it's reasonable to change the behavior of key
> sequences like C-s from their defaults.
>
> However, one possibility is to define a standard "dwim search" key
> binding, and try to use that key binding everywhere we want a command
> that tries to guess where the user wants to search.  Then we can make a
> "dwim search" in Dired mean searching filenames.

Perhaps in this case it would be convenient to have one option that
enables a dwim search globally for all search types: file names in Dired,
function names in source code, etc.

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

Re: Isearch in dired

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>>  (1) There is a significant probability that the user might want to
>>      match the non-file parts.  For instance, the user may want to find
>>      all files modified on a certain date.
>
> Using isearch to find files with a certain date is not the easiest way
> to accomplish this task, especially when the date format is not ISO.
> There are better tools like M-( dired-mark-sexp and find-dired
> with -mtime and -mmin options.  However, isearching dates and other parts
> of a dired buffer will still be possible even with context-dependent
> isearch - when point initially is not a file name.

On the contrary, it is the most intuitive way to search Dired buffers,
for anyone who is used to using C-s for buffer navigation.  It's also
faster, in many cases, than doing M-(.  Having this operation fail
unexpectedly in Dired would be unfortunate.

(Also, gnu ls gives the date in ISO format by default, so that
particular objection is a red herring.)

> The false matches also include owner and group names, month names in
> non-ISO formats, and sometimes even file permissions.

Owner and group names, maybe, but I don't think we have to worry about
people being getting false search matches for files named `rw-r--r' etc.


As for doing a filename search based on the current column, that is a
tad more reasonable, but still suffers from the "unexplained behavior"
problem.  There is simply no visual clue for the user that the "dwim
behavior" is taking place, or what rules govern it, so it will seem like
Emacs is behaving erratically.  Note, also, that upon entering the Dired
buffer, point is placed in the filename column by default, so if the
user attempts to search for dates with C-s, the search fails by default!

So I don't think the dwim behavior should be the default (I support
providing it as an option, though).

Re: Isearch in dired

[Stefan Monnier]

> As for doing a filename search based on the current column, that is a
> tad more reasonable, but still suffers from the "unexplained behavior"
> problem.

Agreed.  For that reason an "isearch-dwim" command sounds like
a better solution.


        Stefan

Re: Isearch in dired

[René Kyllingstad]

* Stefan Monnier:
> > As for doing a filename search based on the current column, that is a
> > tad more reasonable, but still suffers from the "unexplained behavior"
> > problem.
>  
>  Agreed.  For that reason an "isearch-dwim" command sounds like
>  a better solution.

As a side note to this: what about Rob Giardinas patch to merge dired
details into dired?  Toggling between displaying just the filenames and the
full ls -l details makes it very clear what is being searched, and it's
also nice for other reasons.

The patch was sent 2007-07-22 with subject "[rob <at> giardina.us:
dired-details merged into dired]"

    http://thread.gmane.org/gmane.emacs.devel/75275

As far as I can see, nobody has posted review comments for the patch.  Is
it just too ugly?  Too incomplete?  Not an attractive feature?

The only annoyance I have with dired-details.el is that M-w copies the
hidden part too, which is not what I expect.  I'm using a horrible
buffer-substring-filters hack to prevent that locally (don't see how to do
it properly without switching from overlays to text properties).


-- René

RE: Isearch in dired

[Drew Adams]

> As a side note to this: what about Rob Giardinas patch to merge dired
> details into dired?  Toggling between displaying just the 
> filenames and the full ls -l details makes it very clear what is
> being searched, and it's also nice for other reasons.
> 
> The patch was sent 2007-07-22 with subject "[rob <at> giardina.us:
> dired-details merged into dired]"
>     http://thread.gmane.org/gmane.emacs.devel/75275
> 
> As far as I can see, nobody has posted review comments for 
> the patch.  Is it just too ugly?  Too incomplete?
> Not an attractive feature?
> 
> The only annoyance I have with dired-details.el is that M-w copies the
> hidden part too, which is not what I expect.  I'm using a horrible
> buffer-substring-filters hack to prevent that locally (don't 
> see how to do it properly without switching from overlays to
> text properties).

I agree it should be added, and I've brought that up several times now, with no
response. The last time was 2008-07-24.

I brought it up also in the context of searching for filenames. With details
hidden, search in Dired searches only among file names.

Personally, I use dired-details with the details hidden 95% of the time. I use a
separate frame per buffer and automatically fit the frame to the buffer, so
removing Dired details saves a lot of real estate. If I ever want to search
something other than file names, I just hit a key to toggle display of the
details. No big deal.

Why hasn't this been added? There seemed to be agreement that it should be.

Wrt Isearch in Dired: This was discussed thoroughly over a year ago. FWIW, my
opinion about it was expressed here:
http://lists.gnu.org/archive/html/emacs-devel/2007-08/msg00518.html

Re: Isearch in dired

[Richard M. Stallman]

Basing the type of search on where point is will be LESS for users
to remember.  It won't take long for people to figure out the behavior
pattern.

By contrast, the other approach means one more command to remember.
Most people won't learn it and will never use the feature.

Re: Isearch in dired

[Juri Linkov]

> As for doing a filename search based on the current column, that is a
> tad more reasonable, but still suffers from the "unexplained behavior"
> problem.  There is simply no visual clue for the user that the "dwim
> behavior" is taking place, or what rules govern it, so it will seem like
> Emacs is behaving erratically.

Fortunately, there is now a visual clue for the user in the Isearch prompt,
so we can safely enable Isearch-dwim by default, because after typing C-s
the user will clearly see in the prompt whether the Isearch mode is dwim.

> Note, also, that upon entering the Dired
> buffer, point is placed in the filename column by default, so if the
> user attempts to search for dates with C-s, the search fails by default!

Searching for dates with C-s from the first file will miss the date of the
first file because it is located before the filename.  So to search for
dates is better to start from the beginning of the dired buffer or after
moving point to the date of the first file where Isearch is not filename
only (we could later implement dwim-search for the date column only!).

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

Re: Isearch in dired

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> As for doing a filename search based on the current column, that is a
>> tad more reasonable, but still suffers from the "unexplained behavior"
>> problem.  There is simply no visual clue for the user that the "dwim
>> behavior" is taking place, or what rules govern it, so it will seem like
>> Emacs is behaving erratically.
>
> Fortunately, there is now a visual clue for the user in the Isearch prompt,

This tells the user that a special behavior of Isearch is occurring, but
not *why* it occurs (i.e., because point is in the filenames column),
nor how to disable it.

>> Note, also, that upon entering the Dired buffer, point is placed in
>> the filename column by default, so if the user attempts to search for
>> dates with C-s, the search fails by default!
>
> Searching for dates with C-s from the first file will miss the date of the
> first file because it is located before the filename.  So to search for
> dates is better to start from the beginning of the dired buffer or after
> moving point to the date of the first file where Isearch is not filename
> only (we could later implement dwim-search for the date column only!).

This argument banks on the user doing something to disable the special
behavior, so that he is not confused.  If the user happens not to move
point before doing C-s, the confusion occurs.

These problems can be circumvented by implementing a separate dwim
search keybinding (maybe something in the M-s prefix, such as M-s C-s).

Re: Isearch in dired

[Juri Linkov]

While we need to think more about enabling the dwim option by default,
there is one problem in implementing such option - the additional visual clue
in the Isearch message about the search type is not displayed immediately
after typing C-s on a filename column.  The message gets updated only after
typing more keys in Isearch mode.

This is because the code that modifies the Isearch message in Dired is
executed via `isearch-mode-hook', but this hook is called in `isearch-mode'
after `isearch-update' that displays the Isearch message.  So currently
it is impossible to modify the Isearch message before displaying it.

One solution is to change the call order in `isearch-mode' from

  (isearch-update)
  (run-hooks 'isearch-mode-hook)

to

  (run-hooks 'isearch-mode-hook)
  (isearch-update)

Does someone see a bad effect of such change?

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

Re: Isearch in dired

[Juri Linkov]

> One solution is to change the call order in `isearch-mode' from
>
>   (isearch-update)
>   (run-hooks 'isearch-mode-hook)
>
> to
>
>   (run-hooks 'isearch-mode-hook)
>   (isearch-update)

Actually a new call order is more correct because in most cases
isearch-mode-hook is used to setup isearch parameters such as a search
function, search string, message, etc. and after these settings to
update the isearch display with the specified parameters.  So the
current order is wrong.  The only reason it causes no problems now
is because typing the first C-s just activates isearch mode and
doesn't run a real search.

So I see no problems with changing the order:

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.335
diff -u -r1.335 isearch.el
--- lisp/isearch.el	11 Nov 2008 20:11:34 -0000	1.335
+++ lisp/isearch.el	16 Nov 2008 22:21:04 -0000
@@ -800,8 +801,8 @@
   (isearch-push-state)
 
   (setq overriding-terminal-local-map isearch-mode-map)
-  (isearch-update)
   (run-hooks 'isearch-mode-hook)
+  (isearch-update)
 
   (add-hook 'mouse-leave-buffer-hook 'isearch-done)
   (add-hook 'kbd-macro-termination-hook 'isearch-done)

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

Re: Isearch in dired

[Richard M. Stallman]

    Although it's likely that the user wants to match the filename parts of
    the Dired buffer, there are two things to note:

     (1) There is a significant probability that the user might want to
	 match the non-file parts.  For instance, the user may want to find
	 all files modified on a certain date.

We already have a suggestion for a very convenient interface:
to make it depend on where point is when you enter the search.

    However, one possibility is to define a standard "dwim search" key
    binding, and try to use that key binding everywhere we want a command
    that tries to guess where the user wants to search.  Then we can make a
    "dwim search" in Dired mean searching filenames.

It's a reasonable idea, in principle.  If we wanted a special dwim
search in several modes, this could be a good way to invoke it -- if we
can't find an even better interface.

Right now we know of only one mode where we want a sort of dwim
search, and we have an even better interface suggestion.  I think we
should use it.

Re: Isearch in dired

[Juri Linkov]

>     However, one possibility is to define a standard "dwim search" key
>     binding, and try to use that key binding everywhere we want a command
>     that tries to guess where the user wants to search.  Then we can make a
>     "dwim search" in Dired mean searching filenames.
>
> It's a reasonable idea, in principle.  If we wanted a special dwim
> search in several modes, this could be a good way to invoke it -- if we
> can't find an even better interface.
>
> Right now we know of only one mode where we want a sort of dwim
> search, and we have an even better interface suggestion.  I think we
> should use it.

This is implemented by the following patch.  It seems it provides a good
default behavior, so we could install it now and wait for a feedback.

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.181
diff -c -r1.181 dired-aux.el
*** lisp/dired-aux.el	11 Nov 2008 20:12:44 -0000	1.181
--- lisp/dired-aux.el	11 Nov 2008 21:35:18 -0000
***************
*** 2303,2312 ****
  \f
  ;; Search only in file names in the Dired buffer.
  
! (defcustom dired-isearch-filenames nil
    "*If non-nil, Isearch in Dired matches only file names."
    :type '(choice (const :tag "No restrictions" nil)
! 		 (const :tag "Isearch only in file names" dired-filename))
    :group 'dired
    :version "23.1")
  
--- 2303,2313 ----
  \f
  ;; Search only in file names in the Dired buffer.
  
! (defcustom dired-isearch-filenames 'dwim
    "*If non-nil, Isearch in Dired matches only file names."
    :type '(choice (const :tag "No restrictions" nil)
! 		 (const :tag "When point is on a file name search in file names" dwim)
! 		 (const :tag "Always search in file names" dired-filename))
    :group 'dired
    :version "23.1")
  
***************
*** 2330,2336 ****
  (defun dired-isearch-filenames-setup ()
    "Set up isearch to search in Dired file names.
  Intended to be added to `isearch-mode-hook'."
!   (when dired-isearch-filenames
      (define-key isearch-mode-map "\M-sf" 'dired-isearch-filenames-toggle)
      (setq dired-isearch-orig-success-function
  	  (default-value 'isearch-success-function))
--- 2331,2340 ----
  (defun dired-isearch-filenames-setup ()
    "Set up isearch to search in Dired file names.
  Intended to be added to `isearch-mode-hook'."
!   (when (or (eq dired-isearch-filenames 'dired-filename)
! 	    (and (eq dired-isearch-filenames 'dwim)
! 		 (get-text-property (point) 'dired-filename)))
!     (setq isearch-message-prefix-add "filename ")
      (define-key isearch-mode-map "\M-sf" 'dired-isearch-filenames-toggle)
      (setq dired-isearch-orig-success-function
  	  (default-value 'isearch-success-function))
***************
*** 2339,2344 ****
--- 2343,2349 ----
  
  (defun dired-isearch-filenames-end ()
    "Clean up the Dired file name search after terminating isearch."
+   (setq isearch-message-prefix-add nil)
    (define-key isearch-mode-map "\M-sf" nil)
    (setq-default isearch-success-function dired-isearch-orig-success-function)
    (remove-hook 'isearch-mode-end-hook 'dired-isearch-filenames-end t))

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