Neil Hodgson wrote:
Robert Roessler:
Offhand, it looks like it would be nice to have an explicit "width"
attribute available per char in line, rather than depending on being
able to compute it from the start of the *next* char... but no doubt
there is a way of faking this.
I don't think that having a width rather than just the next
position is the problem here: its probably more that the end case is
applied 1 position early.
Like I said, that was an "offhand" (or "convenience" in working with
the code) remark - the real meat of this is in the previous paragraph,
where I allege that *all* of the "close" matches are working
improperly... it does not look like what we both assumed initially - a
bogus end-case handling problem.
Hotspots, dwell events and cursor choice.
Sure keeps things busy.
There has been some questioning of the busyness level of Scintilla
both with mouse move and timer and idle message. This is more of a
problem with remote windowing such as when using Terminal Services.
Some optimisation could be done to avoid most processing for every
mouse move but would require some computation of screen regions (such
as a set of rectangles for the selection range) where moving the mouse
into or out of this region would trigger a reevaluation of the cursor.
You then have the extra complexity of maintaining these secondary
representations of state. Is this complexity justified by the savings?
Probably not until it starts hurting more. ;)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
