Why does render-element only evaluate its render procedure for effect? I was assuming it would let me define a custom method for rendering some content, but it looks like it’s evaluated for effect only before calling render-content.

@wjb To my surprise it actually worked. :slightly_smiling_face: I had seen code:comment in the documentation, but somehow didn’t expect it would work in an evaluated block. I had expected it would be evaluated there like everything else, so the invocation would show up as well.

Now there’s only one small problem. All the inputs in the evaluated example are rendered with the > prompt, but the comment from (code:comment ...) isn’t.

I just tried (code:line "> ; my comment"), but that doesn’t work as I hoped, i. e. the rendered output is > "; my comment" "; my comment" I also tried adding a literal newline in the evaluated code to set off the commented block from the block above, but the newline is removed.

Another approach is to “trick” code:comment with: (code:comment "\n; my comment") This kinda works, but renders a line with a single ";" (as I expected), but it looks a bit funny and I’m not sure I’ll keep it.

Maybe I’ll go with (code:comment "my comment") after all, unless there are even more ideas. :slightly_smiling_face:

For the record, the rendered output now looks like this:

It looks a bit funny, but maybe not too bad. :wink:

> I had seen code:comment in the documentation Seems I had seen https://docs.racket-lang.org/scribble/scribble_manual_code.html?q=code%3Acomment#%28idx._%28gentag._2._%28lib._scribble%2Fscribble..scrbl%29%29%29 , but there’s actually a remark on code:comment in the documentation on examples: https://docs.racket-lang.org/scribble/eval.html?q=examples#%28form._%28%28lib._scribble%2Fexample..rkt%29._examples%29%29 If you search for code:comment in the Racket docs, of these two only the first shows up.

If I swap the #:eval and #:label lines, I get even more errors displayed in the rendered output: > #:label eval:1:0: #%datum: keyword misused as an expression at: #:label > #f #f > #:eval eval:3:0: #%datum: keyword misused as an expression at: #:eval > helper-eval helper-eval: undefined; cannot reference an identifier before its definition in module: top-level

@sschwarzer I have a hunch. I think, you accidently required scribble/eval rather than scrible/example.

Everything you have done sounds right wrt scribble/example.

@soegaard2 You’re right! :+1:

I now see I import scribble/eval at the top of my Scribble document. I followed the pattern for evaluations I somewhere saw in the Scribble docs.

With the change from scribble/eval to scribble/example, this code @interaction-eval[#:eval helper-eval (require racket/string file/todo-txt)] now gives a stacktrace about an unbound interaction-eval in the terminal. But I’ll try to figure out later what I need to do here. (But if you already have an idea, I’m all ears. :slightly_smiling_face: )

Use (require (only-in scribble/eval interaction-eval)) to get than one binding.

Or (require (except-in scribble/eval examples) to get all but examples.

@soegaard2 Yep, that works! Thanks! :slightly_smiling_face:

The error messages are gone and the label (un)renders as it should. :wink:

I’ll stick with the fewer imports for now. (Your first suggestion)

Though note the docs of interaction-eval states that it’s kinda deprecated. “Use examples with #:hidden, instead.”

So you can avoid using scribble/eval entirely

The intent is that new content is added before the render phase. In case you didn’t see it already, delayed-element lets you produce new content. (I see that the documentation there refers to a render field when it means to refer to a resolve, and I’ll fix that.)

Using -j 1 may help to avoid the overhead of starting parallel build processes that don’t pay off.

Interesting, from 7.1 s down to 5.5 s.

A surface (provide (rename-out [plain renamed])) seems to fully expand to a (#%provide (rename plain renamed)) where the renamed piece of syntax lacks any srcloc. :disappointed: That piece of syntax even fails syntax-original?, even though it (originally) came from the user program’s read syntax.

Is this just some srcloc handling oversight, or, some more complicated issue? I tried to follow this in reqprov.rkt from rename-out but got lost pretty quickly. Maybe it’s related to putting only the symbol value of renamed in an export struct, and how that gets synthesized into an identifier later??

I get the impression there’s a whole provide transformer system I’m glossing over, so it’s not like “oh someone just forgot to use syntax/loc”. :slightly_smiling_face:

Yes, this happens because provide transformers return export records. At least for rename-out, the orig-stx field contains the identifier. Maybe provide-trampoline should use orig-stx when constructing a result rename form.

I don’t think what I want is to produce new content, but to custom render the content. (In this case, using pygmentize to render HTML or LaTeX)

Unless I’ve forgotten something, Scribble doesn’t really have a way to control character-level output in the rendering layer. The intent is that you go through a style that is implemented as a LaTeX macro, a CSS class, etc.

From a shallow look at provide-trampoline, it seems like it could almost be as simple as out-sym : symbol? instead being out-id : identifier?. But that would be a breaking change to the public export struct and things that use it. (Maybe more problems, idk yet.) Dang. Hmm.

Sort of. Unless you use xexpr-property (HTML) or the render backend is effectful so you can just print (LaTeX).

But the render-element seemed like a great way to do it, if I could return what the backed expects. Instead of returning an element with xexpr-property, I could use a render-element the renders to xexpr. This would be less of a hack IMO, since the user could easily support new backends using cond-render, while things like xexpr-property and literal-chars need to be first recognized by the backend, and don’t give access to the renderer.

Hmm make-export already gets the full orig-stx. Even though make-export is given only an out-sym symbol, maybe it could reliably use that to make an out-id syntax from orig-stx. Then, it could return an export+ struct derived from export, which adds an out-id field. Struct inheritance should make that invisible to users, but retrievable by provide-trampoline assuming the value is export+?. Or something like that.

Racket Meetup on Gather in 4 minutes :tv: :telephone: https://gather.town/app/wH1EDG3McffLjrs0/racket-users

Looking at this more to refresh my memory, I see that a render-element is simplified to an element if it has to be serialized, such as if the element is part of content that goes in a cross-reference database. So, that’s an advantage of the xexpr-property approach and similar for LaTeX, where there’s data attached to the element instead of a procedure. (Serializing procedures is, of course, a problem.) I guess it would make sense to have a different kind of element that wraps a procedure but that doesn’t work in serialized contexts.

I don’t know about the serializing contexts, so not sure what I’d prefer in those cases. Cross referencing doesn’t seem like something I’d need the normally rendered form for, though.

Thanks @samdphillips I can’t join tonight

See you next time!

Yes, I was able to remove it. :slightly_smiling_face:

Any chance of getting pygmentize installed on the package catalog server so this documentation builds? https://pkgd.racket-lang.org/pkgn/package/scribble-minted-doc

Sorry, no — it would be the pkg-build server, not than the catalog server, and I expect it will stick with its fixed set of OS-level packages as long as I have to maintain it

No worries.

@mflatt Suppose I am writing some parser combinators for a backtracking parser that reads strings from an input port. I originally suspected I wanted to use peek-string to efficiently implement lookahead, then use port-commit-peeked once I’ve committed to the current branch. But I quickly ran into two problems: 1. I’d like to use port-count-lines! to track source location information, but I can’t get the location of my “virtual” position I’ve peeked into the stream. 2. I don’t know how to produce the value for the skip-bytes-amt argument to peek-string because I don’t know the number of bytes I peeked, only the number of characters. So now I’m wondering if maybe peeking isn’t intended for this purpose, and I should just use read-string when I need more than I’ve already read and manage the buffering/committing myself. Does that sound right to you, or am I missing something?

You could use string-utf-8-length to decide how many bytes to consume. For counting, maybe peeking-input-port is useful as an alternative to managing the buffer yourself.

I guess string-utf-8-length requires keeping the string, which might not be convenient. But maybe peeking-input-port helps there, too.

I suppose it’s true that, in practice, it’s rather unlikely for files to be encoded in anything other than UTF–8 in this day and age, but that isn’t strictly necessary, is it? Ports can be any of several encodings, so string-utf-8-length doesn’t necessarily report the number of bytes read to produce the string.

Rebellion now provides a range-set collection :tada: