[Openmcl-devel] Fwd: How does Hemlock ...
arthur.cater at ucd.ie
Tue Jan 31 17:36:10 UTC 2012
Thank you for the information.
My question was really about how a buffer's buffer-point gets to be updated
when a single-click happens; because evidently something I'm doing is
interfering with that, and I don't understand how or why.
Fwiw my suspicions currently centre on #/selectionRangeForProposedRange:granularity:
but #/setSelectedRange:affinity:stillSelecting: might be implicated too.
On 31 Jan 2012, at 01:32, Gary Byers wrote:
> If I understand your question correctly:
> Just about all of the event processing that happens in a Hemlock-based
> text view between a mouse-down event and the corresponding mouse-up
> happens at the Cocoa level. (This includes managing the selection,
> scrolling the view as necessary, and other stuff that's fairly
> complicated and comes "for free" with the Cocoa text system.)
> There are only a few places in this mouse-tracking loop
> where CCL code is involved at all:
> - we override the #/mouseDown:method on HEMLOCK-TEXTSTORAGE-TEXT-VIEW
> and pass a #k"leftdown" event to Hemlock (among other things, this
> cancels any incrememtal searching in progress) before calling the
> next method.
> - we override #/selectionRangeForProposedRange:granularity: so that
> double-clicks at certain buffer positions will select the preceding
> or following s-expression
> - we override #/setSelectedRange:affinity:stillSelecting: to update
> Hemlock's notion of the selection whenever Cocoa's notion needs to
> be updated. (This can happen frequently during mouse dragging.)
> My best guess is that this is what you're interested in.
> These methods are defined in "ccl:cocoa-ide;coca-editor.lisp".
> Hemlock commands (usually invoked via key events) can of course also
> modify the selection; they call the superclass's
> #/setSelectedRange:affinity:stillSelecting: method to notify the Cocoa
> text system of such changes.
More information about the Openmcl-devel