[Openmcl-devel] format to a hemlock view's buffer
arthur.cater at ucd.ie
Wed Feb 8 03:46:26 CST 2012
Creating the stream using buffer-end-mark rather than buffer-start-mark
makes things behave properly.
Glen and Gary, thanks for your attention.
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
> (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