I see your point. I thought of the `racketfont` function as not for typesetting code, but just for wrapping around text to select the code font without changing anything else. Forms like `racket`, `racketblock`, `code`, and `codeblock` are intended for typesetting code.
As we've established, though, `racketfont` does even the job of selecting a font badly, and the documentation incorrectly suggests that `racketfont` is good for code. I've fixed the documentation and added `racketplainfont` as a non-strange variant of `racketfont`, though still preserving decoding for consistency. For what it's worth, see also the discussion at PR 14635. The design choice to split "decode" from font-selection --- but still routinely decode --- was a reaction to the Tex design that tangles font selection with something like decoding (which creates trouble for Scribble trying to use Latex as a back end) while trying to keep things simple and consistent. I still think that `tt` would be right if it simply changed the font while still decoding, but there should be some other and more prominent function that is the inline variant of `verbatim`. Meanwhile, in reaction to your tex.stackexchange.com post, I've repaired the Latex back-end to render plain quote and backquote as plain quote and backquote. At Mon, 14 Jul 2014 00:06:01 -0700, Matthew Butterick wrote: > Thank you, that works. > > FWIW I'm always tripped up by the fact that the `racket___font` functions > decode their arguments by default. IMHO if text is to be formatted to look > like > code, that ought to imply literal handling of characters. > > I've noticed a variant of this problem in the TeX typesetting of both > Dybvig's > Scheme book and SICP (see http://tex.stackexchange.com/a/178779). > > > On Jul 13, 2014, at 10:10 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > > I would have suggested the `literal` pattern, but I see that > > `racketfont` and `tt` (the former defined using the latter) are weird > > and misdocumented: they apply the 'tt style only to string arguments, > > and not uniformly to all given content. > > > > I think that you want > > > > (define (racketfont* . args) > > (element 'tt args)) > > > > This `racketfont*` refrains from calling `decode-content`, which is the > > step that converts quotes to curly quotes. > > > > At Sun, 13 Jul 2014 11:11:09 -0700, Matthew Butterick wrote: > >> In Scribble, the @racketfont tag decodes its content, so this markup: > >> > >>> @racketfont{◊(select 'h1 doc)} > >> > >> Will render as this (with a curly quote in front of h1): > >> > >>> ◊(select ’h1 doc) > >> > >> > >> But I want this (straight quote, not curly) > >> > >>> ◊(select 'h1 doc) > >> > >> > >> @verbatim is not the answer, because it will create a line break. > >> > >> @literal seems like it should be the answer: > >> > >>> @racketfont{◊(select @literal{'}h1 doc)} > >> > >> But oddly, even though @literal is nested inside @racketfont, the > >> resulting > >> markup doesn't reflect this, and renders as if the Scribble had been > >> written > >> this way: > >> > >>> @racketfont{◊(select} @literal{'}@racketfont{h1 doc)} > >> > >> > >> Meaning, the @literal content adopts the formatting of the enclosing > >> block, > not > >> the @racketfont span. > >> > >> Hence the question: how can I force a literal character within @racketfont > that > >> actually adopts the formatting of @racketfont. > >> ____________________ > >> Racket Users list: > >> http://lists.racket-lang.org/users > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
