[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#76167: 31.0.50; view-mode un-expected jump-overs
From: |
Tomas Nordin |
Subject: |
bug#76167: 31.0.50; view-mode un-expected jump-overs |
Date: |
Tue, 25 Feb 2025 20:39:16 +0000 |
Stefan Kangas <stefankangas@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Tomas Nordin <tomasn@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
Description: Text Data