Viewer: broken ShiftF7 from Home

[MKadaner]

Far Manager version

3.0.5000.0

OS version

10.0.22621.1265

Other software

N/A

Steps to reproduce

1. Make sure that the option Persistent selection in Viewer settings is turned on.
2. Install and run the following macro:

-- File ViewerBug.lua
-- This macro reproduces a bug in the Shift+F7 command of the internal Viewer.
-- Internal Editor and internal Viewer should be configured as defaults for F4 and F3.

Macro {
  area="Shell"; key="CtrlAltB"; flags="EmptyCommandLine"; action = function()

    print("cd %temp%") Keys("Enter")
    print("del View-Shift+F7.bug") Keys("Enter")

    Keys("ShiftF4") print("View-Shift+F7.bug") Keys("Enter")

    for i = 0,9 do
      for j = 0,9 do
        print("Line "..j) Keys("Enter")
        if j == 4 then
          print("Pattern") Keys("Enter")
        end
      end
    end
    Keys("F2 CtrlF10 Esc")

    Keys("F3 F7")
    print("Pattern") Keys("Enter")
    for i=0,9 do Keys("ShiftF7") end

    Keys("Esc Home ShiftF7")

  end;
}

Expected behavior

The first occurrence of the word "Pattern" in the generated file is found and highlighted.

Actual behavior

The End of the document reached dialog pops up.

[MKadaner]

It worked in 4242.

The issue can be considered an intentional behavior change. But is it? The last found occurrence is still highlighted after dismissing the End of the document reached dialog for the first time (at the end of the file), and even after jumping to the beginning of the file. After that, the search naturally continues from the highlighted place (the last found pattern), and the pattern cannot be found again.

If the change was intentional, you can close the bug. However, this new behavior is quite inconvenient.

If it was unintentional, you can assign the bug to me. I am working my way through the refactoring and fixing Search / Replace code anyway, so will fix this one as well. I cannot promise quick turnaround though.

[alabuzhev]

I cannot reproduce the issue, or maybe I misunderstand it (it feels like it would've been easier to attach the example file and describe the steps directly).

1. I have a file with multiple pattern occurrences.
2. I search for the pattern it a loop until I reach the EOF where the dialog pops up.
3. If I press "yes", viewer jumps to the beginning and the first occurrence is highlighted.
4. If I press "cancel" and Shift+F7 - the dialog pops up again.
5. If I press "cancel" and Home and Shift+F7 - viewer jumps to the beginning and the first occurrence is highlighted.

Do I understand correctly that you still get End of the document reached dialog after moving to the beginning with Home? If so, then it's a bug.

[MKadaner]

[x] Persistent selection!

I referred to the scenario 5 from your list. I experimented with Far out of the box, like this:

1. Unpack Far archive into an empty directory.
2. Create Far.exe.ini with UseSystemProfiles=0.
3. Copy the test macro to Profile\Macros\scripts.

I have never changed this setting on my systems, so I completely forgot about it, and did not mention in the repro steps / macro. My bad, sorry about that.

So, what is the expected behavior with Persistent selection turned on? This is what I alluded to when I said that the behavior might've been intentional.

P.S. I will update the repro steps.

[alabuzhev]

Ah, I see. I don't remember changing it either, apparently my settings predate 18bbe64f68708d7fd9834bdeec340cb61d59b007 where it was changed. The same commit contains some changes in viewer search; if you say that 4242 works as expected it might be that 4268 is the culprit.

So, what is the expected behavior with Persistent selection turned on?

In my opinion we should start from the beginning if we reached the EOF, regardless of how the dialog was closed. And there is no reason for this behavior to depend on that option in any case.

[MKadaner]

That is what I expect as well. As an aside, it is not exactly clear how it should work. With the persistent selection turned on, we by definition continue searching from the last selected place. Selection does not disappear when we move around the file. If we jump to the top and then return, so that the selection is visible again, I expect the search to continue from the selection rather than from the top of the window.

Anyway, if the fix is not urgent :) please assign the bug to me, I'll think of it.