[Openmcl-devel] format to a hemlock view's buffer
gb at clozure.com
Fri Feb 3 04:49:48 PST 2012
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
(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
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.
More information about the Openmcl-devel