[Openmcl-devel] Fwd: How does Hemlock ...

[Arthur Cater]

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.

Arthur


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.
> 
>> <snip>