undefined

points

[-]

> In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code?

Writing a lisp in an editor that doesn't do boneheaded things with tabs? That's the only one I've personally run into but lack of imagination is hardly a good excuse to implement arbitrary restrictions.

> Let alone using esoteric Unicode whitespace characters for indentation.

How do you know what's esoteric in other countries? I certainly don't. I'm not an expert in linguistics but I'm sure that people everywhere in the world write computer programs at this point.

> I think it is perfectly reasonable ...

Without any concrete justification? Why would entirely artificial restrictions ever be seen as reasonable?

by rmunn8 hours ago|

parent|

[-]

What "boneheaded things with tabs" are you referring to? The picture I'm piecing together from your comments suggests that you may use tab characters in a different way than most people seem to, so I'd quite like a further explanation of how you use tab characters and how you expect an editor to handle them.

by fc417fc8027 hours ago|

parent|

[-]

> you may use tab characters in a different way than most people seem to

As far as I'm aware there are three primary and entirely independent uses for tabs. Indentation, field separation, and typesetting. When it comes to typesetting and also to display of fields with a narrow maximum width the concept of a tabstop is useful.

Boneheaded things with tabs was in reference to code editors (where tabs are more or less exclusively used for indentation) most often failing to provide the ability to disable tabstop. In practice this generally hasn't been a point of friction because until fairly recently the most popular languages (ie C & co) didn't support constructs that would lead to adding any indentation outside of the prefix of a line.

by rmunn7 hours ago|

parent|

[-]

Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meaning, i.e. "parsed into a syntax tree") can make those tab characters correctly align the forms the way you'd want them to be aligned for maximum understanding... but really, you would want space characters, not tab characters, in that context.

So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write

    let person = { FirstName = "Bill"
                   LastName = "Gates" }

Now, that's considered bad style according to https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... — and they're entirely write to recommend against that style — but it's legal syntax. And it's probably why https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... forbids tab characters entirely in F# code.

(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).

by fc417fc8024 hours ago|

parent|

[-]

The cond example commits a sin (see my other reply), in the F# example tabs (were they permitted) would introduce no ambiguity if used solely to communicate indentation, and the only change I would make to the F# example were I formatting it myself would be to also align the `=` characters. Actually that supposedly bad style is more or less exactly how I write nix expressions (as a matter of practicality I do not use tabs when writing those FWIW).

by rmunn2 hours ago|

parent|

[-]

I agree that the cond example is committing the sin of trying to align with tabs. I wrote it because I had misunderstood something you were saying. But also, I've personally seen situations like this. I was working in a team whose indentation convention was "one tab character per indent level", and I had written some C# code like this:

    var result = someObject.SomeMethod(param1, param2,
                                       param3, param4);

And then to my horror I noticed that the editor (earlier I said it was VS Code, but thinking back I think it was actually Visual Studio) had produced this monstrosity:

    var result = someObject.SomeMethod(param1, param2,
    <tab><tab><tab><tab><tab><tab><tab>param3, param4);

(Actual number of tabs was different, of course, and I believe it was followed at the end by a space or two, whereas my example happened to line up without needing an extra space character).

I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.

The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:

    var result = someObject.SomeMethod(
        param1, param2, param3, param4
    );

And then I was safe from the editor trying to align things with tab characters.

If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.