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

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]

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

[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

[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

[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

[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 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

[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

[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

[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

[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

[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.

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

[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

[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/

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

[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

[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

[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

[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]

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/