Support tabs (U+0009) for indentation

[toastal]

Tabs is the more accessible indentation option & makes the math a lot easier (1 tab is 1 level of indentation). There are options to configure the number of spaces, but not the option to use tabs.

As I have gotten older 2-space code is difficult to read, but if I were able to increase the indentation level on my screen, it would be easier for me to read without affecting colleagues.

[shwestrick]

Definitely open to supporting tabs in the output.

One difficulty with tabs is that mixture of tabs and spaces may sometimes still be needed to guarantee vertical alignment, for example:

foobar (let
          ...
        in
          ...
        end)

Here the horizontal offset of the let isn't guaranteed to be a multiple of the tab width.

It might be possible to adjust the layout strategy to avoid these situations (e.g., favoring putting a vertically aligned region onto a new indented line), but it's not immediately clear what a good solution in general is.

So, if we did support tabs, an immediate strategy might be to allow for mixture of tabs and spaces, where each line would begin with some number of tabs, followed by some number of spaces, and finally the content of the line. This works, as long as the tab width used to visualize the formatted output is the same as the tab width that smlfmt expects.

Along these lines, adding support for tabs might be as simple as modifying only these lines of the layout engine:

smlfmt/src/base/PrettyTabbedDoc.sml

Lines 1330 to 1337 in 8966cbf

	fun itemToString x =
	case x of
	Item.Newline => newline
	| Item.Spaces n => spaces n
	| Item.Stuff s => s
	| _ => raise Fail "impossible"
	val result = CustomString.concat (List.map itemToString items)

The layout engine has two steps. First, we produce a sequence of Items, and then we rewrite the items as strings. When rewriting as a string, we could choose to convert every Item.Spaces n that immediately follows an Item.Newline into some mixture of tabs and spaces.

There might be some other issues lurking, but off the top of my head, this seems like it could work.

I'd be happy to review a PR on this.

[snoweuph]

An alternative solution to aligning with tabs could be to place one between foobar and (,

After all Aligning is one of the strengths of tabs.

Let's say you tab length is set to 4, and I will denote tabs as \t for simplicity:

abc\tdef
g\thij

Rendered this would look like this:

abc def
g   hij

so using this on your example:

foobar\t(let
\t\t\t...
\t\tin
\t\t\t...
\t\tend)

and will be displayed as:

foobar (let
          ...
        in
          ...
        end)

Because foobar\t with a tab width of 4 will have a width of 6+t where t is the missing length to the next multiple of the set tab width, so it will be of width 2 in this case.

[shwestrick]

@snoweuph The issue is that tab display widths aren't fixed.

Under a tab display of 8 (which is quite common), your suggested layout isn't vertically aligned. It also isn't vertically aligned with a tab display width of 2.

[snoweuph]

Normally in a project you have a .editorconfig, which IDEs and editors pass as opts to formatters.

For example like this in Nvim/NVF

formatters.astyle = {
      command = getExe pkgs.astyle;
      stdin = false;
      args = mkLuaInline ''
        function(self, ctx)
          local args = {
            "--mode=c",
            "$FILENAME",
          }

          if not vim.bo[ctx.buf].expandtab then
            table.insert(args, "--indent=tab=" .. ctx.shiftwidth)
          else
            table.insert(args, "--indent=spaces=" .. ctx.shiftwidth)
          end

          return args
        end
      '';
    };

so I don't really see the advantage of supporting multiple tab sizes, besides the one, passed as opt. Also thats how most formatters do it, as far as I know (Or they just force n spaces for you, with no opts).

Mixing Tabs and Spaces will btw upset allot of tools out of my experience, so that might not be so great of a solution either. Also mixing wont solve the problem either, because, yes you can align them, but as soon as somebody has a different size, it will look different.

So basically there's just the opts of

• Dont do aligning when using tabs, just do consistent indent levels,
• Have an opts for how tabs should be treated in size, and align with that.
• dont allow usage of tabs.
• change layout style to never require aligning when using tabs, like

  foobar (
  \tlet
  \t\t...
  \tin
  \t\t...
  \tend
  )

  foobar (
  	let
  		...
  	in
  		...
  	end
  )

[shwestrick]

• Dont do aligning when using tabs, just do consistent indent levels,
• Have an opts for how tabs should be treated in size, and align with that.
• dont allow usage of tabs.

This is essentially in line with what smlfmt currently offers. We have smlfmt -indent-width <N> to control the (formatted) output indent size, and smlfmt -tab-width <N> to control how tabs are interpreted on the (unformatted) input.

• change layout style to never require aligning when using tabs...

This could be interesting to explore! Although, for smlfmt, it might require a fairly major change to the layout engine.