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

[Juri Linkov <juri@jurta.org>]

> I wonder if it is realistic to use a temporary helper buffer to
> implement ^.

Good idea.  Maybe even not a buffer, but just a string.
Are there any differences between buffer matching and string matching?

Then first we could remove ^ from the search regexp, and when it finds
something, then get the found buffer-substring using text properties
and match it with the original regexp that contains ^.

> I would like to have a kind of filter that would allow to restrict
> isearch and query replace to arbitrary parts of the buffer, defined e.g.
> by the presence of some text property, anything you can define.

This has been asked before for search/replace in a rectangular region.
So since we have pairs of beg/end bounds for parts of the rectangle,
it shouldn't be different from search/replace in Dired that uses
text properties.

> If we would use a helper buffer that contains only these chunks, ^ and
> such would work out of the box for all of these cases.  I guess that
> such a helper buffer would have to be filled on the fly, successively,
> and the hard part is the details of handling (updating, killing, etc)
> these buffers.

It seems you intended to use such buffers for more complex feature than handling ^.
Because when you copy such a rectangular region to a separate buffer:

     +---+
  123|456|789
  abc|def|ghi
     +---+

then do you want to match the copied parts as contiguous text?
So the above rectangle when copied to a separate buffer:

      456
      def

do you expect it should match the regexp "456.def"?