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.