I'd like to request that when I'm working in the top pane of split window, that the bottom pane be frozen in terms of scrolling position.

Say, for instance, that I'm working on a new class. At the bottom of the class, I have a bunch of private variables, and at the top, I'm writing a constructor that will set them. It's extremely helpful in these situations to split the window so that I can see both the variables and the constructor code that I'm working on. I can do that in PhpED.

However, as I write my constructor code, every time I press enter to add a new line, the bottom pane scrolls one line, eventually pushing my list of variables right off the screen and out of view. Thus, I periodically have to switch over to the bottom pane, fix its scroll position, and then switch back to the top pane and continue my work. In short, by having the bottom pane's scrolling tied to what's happening in the top pane, the two panes are no longer independent and I've lost what to me is the biggest benefit of split windows: the ability to work one part one of the document while keeping an eye on another.

Thus my suggestion: make the panes completely independent. Since you can only work in one pane at a time, the second view is by definition just a read-only view of the document, and it's much easier to read if it's not self-scrolling on you, yet alone scrolling *up*.

For an example of how I'd like to see this work, check out Visual Studio, NotePad++, or TextPad.

Actually it is not that simple and certainly the splitted editor does not scroll.
Say you edit a file of 4000 lines and press enter on 300th. It means that new number of lines is 4001. It's clear that the splitted editor has to adjust vertical scroller to 4001. Also, splitted editor has to retain "current line" which is for example 400. But it's content is changed since you added new empty line after the 300th.

But it is that simple. When I add a line in the top pane, the range of *content* lines visible in the bottom pane changes. Call it scrolling or content adjustment or whatever, but the result is that the content has moved, that you've effectively been scrolled upward by one line in the file.



You've hit the nail on the head with the problem. Right now, the IDE is focused on keeping specific line numbers in view. However, the line numbers are immediately irrelevant when the content changes. Rather than line numbers, the IDE should focus on keeping specific *content* in view. So if I have something like this:

a
b
c
d
e
f
g
<split>
p
q
r
s
t
u
v

and I add a line after b in the top pane, I'd expect to see this:

a
b
b1
c
d
e
f
<split>
p
q
r
s
t
u
v

but right now, I'll see this:

a
b
b1
c
d
e
f
<split>
o
p
q
r
s
t
u

See the difference? I don't understand how this could possibly be useful; what's the point of splitting a window so that you can work in one section while having a view of another, when that view is changing because of your work? The focus should be on content, not changing line numbers. That's what makes this simple - it boils down to the subject of focus.

Look at break points. If I put a break point on line 68 on an if statement, and then add a line after line 20, the break point will still be on that if statement, which is now at line 69. This is how it should be. If it worked like the split function, though, the break point would still be on line 68, and no longer on the line with the if statement. Again, the content is what's important; the line numbers are little more than reference points, and it's silly to focus on a set of reference points that are no longer current because the underlying content has changed.

Please, look at one of the applications I listed. This certainly is possible, and it's the way every serious text editor or IDE I've used has worked.

the key word is "effectively", while the splitted editors keep showing the same physical lines. It's text is scrolling among the lines.

So will you consider making the IDE keep the *content* fixed rather than the *line numbers*, just like Visual Studio, et. al., do? At least as an option? Right now, I rarely use the split feature because the changing content makes it pretty much worthless for me, as I explained earlier.

Does no one else use the split feature? It's awfully quiet in here. If others are using it, and you like the current behavior, would you please explain to me how you're using it? I just don't see how it could be useful as is. If you don't use it, why not?

I just noticed that the IDE does the same thing even when line numbers aren't shown. I was hoping that without line numbers visible, the IDE wouldn't be fixated on keeping them the same. It'd be a really clunky workaround, but a workaround nonetheless.

I think that without line numbers, the current behavior is downright confusing, because as you add lines to the top pane, the bottom pane is scrolling for no visible reason.

Please consider changing this behavior, at least optionally.

Yes, and I agree the behaviour is quite different to other editors, I use UltraEdit a lot, which does the expected freeze normally.

Additional to this, I'd like to be able to float or clone the split screen.

Any further input on this, Dmitri? Will you reconsider adding the behavior I describe, at least as an option, in some future version?

Does UltraEdit support code folding? It makes difference because number of visible lines is varying depending on scrolling, editing (entering new lines and deleting old) and folding (collapsing/expanding). It all makes it a bit harder to keep the "context"

Yes it does.

As do Visual Studio and BBEdit.