-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
leveraging org-publish for the HTML-creation? #2
Comments
I am afraid that I don't get your method. Could you describe it in more detail with a minimal example? Furthermore: I want to have total control over the HTML-generation step because of replacing [[id:another-article]] with the resulting HTML link and much more. I guess by using org-publish, this is not possible any more. |
with org-publish you’d use the HTML-creation from org-mode. You can define new link methods, though (the adaption for HTML creation would then be in elisp, not python). Orgmode provides ways to iterate directly over headlines in org-mode files. I sadly can’t provide a minimal example right now: It could use something like org-map-entries^map to get all tagged entries and then create the site as org-mode documents. These would then use setupfiles for the HTML-export: http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html#sec-6 |
OK, this seems to be a very basic discussion on the underlying principle of getting information from Org to HTML. Firstly, I do not want to lose (total) control over the parsing and generating process. I parse additional stuff and I plan to parse and handle a lot more stuff like, e.g., sub-heading IDs. With org-publish, I would have to invest a lot of effort in re-parsing the HTML to add lazyblorg-stuff like unique IDs, internal links, ... It is not "just" converting Org syntax to HTML - I do interpret, process, and generate additional data during that process. This can not be done that easily when the parsing and generating process is done in Elisp and the rest is done with Python. Therefore, secondly, I do think that using org-something to parse/convert stuff does only make sense if the rest of it is also implemented in Elisp and not in Python. Sure, lazyblorg implemented in Elisp would be a much better idea! I can fully understand your desire for using any kind of Org syntax elements. However, I am not able to implement lazyblorg in Elisp. I was asking for help for this but no one was interested to volunteer to this big task. Therefore, I had to implement lazyblorg in Python which I am using for programming. This results in a technology boundary which results in supporting only a well defined sub-set of Org syntax. However, the design decision was made and lazyblorg will probably never use any Elisp functionality in order to keep the technology complexity at a certain level. However, I'd be happy to see a re-implementation of my ideas with Elisp. But for now, I will stick to Python and my (very limited) Org-mode parser. |
OK - thank you for going into detail in your reasoning! I’m also no elisp-master (and much better with Python than with elisp), so I well understand the design decision. Maybe I’ll manage to build something like that myself some day - I like the idea to give the path as property - fits pretty well to the information concept I found for websites (with the path as its own type of information). |
Update 2015-01-27: I am going to test https://github.com/bebraw/pypandoc for converting blocks of Org-mode syntax elements to HTML. This way, I am able to keep control of the general parsing/htmlizing process. Furthermore, lazyblorg is able to support all Org-mode syntax elements which are understood/parsed/converted by pandoc. Stay tuned how this (big) refactoring is going to turn out. |
very cool! pandoc can be a pain to build (at least on Gentoo), but it’s pretty powerful. |
My first spike was done within minutes:
No further tasks done so far but the test above looks very promising to me. |
Am Freitag, 30. Januar 2015, 08:23:10 schrieb novoid:
Nice! I did not know about pypandoc! Best wishes, |
Please do read http://karl-voit.at/2015/05/15/pypandoc-for-lazyblorg/ for my results of using pypandoc so far. |
Hello, people! Sorry for the necro-posting, but I am a bit curious. Is it possible to re-implement lazyblorg in pure Emacs Lisp? Obviously (?), I am not suggesting to do it here and now as a default implementation, but as a mere experimental, independent 'fork'. The most obvious answer would be "yes, elisp and python are Turing-complete, then they can be converted blah blah blah". So, I need to be a bit more specific: is there heavy use of Python features or external packages that would be needed to be reimplemented in elisp? Something like internet access, file conversion, serialization etc.? (Sorry, my English skills are a bit very poor.) |
Yes.
This needs to be the case, yes.
No. I'm not very keen in external dependencies myself. Therefore, there is little code from external things. However, if you want to re-implement it in Elisp, it's a 100% independent project and chances are that you won't follow the exact implementation details of lazyblorg. Given that, it's just yet another Org-blogging method in Elisp with a few new notions (blog anywhere, templating in Org, lazy linking images, ...). That's OK but it will not be supported by myself since I can't code in Elisp good enough.
Don't worry. I think I got everything. |
I like your approach to URLs and I like the simplicity of lazyblorg. The only thing which irks me is only having a subset of org-syntax.
Could the site be created by setting up org-mode files with exact copies of the blog-entries and then running that through org-publish? A
#+setup: …
line could take care of templates.This would be no true intermediate format, since there would be no conversion step between the org-mode text of the entries in the original files and the org-mode text in the finished website. Also this would allow you to avoid following org-mode syntax.
Another advantage is that you could get a preview of an article by simply exporting the subtree (change the scope in the export).
The text was updated successfully, but these errors were encountered: