The good solution to the line length problem is to not be strict about them. My line length rule is usually "stay roughly within 100 spaces, 120 is too long." If you are seriously undermined by lines being too long, then your text editor choice/setup might be worth revisiting.

> 120 is too long

That sounds a lot like a hard limit. The difference between 2-space and 8-space tabs is huge, so you still have to specify what tab width you're using and someone who prefers a narrow tab width could still accidentally blow past the hard limit if they're not careful.

The alignment in the comment above doesn't work with tabs: your initial line is going to be tab-indented, which means if you want those next lines to align with it you don't have any options for it to work.

Now, I tend to find it's better to just avoid that kind of alignment in your code style completely (just push the first arg to a new line so you're not space-ing everything out a mile to match the function call open paren) but if that's your style then you can't really do it with actually variable tab widths.

"Alignment done with spaces" would look like this for that code.

  module whatever {
  ->fn long_function_name_whatever(arg1: type1,
  ->...............................arg2: type2,
  ->...............................arg3: type3);
  }

It works just fine - tabs for indentation and spaces for alignment.

Oh duh... I don't know why I didn't think of that.

My solution to the maximum line length problem is simple: if a piece of code has more than 3 level of indentation, I start to think about refactoring, and never let it have more than 5.

I find that any reasonably complex code with 5 levels of indentation becomes difficult to read, and with more levels the difficulty grows exponentially.

At least with languages I have significant experience, keeping the levels of indentation low never was a problem. But I never did serious amount of coding in LISP or Python, for example, so I don't know if this is practical in such languages.