I was just using split windows for the first time and ran into a bug. I have a .php file split, and as I was adding lines at the top of a file in the upper pane, the lower pane was scrolling down each time I pressed enter. What I'd expect to happen is that the lower pane would hold its scroll position as the content in the upper pane changes.

This is version 4.6.2 (build 4632).

IHMO it's not a bug. You just expect different behavior of IDE so you'd rather post it in "features request"

Why would you say it's not a bug? Each pane is independent, with its own set of scroll bars. The whole idea is to let you work on multiple parts of a document simultaneously, so it completely defeats the point if adding content in one pane affects the view of the other pane. In this particular case, I was adding documentation at the top of a file about something lower in the file, and as I was adding the lines of documentation, the code I was documenting, in the other pane, was scrolling out of view. This usage is *exactly* the sort of thing split panes exist for, so how in the world does the observed behavior make sense to you?

If your changes in one pane affect the *content* of the other pane--e.g., you hit select all/delete--that's one thing, but generally, the IDE should try to keep the pane you're not working in as static as possible. In other words, treat each pane as a separate view on the data, not as one big view with the middle portion truncated.

I just checked TextPad and Visual Studio 2005, and they work how I expect--the content stays fixed while the scroll bars and line numbers adjust. I often work on a Mac, and every editor I can think of on that platform behaves this way, as well. It just makes sense.

How do you justify the existing behavior? Since the existing behavior runs counter to every use I can think of for the future, I assume you have some good reasons to think it's the better behavior.

IMO it's just how you look at the matter.
VS '05 and Textpad keep the "content" at a fixed position, the folks at NuSphere opted to keep the starting line-number for the bottom pane as the fixed item. As a logical consequence the content then scrolls down when lines are added above. I'm sure it's not a bug but more like intended behaviour and thus the initial reaction is correct afaic, your question is a feature request.
And as for justifying the behaviour, that is a subjective something, what you don't like someone else will probably like and vice versa.
Just my $0.02

bobwilliams: I think it's more intended behavior, PhpED works just a little different with this feature. For me it's what I'm expecting, but you expect a little different behavior and that's OK. If I ware you I would suggest your ideas to submit on "feature request", I think it's not a big deal this feature to be included in the forthcoming PhpED 5.0.

I ask this legitimately: What's the point of keeping the starting *line number* fixed, rather than the starting *line of code*? I rarely care about line number other than when referring to a specific line for debugging (and once I go there, I no longer care). Basically, when using the spit feature, I'm *always* interested in seeing two specific sections of my content, with the line numbers being whatever they are.

I'm just trying to understand how folks are using the current style to increase their productivity. I've never used an editor whose split feature works like PhpED's, and the idea of focusing on line numbers--which constantly change--rather than the lines themselves just boggles my mind. I mean, are you really trying to see two sections of line numbers at once, or two sections of code?