With sort by mtime, after Alt-i , making a change in a panel alters scrolling position of the other panel

[cri]

How to reproduce:

1. Create a main directory with a lot of subdirectories, so that they won't fit in a single page of the panel

mkdir main ; cd main ; for d in $(seq 1 100) ; do mkdir $d ; done

2. Open main in mc and configure both panels to sort files by modification time

3. Manually scroll down the main panel until the cursor is on the 50 directory

4. Hit Alt-i, so that the _other_ panel will display the subdirectories of main at about the same position, i.e. the 50 directory should be roughly in the middle of the page

5. Enter 50, make a subdir into it, go back: cd 50 ; mkdir test ; cd ..

Now the current panel has scrolled all the way down, which is ok, since we just modified the 50 directory and it is now at the bottom of the list (sorted by last modified).

The problem is that the same happened also in the other panel, it too has now automatically scrolled to the bottom of the directory list.

Since I didn't even switch to the other panel, I assume that its view should remain unaffected by changes made in the current panel. Am I wrong?

[zaytsev]

Since I didn't even switch to the other panel, I assume that its view should remain unaffected by changes made in the current panel. Am I wrong?

How exactly do you envision it? The panel should show outdated / wrong information?

[cri]

Replying to zaytsev:

How exactly do you envision it? The panel should show outdated / wrong information?

No, nothing outdated or wrong, it's ok that the newly modified directory (50 in my example) is moved at the bottom of the list in the other panel, that's standard mc behaviour (changes made in one panel are reflected in the other too).

What I wouldn't expect is that the other panel also automatically scrolls at the bottom of the page, "following" the modified directory, so that this is visible also in the other panel. For my use case I need the other panel to be updated with changes, BUT keeping the same scrolling position.

Interestingly the bug happens also if at step 5. instead of doing cd 50 ; mkdir test ; cd .. I just do mkdir 50/test, so entering in the directory is not required to trigger this effect, just modifying it is enough.

[cri]

Interesting note: the bug only happens if the directory that gets modified in step 5. is the same where the selection bar was in step 4. when I did Alt-i.

If I do Alt-i, then I select another directory and I modify it, the bug doesn't happen.

So it seems mc has a special memory for the directory under the selection bar when Alt-i is executed.

[egmont]

Replying to cri:

So it seems mc has a special memory for the directory under the selection bar when Alt-i is executed.

Isn't this simply the "selected" file of the other panel, that is, the one where the TAB key takes you?

This concept exists anyway (even without Alt-i), provides the simplest possible explanation (that is no extra code is there for Alt-i specifically that would break things), and also explains the scrolling behavior.

[zaytsev]

For my use case I need the other panel to be updated with changes, BUT keeping the same scrolling position.

In other words, in general, "scrolling position" does not make sense anymore when the panel contents is updated, because the new state may be completely different from the previous one, and so it is reset. It only makes sense when you want to track selected file, which is what you are observing on the other panel.

[cri]

Isn't this simply the "selected" file of the other panel, that is, the one where the TAB key takes you?
This concept exists anyway (even without Alt-i)

Not generally: just pressing TAB doesn't take me to the same directory in the other panel.
It only does it after pressing Alt-i.

So it seems Alt-i has the following effects (only the first is documented):

• make the current directory of the current panel also the current directory of the other panel
• make the directory under the selection bar the one that will be selected in the other panel when you press TAB
• make sure this directory will be visible in the other panel when it is updated (so scroll the panel to make it visible if needed)

If you confirm this is intended behaviour, then this (non-)bug can be closed, and I've found a workaround for my special case.

[egmont]

Replying to cri:

Isn't this simply the "selected" file of the other panel, that is, the one where the TAB key takes you?
This concept exists anyway (even without Alt-i)

Not generally: just pressing TAB doesn't take me to the same directory in the other panel.
It only does it after pressing Alt-i.

I guess I wasn't clear enough.

The concept of "selected file/dir on the other panel" always exists. There's always some place where TAB takes you. It's just not visible on the screen until you press TAB. You don't have to ever use Alt-i for this.

If instead of Alt-i, you navigate to the same location and over the same subdirectory ("50" in the example above) using the TAB and Down arrow keys, the same behavior can be observed.

This is because the "selected file/dir on the other panel" is preserved (even despite it's not being reflected on the UI which file/dir it is), and is scrolled to be in the viewport.

Does this sufficiently explain the behavior to you?

[egmont]

Oh, actually the "selected file/dir on the other panel" _is_ visible: its name is repeated below the list of files, above the command line. So, when you press Alt-i, you can clearly see the "50" becoming the selected entry on the other panel too.