Since I haven't found a good way to implement a dynamic horizontal scrollbar in Scintilla (and I tried again recently in SinkWorld) there should probably be a compromise option. This would provide a better but not perfect range and since it would be an option the user could choose whether the performance cost is worth paying. There may also be some visual bugs (such as the caret disappearing upon range modification) in the initial implementation so I'd want it to be an option to avoid any such bugs as well. Common machines are much faster than when Scintilla was first developed so the performance trade-offs change. However, some people do use Scintilla on slower machines and shouldn't be penalised.
One of my problems with implementing correct dynamic range setting is that it is hard to determine when and how to decrease the range after the user has, for example, undone a large scale join operation (such as Select All + Paragraph Join) or zoomed. A possible implementation of range sizing would be to perform a synchronous lexing and layout of the whole file (or initial fixed size portion) to discover the maximum pixel width. Another is to maintain a maximum seen pixel width in the line layout data and modify the scroll range when this changes at the end of painting or in periodic or idle processing. Approximate widths could be discovered by counting line widths in bytes and multiplying by an approximate per-byte byte width (making allowance for such things as tabs and multi-byte characters). I won't be implementing this myself, at least in the near future. Neil _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
