Hacker News Reader

Comment by DoubleGlazing | Hacker News Reader

I think this is a subject most editors fail to address.

A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings.

Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator or a dot in a function chain. Wrapped lines could be tabbed or visually flagged to let you know.

In other words there should not be am ideal line length for code, but instead editors should be able to adapt to make life easier for developers.

Look at word processor documents, imagine how much of a nightmare it would be if such documents had a hard limit of characters per line.

View on HN

> wrap gracefully at logical point in the code

This is so clearly right, how can it not yet exist?

‘Just’ dynamic virtual pretty print per personal lang style prefs.

One thing that's a little tricky is once you do that, the real code doesn't match what's on the screen. Not so bad if it's just whitespace, a little worse if you have to add characters to allow the line breaks. Still, I'd like it and would probably use it. I'm sort of a sadist in that I like 120 width, even though I can't quite go 2 windows wide on my laptop. I just side scroll like a peasant.

Xcode on OS X has been doing this for at least one decade.

http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro... might explain why 'just' doing the pretty print on the fly might not be a easy thing (even if the problem here is limited to a single line of code and something based on line length).

This would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets.

That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.

The editor could show both the final line number and "sub-line-numbers" after a decimal point or something. E.g.:

    1   /* A function that does something */
    2.1 int do_something(int foo,
    2.2                  int bar,
    2.3                  int baz)
    2.4 {
    2.5     return foo + bar + bam;
    2.6 }

Which would condense to:

    1    /* A function that does something */
    2    int do_something(int foo, int bar, int baz) { return foo + bar + bam; }

When you try to compile this, the compiler will complain about line 2, which you know from your editor's line numbering encompasses lines 2.1 through 2.6. As an alternate strategy, you could use column numbers instead of sequential sub-lines, like so:

    1    /* A function that does something */
    2.0  int do_something(int foo,
    2.26                  int bar,
    2.35                  int baz)
    2.44 {
    2.46     return foo + bar + bam;
    2.70 }

And then, if the compiler reports a column number or offset into the line, you'll immediately know "well the compiler's complaining about line 2 column 65, which is between 2.46 and 2.70... golly gee willikers, I fat-fingered the third addend in the return statement!".

You could get even more abstract than this, with "line numbers" instead being local to a given scope, and the compiler reporting erroneous line numbers relative to said scope. If the compiler tells you that the syntax error is in the first (in this case also last) statement in the function do_something, then it should be apparent where to look.

Not always. I can set the breakpoint in jetbrains rider to a function in a multi function line. And Java stacktraces certainly contain character offsets.

I’ve seen character offsets for JavaScript (which requires it due to minimization), but never Java. I’m pretty sure that data is not available in Java bytecode, nor most compiled languages.

Even vim handles word wrapping well. A text editor which can't... well, it's a pretty poor text editor then, isn't it?

That said, I don't know of many text editors (outside of notepad, and even that's gotten better lately) which don't offer options about how to (or not to) wrap text.

No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.

If you modify breakat and a couple other options (foldindent, to make the autowrapped lines stand out from the others), you can make vim’s autowrapping a lot nicer for word-wrapping code.

When I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet.

So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.

I think it’s pretty simple. Word wrap the way a N-character wide linter would

Yes! Someone please make this a reality!!

Is it an issue of editors or of language? The amount of errors that incorrect whitespace characters cause in whitespace sensitive languages could attributed to editors obfuscating what's written to file.

I think the pragmatic solution is an opinionated linter that can be broken.

Now that you’ve said it you have to make it happen!

Reply on news.ycombinator.com