[Openmcl-devel] format to a hemlock view's buffer

[Arthur Cater]

Thanks Gary, but I'm not getting the effects you describe.

Both the obscure-and-redraw, and the use of hi::handle-hemlock-key, 
result in the same behaviour as I have always been observing.

For me there seems to be a disconnect between two "cursor positions".
A mouse click causes the blinking cursor to appear where I clicked.
An arrow key press moves the cursor relative to the last character written,
or last arrow key result.

I also noticed now that (using the handle-hemlock-event version anyhow)
typing text into the window after the six lines have been printed adds them
at the end, as expected. But mouseclick somewhere and type, there is an
altconsole error that "NIL is not a line!" (and indeed it isn't!)

Arthur

ps it's weekend, don't busy yourself on this now! Best wishes.


On 3 Feb 2012, at 12:49, Gary Byers wrote:

> If you obscure the window that your example writes to (e.g., move another
> window in front of it, minimize it, whatever) and then force it to display
> itself, everything seems fine.  (Until that happens, the buffer and view
> seem to be out of synch.)
> 
> A Hemlock keystroke is processed (at the moment) by
> HI::PROCESS-HEMLOCK-EVENT; that method's second argument can be either
> a key event or a function of 0 arguments.  Changing your example so that
> it uses HI:HANDLE-HEMLOCK-EVENT instead of enclosing the DOTIMES in
> WITH-HEMLOCK-PROTOCOL:
> 
> (hi::handle-hemlock-event
>    view
>   (lambda () (dotimes (num nlines) (format stream "Line ~a is here~%" num))))
> 
> seems to ensure that the right kind of redisplay happens (in the right view)
> after the buffer is modified.
> 
> Like I said,  I agree that there should be an easier public way to do this
> sort of thing.  Using HI::HEMLOCK-EVENT like this is fairly easy, but it's
> not intended to be a public interface and it could change/disappear in the
> future.
> 
> On Fri, 3 Feb 2012, Arthur Cater wrote:
> 
>> Thank you Gary for responding, I appreciate the help.
>> 
>> The test case code attached here is quite small, 42 lines, see below.
>> Since everything it does is done inside gui::execute-in-gui I have removed
>> the redefinitions of stream-write-char and stream-write-string that ensured this.
>> 
>> I have taken code from handle-hemlock-event that seems to me to cover
>> the protocol issues you mentioned, and - with some reordering of bindings -
>> encapsulated it in the with-hemlock-protocol macro. Without success:
>> still, a mouseclick moves the visible cursor but a subsequent arrowkey
>> reveals the buffer-point is still at the end of the inserted text.
>> 
>> Arthur
>>