mapreduce

> If you are strictly going to stick with Hugo forever, then that's fine. But how many of us can guarantee that we want to keep using the same tool to render our Markdown for ever? I certainly can't!

The problem I have is that I don't want to lock myself into one single Markdown renderer like Hugo or whatever it uses internally. I'd like the flexibility to change tools later without worrying that the new tool may break the rendered output.

Like I said, not even something as basic as nested lists are rendered the same way by all tools. What is rendered as nested list by one tool is rendered as a broken list with unexpected code blocks interspersed between them.

A single spec consistently implemented by all tools could fix these issues. Sadly such a spec does not exist in the Markdown world. That's really why I was looking for something like C89 of the Markdown world.

> X/Winteracter 15.0 demo (Linux/x64)

> OpenGL demo (Linux/x64)

Apparently I am not up-to-date with all the Wayland stuff that is going around in Linux, so this may be a stupid question. But does the above quote mean that Winteracter is not going to work in new Linux distro versions that only support Wayland? Do let me know if my question is not making sense and enlighten me about how GUI toolkits work on Linux these days.

Where I'm coming from: I used to take org-mode notes sometime back and push them to GitHub. Everyone told me GitHub can render org-mode, so it is going to be a great experience when I want to read my notes later and when I want to share the notes with others. But sadly the GitHub org-mode parser is terrible. Instead of just using Emacs itself to parse org-mode files, GitHub has reimplemented some half-baked org-mode parser in Ruby that breaks in all sorts of edge cases. So I can still write my org-mode notes in Emacs and review them in Emacs but I cannot really share them easily with other GitHub users as the initial claims promised it to be.

Every Markdown spec differs from others in one way or the other and there is no way to tell that if the Markdown documents I am writing today will convert to PDF, HTML, etc. in exactly the same way 10 years later as they are converting today.

Two Markdown specs may end up converting the Markdown into different types of HTML and PDF -- sometimes even with semantic changes like nested lists in one spec is broken list in another one. Nothing is more displeasing than seeing a carefully written nested lists appear as ugly code blocks within lists because a different Markdown spec does not support nested lists the same way as the first Markdown spec I was using. This is just one of many examples where Markdown for one spec can break in another spec.

If you are strictly going to stick with Hugo forever, then that's fine. But how many of us can guarantee that we want to keep using the same tool to render our Markdown for ever? I certainly can't! I really wish there was a simple documentation format that with a single spec with a large number of implementations -- something like the C89 of text formats. Is there one?

So when I revisit that page after a long time and see that the light is lit, does it mean that the state is currently ON or does it mean that the state will change to ON when I click it? How can I tell this by instantly looking at the lit light?

I mean I did not try AsciiDoc until now because there are so many choices of input formats and the ones I've tried so far have been disappointing one way or the other.

I talked about Org-mode rendering broken in edge cases. Same with Latex too. I see Pandoc has first-class support for its own Pandoc Markdown format. But the support for all other input formats seem patchy.

If you think Pandoc has good support for AsciiDoc without any edge case issues, I'll be most certainly trying it out.

> In the case of the second, the Story was in third place on the Front Page, less than an hour after the submission. In this case it was simply removed from the Front Page.

With repeatedly getting flagged articles like this, at some point you have to begin to wonder if you are not simply spamming the community by trying to promote your links.

I get that people want to promote their stuff but the community has preferences too. The community can get tired of LLM articles reaching the front page everyday! The community can refuse to be spammed and the community can flag articles!

> While I have no reason to doubt Daniel's good faith, it's hard to believe that HN users would be tired of LLM-related news.

Denial? Why is it so hard to believe that HN users would get tired LLM-related news. I get tired of it myself but I don't have flagging privilege. I find it very believable that HN users who have the flagging privilege might want to flag LLM-related news.

I find Org-mode the easiest but like I said in my comment, the conversion quality is not great. Pandoc breaks a lot of stuff in Org-mode in edge cases. One example I shared in my comment was Pandoc breaking internal links.

So by selecting something I find the easiest I have burned many hours of troubleshooting figuring out why the output does not look right.

That's why I want to draw upon the wisdom of the community here to find out which input format works best and by best I mean flawlessly. No edge case issues. No rendering flaws. If I get the specific recommendations, I'll try them out for sometime and then commit myself to it instead of burning more time trialling all of the different input formats.

I want to write a small book that I want to generate in 3 formats: HTML pages, EPUB and PDF. What is the best input format (source format) for the book? Pandoc Markdown? CommonMark? GFM?

I'm a little hesitant to committing myself to Pandoc Markdown or any Markdown because they all have tiny differences with each other. Each is like its own standard.

I considered Org-mode for some time but there are so many edge cases in which Pandoc does not parse Org-mode properly. I mean sometimes simple things like internal links are not rendered properly by Pandoc in the generated output.

So what's the best format to write the input in? Any ideas? Opinions?

What I'm struggling to understand is how the insects then reach so close to the artificial light. Why don't they spiral the artificial light from a great distance like 1 metre or 2 metres away? I see the insects hovering like millimetres or centimetres away from artificial light.

"In both field and lab conditions, insects rarely head directly towards, but consistently fly orthogonal to the light source. This refutes the fundamental premise of an escape response."

"An insect should keep a light source at a fixed visual location for maintaining its heading. Switching light position (Supplementary Fig. 5) shows that insects readily hold the light source on either side of the body."

It makes sense to me. Imagine you were an insect and you would use the moon for navigation. Would you really be flying directly towards moon? No, right? Then how could someone think that insects flying directly towards artificial light source is the basis for the theory that insects use moon as navigational aid?

I read the whole article and its a lot of words to simply say: There are a lot of factors at play. It could be a mix of those factors.

Beyond that the article does not seem to give any specific insights. It provides many loose analogies to show how something good might not be not mainstream in other walks of life. But it does not go on to elaborate what it is specifically about Lisp.

So I guess I am trying to say I don't know what to do with this article. The talking points are all common sense. And there's nothing specific about Lisp I can learn from this article.

If you follow the comment you replied to the discussion was about implementing a renderer. So no, I am not shifting the conversation to implement a renderer. The conversation is about implementing a renderer. That it is incredibly difficult to do today with the modern specs is the point.

It still is but you are missing the point of the thread. HTML still is hypertext, some links, some images, some tables. No doubt about that. But HTML is also so much more than that. The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. It's like "go implement a new browser" like someone said in this thread above.

> "Styling is not handled by HTML. It's a separate concern assigned to CSS."

Missing the point again. We know styling is not handled by HTML. The point of the thread was to tell how big of a task it is to create your own HTML based reader. If you want to create your reader like it or not you have to implement support for CSS too and that too is a mammoth spec.

So our only options are: A. Go implement a new browser. B. Use something like Webkit. C. Implement a small subset of the HTML and CSS specs.

Don't we need to define the custom element <whatever-you-can-dream-of> using javascript first?

All my knowledge about custom elements comes from this Mozilla doc: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

If custom elements is the way to go, it sounds like a lot of javascript and coding overhead that I have to take. Doesn't it?

Allow me to become a little philosophical but since human beings which are product of nature made plutonium, isn't the making of plutonium natural too?

I mean everything that is happening in this universe is natural!

I know the general usage of the words "artificial" for human-made and "natural" for everything else. But when we are talking at the grand scale of life and universe I think a human-made plutonium is as natural as bee-made honey.

In this day why don't the credit card payment systems require multi-factor authentication for online payments? Why don't payment machines challenge you for PIN for payments?