So yes this might be unnecessary. In my mind, the most efficient way to
implement what I want is to generate the references data up front, and then
render what I need with that data. So, basically I am using a two step
process, step one is analysis, step two is rendering.
Let me try to describe what I am trying to accomplish more fully. Much of
this has been discussed, but I think it might clear up a couple of things:
1- I want to be able to specify links more flexibly than by specifying the
exact path/filename/element id each time I wish to link something. Lets say
I had a file `entries/fp-jargon.html.pm, with an element which has a
definition for traversable. My vision for the best way to conveniently link
to this would be to be able to type e.g. `◊link[#:to '(jargon
traversable)]{Traversable}`. In order to do that, I need to have the
`link` tag be able to find which file has the name and/or alias "jargon",
and then see if that file has a sub-item "traversable". If it does, great,
produce the link, otherwise, output an error for me, and ideally also
provide suggestions for what *would* be a valid link reference.
2- As alluded to, I would like to be able to see a list of all the valid
linkable items. I confess that I regularly forget what I named something
that I wrote a few years ago, and this friction makes me lazy enough to
tend to avoid cross-linking things I have written, and *especially* avoid
looking at the things that I wrote in the past to see if they should refer
to something I have written more recently.
Now, the behavior I wish to design for ◊link is somewhat complex. Ideally,
I could refer to `traversable` as either `◊link[#:to '(traversable)]` OR
`◊link[#:to '(jargon traversable)]`. In the first case, it would need to
first scan every file to see if any of these have a name or alias matching
"traversable". If none is found, then it would need to scan each file and
see if any element in that file has defined a "traversable" id/element.
Additionally, I think I may to have an error if it is ambiguous to where a
link should refer -- say in the case where I later implemented a page with
the name "traversable.html.pm", so the older references might now link to
either place (but I want them to stay where they were originally).
I describe this full behavior because I think the calculation of all the
potential destinations is fairly complex. In fact, the basic implementation
I currently have *is* slow enough at this point that I do not think I want
to make it that much slower.
The way I have currently implemented page element link destinations is by
having them be "registered" by side-effect. So, if I have an
◊linkdest[#:name 'intro], the tag handler function for this adds the
destination into a file. In fact, this is the case I was referring to last
night, because I want the destination registered to be '(my-page intro),
not just '(intro), which requires linkdest to know the name of the page it
is currently on. Now, I did consider deriving all the potential page link
destinations by processing the xexpr doc export instead of doing it by side
effect in the function handlers, and I still may go to that, but that seems
even slower. Relatedly, Ive tried recursively processing xexprs in the past
and found it frustrating, so I was hoping to avoid that for now.
The point is I was hoping to avoid having to rebuild the entire links table
every time I process another file. However, I might try it anyway, because
it would be useful for me to understand the order of operations of
rendering/what I get out of `get-doc` exactly. Rebuilding might not be as
slow as I imagine. But, it used to take quite a while to rebuild my Jekyll
site, enough to make it painful.
There are still other "state" concerns that I will need to handle though,
such as "which environment should this be built for?". But the performance
concerns here are not nearly as large.
On Mon, May 27, 2019 at 6:52 PM Matthew Butterick <m...@mbtype.com> wrote:
>
>
> > On May 27, 2019, at 3:20 PM, Joel McCracken <mccracken.j...@gmail.com>
> wrote:
> >
> > I suppose I might be able to do that, but I don't think it will solve
> my overall problem. `pollen.rkt` gets loaded/computed repeatedly, once per
> page, so it would lose context between pages. I would then have to
> re-compute it, and/or read/write it to disk, which is what I am doing right
> now, which I would like to avoid if possible.
>
> I'm still not clear why you need to introduce global state. Didn't you say
> the alias names are embedded in the source files as `meta` values? So why
> not just have "pollen.rkt" generate the alias table every time it runs?
> (You can read the `metas` of a Pollen source without rendering the file, or
> even the `doc`, for that matter.)
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pollenpub+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pollenpub/CAOdqJSjb5H%3Do0R%2B%3Ddd7qvtnPGu8fMWD8RLOQ9Uqib8NmHLY_mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
