if you’re looking for some low-level control, I think you’ll find Pollen more to your liking. The tradeoff is that you need to do considerable more work; there’s only rudimentary support (if that!) for stuff you take for granted in Jekyll

I use Pollen to generate my own sites, but I’m fussy like that. I’ve been bitten a number of times by having to do many tasks myself, having to do stuff that probably comes out-of-the-box with other tools

That’s not a criticism of Pollen; I see it as something that comes with the territory.

I also use Pollen for my books (but there, I’m generating ConTeXt rather than HTML).

Yeah, I used Pollen for a book-like thing once and it seems really nice for that!

Oh, I think I see! You mean I should create syntax-classes for the next phase. I’ll try that, yeah, I didn’t think about it.

That would make things easier to understand

@greg I’ll delurk to second what Jesse said - racket-mode is my primary method of working with racket.

The Reddit user experiencing scrolling problems in DrRacket has provided more information. Does scrolling become slower in larger windows? https://www.reddit.com/r/Racket/comments/b5o34z/any_way_to_improve_performance_of_drracket/

I am quite surprised, user lispm on the thread (https://www.reddit.com/r/Racket/comments/b5o34z/any_way_to_improve_performance_of_drracket/ejiv0n4?utm_source=share&utm_medium=web2x) says that it’s pretty bad for him as well. I expected DrRacket on MacOS to be flawless - I had this idea that a lot of the core people were using it.

Compared to, say, SublimeText the UI is slow - but I am puzzled too.

Unfortunately can’t comment here, since I know next to nothing about OSX and don’t own a Mac.

I use drracket on macOS regularly and can confirm that scrolling speed is consistently the most frustrating problem

And it’s okay on small files but much worse on large files

A few years ago I found the background expansion slow enough that, turning it off made a big difference. That was on a slower laptop on macOS. Scrolling hasn’t bothered me but I use Emacs for heavy edits and DrRacket for its special features. (Emacs is also not immune from probs with large files, esp if there aren’t many line-endings to “break it up”.)

Alex is right - something happens for very large files. I have a tendency to put everything in the same file at first - then split things later. And at some point DrRacket becomes noticeably slower.

I’m generally stuck on how to improve refresh performance on Mac OS. Some of it is that Mac OS changes have made things worse; Slideshow animations don’t work nearly well after I upgraded to 10.14, for example. My only idea currently is to try out Skia as a replacement for Cairo+Pango, but it’s not clear that it would help.

That does indeed sound drastic. I attempted to find out whether anyone is working on a Metal backend for Cairo, but I couldn’t find anything.

@mflatt it occurs to me that this seems like precisely the kind of modularity that units are meant to allow for.

When I’ve tried in the past though, units don’t play very well with redex.

Awesome. That is what I needed to hear, Matthew.

I doubt that units will help. Units are good for scaling up function-style abstraction. Redex wants a lot of not-first-class info (so macros instead of functions).

Anecdote: The Unity Editor also suffered a slow-down when Mojave came out. This user blames the new font-rendering in macOS. https://forum.unity.com/threads/unity-editor-performance-under-mojave-10-14-is-less-than-half-of-10-13-x-versions-of-macos.552736/#post-3732451

The slowdown problem for large files has been around for years though (that is, before Mojave came out). I remember quitting using DrRacket when I took an introductory programming class in 2014 due to how laggy DrRacket was.

@mflatt fwiw, I’d be down for a replacement of cairo+pango.

(And given enough time might do it myself….you know in a few years. :stuck_out_tongue: )

It would solve so many problems. (Like the really slow performance on linux, and the HORRIBLE situation is PangoCairoFontConfigTtfEtcEtc fonts…)

BTW, is there any way to remove the scope added from reader extensions?

(Like, the syntax that a reader extension adds seems to have a module scope for both the module its reading, as well as the implementation module.)

I don’t think #reader should add a scope for the reader implementation. Are you sure the implementation isn’t adding one itself?

@mflatt Yes, its certainly the implementation, its the syntax object its returning.

And that syntax object has the scopes of the module its defined in.

(Unless you are saying that I should bootstrap with datum->syntax, and then try to manually add scopes?

(Basically, right now I am using quasisynta to return syntax, because it reads to something that’s not otherwise in the core.)