GNU bug report logs - #13402
24.2.92 pretest: bugs in isearch-yank-line in info page

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> jurta.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 13402 <at> debbugs.gnu.org
Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch]
Date: Wed, 20 Feb 2013 12:49:04 +0200

> I predict, if we don't fix it, there will be quite a few angry
> bug reports, a bit like when the "fringe" was introduced in 21.1
> with no way of disabling it, but probably not as bad.

Unlike fringes in 21.1, it's easy to disable this feature by customizing
`search-whitespace-regexp' to nil.

> And this _is_ a regression, maybe not in the code, but certainly from the
> point of view of a user.  It is true that this effect can be disabled by
> `isearch-toggle-lax-whitespace' but there is no way a normal user can
> find this out, apart from stumbling on it by luck.

I think you are overestimating the seriousness of the problem.
The highlighting effect that you don't like might seem peculiar
but it has a logical explanation.  Trying to change its logic to
more complicated will introduce other problems that might seem illogical
to other users.  For example, consider the following test case:

With `search-whitespace-regexp' customized to nil, try to put the cursor
to the second space character in the string "   Each entry" and type
`C-M-s SPC'.  It lazy-highlights the previous space character too
(it's the first space character in the string).  This is right.

Now with your patch applied, add the character "+" to the search regexp,
so that a complete search regexp is " +" and the cursor is on the second
space character in the string "   Each entry".  The result is that
the first space character is not lazy-highlighted.  I think this is wrong.

If you assume that the boundary of the current match should begin only
from the leading character of the search string, then you have to allow
the preceding match to be lazy-highlighted separately in its own right
(in the above case the first space character in the string) because
it matches the search regexp.

IOW, what is more logical to do according to your approach is not to hide
the lazy-highlighted match under point, but split it to two matches
where the match preceding the current search position is lazy-highlighted
and the second match under point is hidden.

> We can't really document this either.

Actually, documenting this effect is a very good idea
that in any case should be done in emacs-24.

> I'm surprised how difficult the fix is.

That's is why I prefer to refrain from making hasty changes that might
cause more problems in unexpected places making other users unhappy.

Previous Next

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