3.6 is required because my early implementation used f strings so heavily that I had no intention of going back and fixing it!!
Has there been talk about adding a filesystem watcher so that
gitbuilding serve will work with external editors (VS Code, emacs, etc)? Is there support for a feature request related to that? Also, is it intended that when I click the Edit button with the landing page selected, that both panes seem to fill with the content for a new page, rather than editing the landing page itself?
Looks like the edit button link for the landing page should point to
http://localhost:6178/landing.html/-/editor/ instead of http://localhost:6178/index.html/-/editor/. I'm assuming the exported html in _site turns landing.md into index.html though to avoid additional web server configuration though.
This should be my last one for this evening. I changed the hardware license in buildconf.yaml to match what I have on my repository, and now I get a warning:
Warning: License CERN-OHL-P set configuration. Could not match to licence text. I'm not sure what GitBuilding is matching against, but CERN-OHL-P should be a valid license code. I also just noticed that "license" is misspelled. I'm still learning GitBuilding, but I like where you're headed with it. I may want to retract my question about using external editors. BuildUp is just enough different that it creates a fair amount of friction with the markdown extension I use. Some syntax highlighting in GitBuilding's markdown editor would be very welcome though.
These are all really useful feedback. The landing page thing seems to be a bug. The file system watcher is something that would be good to do. Syntax highlighting I tried to do, but I suck at javascript and everything I tried broke something else. As for licenses we use the SPDX list: https://github.com/spdx/license-list-data/tree/master/text
Thanks, I had not put
-2.0 on the end of the CERN-OHL-P license identifier. That's fixed now. The editing bug only happens when at the root of the server (http://localhost:6178/). If you're at this address http://localhost:6178/landing.html clicking Edit has the intended behavior. A flash message instead of a popup after clicking Save (or at least when hitting Ctrl+S) would be helpful during busy editing sessions. Having to acknowledge the popup after saving adds some friction for somebody like me who compulsively saves.
I feel like it would be good if links to external sites opened in a new tab by default. Right now what I have is a link to the CadHub.xyz website where the user can modify, run and download a 3D model created in CadQuery. When I click on that, CadHub loads in the GitBuilding tab and the user loses their place in the docs. Normally I would embed html with
target=_blankto achieve this, but I'm not sure how that would work in GitBuilding's editor, and it seems a little clunky to mix HTML into markdown anyway. Thoughts?
GitBuilding doesn't already do that, does it?
It might be nice if a note on a part had some sort of indicator attached to it. Right now the part name and the note kind of run together. Maybe that's intended though?
Or maybe notes could be in a tooltip or in a text area that can be expanded/collapsed? I don't know, just throwing ideas out there.
Sorry, the previous screenshot of the rendered text was from the wrong spot.
Ok, I got it. Please let me know if there are things I need to improve about my use of GitBuilding's tools. https://7b-things.github.io/braille-signage-generator/
When I export my build docs to HTML, the tab title in the browser, title at the top of the page, and title in the nav bar on the left all say "Untitled Project". I didn't have that problem before I exported. I do have the Title value set in buildconf.yaml, so I'm not sure why this is happening.
I have deployed a GitBuilding project to the static directory of a larger site, so it's not hosted as the root site. That makes it so that I have to end the home/root URL with index.html instead of just a forward slash. When GitBuilding generates the static HTML, it assumes that the root of the docs will be available via the forward slash URL, so the home links in the title and top of the nav bar are effectively broken (with the way I have it deployed). Right now I'm editing each of the pages by hand to fix this. It would be nice to have an setting to make the home/root links use index.html instead of assuming forward slash. Does this make sense?
If you remove the index.html from this URL, you will recreate the URL that the nav/title links lead to. https://7bindustries.com/static/braille-signage-generator/index.html
So the more I think about the "./" vs "./index.html" problem, the more I'm glad I didn't file an issue for it. I think it's probably mostly due to the fact that I'm serving the files from the static directory of a Flask app, which is behind an nginx server. If I was just serving it via nginx, I don't think this would be an issue. All I should need to do is to add a route in the Flask app that serves the index.html file at the URL that GitBuilding expects. I'll hopefully have time to try that tomorrow.
Soon I hope to make a start on some of the issues you found
V0.9 is released, It fixes the bug with the landing page and also adds the space around the note as well as a number of other things that have been in the pipeline for a while https://pypi.org/project/gitbuilding/0.9.0/
Hi all! I have a question: is there a syntax highlighting functionality for code chunks in markdown? those sandwiched between three backticks ยดยดยด (i think its called "fenced code").
I looked at the markdown module used to render the .md files to HTML: https://python-markdown.github.io/reference/
It seems to have a syntax highlighting extension available, but im not sure how to use it.
The render_md function at gitbuilding/render.py seems to load extensions such as this one.
Using the extension also requires generating a CSS stylesheet for the highlighting using python-pygments.
There may be more requirements, but that is as far as i got for now.
Perhaps one of you will know how to enable this feature. Im interested because i got used to syntax highlighting and it sort of became important (at least to me) when looking at code.
Thanks :)
I think the highlighting needs to be solved in Javascript. But I am not the best person to do that. GitBuilding really needs a Javascript developer. Rather than me hacking wildly whenever we need to improve the editor