Hacker News Reader

Grouping code … You can't really represent that in an AST.

<visual-group>…</visual-group>

Also, I wish that at least in current editors there would be a way to render \n\n as a half-height line. Full-height empty lines are too bold.

Automatic wrapping doesn't work because you want to break at specific points

You really want to have a set of buttons that switch between:

  - a line of arguments
  - a block of arguments
  - a line/block of only non-default valued arguments
  - arguments sorted by name
  - …

And a hint on a default representation, with some default heuristics.

How does it know that x, y, width, and height are semantically grouped and best put on the same line? It doesn't. (from the other comment)

Look higher, parameters can be grouped at the declaration level. <params><related-params name=“coords”>…</>…</>. Now you can render a nice frame around these in block mode. Or not, depending on local renderer settings.

Everyone will hate it.

There’s always a way to make everyone hate something, especially if the solution is clueless about its problem. It doesn’t mean it should be done this way. Experiment and evolution could make it work, we just have to let people try instead of dismissing it so confidently.

I agree about horizontal space adding to readability and I use that method fairly often.

That said, if you use classes, descriptive names, and appropriate comments, it won't matter how you group because your code will be self explanatory.

Finally, with today's wide-screen monitors on desktop, line length is less of a worry. Problem only arises when reading code on mobile devices.

The last workplace I was at had a soft wrap around 80 characters, but we upped that to 100 when functions and methods became almost vertical.

Line length is a worry because of readability. This is unrelated to the width of monitors. Having to read and visually parse a 200-character line is no fun. In addition, since most lines are relatively short, you also don’t want to have your source code window extra wide just in case, if instead you can use that space for other useful information and controls.

Also, why does your comment have a paragraph break after each sentence except after the third? Because of semantics and the related readability. The same is true for source code. Readable layout does not depend on syntactical structure alone.

> today's wide-screen monitors on desktop, line length is less of a worry

did you buy a large monitor just to full-screen a single text file?

You want to wrap in logical locations at times. That's my point. To repeat: cramming as much as possible on as few lines as possible is just not going to work well. Wrapping at column 80 vs 100 or whatever has nothing to do with that. That XCreateWindow() would be:

  window = XCreateWindow(display, XRootWindow(display, screen), center_x, center_y, size, size,
      4, vinfo.depth, CopyFromParent, vinfo.visual, CWColormap|CWBorderPixel|CWBackPixel|
      CWOverrideRedirect, &window_attr);

And that's just not better. It's much much worse. Only a human can judge where it makes sense to break things (or not break things).

Completely forbidding "paragraphs" would be atrocious. Almost everyone will hate it. Just like everyone hates walls of text in comments.

And in the end a huge amount of complexity is added throughout the entire stack (from editors to grep to sed to code hosting) for very marginal gain with significant trade-offs.

Two points:

1. Breaking at specific points is something that can be specified by the pretty-printer of the _viewer_ you are using. Think of existing auto-formatters and imagine that they're working over the view instead of the persisted form.

2. The AST can have pointers into advisory data (or the other way around, if desired, the "program data" can include the AST, but also other things as well) to note that there is an anonymous region here (C# and friends already have conventions for this _for the source code_ that Visual Studios understands - look at `#region` comments). This would let viewers choose their preferred representation for a region.

You can't specify it in the viewer, because it won't know where to break. How does it know that x, y, width, and height are semantically grouped and best put on the same line? It doesn't. Auto-formatters can't format this. Or rather: they can only format it in dumb ways.

And including tons of extra info in the AST means you've just got the same as a text file, but in a more awkward and obfuscated format.

Also what you want can already be done right now. Converting your source code to AST and then formatting it how you want is already easy to do. But your coworkers will hate you, because you will lose all these small details that are actually quite significant. And there is no way to get them back once they're lost, so your coworkers all using some formatting tool is not going to help.

You're thinking about the AST as the-AST-for-LanguageX not the-AST-for-LanguageX-withAdvice. Including an AST node called `Region` or a decoration for "Region" that multiple AST nodes can point to (or vice-versa a list-of-region indicies pointing into the AST tree) _that is serialized and stored in the same kind of way that #region is for C# code_ would allow for multiple people to look at the code structured in the correct way while displaying that structure in different ways (color coding vs. block outlining vs. extra newlines vs ... you get the idea).