Potentially Ghost, with a Tumblr-like theme? https://github.com/TryGhost/Ghost

Thanks, I had already seen this. Looks almost exactly like what I need

I am genuinely surprised to see such a long message about 80 character limit in 2020.

Also in the character limit itself :)

Limit in 80 characters or a limit in general? Because the latter, if used as a warning, can make both the author and the reviewers think twice, which is a good thing.

In Clojure we have a 80 characters limit though

"We" as in "in the company I work with" or as in "in the Clojure community in general"?

@U2FRKM4TW I was pointing at the email's character limit.

Ah, yeah.

There's probably some relevant context here. I suspect ~80 is still a guideline.

Lobsters discussion brought up the idea of 72 non-whitespace characters. In alignment with human reading limits.

Is there a link?

A common pitfall is to equal reading code to reading prose. IMO it's completely wrong and what's suitable for one is not suitable for the other.

The issue can't be universally solved at the text level. It needs to be higher such that the text can be parsed into something with more structure and a program can read that and format it based on what ever preferences the reader has. Why isn't this possible now? Is it git:? are we all so used to it that we can't invent another way to track change? I seem to recall that Unison attempts to solve this issue.

it (literate programming) is possible now. it’s just not widely adopted

For a good reason, I imagine. I cannot think of a way to manage comments with that approach.

that’s what the literate programming tools help you do

Could they help reformat a 120-character-wide ASCII diagram in a comment into an 80-character-wide one?

actually, yes, but you would never do that because most of these tools also allow you to embed actual diagrams

I can't find anything quickly - everything that I find seems utterly irrelevant. Do you have an example or at least a link that more or less clearly shows such capability?

the source code for tex is the canonical example, http://brokestream.com/tex.pdf . jupyter notes books are an example of a more recent approach: • https://github.com/jupyter/jupyter/wiki/A-gallery-of-interesting-Jupyter-Notebooks • https://nbviewer.jupyter.org/github/jrjohansson/qutip-lectures/blob/master/Lecture-2B-Single-Atom-Lasing.ipynb

a more clojure(script)y example: https://github.com/bhauman/devcards

OK, those are some of the examples that I've found. But I still don't get what you're saying. I'm using Jupyter notebooks from time to time. And they have nothing of what you describe. You can mix text and code there, yes, and the text will be laid out depending on how the notebook is represented. But the code will never be reformatted for you, ever.

in the example of tex (initially released in 1978), the source code is heavily reformatted. in the last 42 years, there’s been lots of work/research/examples of literate programming. I don’t know how much reformatting is considered enough. basically, I don’t know it what it is you’re looking for.

I'm looking for an example where the source file formatting does not matter at all, where how a user sees the code depends only on the preferences of the user and not on how the file was initially formatted.

I personal wasn't talking about literate programming. I was saying that ideally our tools (editor, version control) know about the abstract syntax tree of our language and are able to track changes at that level rather then text/whitespace/etc...

you can set you editor write now to wrap lines at what ever you like. The big hurdle i see is that we track changes on git and so you can't reformat the entire project everytime.

structured editors do that, but I don’t think it’s very common outside structured editors because it’s not very useful. the main problem is that it causes issues with version control and that the alternative solution, making everyone that works on the code base adhere to a specific style guide (eg. gofmt) is much better.

> the main problem is that it causes issues with version control Yes, because they track changes at a text level?

right

Yea. That's the problem that needs fixing imo. Everything upstream of it is just pushing the complexity around.

and the benefits are much greater than just allowing you to change how whitespace is used in your program

you could technically achieve this while still using git, but you’d have to augment the git porcelain to make it usable

I think unsion, which treats functions more like data in a database is probably a step in the right direction. I'm not aware of what porcelain does.

oh i see. yea.

right, git commits are just a tree of of data.

so instead of storing text files, you could store the AST somehow

that would be a fun project

I think there’s a talk where someone from cognitect started storing programs in datomic and found some interesting things you could do with that

you could still have formatting be user independent without solving the version control issue as long as a canonical formatting exists. for example, you run something like gofmt to format the code in your preferred style when you work on the code, but then you run the “official” gofmt when you check code in.

Can't you change git's diffing algorithms?

Also just saying, I'm 💯 with Linus, at least go 120 if not more

Personally I prefer having no line lengths. Let the dev put newlines wherever they think is best. And only have a formatter like cljfmt that indents and aligns, not one that wraps lines