@popa.bogdanp Added vc-root-dir: https://github.com/greghendershott/racket-mode/commit/fd33ee9f1fe2292d64cadbb2beeab761adb98698

Not urgent but if anyone involved with lindenmayer/turtle — e.g. @robby @florence @dan @stamourv ? — could point me in the right direction I’d be grateful: https://github.com/greghendershott/racket-mode/issues/430#issuecomment-590887988

IIRC lindenmayer sticks the actual executino of the l-system into the main submodule. are you running that?

DrRacket makes a special port where port-write-special recognizes snips it gets

Setting the print handler is a different way and I can no longer recall the trade offs between them

The print-handler is a trick I originally learned from Geiser mode for Emacs.

It’s pretty handy in non-GUI envs like Emacs or Vim or whatever, given file/convertible, and riding on the idea that module-begin prints values.

But I can imagine it would have drawbacks in DrRacket.

No I don’t agree with that

I think that the port handler approach will work fine in emacs

The pint is that you are in control of the initial environment of the program you are running and there are different ways to shape that environment that lead to different sets of things working well.

I went through many many of them a long time and ended up with the current set.

But the place you are displaying the output does not seem relevant in a deep way for choosing between them

What is relevant is what kinds of customizations affect the program’s behavior and how general you can be in supporting various printouts.

(Eom)

When you say port-write-special recognizes snips. Does using a snip imply needing to require racket/gui/base?

Ah good point. I forget the answer to this question but I do agree that racket/GUI/base dependency issues are a thing for emacs mode in a way that affects drr less

Also when I wrote snip I wrote wrong.

If lindenmayer uses snips and exploits drr’s security hole to print nicely then that’s a bug in drr not in racket mode

But if it just sends cnvertible values via write special to the default output ports then I would say that emacs mode should be able to support that

I mean, if it turns out a port-write-special approach will handle more things like lindenmayer, if/as/when racket/gui/base is loaded anyway, then I can add that as a second method.

But it sounds like I might need to keep the first-line print-handler approach, for user programs that don’t need/want to pull in racket/gui/base. I mean, a program can produce picts without using racket/gui/base, for instance, and the status quo works for that in Racket Mode in Emacs.

Oh OK.

So look at the output port level, not the print handler.

I can look into how to do that.

I’m not seeing why the print handler vs port handler issue decision is tied to the racket/gui/base issues?

Maybe it is?

“port handler” isn’t tied, but I thought “special snip or other value” might be. When I see % at the end of a name, I always want to check. :smile:

But you already said it’s not “snips”.

I can read more and understand.

It does seem like racket mode and drracket should interpose on programs for this pinting purpose in the same way. Because so much time went into the current set of overridden handlers I’m skeptical we want to change DrRacket but I do rate “changing drracket” as better than “racket mode and drracket interposing in different ways”

I think my brain just did a wrong when I wrote snip.

I really mean “value that isn’t ascii that we want to print”

Yep.

:smile:

I haven’t had a reason to use port handlers in all these years, so I’ll read up and learn more.

Thanks for your guidance! I’ll touch base later.

Looking at the lindenmayer code, it looks like it actually uses graphics/turtles to print (non–3d)

graphics/value-turtles, I mean

and it looks like that does create a snip

but that depends only on racket/snip, it looks like?

(I’m just looking at the code not trying things out)

But maybe a graphics/value-turtles program is a better program to focus on than a lindenmayer one for trying things out.

Thanks a lot, Greg!

@florence Good catch on the main submodule. That seems to be the proximate cause here. With xerepl if you ,en the file, it does not print. Similarly Racket Mode’s racket-run, does module->namespace on the file module.

Racket Mode does let you put point inside any module form to run/enter that. Alas in this case there is no (module+ main __) apparent in the source. That’s why no image prints.

That’s orthogonal to how it prints, which was still a good discussion for @robby and me to have, and a separate to-do.

Sweet! Thanks!

I guess it’d be good to have a way to config (and perhaps inform the user) what submodules are available and which one to run

but personally I’m also always avoid running the test and main submodule when working in DrRacket

Oh that’s good to hear!