Unexpected behavior with synchronize scrolling

[Guy Rouillier]

I have files A and B, and a file C which is a concatenation of A+B. I
wanted to make sure that Windows concatenated these properly, so I
brought up A and C in TSE in vertical split mode (ctrl-o-v).

I turned on synchronize scrolling (ctrl-o-y), then with the cursor in
file A, told TSE to go to the bottom of the file (ctrl-pgdn). That sent
the cursor bar for file A to the bottom of that file - line 682, as
expected.

However, it also sent the cursor bar for file C to the bottom of *that*
file - line 903. That doesn't seem right to me. Since synchronize
scrolling is turned on, shouldn't file C have also scrolled to line 682,
just like file A?

Thanks.

--
Guy Rouillier

[Scott Wagner]

Philosophically, the behavior seems correct because it synchronized the "go to bottom of file" command.  If you wanted it to go down 682 lines on each pane, then I would have expected that [Down][CtrlQ][Q] then telling it 681 times to repeat would take you to line 682 of both files.

- Scott

[Hayes Smith]

 

                if Query(Key) in <Ctrl PgDn>, <Ctrl PgUp>, <Ctrl Home>, <Ctrl End>

If you look at this line in the source of synchscr.s, notice that the commands for these keys are not considered 'scrolling' keys, but are acted on literally. You can probably make a few changes in this section so it does what you want.

[Hayes Smith]

As for why, think of it the other way. Say you were in file C and chose to go to the end of the file, and C was synchronized to A, but A was a shorter file, if you tied the synch scrolling absolutely, then you could never go to the end of file C as long as the two files were synchronized.

 

Just a guess.

 

------------------------------------------