I guess you've probably already found the implementation, but just in
case, it is here:
I think the thing you'd want to do is break out the code currently in
the on-paint method (and things it needs) into a separate function
that can be called from that on-paint and from a separate canvas%
object. Then have a mode so you can tell an inline-overview that there
is a separate canvas% object, in which case it won't do any drawing in
on-paint but will just notify that canvas when it needs to be
refreshed. I think you'll want that canvas to NOT have scrollbars at
all (manual or otherwise) and just have the text tell it what to draw.
There will also be some work to get clicks to go backwards to move the
insertion point, which will amount to a similar process, but with the
Then, once those two modes work, we can set up a frame mixin that
manages the two modes (hiding and showing the canvas% object from its
frame, as appropriate) and then add it to DrRacket.
Does this make sense?
On Sat, Jan 27, 2018 at 4:23 AM, Philip McGrath
> I can't say how soon I'd get to doing it, but I would potentially be
> interested in submitting a pull request. I can see the benefits of the new
> setup as you explain them, and I probably need to live with it for a while
> longer to know what I prefer for editing Racket code, but the ability to
> render the contour in a separate canvas% would be much better for the other
> application for which I was experimenting with text:inline-overview-mixin.
> In that case, the lines almost always fill the full width and rely on
> auto-wrap, which means the contour makes the actual text essentially
> On Thu, Jan 25, 2018 at 2:21 PM, Robby Findler <ro...@eecs.northwestern.edu>
>> On Thu, Jan 25, 2018 at 2:17 PM, Philip McGrath <phi...@philipmcgrath.com>
>>> I took the steps you described and I no longer get the doubled program
>>> contour, but I do get results like the screenshot of my experiment with
>>> text:inline-overview-mixin I sent
>>> earlier (maybe that's what the contour is supposed to look like now?). In
>>> both cases, drawing the contour on top of the actual text seems to me to be
>>> causing a problem: in, for example, line 219 of the following screenshot,
>>> the overview covers up part of the program source, and I can't scroll to
>>> reveal the covered part. In the example I sent earlier, auto-wrap is on, but
>>> wrapping places text under the overview, and again it isn't possible to
>>> scroll to uncover the text.
>>> Is this the way this is supposed to work now? Is there some way to
>>> prevent the overview from covering up text in the editor?
>> Currently the only way is to type cmd-u (temporarily turning it off) or,
>> of course, making the window wider.
>> It would not work well to adapt the current implementation so that
>> scrolling works. It would be doable, however, to adapt the current
>> implementation so there was a preference to move it into its own separate
>> canvas% object that lived beside the text (like the old contour). I opted
>> for the current setup, as typing cmd-u is fast and because you don't have to
>> pre-allocate space for the contour that could profitably be used for lines
>> in, say, only one part of the file.
>> That said, I can understand how you migth like to have the option. If you
>> (or anyone!) has interest in making a pull request, I can provide basic
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.