Question about `parse_rpath`

[findmyway]

If I understand it correctly, when executing parse_rpath("./file"; canonical=false, code=true) in blog/a/index.md, it will be resolved to /assets/blog/a/code/file. If code=false then it will be resolved to /assets/file.

If so, why is ./file resolved to /assets/file instead of /{locvar("fd_rpath")}/file?

[tlienart]

Possibly this can be revisited; this is the kind of small, a bit annoying but important thing to get right.

The reasoning is as follows: code blocks generate files; and I thought it made sense for the generated stuff to follow a folder structure that matched that of the source file. To make it simple to access that folder structure, there's the shortcut ./....

However, in general, assets are just "there" in the assets folder and I thought it made sense to also provide an easy way to just get those by saying that ./ would refer to the /assets/ folder.

Does that make sense?

[findmyway]

Yeah, it makes sense. But you only mentioned the cases when calling it in code. Personally I'd like to put related files together in the same folder (index.md, figs, data).So would it make more sense to look into current folder first, then in assets with the same structure and then code folder?

Anyway, it's not a big problem. I can handle it in my customized function. Just wondering am I the only one to have this problem 🤔

[tlienart]

Ok no so maybe I wasn't clear:

Code context

in this case, files are generated meaning that the execution of code will generate files (.jl, .out and .res) which should go somewhere; the "somewhere" that seemed to make sense to me is to match the structure of the file that generated them so if you run stuff in /blah/foo.md then it will go in /assets/blah/foo/code.

The shortcut here is ./ for code because given the rule above (where files are generated) it makes sense to have a shortcut that directly draws from those files.

Non-code context

In the general context people might not care about code at all, they might put their assets in assets following the file structure that they want which may be the same file structure as the calling file but not necessarily, this is not imposed on them and so as a result it doesn't make sense to have ./ refer to the same file structure as the calling file as that file structure might not exist.

Organising stuff

indeed if you do want to have all assets required on a specific page to be in assets using the same file structure as the calling file, then that's great, and you could write a command that fills in that path for you, indeed something like

\newcommand{\rpath}[1]{/assets/{{fd_rpath}}/!#1}

might work.

So the important thing here to understand for the current situation is what is imposed (what Franklin can assume will be true) vs what is "encouraged" or "possible"; people get quite defensive with their way of organising files (which is totally fine) and so it seems wrong to enforce specific folder structure which might quickly become rather cumbersome.

Does that seem more reasonable?

[findmyway]

My confusion was why it looks for files in assets folder.

In the general context people might not care about code at all, they might put their assets in assets following the file structure that they want which may be the same file structure as the calling file but not necessarily, this is not imposed on them and so as a result it doesn't make sense to have ./ refer to the same file structure as the calling file as that file structure might not exist.

Now I think it explains well.

Regarding

(what Franklin can assume will be true)

Let's take this folder structure as an example.

.
├── blog
│   └── a.md
└── _assets
    └── blog
        ├── x.png
        └── y.svg

I think this is the assumption in Franklin.jl. But I personally usually use the folder structure below:

.
├── blog
│   └── a
│        ├── index.md
│        ├── x.png
│        └── y.svg
└── _assets

Doing so will make things easier to manage. And I think parse_rpath doesn't consider this situation.

[tlienart]

yes I understand; maybe that this behaviour could also be specified in a global page variable. Not sure what it should be named though.