bug#17533: 24.4.50; Word Isearch bug

bug#17533: 24.4.50; Word Isearch bug

[Dani Moncayo]

From "emacs -Q":
  f o o RET - > f o o C-s M-s w - > f o o

Expected: Only the string "->foo" is matched.

Observed: There are two (quite strange) matches:
1. From the final dot in the *scratch* buffer to the end of the first
   "foo".
2. From the end of the first "foo" to the end of the second "foo".


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-04-21 on LEG570
Repository revision: 117001 dancol@dancol.org-20140421012855-xu7gwqdl59pgkgur
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252

-- 
Dani Moncayo

bug#17533: 24.4.50; Word Isearch bug

[Juri Linkov]

> From "emacs -Q":
>   f o o RET - > f o o C-s M-s w - > f o o
>
> Expected: Only the string "->foo" is matched.
>
> Observed: There are two (quite strange) matches:
> 1. From the final dot in the *scratch* buffer to the end of the first
>    "foo".
> 2. From the end of the first "foo" to the end of the second "foo".

In word search mode, non-word characters are interpreted as whitespace.

bug#17533: 24.4.50; Word Isearch bug

[Dani Moncayo]

> In word search mode, non-word characters are interpreted as whitespace.

IMO, that rule should have an exception: the characters in the current
search string should be interpreted as word characters (for the
purpose of the search), because IMO, what the user wants is to search
for occurrences of _that_ string (regardless of the type of its
characters), where the _surrounding_ characters are non-words.


-- 
Dani Moncayo

bug#17533: 24.4.50; Word Isearch bug

[Dani Moncayo]

On Wed, May 21, 2014 at 12:07 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>> In word search mode, non-word characters are interpreted as whitespace.
>
> IMO, that rule should have an exception: the characters in the current
> search string should be interpreted as word characters (for the
> purpose of the search), because IMO, what the user wants is to search
> for occurrences of _that_ string (regardless of the type of its
> characters), where the _surrounding_ characters are non-words.

Though admittedly, it's a bit odd to put non-word characters in a
word-type Isearch.

My use case is this: I was editing a C source code file, which had
things like: "pointer->foo", "pointer->foobar", and also stand-alone
variables "foo" and "foobar".

I wanted to find only the occurrences of "pointer->foo", so I tried to
do a word-type Isearch with "->foo" as search string.

Therefore, I think that I intuitively expected the following behavior
for word-type Isearch: find matches of (literally) the search string
which have a "change in type of character" in its boundaries, i.e.:

1. If the first character in my search string is word-type, its
previous character in the buffer must be non-word-type (and vice-versa).

2. If the last character in my search string is word-type, its
following character in the buffer must be non-word-type (and vice-versa).



-- 
Dani Moncayo

bug#17533: 24.4.50; Word Isearch bug

[Dani Moncayo]

> Therefore, I think that I intuitively expected the following behavior
> for word-type Isearch: find matches of (literally) the search string
> which have a "change in type of character" in its boundaries, i.e.:
>
> 1. If the first character in my search string is word-type, its
> previous character in the buffer must be non-word-type (and vice-versa).
>
> 2. If the last character in my search string is word-type, its
> following character in the buffer must be non-word-type (and vice-versa).

Mmmm... perphaps the "vice-versa"s above should be removed.


-- 
Dani Moncayo

bug#17533: 24.4.50; Word Isearch bug

[Dani Moncayo]

> In word search mode, non-word characters are interpreted as whitespace.

Indeed, I now remember the philosophy behind word-type Isearch: you
can search for "foo, bar" (with punctuation between the words) and
you'll find that sequence of words, regardless of the whitespace or
punctuation between the words.

So my expectations were wrong.

I'm closing the bug report.  Sorry for the noise.

-- 
Dani Moncayo