GNU bug report logs - #14013
24.3.50; dired-isearch-filenames-regexp is matching text outside filenames

Previous Next

Package: emacs;

Reported by: michael_heerdegen <at> web.de

Date: Wed, 20 Mar 2013 23:42:01 UTC

Severity: normal

Tags: patch

Merged with 29215

Found in versions 24.3.50, 26.0

Fixed in version 29.0.50

Done: Juri Linkov <juri <at> jurta.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> jurta.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 14013 <at> debbugs.gnu.org
Subject: bug#14013: 24.3.50; dired-isearch-filenames-regexp is matching text outside filenames
Date: Fri, 01 Apr 2022 19:39:10 +0300
> 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"?




This bug report was last modified 1 year and 352 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.