propose: dired-isearch.el --- isearch in Dired

propose: dired-isearch.el --- isearch in Dired

[William Xu]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

A simple but quite useful extension, which does isearch in Dired but
match only at filenames.

I suggest adding this to emacs cvs.

-- 
William

[-- Attachment #2: dired-isearch.el --]
[-- Type: application/emacs-lisp, Size: 5727 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: propose: dired-isearch.el --- isearch in Dired

[Levin]

William Xu Wrote:
> A simple but quite useful extension, which does isearch in Dired but
> match only at filenames.
>
> I suggest adding this to emacs cvs.

This is very useful. There's one bug I encounter: use `M-C-s' `^m' to do a 
regexp search for file starting with "m", when I type `^', emacs freeze, and 
I have to quit with C-g.

Levin

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

Levin <zslevin@gmail.com> writes:

> This is very useful. There's one bug I encounter: use `M-C-s' `^m' to do a 
> regexp search for file starting with "m", when I type `^', emacs freeze, and 
> I have to quit with C-g.

Yes, this is a known bug..

,----
| ;;; Bugs:
| 
| ;; - search string starting with a "^" causes some infinite loop
`----

-- 
William

Re: propose: dired-isearch.el --- isearch in Dired

[Herbert Euler]

>Yes, this is a known bug..
>
>,----
>| ;;; Bugs:
>|
>| ;; - search string starting with a "^" causes some infinite loop
>`----

This bug is in the loop:

  (let ((point (re-search-forward regexp bound noerror count)))
    (catch 'return
      (while point
        (when (get-text-property (1- point) 'help-echo)
          (throw 'return point))
        (setq point (re-search-forward regexp bound noerror count))))))

When the user types "^", REGEXP is "^".  The value of POINT in
`let' is the point of the start of the next line after point, which won't
be changed in the future searches (i.e. the last form of the invocation
to `re-search-forward').  So POINT is always the same value as the first
invocation to `re-search-forward', and `throw' never gets called.
As a result, this function won't return and the user won't get the
chance to input the next character.  I thought but got no simple
solution.

There is another bug: I searched "2.*" with
`dired-isearch-forward-regexp', but search goes into other fields other
than the file names.  The properties of the start of the search results
need to be checked as well.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: propose: dired-isearch.el --- isearch in Dired

[Miles Bader]

A style question:  Is there a reason you're using catch/throw instead of
just directly testing the result of get-text-property?  The latter seems
both more efficient and more clear:

   (let ((V ...))
     (catch 'return
       (while V
	 (when COND
	   (throw 'return V))
	 (setq V ...))))

=>

   (let ((V ...))
     (while (and V (not COND))
       (setq V ...))
     V)

Thanks,

-miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

Miles Bader <miles.bader@necel.com> writes:

> A style question:  Is there a reason you're using catch/throw instead of
> just directly testing the result of get-text-property?  

I can't call back, maybe just being stupid at the time of writing...

> The latter seems both more efficient and more clear:

Indeed. I have updated it. Thanks ! 

-- 
William

Re: propose: dired-isearch.el --- isearch in Dired

[Stefan Monnier]

>    (let ((V ...))
>      (catch 'return
>        (while V
> 	 (when COND
> 	   (throw 'return V))
> 	 (setq V ...))))

> =>

>    (let ((V ...))
>      (while (and V (not COND))
>        (setq V ...))
>      V)

Another one:

   (let ((X EXP))
     (while C
       BODY
       (setq X EXP))
     TAIL)
   
   =>
   
   (let (X)
     (while (progn (setq X EXP) C)
       BODY)
     TAIL)

Often BODY is empty (in which case the loop would be a do...while in C).

As for the non-termination of the loop: why not just increment point after
the failure of get-text-property?


        Stefan

Re: propose: dired-isearch.el --- isearch in Dired

[Stefan Monnier]

Actually all the search funs can be collapsed into one:

   (defun dired-isearch-search-fun-function () 'dired-isearch-search)
   
   (defun dired-isearch-search (&rest args)
     (let ((fun (let ((isearch-search-fun-function nil))
                  (isearch-search-fun)))
           ret)
       (while (and (setq ret (apply fun args))
                   ;; Use `help-echo' instead of `dired-filename' so as to
                   ;; also work in Tramp dired buffers.
                   (not (get-text-property (1- point) 'help-echo)))
         (forward-char 1))
       ret))

But there are two problems left:
1 - find a UI for it: just providing N new commands doesn't seem good enough.
    Maybe just something like:

    (define-minor-mode dired-isearch-filenames-mode
      "Only match filenames in isearch."
      (if dired-isearch-filenames-mode
          (set (make-local-variable 'isearch-search-fun-function)
               'dired-isearch-search-fun-function)
        (kill-local-variable 'isearch-search-fun-function)))

    and then bind it to a key?

2 - checking `help-echo' is bound to get us into trouble when we add
    help-echo to other elements such as access right bits, etc...
    We really should check `dired-filename'.  And if that doesn't work,
    let's fix it so that it does.  And/or add a dired-pos-in-filename-p
    predicate to abstract over it.


-- Stefan


PS: The above pieces of code are all guaranteed 100% untested.

Re: propose: dired-isearch.el --- isearch in Dired

[Juri Linkov]

I think using isearch in Dired to match only at filenames is a very good idea.

> Actually all the search funs can be collapsed into one:
>
>    (defun dired-isearch-search-fun-function () 'dired-isearch-search)
>
>    (defun dired-isearch-search (&rest args)
>      (let ((fun (let ((isearch-search-fun-function nil))
>                   (isearch-search-fun)))
>            ret)
>        (while (and (setq ret (apply fun args))
>                    ;; Use `help-echo' instead of `dired-filename' so as to
>                    ;; also work in Tramp dired buffers.
>                    (not (get-text-property (1- point) 'help-echo)))
>          (forward-char 1))
>        ret))

With patches (uninstalled due to feature freeze) from the thread
http://lists.gnu.org/archive/html/emacs-devel/2005-03/msg00785.html
this implementation can be collapsed even more:

    (set (make-local-variable 'isearch-success-function)
         (lambda () (get-text-property (1- point) 'help-echo)))

or with a new function `dired-pos-in-filename-p':

    (set (make-local-variable 'isearch-success-function)
         'dired-pos-in-filename-p)

> But there are two problems left:
> 1 - find a UI for it: just providing N new commands doesn't seem good enough.
>     Maybe just something like:
>
>     (define-minor-mode dired-isearch-filenames-mode
>       "Only match filenames in isearch."
>       (if dired-isearch-filenames-mode
>           (set (make-local-variable 'isearch-search-fun-function)
>                'dired-isearch-search-fun-function)
>         (kill-local-variable 'isearch-search-fun-function)))
>
>     and then bind it to a key?

And to use the same key to activate other links-only searches like on
links in Info (filenames in dired buffers are links too).

> 2 - checking `help-echo' is bound to get us into trouble when we add
>     help-echo to other elements such as access right bits, etc...
>     We really should check `dired-filename'.  And if that doesn't work,
>     let's fix it so that it does.  And/or add a dired-pos-in-filename-p
>     predicate to abstract over it.

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

Re: propose: dired-isearch.el --- isearch in Dired

[Richard Stallman]

    A simple but quite useful extension, which does isearch in Dired but
    match only at filenames.

I can see why the operation is useful, but I am not sure that the usual
isearch operation is so useless that we what to replace it.

This is the sort of question for which I used to poll the users.
Does someone want to do that?

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

Richard Stallman <rms@gnu.org> writes:

> I can see why the operation is useful, but I am not sure that the usual
> isearch operation is so useless that we what to replace it.

The usual isearch operation is not replaced, user can still call
isearch-* functions.  dired-isearch.el just provides some new functions.

-- 
William

RE: propose: dired-isearch.el --- isearch in Dired

[Herbert Euler]

Without applying Juri's proposal, this is an implementation that
resolves both the two bugs mentioned in my previous message: the
regexp "^" bug and searching goes into fields other than file names
bug.  I think other functions (e.g. dired-re-search-backward) can be
implemented this way too.

(defun dired-next-file-name (point bound)
  (let* ((start (cond ((= point 1)
                       (if (get-char-property point 'help-echo)
                           point
                         (next-single-property-change point 'help-echo)))
                      ((get-char-property point 'help-echo)
                       (if (get-char-property (1- point) 'help-echo)
                           (progn
                             (setq point
                                   (next-single-property-change point
                                                                'help-echo))
                             (next-single-property-change point 'help-echo))
                         point))
                      (t
                       (next-single-property-change point 'help-echo))))
         (end (when start
                (next-single-property-change start 'help-echo))))
    (when (and end (< end bound))
      (goto-char start)
      (buffer-substring start end))))

(defun dired-re-search-forward (regexp &optional bound noerror count)
  "In Dired, run `re-search-forward' but match only at file names."
  (let ((start (point))
        (not-found nil)
        name
        match-data)
    (save-excursion
      (unless bound
        (setq bound (point-max)))
      (while (and (prog1 (setq name (dired-next-file-name start bound))
                    (unless name (setq not-found t)))
                  (not (string-match regexp name)))
        (setq start (1+ (point))))
      (unless not-found
        (setq match-data (list (+ (point) (match-beginning 0))
                               (+ (point) (match-end 0))))
        (set-match-data match-data)
        (nth 1 match-data)))))

Please consider rewriting other functions this way.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: propose: dired-isearch.el --- isearch in Dired

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>    =>
>
>    (let (X)
>      (while (progn (setq X EXP) C)
>        BODY)
>      TAIL)
>
> Often BODY is empty (in which case the loop would be a do...while in C).

I wish every language had some sort of nice "test-in-the-middle" loop
construct!

In C, the existing syntax seems to cry out for it, even:

    do
      {
        something;
      }
    while (test)
      {
        something else;
      }

:-]

-miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually all the search funs can be collapsed into one:
>
>    (defun dired-isearch-search-fun-function () 'dired-isearch-search)
>    
>    (defun dired-isearch-search (&rest args)
>      (let ((fun (let ((isearch-search-fun-function nil))
>                   (isearch-search-fun)))

It seems (isearch-search-fun) is problematic here. forward + backward
search would fail.

>            ret)
>        (while (and (setq ret (apply fun args))
>                    ;; Use `help-echo' instead of `dired-filename' so as to
>                    ;; also work in Tramp dired buffers.
>                    (not (get-text-property (1- point) 'help-echo)))
>          (forward-char 1))

I tried this trick, the bug is still there. Maybe need to look into
isearch itself..

>        ret))
>
> But there are two problems left:
> 1 - find a UI for it: just providing N new commands doesn't seem good enough.
>     Maybe just something like:
> 
>     (define-minor-mode dired-isearch-filenames-mode
>       "Only match filenames in isearch."
>       (if dired-isearch-filenames-mode
>           (set (make-local-variable 'isearch-search-fun-function)
>                'dired-isearch-search-fun-function)
>         (kill-local-variable 'isearch-search-fun-function)))
>
>     and then bind it to a key?

Although i think it's good enough, your idea is also very good. User can
put it into some dired hooks.

> 2 - checking `help-echo' is bound to get us into trouble when we add
>     help-echo to other elements such as access right bits, etc...
>     We really should check `dired-filename'.  And if that doesn't work,
>     let's fix it so that it does.  And/or add a dired-pos-in-filename-p
>     predicate to abstract over it.

Checking 'dired-filename fails in tramp dired buffers. I'm not sure
whether this is a bug or not.

-- 
William

RE: propose: dired-isearch.el --- isearch in Dired

[Drew Adams]

>     A simple but quite useful extension, which does isearch in Dired but
>     match only at filenames.
>
> I can see why the operation is useful, but I am not sure that the usual
> isearch operation is so useless that we what to replace it.
>
> This is the sort of question for which I used to poll the users.
> Does someone want to do that?

I haven't looked at the details, but in principle I have no objection, as
long as this command is not bound to the standard isearch keys.

However, with the recent addition of `dired-details.el', the need for this
is not so great, IMO. I expect that many users will keep Dired details
hidden most of the time, in which case regular isearch searches only the
file names (they are all that is visible). And if you want to search other
than a file name, you just hit one key to toggle the display of details.

In sum, I'd prefer that regular isearch still be bound to its normal keys
(C-s, C-r, C-M-s, C-M-r). I don't really care whether dired-isearch.el is
added or bound to other keys. I probably won't use it, but others might.

Re: propose: dired-isearch.el --- isearch in Dired

[Richard Stallman]

    The usual isearch operation is not replaced, user can still call
    isearch-* functions.

Yes, but the key bindings for it are replaced.  So it isn't easy
to call the ordinary isearch-* functions.

It may be a good change, but I'd like to see users' reactions
after using it for a while, to try to determine if that is so.

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

Richard Stallman <rms@gnu.org> writes:

> Yes, but the key bindings for it are replaced.  

Then maybe Stefan's minor mode idea could solve this better.

> So it isn't easy to call the ordinary isearch-* functions.

Personaly, I never search fields other than filenames in Dired. I guess
most people also do.

-- 
William

Re: propose: dired-isearch.el --- isearch in Dired

[Mathias Dahl]

> Personaly, I never search fields other than filenames in Dired. I guess
> most people also do.

I think so too although occasionally I find it useful to search for
owner or group name or file size. However, I think I like Drew's
suggestion, to use dired-details and toggle the display of those extra
fields when we need to search in them. I haven't tried that out
though.

Re: propose: dired-isearch.el --- isearch in Dired

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> Personaly, I never search fields other than filenames in Dired. I guess
>> most people also do.
>
> I think so too although occasionally I find it useful to search for
> owner or group name or file size. However, I think I like Drew's
> suggestion, to use dired-details and toggle the display of those extra
> fields when we need to search in them. I haven't tried that out
> though.

That's jumpy.  How about using file-name-shadow face for this?

-- 
David Kastrup

RE: propose: dired-isearch.el --- isearch in Dired

[Drew Adams]

Mathias> I think I like Drew's suggestion, to use dired-details and
Mathias> toggle the display of those extra fields when we need to
Mathias> search in them. I haven't tried that out though.

FWIW, it works fine in Emacs 21 and 22. It does not work in Emacs 20 - the
invisible part of the buffer is still searched.

David> That's jumpy.

I assume you mean that the display changes when you hide the non-file
fields.

FWIW, my guess is that most people will end up leaving those fields
invisible much of the time, once they find out about dired-details. In that
case, there is no display change to search only the file names. Instead,
there would then be a display change to search beyond the file names.

An advantage of this approach is WYSIWYG: search searches the text that you
see, nothing more or less. Another advantage is that isearch always acts the
same, in Dired and elsewhere.

David> How about using file-name-shadow face for this?

Use it for what? Do you mean not hide the details and instead use that face
for fields other than the file names? How would that affect searching?

Re: propose: dired-isearch.el --- isearch in Dired

[William Xu]

"Drew Adams" <drew.adams@oracle.com> writes:

> FWIW, my guess is that most people will end up leaving those fields
> invisible much of the time, once they find out about dired-details.

In OSes like Windows XP, maybe this is true. But in *nix, i think those
"details" are still very valuable to be visible.

-- 
William

RE: propose: dired-isearch.el --- isearch in Dired

[Drew Adams]

> > FWIW, my guess is that most people will end up leaving those fields
> > invisible much of the time, once they find out about dired-details.
>
> In OSes like Windows XP, maybe this is true. But in *nix, i think those
> "details" are still very valuable to be visible.

No one said they are not valuable. I've used UNIX for 25 years and GNU/Linux
for over a decade, so I'm aware of that. Let the details show all of the
time, if you prefer. I hide them most of the time - on GNU/Linux as well as
Windows.

The point is that you don't need to sacrifice screen real estate when you're
not looking at that information. And when you want it, it's only a keystroke
away.

Re: propose: dired-isearch.el --- isearch in Dired

[Robert J. Chassell]

   > FWIW, my guess is that most people will end up leaving those fields
   > invisible much of the time, once they find out about dired-details.

   In OSes like Windows XP, maybe this is true. But in *nix, i think those
   "details" are still very valuable to be visible.

William Xu is right.  Having found out about dired-details, I will
never use it again.  As a practical matter, I often search for
permissions and sort by time.

Different people do different things.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: propose: dired-isearch.el --- isearch in Dired

[Drew Adams]

>    > FWIW, my guess is that most people will end up leaving those fields
>    > invisible much of the time, once they find out about dired-details.
>
>    In OSes like Windows XP, maybe this is true. But in *nix, i think those
>    "details" are still very valuable to be visible.
>
> William Xu is right.  Having found out about dired-details, I will
> never use it again.  As a practical matter, I often search for
> permissions and sort by time.
>
> Different people do different things.

Your last sentence makes sense, and argues against your first one. It's
about personal preference, not about right vs wrong, correct vs incorrect.

FWIW, I often sort by time too - very often. But often I'm interested mainly
in the chronological order and I don't really care about seeing the exact
times. Different people sometimes do the same thing differently.

No one is proposing to take away your valuable details. This is a discussion
about isearch in Dired. If you "often search for permissions", then that is
an argument for keeping the normal isearch bindings. So we agree.

Re: propose: dired-isearch.el --- isearch in Dired

[Juri Linkov]

>> FWIW, my guess is that most people will end up leaving those fields
>> invisible much of the time, once they find out about dired-details.
>
> In OSes like Windows XP, maybe this is true. But in *nix, i think those
> "details" are still very valuable to be visible.

Even in *nix, `ls' without options or with `-1' lists just file names.
But I agree that in Dired the best default is to list details and allow
isearch to search everything.  I regularly use isearch to search
filenames, but sometimes also need to search file sizes and dates.

I have one idea: if the initial point position before search is on the
filename, then search filenames only.  If the initial position is on the
date, then search dates only, and so on for other ls columns.

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

RE: propose: dired-isearch.el --- isearch in Dired

[Drew Adams]

> >> FWIW, my guess is that most people will end up leaving those fields
> >> invisible much of the time, once they find out about dired-details.
> >
> > In OSes like Windows XP, maybe this is true. But in *nix, i think
> > those "details" are still very valuable to be visible.
>
> Even in *nix, `ls' without options or with `-1' lists just file names.
> But I agree that in Dired the best default is to list details and allow
> isearch to search everything.

I agree with those defaults.

> I regularly use isearch to search
> filenames, but sometimes also need to search file sizes and dates.

I too want normal isearch, not just file-name search. And with the normal
isearch bindings. It's no problem to have an additional search command for
file names, if people want that, but it shouldn't use C-s (or C-M-s).

> I have one idea: if the initial point position before search is on the
> filename, then search filenames only.  If the initial position is on the
> date, then search dates only, and so on for other ls columns.

I don't like that; it's too restrictive. I don't want to have to position
the cursor just to make sure I get the right kind of search. That's far more
difficult than hitting a key to hide everything but the file names.

However, if people think it is useful to have field-specific searches
(beyond just file names), then we could have commands for that. They could
have other bindings than the standard isearch ones, and they could be added
to a Dired menu. They could even be accessible from isearch (e.g. C-s
<some-key>). But plain old isearch should be available in Dired too, with
its standard bindings.

Re: propose: dired-isearch.el --- isearch in Dired

[Juri Linkov]

>> I have one idea: if the initial point position before search is on the
>> filename, then search filenames only.  If the initial position is on the
>> date, then search dates only, and so on for other ls columns.
>
> I don't like that; it's too restrictive. I don't want to have to position
> the cursor just to make sure I get the right kind of search. That's far more
> difficult than hitting a key to hide everything but the file names.

I need to search file names without hiding everything else.

> However, if people think it is useful to have field-specific searches
> (beyond just file names), then we could have commands for that. They could
> have other bindings than the standard isearch ones, and they could be added
> to a Dired menu. They could even be accessible from isearch (e.g. C-s
> <some-key>). But plain old isearch should be available in Dired too, with
> its standard bindings.

Plain isearch could be available when called not at the file line, e.g. at
the beginning of the dired buffer.

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

Re: propose: dired-isearch.el --- isearch in Dired

[Mathias Megyei]

On Mon, 2007-08-13 at 02:23 +0300, Juri Linkov wrote:

> I need to search file names without hiding everything else.

What about a special prefix (e.g. C-u) to let C-s search 
filenames only.
Other numeric arguments would still start regular expression search.

C-u has already special meaning in some cases. From C-h k C-u:

   For some commands, just C-u by itself serves as a flag
   which is different in effect from any particular numeric argument.
   These commands include . and M-x start-kbd-macro.

Mathias

Re: propose: dired-isearch.el --- isearch in Dired

[Andreas Schwab]

Mathias Megyei <mathias@mnet-mail.de> writes:

> On Mon, 2007-08-13 at 02:23 +0300, Juri Linkov wrote:
>
>> I need to search file names without hiding everything else.
>
> What about a special prefix (e.g. C-u) to let C-s search 
> filenames only.

C-s runs the command isearch-forward
[...]
With a prefix argument, do an incremental regular expression search instead.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: propose: dired-isearch.el --- isearch in Dired

[Mathias Dahl]

> > What about a special prefix (e.g. C-u) to let C-s search
> > filenames only.
>
> C-s runs the command isearch-forward
> [...]
> With a prefix argument, do an incremental regular expression search instead.

How about a numeric prefix argument then?

Re: isearch in Dired

[Juri Linkov]

Isearch in Dired limited to filenames only is a good feature, so I'd like
to finish it with the patch below.

The main point is that it doesn't change default Isearch key bindings
C-s and C-M-s.  It provides two ways to limit Isearch to filenames:

1. new user option `dired-isearch-filenames'.
   It is nil by default, but when custimized to non-nil,
   C-s and C-M-s search only in filenames.

2. new commands `'dired-do-isearch-filenames' and
   `dired-do-isearch-regexp-filenames' bound to the
   keys `M-s f C-s' and `M-s f M-C-s'.
   Two similar key bindings from another patch are for
   demonstration purposes: `M-s a C-s' and `M-s a M-C-s'
   are placed on the same prefix key and they start Isearch
   in all marked files.

For this feature to work reliably it was necessary to put text
properties `filename' on file name areas.  Tramp already puts it
in Tramp buffer, and it seems the `filename' property in all Dired
buffers doesn't conflict with Tramp.

Index: lisp/dired.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired.el,v
retrieving revision 1.402
diff -c -r1.402 dired.el
*** lisp/dired.el	19 Jul 2008 23:55:41 -0000	1.402
--- lisp/dired.el	23 Jul 2008 20:33:44 -0000
***************
*** 1068,1074 ****
  		 (dired-move-to-end-of-filename)
  		 (point))
  	       '(mouse-face highlight
! 		 help-echo "mouse-2: visit this file in other window")))
  	(error nil))
        (forward-line 1))))
  \f
--- 1068,1075 ----
  		 (dired-move-to-end-of-filename)
  		 (point))
  	       '(mouse-face highlight
! 		 help-echo "mouse-2: visit this file in other window"
! 		 filename t)))
  	(error nil))
        (forward-line 1))))
  \f
***************
*** 1295,1300 ****
--- 1297,1307 ----
      ;; hiding
      (define-key map "$" 'dired-hide-subdir)
      (define-key map "\M-$" 'dired-hide-all)
+     ;; isearch
+     (define-key map (kbd "M-s a C-s")   'dired-do-isearch-marked-files)
+     (define-key map (kbd "M-s a M-C-s") 'dired-do-isearch-regexp-marked-files)
+     (define-key map (kbd "M-s f C-s")   'dired-do-isearch-filenames)
+     (define-key map (kbd "M-s f M-C-s") 'dired-do-isearch-regexp-filenames)
      ;; misc
      (define-key map "\C-x\C-q" 'dired-toggle-read-only)
      (define-key map "?" 'dired-summary)
***************
*** 1713,1718 ****
--- 1720,1726 ----
    (when (featurep 'dnd)
      (set (make-local-variable 'dnd-protocol-alist)
  	 (append dired-dnd-protocol-alist dnd-protocol-alist)))
+   (add-hook 'isearch-mode-hook 'dired-isearch-filenames-setup nil t)
    (run-mode-hooks 'dired-mode-hook))
  \f
  ;; Idiosyncratic dired commands that don't deal with marks.

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.170
diff -c -r1.170 dired-aux.el
*** lisp/dired-aux.el	6 May 2008 07:57:30 -0000	1.170
--- lisp/dired-aux.el	23 Jul 2008 20:33:59 -0000
***************
*** 2273,2281 ****
--- 2293,2363 ----
  ;;;###end dired-ins.el
  
  \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."
+   :version "23.1"
+   :type '(choice (const :tag "No restrictions" nil)
+ 		 (const :tag "Isearch only in file names" filename))
+   :group 'dired)
+ 
+ (defvar dired-isearch-orig-success-function nil)
+ 
+ (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
+     (setq dired-isearch-orig-success-function
+ 	  (default-value 'isearch-success-function))
+     (setq-default isearch-success-function 'dired-isearch-success-function)
+     (add-hook 'isearch-mode-end-hook 'dired-isearch-filenames-end nil t)))
+ 
+ (defun dired-isearch-filenames-end ()
+   "Clean up the Dired file name search after terminating isearch."
+   (setq-default isearch-success-function dired-isearch-orig-success-function)
+   (remove-hook 'isearch-mode-end-hook 'dired-isearch-filenames-end t))
+ 
+ (defun dired-isearch-success-function (beg end)
+   "Isearch only text that have a property specified in `dired-isearch-filenames'."
+   (and (isearch-success-function-default beg end)
+        (if dired-isearch-filenames
+ 	   (text-property-not-all (min beg end) (max beg end)
+ 				  'filename nil)
+ 	 t)))
+ 
+ ;;;###autoload
+ (defun dired-do-isearch-filenames ()
+   "Search for a string only in file names in the Dired buffer."
+   (interactive)
+   (let ((dired-isearch-filenames t))
+     (isearch-forward)))
+ 
+ ;;;###autoload
+ (defun dired-do-isearch-regexp-filenames ()
+   "Search for a regexp only in file names in the Dired buffer."
+   (interactive)
+   (let ((dired-isearch-filenames t))
+     (isearch-forward-regexp)))
+ 
+ \f
  ;; Functions for searching in tags style among marked files.

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

Re: isearch in Dired

[Mathias Dahl]

Is the filename property always set or is it just used when this
feature is turned on? If it is always there, does it affect the
performance for large listings? I use Dired a lot and would not like
to have it slower because of a minor feature like this.

2008/7/23, Juri Linkov <juri@jurta.org>:
> Isearch in Dired limited to filenames only is a good feature, so I'd like
> to finish it with the patch below.
>
> The main point is that it doesn't change default Isearch key bindings
> C-s and C-M-s.  It provides two ways to limit Isearch to filenames:
>
> 1. new user option `dired-isearch-filenames'.
>    It is nil by default, but when custimized to non-nil,
>    C-s and C-M-s search only in filenames.
>
> 2. new commands `'dired-do-isearch-filenames' and
>    `dired-do-isearch-regexp-filenames' bound to the
>    keys `M-s f C-s' and `M-s f M-C-s'.
>    Two similar key bindings from another patch are for
>    demonstration purposes: `M-s a C-s' and `M-s a M-C-s'
>    are placed on the same prefix key and they start Isearch
>    in all marked files.
>
> For this feature to work reliably it was necessary to put text
> properties `filename' on file name areas.  Tramp already puts it
> in Tramp buffer, and it seems the `filename' property in all Dired
> buffers doesn't conflict with Tramp.
>
> Index: lisp/dired.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/dired.el,v
> retrieving revision 1.402
> diff -c -r1.402 dired.el
> *** lisp/dired.el	19 Jul 2008 23:55:41 -0000	1.402
> --- lisp/dired.el	23 Jul 2008 20:33:44 -0000
> ***************
> *** 1068,1074 ****
>   		 (dired-move-to-end-of-filename)
>   		 (point))
>   	       '(mouse-face highlight
> ! 		 help-echo "mouse-2: visit this file in other window")))
>   	(error nil))
>         (forward-line 1))))
>
> --- 1068,1075 ----
>   		 (dired-move-to-end-of-filename)
>   		 (point))
>   	       '(mouse-face highlight
> ! 		 help-echo "mouse-2: visit this file in other window"
> ! 		 filename t)))
>   	(error nil))
>         (forward-line 1))))
>
> ***************
> *** 1295,1300 ****
> --- 1297,1307 ----
>       ;; hiding
>       (define-key map "$" 'dired-hide-subdir)
>       (define-key map "\M-$" 'dired-hide-all)
> +     ;; isearch
> +     (define-key map (kbd "M-s a C-s")   'dired-do-isearch-marked-files)
> +     (define-key map (kbd "M-s a M-C-s")
> 'dired-do-isearch-regexp-marked-files)
> +     (define-key map (kbd "M-s f C-s")   'dired-do-isearch-filenames)
> +     (define-key map (kbd "M-s f M-C-s")
> 'dired-do-isearch-regexp-filenames)
>       ;; misc
>       (define-key map "\C-x\C-q" 'dired-toggle-read-only)
>       (define-key map "?" 'dired-summary)
> ***************
> *** 1713,1718 ****
> --- 1720,1726 ----
>     (when (featurep 'dnd)
>       (set (make-local-variable 'dnd-protocol-alist)
>   	 (append dired-dnd-protocol-alist dnd-protocol-alist)))
> +   (add-hook 'isearch-mode-hook 'dired-isearch-filenames-setup nil t)
>     (run-mode-hooks 'dired-mode-hook))
>
>   ;; Idiosyncratic dired commands that don't deal with marks.
>
> Index: lisp/dired-aux.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
> retrieving revision 1.170
> diff -c -r1.170 dired-aux.el
> *** lisp/dired-aux.el	6 May 2008 07:57:30 -0000	1.170
> --- lisp/dired-aux.el	23 Jul 2008 20:33:59 -0000
> ***************
> *** 2273,2281 ****
> --- 2293,2363 ----
>   ;;;###end dired-ins.el
>
>
> + ;; Search only in file names in the Dired buffer.
> +
> + (defcustom dired-isearch-filenames nil
> +   "*If non-nil, Isearch in Dired matches only file names."
> +   :version "23.1"
> +   :type '(choice (const :tag "No restrictions" nil)
> + 		 (const :tag "Isearch only in file names" filename))
> +   :group 'dired)
> +
> + (defvar dired-isearch-orig-success-function nil)
> +
> + (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
> +     (setq dired-isearch-orig-success-function
> + 	  (default-value 'isearch-success-function))
> +     (setq-default isearch-success-function
> 'dired-isearch-success-function)
> +     (add-hook 'isearch-mode-end-hook 'dired-isearch-filenames-end nil t)))
> +
> + (defun dired-isearch-filenames-end ()
> +   "Clean up the Dired file name search after terminating isearch."
> +   (setq-default isearch-success-function
> dired-isearch-orig-success-function)
> +   (remove-hook 'isearch-mode-end-hook 'dired-isearch-filenames-end t))
> +
> + (defun dired-isearch-success-function (beg end)
> +   "Isearch only text that have a property specified in
> `dired-isearch-filenames'."
> +   (and (isearch-success-function-default beg end)
> +        (if dired-isearch-filenames
> + 	   (text-property-not-all (min beg end) (max beg end)
> + 				  'filename nil)
> + 	 t)))
> +
> + ;;;###autoload
> + (defun dired-do-isearch-filenames ()
> +   "Search for a string only in file names in the Dired buffer."
> +   (interactive)
> +   (let ((dired-isearch-filenames t))
> +     (isearch-forward)))
> +
> + ;;;###autoload
> + (defun dired-do-isearch-regexp-filenames ()
> +   "Search for a regexp only in file names in the Dired buffer."
> +   (interactive)
> +   (let ((dired-isearch-filenames t))
> +     (isearch-forward-regexp)))
> +
> +
>   ;; Functions for searching in tags style among marked files.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>

Re: isearch in Dired

[Stefan Monnier]

> Isearch in Dired limited to filenames only is a good feature, so I'd like
> to finish it with the patch below.

> The main point is that it doesn't change default Isearch key bindings
> C-s and C-M-s.  It provides two ways to limit Isearch to filenames:

> 1. new user option `dired-isearch-filenames'.
>    It is nil by default, but when custimized to non-nil,
>    C-s and C-M-s search only in filenames.

> 2. new commands `'dired-do-isearch-filenames' and
>    `dired-do-isearch-regexp-filenames' bound to the
>    keys `M-s f C-s' and `M-s f M-C-s'.
>    Two similar key bindings from another patch are for
>    demonstration purposes: `M-s a C-s' and `M-s a M-C-s'
>    are placed on the same prefix key and they start Isearch
>    in all marked files.

> For this feature to work reliably it was necessary to put text
> properties `filename' on file name areas.  Tramp already puts it
> in Tramp buffer, and it seems the `filename' property in all Dired
> buffers doesn't conflict with Tramp.

ls-lisp uses `dired-filename'.  And IIRC wdired.el as well.
Not sure why Tramp uses something else, but that should probably be
investigated and explained/fixed.

The other comment I have is that I'd like to be able to toggle the kind
of search from within isearch.  Currently within `isearch', we have M-c,
M-r to toggle the case sensitivity and the use of regexps, and it would
make sense to provide additional such toggles for "word search" (tho it
might rather be folded into the regexp-toggle since there are really
only 3 possible states, not 4), and (in dired buffers) toggle-filename
and in some other buffers, other such things would make sense.
We should come up with a prefix key in isearch to replace M-c and M-r
and to give us space for extra toggles.


        Stefan

RE: isearch in Dired

[Drew Adams]

> The other comment I have is that I'd like to be able to 
> toggle the kind of search from within isearch.  Currently
> within `isearch', we have M-c, M-r to toggle the case
> sensitivity and the use of regexps, and it would
> make sense to provide additional such toggles for "word 
> search" (tho it might rather be folded into the
> regexp-toggle since there are really only 3 possible
> states, not 4), and (in dired buffers) toggle-filename
> and in some other buffers, other such things would make
> sense. We should come up with a prefix key in isearch to
> replace M-c and M-r and to give us space for extra toggles.

Sounds like a fair amount of specialization of Isearch, just for Dired...

Did Rob Giardina's dired-details stuff ever get added to Emacs (July 2007)? I
thought it had been merged in, but I don't find anything in the UI or doc about
it (e.g. which keys to hide/show? menu items?).

With that feature, normal Isearch gives you everything you need in this regard:
just hide all but the file names to search only for file names, then show all
other fields again, if you like. The normal Isearch toggles (e.g.
case-sensitivity) apply.

(I'm not necessarily against also adapting Isearch for Dired. This was mainly a
question about what happened to the dired-details stuff.)

Re: isearch in Dired

[Stefan Monnier]

> Sounds like a fair amount of specialization of Isearch, just for Dired...

Obviously, this is not just for dired.  This is to add a toggle for
word-search, and also for other specialized search facilities, such as
provided in hexl-mode maybe.  Also by using a prefix key for M-c and
M-r, this will free up a key binding.


        Stefan

dired-details status [was: isearch in Dired]

[Drew Adams]

> > Sounds like a fair amount of specialization of Isearch, 
> > just for Dired...
> 
> Obviously, this is not just for dired.  This is to add a toggle for
> word-search, and also for other specialized search facilities, such as
> provided in hexl-mode maybe.  Also by using a prefix key for M-c and
> M-r, this will free up a key binding.

As I said:

> (I'm not necessarily against also adapting Isearch for Dired. 
> This was mainly a question about what happened to the
> dired-details stuff.)

Any news on that?
Was it added? If not, could you please add it?

Re: isearch in Dired

[Juri Linkov]

> Is the filename property always set or is it just used when this
> feature is turned on? If it is always there, does it affect the
> performance for large listings? I use Dired a lot and would not like
> to have it slower because of a minor feature like this.

It is always there but I think it does not affect the performance.
As you can see, Dired already puts other text properties:

    mouse-face highlight
    help-echo "mouse-2: visit this file in other window"

so a new text property doesn't make this worse.

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

Re: isearch in Dired

[Juri Linkov]

> ls-lisp uses `dired-filename'.  And IIRC wdired.el as well.
> Not sure why Tramp uses something else, but that should probably be
> investigated and explained/fixed.

OK, at least I will use `dired-filename' for Dired filename Isearch.

> The other comment I have is that I'd like to be able to toggle the kind
> of search from within isearch.  Currently within `isearch', we have M-c,
> M-r to toggle the case sensitivity and the use of regexps, and it would
> make sense to provide additional such toggles for "word search" (tho it
> might rather be folded into the regexp-toggle since there are really
> only 3 possible states, not 4), and (in dired buffers) toggle-filename
> and in some other buffers, other such things would make sense.
> We should come up with a prefix key in isearch to replace M-c and M-r
> and to give us space for extra toggles.

Such a prefix already exists in Isearch, so we could use `M-s f' to
toggle filename-only Isearch.

As for 3-state regexp/word toggles, I currently have no idea for a
good key: "r" means "regexp" and "w" means "word", but I don't see
what a key would be common for them.

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

Re: isearch in Dired

[Lennart Borgman (gmail)]

Juri Linkov wrote:
> As for 3-state regexp/word toggles, I currently have no idea for a
> good key: "r" means "regexp" and "w" means "word", but I don't see
> what a key would be common for them.

r - regular expression search
w - word search
s - search

Re: word search (Re: isearch in Dired)

[Juri Linkov]

>> As for 3-state regexp/word toggles, I currently have no idea for a
>> good key: "r" means "regexp" and "w" means "word", but I don't see
>> what a key would be common for them.
>
> r - regular expression search
> w - word search
> s - search

When you want to switch to the regexp search then the most natural key
is "r".  When you want to switch to the word search then the most natural
key is "w".  Currently I see no alternative common key whose mnemonics
would be obvious.  So to toggle to the regexp or word search and back
to the non-regexp non-word search could be done using either of two keys
`M-s r' or `M-s w'.  It seems there is no problem with this.  In this
case, the following patch looks like a satisfactory solution.  It also
binds `M-s w' globally to start word isearch.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.324
diff -c -r1.324 isearch.el
*** lisp/isearch.el	27 Jul 2008 18:24:30 -0000	1.324
--- lisp/isearch.el	29 Jul 2008 15:43:27 -0000
***************
*** 491,496 ****
--- 491,499 ----
      (define-key map "\M-r" 'isearch-toggle-regexp)
      (define-key map "\M-e" 'isearch-edit-string)
  
+     (define-key map "\M-sr" 'isearch-toggle-regexp)
+     (define-key map "\M-sw" 'isearch-toggle-word)
+ 
      (define-key map [?\M-%] 'isearch-query-replace)
      (define-key map [?\C-\M-%] 'isearch-query-replace-regexp)
      (define-key map "\M-so" 'isearch-occur)
***************
*** 596,601 ****
--- 599,605 ----
  (define-key esc-map "\C-s" 'isearch-forward-regexp)
  (define-key global-map "\C-r" 'isearch-backward)
  (define-key esc-map "\C-r" 'isearch-backward-regexp)
+ (define-key search-map "w" 'isearch-forward-word)
  
  ;; Entry points to isearch-mode.
  
***************
*** 684,689 ****
--- 693,708 ----
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))
  
+ (defun isearch-forward-word (&optional not-word no-recursive-edit)
+   "\
+ Do incremental search forward for a sequence of words.
+ With a prefix argument, do a regular string search instead.
+ Like ordinary incremental search except that your input
+ is treated as a sequence of words without regard to how the
+ words are separated.  See \\[isearch-forward] for more info."
+   (interactive "P\np")
+   (isearch-mode t nil nil (not no-recursive-edit) (null not-word)))
+ 
  (defun isearch-backward (&optional regexp-p no-recursive-edit)
    "\
  Do incremental search backward.
***************
*** 1303,1308 ****
--- 1322,1334 ----
    (setq isearch-success t isearch-adjusted t)
    (isearch-update))
  
+ (defun isearch-toggle-word ()
+   "Toggle word searching on or off."
+   (interactive)
+   (setq isearch-word (not isearch-word))
+   (setq isearch-success t isearch-adjusted t)
+   (isearch-update))
+ 
  (defun isearch-toggle-case-fold ()
    "Toggle case folding in searching on or off."
    (interactive)

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

Re: isearch in Dired

[Juri Linkov]

>> The other comment I have is that I'd like to be able to toggle the kind
>> of search from within isearch.  Currently within `isearch', we have M-c,
>> M-r to toggle the case sensitivity and the use of regexps, and it would
>> make sense to provide additional such toggles for "word search" (tho it
>> might rather be folded into the regexp-toggle since there are really
>> only 3 possible states, not 4), and (in dired buffers) toggle-filename
>> and in some other buffers, other such things would make sense.
>> We should come up with a prefix key in isearch to replace M-c and M-r
>> and to give us space for extra toggles.
>
> Such a prefix already exists in Isearch, so we could use `M-s f' to
> toggle filename-only Isearch.

I see that it is better to implement this in isearch.el to toggle the effect
of the variable `isearch-success-function' but for a general solution we need
a general function name for the letter "f".  It seems a good name is "field"
since it narrows the search to a set of fields where one particular case is
Dired file names.  Then a new function `isearch-toggle-fields' bound to
`M-s f' in Isearch mode will toggle the search restricted to fields/filenames.

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

Re: word search (Re: isearch in Dired)

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> When you want to switch to the regexp search then the most natural key
> is "r".  When you want to switch to the word search then the most natural
> key is "w".  Currently I see no alternative common key whose mnemonics
> would be obvious.  So to toggle to the regexp or word search and back
> to the non-regexp non-word search could be done using either of two keys
> `M-s r' or `M-s w'.  It seems there is no problem with this.  In this
> case, the following patch looks like a satisfactory solution.  It also
> binds `M-s w' globally to start word isearch.

Looks OK to me.  Please check it in ASAP, and don't forget to write a
NEWS entry, and to document the keybinding in the docstring of
`isearch'.

Something that might be good to work on, after the release, is a better
help facility for C-s, to allow the user to remind himself what the
isearch key bindings are.  The current `C-s C-h ? [bmk]' menus aren't
very easy to read.

Re: isearch in Dired

[Stefan Monnier]

> I see that it is better to implement this in isearch.el to toggle the effect
> of the variable `isearch-success-function' but for a general solution we need
> a general function name for the letter "f".  It seems a good name is "field"

I think the key to use should be chosen by the client package
(e.g. dired in this case), so that the key can be a menmonic for its
functionality (rather than for its implementation technique).


        Stefan

Re: isearch in Dired

[Juri Linkov]

>> I see that it is better to implement this in isearch.el to toggle the effect
>> of the variable `isearch-success-function' but for a general solution we need
>> a general function name for the letter "f".  It seems a good name is "field"
>
> I think the key to use should be chosen by the client package
> (e.g. dired in this case), so that the key can be a menmonic for its
> functionality (rather than for its implementation technique).

Ok, this is implemented by the patch below:

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.176
diff -c -r1.176 dired-aux.el
*** lisp/dired-aux.el	30 Jul 2008 14:18:04 -0000	1.176
--- lisp/dired-aux.el	30 Jul 2008 14:27:08 -0000
***************
*** 2310,2320 ****
--- 2321,2346 ----
  
  (defvar dired-isearch-orig-success-function nil)
  
+ (defun dired-isearch-filenames-toggle ()
+   "Toggle file names searching on or off.
+ When on, Isearch checks the success of the current matching point
+ using the function `dired-isearch-success-function' that matches only
+ at file names.  When off, it uses the default function
+ `isearch-success-function-default'."
+   (interactive)
+   (setq isearch-success-function
+ 	(if (eq isearch-success-function 'dired-isearch-success-function)
+ 	    'isearch-success-function-default
+ 	  'dired-isearch-success-function))
+   (setq isearch-success t isearch-adjusted t)
+   (isearch-update))
+ 
  ;;;###autoload
  (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))
      (setq-default isearch-success-function 'dired-isearch-success-function)
***************
*** 2322,2327 ****
--- 2348,2354 ----
  
  (defun dired-isearch-filenames-end ()
    "Clean up the Dired file name search after terminating isearch."
+   (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/

Re: word search (Re: isearch in Dired)

[Juri Linkov]

>> When you want to switch to the regexp search then the most natural key
>> is "r".  When you want to switch to the word search then the most natural
>> key is "w".  Currently I see no alternative common key whose mnemonics
>> would be obvious.  So to toggle to the regexp or word search and back
>> to the non-regexp non-word search could be done using either of two keys
>> `M-s r' or `M-s w'.  It seems there is no problem with this.  In this
>> case, the following patch looks like a satisfactory solution.  It also
>> binds `M-s w' globally to start word isearch.
>
> Looks OK to me.  Please check it in ASAP, and don't forget to write a
> NEWS entry, and to document the keybinding in the docstring of
> `isearch'.

Done.

> Something that might be good to work on, after the release, is a better
> help facility for C-s, to allow the user to remind himself what the
> isearch key bindings are.  The current `C-s C-h ? [bmk]' menus aren't
> very easy to read.

BTW, I already half-finished a new help facility based on Info.
It also provides a virtual Info file for `Info-apropos' that contains
results of different invocations in separate virtual Info nodes.
I afraid it's too late to include this to 23.1.

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

Re: word search (Re: isearch in Dired)

[Juri Linkov]

>> Looks OK to me.  Please check it in ASAP, and don't forget to write a
>> NEWS entry, and to document the keybinding in the docstring of
>> `isearch'.
>
> Done.

Actually incremental word search is useless.  While typing a sequence of
words, incremental word search advances forward through false positives
and failures because it tries to match on all incomplete word boundaries.
When the user finishes typing a complete sequence of words, the current
match may skip some matches from the starting point.  So this behavior
makes more harm!

What is necessary instead is reading a sequence of words in the minibuffer,
starting Isearch on the entered words, and using C-s or C-r to find next or
previous word occurrences.  This is essentially what currently a clumsy trick
`C-s M-e C-w' tries to do.  But it is better to put this feature on `M-s w'.
This was already discussed in March 2008, and Stefan agreed to this change
but Richard worried about eliminating the C-w word-search feature.

So I propose to display a warning after typing C-w in the isearch-edit-string
minibuffer that this feature is obsolete and suggest using `M-s w' instead
for the upcoming release.  After this release, we can eliminate it completely
or replace with word-yanking.

The following patch does this, and also binds `M-s w' to a new command that
starts Isearch with reading a sequence of words in the minibuffer.  This
feature is useful for regexp Isearch as well because often it is distracting
to see warnings "incomplete input" while typing a complex regexp in Isearch
mode.  So it binds `M-s r' to a similar command that reads a regexp in the
minibuffer and starts Isearch with it.

This is the last patch I submit before the feature freeze, and I think
it is important to install it now.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.325
diff -c -r1.325 isearch.el
*** lisp/isearch.el	30 Jul 2008 16:40:23 -0000	1.325
--- lisp/isearch.el	31 Jul 2008 12:35:35 -0000
***************
*** 509,514 ****
--- 509,515 ----
      (define-key map "\M-\t" 'isearch-complete-edit)
      (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
      (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
+     (define-key map "\C-w"  'isearch-edit-string-set-word)
      (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
      (define-key map [right] 'isearch-yank-char-in-minibuffer)
      map)
***************
*** 599,605 ****
  (define-key esc-map "\C-s" 'isearch-forward-regexp)
  (define-key global-map "\C-r" 'isearch-backward)
  (define-key esc-map "\C-r" 'isearch-backward-regexp)
! (define-key search-map "w" 'isearch-forward-word)
  
  ;; Entry points to isearch-mode.
  
--- 600,607 ----
  (define-key esc-map "\C-s" 'isearch-forward-regexp)
  (define-key global-map "\C-r" 'isearch-backward)
  (define-key esc-map "\C-r" 'isearch-backward-regexp)
! (define-key search-map "r" 'isearch-edit-regexp-search)
! (define-key search-map "w" 'isearch-edit-word-search)
  
  ;; Entry points to isearch-mode.
  
***************
*** 693,708 ****
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))
  
- (defun isearch-forward-word (&optional not-word no-recursive-edit)
-   "\
- Do incremental search forward for a sequence of words.
- With a prefix argument, do a regular string search instead.
- Like ordinary incremental search except that your input
- is treated as a sequence of words without regard to how the
- words are separated.  See \\[isearch-forward] for more info."
-   (interactive "P\np")
-   (isearch-mode t nil nil (not no-recursive-edit) (null not-word)))
- 
  (defun isearch-backward (&optional regexp-p no-recursive-edit)
    "\
  Do incremental search backward.
***************
*** 715,725 ****
    (interactive "P\np")
    (isearch-mode nil (null not-regexp) nil (not no-recursive-edit)))
  
+ (defun isearch-edit-regexp-search ()
+   "Read regular expression and do incremental search on input.
+ It reads regular expression in the minibuffer, and after exiting minibuffer
+ with RET, C-s or C-r, Isearch starts incremental search with the entered
+ regular expression.  See the command `isearch-forward' for more information."
+   (interactive)
+   (isearch-mode t t nil nil)
+   (isearch-edit-string))
+ 
+ (defun isearch-edit-word-search ()
+   "Read sequence of words and do incremental search on input.
+ It reads words in the minibuffer, and after exiting minibuffer
+ with RET, C-s or C-r, Isearch starts incremental search with
+ entered words without regard to how the words are separated.
+ See the command `isearch-forward' for more information."
+   (interactive)
+   (isearch-mode t nil nil nil t)
+   (isearch-edit-string))
+ 
  \f
  ;; isearch-mode only sets up incremental search for the minor mode.
  ;; All the work is done by the isearch-mode commands.
***************
*** 1111,1141 ****
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
- 	  (isearch-message) ;; for read-char
  	  (unwind-protect
! 	      (let* (;; Why does following read-char echo?
! 		     ;;(echo-keystrokes 0) ;; not needed with above message
! 		     (e (let ((cursor-in-echo-area t))
! 			  (read-event)))
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol)
! 		     (message-log-max nil))
! 		;; If the first character the user types when we prompt them
! 		;; for a string is the yank-word character, then go into
! 		;; word-search mode.  Otherwise unread that character and
! 		;; read a key the normal way.
! 		;; Word search does not apply (yet) to regexp searches,
! 		;; no check is made here.
! 		(message "%s" (isearch-message-prefix nil nil t))
! 		(if (memq (lookup-key isearch-mode-map (vector e))
! 			  '(isearch-yank-word
! 			    isearch-yank-word-or-char))
! 		    (setq isearch-word t;; so message-prefix is right
! 			  isearch-new-word t)
! 		  (cancel-kbd-macro-events)
! 		  (isearch-unread e))
! 		(setq cursor-in-echo-area nil)
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
--- 1122,1132 ----
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
  	  (unwind-protect
! 	      (let* ((message-log-max nil)
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol))
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
***************
*** 1209,1214 ****
--- 1200,1214 ----
       (isearch-abort)  ;; outside of let to restore outside global values
       )))
  
+ ;; Obsolete usage of `C-s M-e C-w'.  Remove after 23.1.
+ (defvar isearch-new-word)
+ (defun isearch-edit-string-set-word ()
+   "Do word search after exiting `isearch-edit-string'."
+   (interactive)
+   (message "This feature is obsolete since 23.1; use `M-s w' instead.")
+   (setq isearch-word t isearch-new-word t))
+ 
+ 
  (defun isearch-nonincremental-exit-minibuffer ()
    (interactive)
    (setq isearch-nonincremental t)

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

Re: word search (Re: isearch in Dired)

[Stefan Monnier]

> Actually incremental word search is useless.  While typing a sequence of
> words, incremental word search advances forward through false positives
> and failures because it tries to match on all incomplete word boundaries.
> When the user finishes typing a complete sequence of words, the current
> match may skip some matches from the starting point.  So this behavior
> makes more harm!

I'm not sure what you mean by "this behavior".  If you mean the behavior
of M-s w, then it's no worse than what we had before, right?  And it
does allow circumventing this problem in some cases if you use "C-s
<words> M-s w".

The right behavior for word search would be to only add a "word
boundary" at the end of the pattern when the user is done entering
the pattern.  Since isearch has no such notion of "done entering the
pattern", getting things right requires extra changes. 

Your suggestion to just revert to a non-incremental search might be
a good one.  But I think it gives up a bit too early.  We should first
try harder to make incremental word search work.

E.g. we could provide a key that says "here, I'm done entering the
pattern".  That key could be C-s/C-r or RET, or something else.
Entering more text should probably revert back to "the pattern is not
done yet".

Thinking a bit more about it, there's already a key that will do just
that: SPC.  So I suggest we change isearch to not use
word-search-forward but use its own implementation of it that only adds
a trailing \b if the last char of the pattern is a word constituent.
It should give us the right behavior.

> So I propose to display a warning after typing C-w in the isearch-edit-string
> minibuffer that this feature is obsolete and suggest using `M-s w' instead
> for the upcoming release.  After this release, we can eliminate it completely
> or replace with word-yanking.

Fine by me.

> This feature is useful for regexp Isearch as well because often it is
> distracting to see warnings "incomplete input" while typing a complex
> regexp in Isearch mode.

I completely disagree.  I always use C-u C-s ... M-% to do regexp
search&replace specifically because it's so much more convenient to be
able to enter the regexp incrementally.  If you're bothered by the
"incomplete input" warning, we should try and address that directly.


        Stefan

Re: word search (Re: isearch in Dired)

[Juri Linkov]

>> Actually incremental word search is useless.  While typing a sequence of
>> words, incremental word search advances forward through false positives
>> and failures because it tries to match on all incomplete word boundaries.
>> When the user finishes typing a complete sequence of words, the current
>> match may skip some matches from the starting point.  So this behavior
>> makes more harm!
>
> I'm not sure what you mean by "this behavior".  If you mean the behavior
> of M-s w, then it's no worse than what we had before, right?

I meant the behavior of the global binding `M-s w' that I've
installed yesterday.  I discovered that it needs immediate fixing
since incremental word search doesn't work satisfactorily.

> And it does allow circumventing this problem in some cases if you use
> "C-s <words> M-s w".
>
> The right behavior for word search would be to only add a "word
> boundary" at the end of the pattern when the user is done entering
> the pattern.  Since isearch has no such notion of "done entering the
> pattern", getting things right requires extra changes.
>
> Your suggestion to just revert to a non-incremental search might be
> a good one.

I suggest to revert not to a completely non-incremental search like
what `word-search-forward' does interactively, but still starting a
normal incremental search after reading a sequence of words.  This
can be labelled as "initially non-incremental word search".

> But I think it gives up a bit too early.  We should first try harder
> to make incremental word search work.
>
> E.g. we could provide a key that says "here, I'm done entering the
> pattern".  That key could be C-s/C-r or RET, or something else.

This is what `isearch-edit-string' does in a less surprising way
because every Emacs user knows that RET exits the minibuffer
in contrast with typing RET to finish a sequence of words
in incremental word search.

> Entering more text should probably revert back to "the pattern is not
> done yet".
>
> Thinking a bit more about it, there's already a key that will do just
> that: SPC.  So I suggest we change isearch to not use
> word-search-forward but use its own implementation of it that only adds
> a trailing \b if the last char of the pattern is a word constituent.
> It should give us the right behavior.

Typing SPC to mark the end of the word sequence is not obvious too,
but perhaps with enough documentation might provide a convenient UI
for incremental word search.  I see this can be implemented in a way
similar to using the variable `search-whitespace-regexp' in regexp search.

>> This feature is useful for regexp Isearch as well because often it is
>> distracting to see warnings "incomplete input" while typing a complex
>> regexp in Isearch mode.
>
> I completely disagree.  I always use C-u C-s ... M-% to do regexp
> search&replace specifically because it's so much more convenient to be
> able to enter the regexp incrementally.  If you're bothered by the
> "incomplete input" warning, we should try and address that directly.

Sometimes it is sufficient to write a regexp non-incrementally without
paying attention where it matches during typing.  But really this is
not important since there is already the key `M-e', so it is easy
to type `C-u C-s M-e' when necessary.

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

Re: word search (Re: isearch in Dired)

[Stefan Monnier]

> So I suggest we change isearch to not use word-search-forward but use
> its own implementation of it that
> only adds a trailing \b if the last char of the pattern is a word constituent.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  doesn't add a trailing \b.


Stefan

Re: word search (Re: isearch in Dired)

[Stefan Monnier]

> Typing SPC to mark the end of the word sequence is not obvious too,
> but perhaps with enough documentation might provide a convenient UI
> for incremental word search.

Agreed.

>>> This feature is useful for regexp Isearch as well because often it is
>>> distracting to see warnings "incomplete input" while typing a complex
>>> regexp in Isearch mode.
>> 
>> I completely disagree.  I always use C-u C-s ... M-% to do regexp
>> search&replace specifically because it's so much more convenient to be
>> able to enter the regexp incrementally.  If you're bothered by the
>> "incomplete input" warning, we should try and address that directly.

> Sometimes it is sufficient to write a regexp non-incrementally without
> paying attention where it matches during typing.  But really this is
> not important since there is already the key `M-e', so it is easy
> to type `C-u C-s M-e' when necessary.

My thought exactly: I agree that sometimes it's more convenient to use
a minibuffer rather than the incremental search entry, but it should not
be the default for regexp isearch.


        Stefan