There was a bug that caused a double "html/html" in front of the link
URLs for each file listed in the "Files" view.
This PR fixes this. It's an ugly fix, because I just replaced "html"
with "" as the function argument, but it works? haha. Feel free to do
this the proper way, if such a way exists!
CLONE-URL, TITLE, and H1 are no longer processed. instead, the user
should modify the templates/default.html to their liking.
the output used to be structured like this:
target-html-directory/
+-- index.html
+-- files.html
+-- README.md.html
+-- (all the other files)
the output is now structured like this:
target-html-directory/
+-- index.html
+-- html/
+-- files.html
+-- README.md.html
+-- (all the other files...)
this makes it so people who are hosting bare repos for cloning on static
webservers will have only two new directory entries (index.html and
html) in the bare repo directory, reducing the risk of clobbering
something.
finally, i tried something hacky with gitattributes to get an automatic
version idenifier to show up. but it turns out this is not the git hash
of the commit, but instead the hash of the blob for main.scm, which
could remain the same across releases. doesn't hurt, so i'll look for a
better approach in the future.
well this was a journey :)
behavior when running `repo2html <output directory>` remains the same;
we apply our internal sxml template as usual.
to use ersatz templates, run like this:
`repo2html <output directory> <template directory>`
the program will look for a "default.html" file in that directory.
this code feels like it could be way shorter and prettier
and it's broken for a few edge cases, here's some i can think of:
- it makes no attempt to ensure the ids that it assigns are unique on
the page
- there might yet be weird characters inappropriate for an id that it
uses anyway
- it doesn't make an attempt to limit the length of the id
but other than that it pretty much works
what would that look like? (it would look like this)
- rewrote the template in sxml
- deleted (first-if) as srfi-1's (find) is the same
- made the template function into a factory, which might go faster?
- rewrote all the special-page-generator functions to emit sxml
added source-files-list to populate-html-template. kindof dislike having
so many variables passed to a function but i also kindof dislike global
variables; not sure how to make this prettier yet. but this solves the
bug i introduced in my last commit where the nav links were broken when
used as a githook.
this could use some extra thinking and cleanup, got some copy-pasted
code in both populat-html-template and display-source-html. but it's
working in my clone of fa!
This works, because when you click a link to view a file source, the
link takes you into the directory where the image is, because
directories are recursively made in the web server directory to mimic
the structure of the git repository, and so files with the same name
don't conflict, because they'll be in a different directory.
- my last fix used to use a relative path to the image, this fix makes
an absolute path
- i added a parameter to the display-source-html function so i could use
the repository-name in the format functions that are used there
- changed some of the string template "repo-name"s to "repository-name"s
to stay consistent with the rest of the main.scm
- Image paths: Images worked on the README.md, but as soon as you tried
to view the images in the files tree, and the images were in a
subdirectory, the full path was added after the directory name.
For example, an image at <git-repo-root>/images/screenshot.gif, would be
generated in the file tree with the following link:
<git-repo-root>images/images/screenshot.gif
because it doesn't know that the link to the source file is actually
also linking to the images directory, because I generate directories for
all links, as if you were actually traversing them.
This means we are able to strip the directory from the file path
completely, because our links already go to the desired directory, to
get images to show up in the source file view
- Unknown file type issues: I changed the else statement to render the
unknown filetype, because it cause the source of, for example,
main.scm to just say "(Unknown file type)". Maybe we can revise this
in the future to see when we want to use Unknown filetypes!
Thoughts: I think I'm going to try to see if prepending a slash at the
front of image paths will create an absolute path, so we dont have to
get into messy relative paths haha.
also don't attempt to render (some) binary files
we need to figure out a better heuristic for detecting what's a viewable
file and what's not. git has something built-in for diffs but i don't
know where it lives to trigger it. .gitattributes lets you configure it
but there are also built-in rules it has as well.
there's other mechanisms to detect filetype like file(1) that we could
call out to. maybe there's an egg for it but i haven't found it
