GNU bug report logs - #76167
31.0.50; view-mode un-expected jump-overs

Previous Next

Full log

View this message in rfc822 format

From: Tomas Nordin <tomasn <at> posteo.net>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 76167 <at> debbugs.gnu.org
Subject: bug#76167: 31.0.50; view-mode un-expected jump-overs
Date: Tue, 25 Feb 2025 20:39:16 +0000

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Tomas Nordin <tomasn <at> posteo.net>
>>> Date: Sun, 09 Feb 2025 22:09:42 +0000
>>>
>>> View-mode has less like features like View-search-regexp-forward (/) and
>>> View-search-last-regexp-forward (n). Using them I do some un-expected
>>> observations. Here is a repro:
>>>
>>> $ echo 1 word > words
>>> $ echo 2 >> words
>>> $ for n in $(seq 3 6); do echo $n word >> words; done
>>> $ emacs -Q words
>>> M-x view-mode
>>> / word
>>> n                               ; until on line 6
>>> p                               ; as far up as possible
>>>
>>> The observation is that searching backwards jumps over every second
>>> search hit when matches occur on consecutive lines.
>>>
>>> Now do
>>>
>>> / !drow
>>>
>>> And play with n and p. The bang tells to match every line that does
>>> not match the regex. Again every second expected match is "jumped"
>>> over. In this case also when searching forward. (Expected is that
>>> every line is a search hit).
>>>
>>> Maybe not many people use view-mode and it's less-like search
>>> features, and so this was never complained about.
>>>
>>> I find that the attached patch solves the problem. What do you think?
>>
>> Thanks.
>>
>> I don't use view-mode that much, so I don't have an opinion on this
>> behavior change.  Could people who use view-mode please chime in and
>> voice their opinions?
>
> I agree that it just looks like a bug.  It does seem strange that we
> didn't catch it before.

My estimation is that it was a mistake not discovered because matches
are rarely expected on every line in combination with the mode not being
super popular (maybe).  I don't think that the behavior described
by the recipe was ever intended.

> The patch works here, and I don't see anything obviously wrong with it.

I tried also with an even smaller patch, just changing the -1 to 0, like
this (forward-line (if (< times 0) 0 1)).  But starting the forward
search on the beginning of next line is a problem when doing inverted
searches.  (Control is propagated to `view-search-no-match-lines' which
makes its own line movements)

Attached is a patch amended with the bug number.

[0001-Start-search-from-beginning-or-end-of-line.patch (text/x-diff, attachment)]

Previous Next

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