bug#14013: 24.3.50; dired-isearch-filenames-regexp is matching text outside filenames

[Michael Heerdegen]

Hi Juri,

thanks for working on this!

> > Would it be an appropriate approach to use a more sophisticated value
> > for `isearch-search-fun-function' for that case?  This function could
> > e.g. jump to the next filename before starting searching.
>
> Instead of duplicating the complex logic of `isearch-search-fun-function'
> in a new specialized function it would be better to implement this
> using hooks.

Ok.  In the meanwhile, I wrote a proof of concept, which seems to work
well (just for the record):

(defun dired-search-forward-filename-regexp (&rest args)
  (catch 'result
    (while t
      (let* ((result (apply #'search-forward-regexp args))
             (beg (and result (match-beginning 0)))
             (end (and result (match-end 0))))
        (if (or (not result)
                (and (get-text-property beg 'dired-filename)
                     (or (get-text-property end 'dired-filename)
                         (eq (char-after end) ?\n))))
            (throw 'result result)
          (if (eobp)
              (throw 'result nil)
            (goto-char (1+ beg))))))))

To test shortly, just eval

 (defun isearch-search-fun () 'dired-search-forward-filename-regexp)

Works well for me.  But I think that your approach is more appropriate
here.

> We have already a post-processing hook `isearch-update-post-hook'
> invoked after isearch has found matches.  So we need a similar hook
> invoked before isearch starts searching matches, with a name like
> `isearch-search-fun-pre-hook'.
>
> It fixes your test case of searching for ".*":

I quickly tested it.  But it doesn't yet do the right thing.  For the
first search hit, it does - but if you repeat searching (by repeatedly
hitting C-M-s), the behavior is like it is now - i.e., with repeated
searching, there is no progress.  Do you need to run
`isearch-search-fun-pre-hook' at other places as well?


Thanks,

Michael.