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
m455, i lost the advice you gave me previously, detailing conventions
you'd like to conform to when writing documentation for this project. i
tried to make some changes here that conform to what pieces i remember
but probably got some of it wrong. would you mind reiterating your
recommendations in an email or text file for me? thanks!!
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
this set of patches gets repo2html working for me running as cli, both compiled
and not, for fa! there was one markdown file in fa that lowdown throws an error
about, i haven't investigated further. but i catch the error and render as
plaintext instead.
i haven't re-tested running as githook for pushing to fa and other repos yet.
i started this off by trying to learn more about how scheme does file
i/o. it seems like many of its functions just expect you'll want them to
write to (current-output-port) instead of returning a string. so i
thought, i wonder what it would look like if i tweak these content
generator functions to just (display) their stuff, and
call (with-output-to-file) and apply the html template each time i call
them?
and whew it kindof got away from me
i totally understand if you feel like this is an unpleasant overhaul of
your whole project and don't want to merge this change!
anyway let's see if i can summarize the changes:
- image support!!
- svg image support!! it shows both the svg and its source code!
- markdown support; we now render all .md files instead of showing source
- using string->goodHTML instead of clean-html. turns out, it's a little
annoying, in that it only returns a string if it makes no changes, but
if it does, it returns a list of strings. it expects to be passed to
one of the other functions in the sxml library, so that's what i do.
- moved "wrap the template" outside of various "generate content"
functions
- simple command line use: from any git work-tree OR bare repo, run
repo2html /path/to/www/output/repo-foo-bar and it will create that
directory and use "repo-foo-bar" as the repo name.
- made our example post-receive a bit more robust
- changed env var names to have REPO2HTML_ prefix
- better repo name detection and automatic caching of it in git config
- moved the post-receive-specific logic to avoid generating if we're
not updating HEAD into the post-receive hook itself, along with some
status messages
- checked directory permissions in the hook so it doesn't even attempt
to run repo2html and avoids a crash
i very much don't know quite what i'm doing with scheme's ports and
capturing output to write to files. this arrangement seems to work but i
suspect some of my changes are unnecessary or redundant and there must
be a much more elegant way to write it
post-receive commit hooks receive on standard input lines of the form:
old-commit new-commit ref
old-commit new-commit ref
old-commit new-commit ref
so we can inspect those lines to determine whether or not the current
branch (aka HEAD) has been changed. because there's no reason to rebuild
the html representation of other branches.
in future we might even use the git tree-diff between old-commit and
new-commit to determine the set of files that have been added, removed,
or changed, and regenerate the html representation for only those files,
instead of deleting and rebuilding all files every time.
