Robert Roessler: > What was the underlying problem? Was it simple, like the > non-line-specific marker changes not getting redrawn at all, or > something more subtle? I assume it was trickier, since I use markers > a lot in my client, and never saw any [non]redraw issues...
The underlying problem was the inaccurate handling of the region being redrawn. This is (I hope) fixed on Windows native with the addition of hRgnUpdate and the PaintContains method. It may still be a problem on other platforms which have not yet implemented PaintContains. On GTK+/X, painting is not restricted to the update region so the bug didn't occur and I never investigated GTK+/Windows. Redrawing just the line containing the changed marker is also a worthwhile optimisation. > Yes, I remember the posted pic of the marker margin not being redrawn > properly... if I can devise a "cleaner" (to me) fix, would you > consider it? A rearrangement of the notification so that the 'all lines' state is communicated by something else rather than an out-of-bounds line number may be OK but I would like to preserve the ability to determine which line is being changed when possible. > This looks doable (both "notify these users on any commit" and "notify > ME when this file changes" sorts of things) - but with admin work and > scripts on the repository machine... which looks like more than you > would want to do, even if you had all of the necessary access. :( Some SourceForge projects have CVS commits mailing lists but to me commit streams are too detailed so I prefer running client side diffs to see changes such as cvs diff -D yesterday or cvs diff -D 2005-12-26 Yesterday, CVS thought that LexCaml.cxx had disappeared from the server: possibly you were updating it but there is nothing in the log. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
