[Openmcl-devel] How do I move the cursor in a window under program control?

Gail Zacharias gz at clozure.com
Fri Oct 17 12:35:11 PDT 2014 

Yeah, the thing is that the buffer-selection-info gets secretly switched in
and out of the buffer by Cocoa code  (that's what I meant about it being a
back-door kludge, and that's why I suggested grepping for references - to
find where it gets fiddled with).

Alternatively, try doing whatever you're doing inside
hi::handle-hemlock-event (pass a function as the second argument).  That
should insure that whatever weirdness we do around hemlock events also gets
done around your code.  Just running on the main thread is not enough
context for doing editor things, at least not any more.

On Fri, Oct 17, 2014 at 3:09 PM, Ron Garret <ron at flownet.com> wrote:

> Thanks for the hint, Gail, but I’m afraid that doesn’t help much.
> BUFFER-SELECTION-INFO is just an accessor into the buffer class.  If I look
> at the selection-info object in my buffer, it looks like this:
>
> #S(HI::SELECTION-INFO :POINT #<Hemlock Mark "XX^baz">
>                       :%MARK #<Hemlock Mark "^XXbaz"> :MARK-RING #<Hemlock
> Ring>
>                       :REGION-ACTIVE NIL :VIEW NIL)
>
> which looks correct to me.  The point is where it should be (after the
> “XX”) but the cursor in the window is still at the end of the buffer.  The
> peculiar result is that if I type into the buffer, characters get added at
> the end, and if I call hi:insert-character, they get added at the point
> position (and then all hell breaks loose and lines start to vanish from the
> display).
>
>
> On Oct 17, 2014, at 11:22 AM, Gail Zacharias <gz at clozure.com> wrote:
>
> One of the things that has changed hemlock is that cursor position is no
> longer per buffer, it is per view.  This is to allow multiple views on the
> same buffer.
>
> Beware that the currently implementation of this is a back-door kludge,
> and leaks Cocoa stuff into Hemlock code, and I plan to change it as soon as
> I get some time to work on it. But for now, you might want to grep
> references to buffer-selection-info.
>
>
>
>
> On Fri, Oct 17, 2014 at 2:07 PM, Ron Garret <ron at flownet.com> wrote:
>
>> Yes, obviously something in Hemlock has changed.  Mostly for the better,
>> because a lot of my old private hacks are no longer needed.  But this one
>> thing is just driving me bananas.  I’ve spend hours groveling through the
>> source thinking, “It just can’t be that hard to figure this out.”  Well,
>> yeah, it is that hard (at least for me).  But maybe I’m just getting too
>> old for this sort of thing.  :-(
>>
>> I’ve managed to figure out this much: when you call (say)
>> hi:insert-character, that in turn calls hemlock-ext:buffer-note-insertion,
>> which calls #/noteHemlockInsertionAtPosition:length:extra:, which calls a
>> whole bunch of cocoa functions to update the window.  But it doesn’t update
>> the cursor position.
>>
>> it really seems like this ought to work, but it doesn’t:
>>
>> (setf ts (gui::make-textstorage-for-hemlock-buffer b))
>> (easygui::running-on-main-thread ()
>>   (gui::update-hemlock-selection ts))
>>
>> rg
>>
>> On Oct 17, 2014, at 8:19 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>
>> > Hi Ron,
>> >
>> > This may not be relevant to your issue but just in case it is I offer
>> it up.
>> >
>> > I'm just upgrading from ccl1.7 to ccl1.10 and I find my "clickable"
>> contrib doesn't
>> > work any more, most obviously because gui::compute-temporary-attributes
>> has changed,
>> > and gui::set-temporary-character-attributes no longer exists. (My
>> reward for
>> > tinkering with unexported functions I guess. Must have gsoh!) My code
>> had also
>> > redefined hi::handle-hemlock-event and hi::stream-write-char and
>> hi::stream-write-string.
>> > I had recently been noticing other things about clickable and so I
>> suspect maybe it hadn't
>> > worked properly since 1.6.
>> >
>> > I noticed along the way that ordinary use of the editor was acting
>> strangely.
>> > Putting the cursor somewhere in a file and typing text put the new text
>> at the
>> > top of the file, while maintaining cursor position.
>> >
>> > If you're using my clickable contrib then maybe I'm to blame. If (as is
>> likely) you're not
>> > then maybe other hacks to hemlock that you privately use are running
>> foul of these
>> > (...temporary-attributes) or other changes inside hemlock. Point is,
>> there have been
>> > changes to hemlock's internals.
>> >
>> > But you most likely thought of that. Just in case ...
>> >
>> > Arthur
>> >
>> > On Oct 17, 2014, at 2:51 AM, Ron Garret wrote:
>> >
>> >> This is really driving me nuts.  If I do this:
>> >>
>> >>
>> >> (setf b (hi:hemlock-view-buffer (ed)))
>> >>
>> >> (let ((hi::*current-buffer* b))
>> >> (hi:insert-string (hi:buffer-point b)
>> >> "baz
>> >> bar
>> >> bing
>> >> "))
>> >>
>> >> (hi:move-mark (hi:buffer-point b) (hi:buffer-start-mark b))
>> >>
>> >> (let ((hi::*current-buffer* b)) (hi:insert-character (hi:buffer-point
>> b) #\X))
>> >>
>> >>
>> >> The X gets inserted at the start of the buffer just as I would expect,
>> but if I then click on the window the cursor is still at the end of the
>> buffer, and if I type a character, that gets inserted at the end of the
>> buffer.
>> >>
>> >> (If I then call the last line again, I get another X at the beginning
>> of the buffer, and the “bar” and “bing” lines disappear!)
>> >>
>> >> So clearly moving the buffer point around is not the same as moving
>> the cursor around.  How do I move the cursor???
>> >>
>> >> rg
>> >>
>> >>
>> >> On Oct 5, 2014, at 7:58 AM, Ron Garret <ron at flownet.com> wrote:
>> >>
>> >>> This appears to be a regression.  It works properly even without my
>> patch in 1.8 but doesn’t work in 1.10.  Apparently the problem is caused by
>> some change deep in the GUI code because the code for
>> editor-execute-expression-command and move-mark have not changed AFAICT.
>> >>>
>> >>> I’ve opened a ticket.
>> >>>
>> >>> On Oct 4, 2014, at 5:51 PM, Ron Garret <ron at flownet.com> wrote:
>> >>>
>> >>>> I want to move the cursor in the top listener to the end of the
>> buffer.  It seems like this should work but it doesn’t.
>> >>>>
>> >>>> (in-package :hemlock-interface)
>> >>>> (setf b (gui::hemlock-buffer (#/topListener
>> gui::hemlock-listener-document)))
>> >>>> (move-mark (buffer-point b) (buffer-end-mark b))
>> >>>>
>> >>>> What I’m really trying to accomplish is to insure that the bottom of
>> the top listener is visible after doing an eval-region in an editor
>> window.  This is supposed to happen automatically, but it has never
>> worked.  I had a patch that fixed this, but the patch stopped working in
>> version 1.10.
>> >>>>
>> >>>> Thanks,
>> >>>> rg
>> >>>>
>> >>>> _______________________________________________
>> >>>> Openmcl-devel mailing list
>> >>>> Openmcl-devel at clozure.com
>> >>>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>> >>>
>> >>> _______________________________________________
>> >>> Openmcl-devel mailing list
>> >>> Openmcl-devel at clozure.com
>> >>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>> >>
>> >> _______________________________________________
>> >> Openmcl-devel mailing list
>> >> Openmcl-devel at clozure.com
>> >> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>> >
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20141017/21ffc4e2/attachment.htm>

More information about the Openmcl-devel mailing list