adobe/brackets — pull request #796 by njx (2012-05-03 01:37:13+00:00)
Title: Set horizontal scrolling region based on visible lines in inline editor

@gruehle

For issue #600.

We limit the horizontal scrolling by figuring out the longest line visible in the editor, then forcibly resizing the container to that editor's width (plus padding for the rule list). Note that we still have the issue mentioned in #623 (number 2), where the horizontal scroll area is always bigger by the width of the rule list. But at least it will ignore the non-visible lines in the document.

This implementation is pretty simple: on every change to the inline editor's content, it iterates over the text of the visible lines in the inline editor to figure out the longest one, and calculates its width. In theory, we could make this faster by only doing this work if the user either makes a line wider than the widest line, or makes the widest line shorter. But that would involve some messy tracking based on the individual changes we receive on each change in the inline editor (basically duplicating similar logic inside CodeMirror).

Since the number of lines in the inline editor should be relatively small, I'm assuming this isn't too bad. But it does mean we're doing this work on each character typed. I'm wondering whether we should try to optimize this now, or wait until we see the results of the typing performance instrumentation to see whether this changes that materially. Let me know what you think.

Some other notes:
* I noticed while working on this that we seem to be doing more work than we need to on change messages in the inline editor--specifically, we seem to call `_updateRelatedContainer()` more than we need to, which might be expensive. I removed one source of redundancy here, but we should probably check to make sure there isn't more. (For example, we could split `_updateRelatedContainer()` into different pieces that update the vertical size and the horizontal size separately based on different cases.)
* I also noticed a bug in one of the unit tests that didn't account for the fact that some stuff in MultiRangeInlineEditor.load() happens on a setTimeout(). I added a waits() to get around this.