Hacker News Reader

Comment by VBprogrammer | Hacker News Reader

Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.

View on HN

You're absolutely right of course.

But even now I have to adapt on screen shares when my coworkers are using dark themes before sunset. Can't imagine what that would be like with different code formatting. So the next next step is to display their desktop with my theme.

IOW collaboration tools still have a long way to go.

I think this is the most wonderful part of Lisp. Specifically its homoiconicity, or the fact that the syntax of the program is the program, and yet the syntax (as far as linebreaks, indentation, spaces vs tabs, etc) is completely irrelevant to the meaning of the code.

Ostensibly you could craft a future where what is on disk is not what the user is actually editing - a-la the virtual DOM. And on read/save the developer's preference is used to transform the syntax into their ideal shape. This is trivial in a Lisp, but not so easy in other languages.

Indentation is not the reason why it's hard to autoformat Python code, or any other language for that matter.

it's definitely a reason for python. consider:

if foo: if bar: do something else: do something else

how would you autoindent that?

You wouldn't, as that's not a valid python line.

I'm pretty sure you can already do that with some scripting. Just write a git alias, say git edit, which will run the work tree copy through your favorite formatter to a temp file and send that temp file to your editor, and a commit hook to rename all the temp files back to the original and format them back to whatever the canonical format is. You can also configure your git diff and stash etc to make them aware of the temp file naming convention. You might even be able to write a script to generate all these aliases. There are some annoying details such as needing a separate command to temporarily move the temp files to the work tree to give your IDE a hand, but totally doable. It's going to take maybe a few weeks of work, but doable for a single person.

This is the way. I had not considered this before reading your comment.

If this system results in syntactically identical code [1] it should not matter if it’s displaying for you differently [2] if it means you can read or write around or in it more comfortably it’s just a hairstyle.

I was asked to familiarize myself with Replit the other day and it seemed the editor defaulted to two spaces for Python. Two spaces?! I changed it to four.

A friend joined my session and began to code with me, their editor was in the default two space indentation. It was madness.

[1] This seems like is a decent sized presumption across many languages and versions.

[2] This seems like an interesting AI problem, showing code structures you’ve never used in your style you’ve never defined.

You brilliant lunatic

I've been thinking about this for a while too.

I think that making editors do this is within the realms of feasibility. Most support auto-formatting to your preferred style so it doesn't feel like a leap for it to format to your preferred style but keep the file on disk the project owner's preferred style. I haven't looked extensively to see if this already exists though but we chatted about this at work as I was advocating for use of prettier on a front-end project!

I think that’s already possible using git smudge.

Example here: https://bignerdranch.com/blog/git-smudge-and-clean-filters-m...

Smudge & clean might do the trick, but it could be dirty. The smudge -> clean process might produce additional changes that aren't related to the purpose of your commit. Whitespace in particular could be a problem, especially where there's ambiguity in how it should be used. black isn't as bad because it has stricter rules on whitespace. Still, if you aren't checking style rules before every merge someone using smudge and clean could end up reformatting entire files.

IMO the next next step is, as others have discussed on HN, getting your version control to store and abstract syntax tree. tree-sitter could make this easier nowadays, but I think it'd need more invasive changes in Git than just using the filters.

See this HN thread https://news.ycombinator.com/item?id=28670372

Reply on news.ycombinator.com