Formatter: consider using tabs instead of spaces

[giacomocavalieri]

From time to time someone in the Gleam Discord suggests the formatter could use tabs instead of spaces for accessibility reasons.

A couple of things that have emerged so far:

• The formatter won't ever be configurable, so it's not a choice to make it opt-in. Either we always use tabs or we always use 2 spaces
• People bring up accessibility as a point in favour of using tabs as one might have a bit of trouble reading code that uses two-space indentation
• However, GitHub displays tabs as 8 spaces by default. That can be configured to use less space but it would probably look bad to the average user who's reading Gleam code on GitHub and we'd like to avoid it

I've opened this discussion so people can chime in here if they have anything to add or any experience they'd like to share :)

[lpil]

Do we have any information on the accessibility concerns relating to tabs and spaces?

[giacomocavalieri]

I don't personally, when it's brought up I see people sharing links like the ones in this question https://discord.com/channels/768594524158427167/1286540015274561576/1286540015274561576

[lpil]

Thank you. Some of these are very compelling.

[lpil]

The downside to this is an increase in perceived strangeness of Gleam. Tabs are unpopular and 8 space tabs even more so, so adopting these will result in fewer people deciding to try Gleam, hurting our growth.

Is there anything we can do to avoid GitHub etc showing Gleam with 8 space tabs?

[giacomocavalieri]

There's a couple of ways:

• it can be configured on your own account, this is not up to us and I don't expect many people to know this https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/managing-your-tab-size-rendering-preference
• it can be configured by appending something to a GitHub's url, even more obscure than the other one https://stackoverflow.com/a/23522945/19214823
• add an .editorconfig to every repo setting the tab size to 2. This is something gleam new could take care of but wouldn't work for older projects and I'm not a huge fan of having yet another configuration file

If GitHub were to use a 2/4 spaces default for tabs it would be way easier to push for a switch 🥲

[lpil]

1 and 2 are not options as we cannot control what settings people use, and we cannot modify all links to GitHub.

It would be annoying to have an additional config file but seems 3 could work. Are there any accessibility implications of using this config file? Does it prevent them from getting the tab size they want?

[giacomocavalieri]

I haven't really looked into so I'm not sure. I think it will depend on how any specific editor handles it

[00-kat]

GitHub seems to default to four spaces now:

[mpldr]

Hi, just wanted to chime in that I am one of the people for whom this accessibility is a thing. 2-space indents makes it nigh-impossible to me to separate scopes. In space-obligatory languages I will use 8 space indents which (as was already pointed out) is a bad choice for many people and tabs are the only solution I know of to address this in a flexible enough way.

As for the specifics, I would recommned trying to reformat some larger codebases and identify issues that look weird (sometimes a few linebreaks might be a better way)

As for "legacy-support" I see a relatively simple option:

• use editorconfig as the marker. If it has *.gleam: indent_style = tab, its new one
• otherwise use "legacy-mode"

While not a great fan of keeping two modes around, I think the value of tabs is worth it. I am biased though, I will freely admit that.

TL;DR: I have yet to find a case where indentation with tabs and aligning with spaces does not work as well, if not better than space-indentation. Also +1 for editorconfig.

[nhcoding4]

Allowing an option in the gleam.toml file would be cool so that people who prefer tabs > spacing . Something like spacing="tab" .

[GearsDatapacks]

The formatter is not configurable by design. That's unlikely to change

[Goldenlion5648]

Looks like this was opened 1 year ago. I don't have preference of tabs or spaces, I just want to be able to easily distinguish what code block a line belongs to. Currently with two spaces that requires some squinting on my part.

The downside to this is an increase in perceived strangeness of Gleam. Tabs are unpopular and 8 space tabs even more so, so adopting these will result in fewer people deciding to try Gleam, hurting our growth.

Basically every language allows whitespace configuration. If anything I would think that not having a config for it deters more people from using the language due to potential eyesight trouble.

[lpil]

Gleam permits whitespace configuration, you can use any formatting you want with Gleam and it will compile successfully.

There is an argument in favour of switching the formatter to tabs, if you have thoughts or research on that I am interested 🙏

[Goldenlion5648]

Gleam permits whitespace configuration, you can use any formatting you want with Gleam and it will compile successfully.

do you mean this is configurable via gleam.toml/ command line arg or similar? Or are you saying gleam doesn't care about whitespace, and that the user can just configure their text editor to use the spacing that they want (if this is the case, the gleam formatter should make this configurable).

As for tabs or spaces, I have my editor (VSCode) configured to insert X spaces when I press tab (if the current file is using spaces as indent) and tabs if the current file uses tabs as indent. Though using tabs as a default would mean people can freely set their editor to interpret tabs as whatever size they desire (2, 4, or 8 spaces) so that would solve the "eyesight" issue.

[lpil]

The formatter is not configurable by design, no.

Yup that's right, using tabs instead of spaces.

[Goldenlion5648]

As a quick fix so that I can read where blocks are, I made a fork that changes the indent size to 4 spaces rather than 2. The language seems great now that I can see where blocks are!

[Joshua-Hell]

For me, readability is one of the most important aspects of any language — often it’s even the reason people give a new one a try.

What I really like about Gleam is that the formatter isn’t customizable. It enforces a consistent style, which already makes code much easier to read. But readability also depends on your editor — even small details like spacing (tabs, in this case) can make a difference.

That’s why I think tabs are the best fit for Gleam: everyone can adjust the spacing to their own preference, while the code itself stays consistent. This is also valuable for people with visual impairments, who might need larger spacing to make code easier to follow on screen.

Edit: I wrote this with a little help from AI, as english isn't my native language. I hope you don't mind.

[pierre-rouleau]

I agree with this. Using hard tabs for indentation and controlling how wide the hard-tab is rendered, allows quickly changing the width rendering of the indentation.

I am using Emacs. If I look at code that uses 2-space indentation and I find it difficult to read, then I do this:

• I set Emacs tab-width to 2, then
• I tabify the code. Nothing should change in the way the code looks.
• Then I change the tab-width for something bigger (like 4) else and the indentation looks wider.
  Of course during this I make sure the formatter does not get in the way.
  If hard-tabs was the default, that method would comply with the formatter.

Go decided to use that method and it works great.

Another aspect to all this is human nature; if rules are too strict people will find ways to bypass them.

[pierre-rouleau]

There's another potential advantage of using hard tabs when we consider the maximum line length.
If hard tabs are used, and the convention is to use a tab rendered width of 2 columns, then the tools computing
the line length could count a hard tab character as 2 columns, and every other character (or rune) as 1.

Then if someone wants to render the hard tabs as 4 columns, the lines would look longer but the formatter tool would still count each tab as 2, regardless of the way they are rendered, allowing the person with wider rendered hard tabs to see longer lines for his/her eyes benefit without being impacted negatively by the formatter.

[pierre-rouleau]

I have written an example of using a technique that works on Emacs where I temporary use hard-tabs for indentation, using an indentation of 2 columns at first and then changing it to be able to show wider indentation steps without any impact on the file content. Of course I have to disable using gleam formatter while doing that.

The description comes with screenshots using Emacs in terminal mode with my PEL system providing help for setting up Gleam major mode appropriately. See the screen shots and the explanation in the table in this section of the document.

[pierre-rouleau]

For Emacs users I wrote a minor mode that automatically converts 2-space indentation into tabs-based indentation for editing and viewing. I have command that changes the visual rendering of hard-tabs and then indentation width, so it becomes possible to change the indentation width dynamically, making wider or narrower while you edit the file. When you save the file, it gets saved using the 2-space indenting scheme.

The code is experimental at the moment and is part of my PEL system. I have used it on Gleam and Dart code (which also strongly imposes a 2-space indent scheme, and people also complain about it). I have not found problems with the mode so far.

If all goes well and get positive feedback I'll probably extract the logic into a stand-alone package.

[pierre-rouleau]

Inside PEL the minor mode is called pel-indent-with-tabs-mode. Under PEL that minor mode can be activated automatically, setting the visual indentation width you want (a value in the [2,8] range). When you open a Gleam file, you see that tab-based indentation as if that was used in the file. You can edit the buffer with that wider indentation scheme. When you save the buffer content, the minor mode automatically saves this back using the 2-space indentation scheme; it's transparent to the user.

While editing the buffer the minor mode uses an adjusted fill-column value. This way if you are using a visual indentation that differs from what is used in the file, and auto-fill-mode is active, the text will wrap at the relative spot it would had you used the 2-space indentation scheme in the buffer.

[pierre-rouleau]

For people using Emacs: a working, but preliminary version of tbindent-mode allowing seamless conversion between space-based indentation to/from tabs-based indentation might provide a useful work-around.
See: tab-based-indent @ Github

This is not yet elpa compliant. That's my next step for this. Any feedback would be appreciated.

[pierre-rouleau]

For Emacs users: tb-indent is now on MELPA

You can use the tbindent-mode minor-mode to convert a space-based indentation file to tab-based indentation buffer and then change the tab width to what is comfortable.

[schrottkatze]

hi, also just chiming in that this is one of the things that are majorly annoying me about gleam.

i tried to change this via editorconfig, and the formatter is now clashing with my editor (which, correctly, inserts tabs which then get reverted to unreadability on save)

even if not officially configurable, the formatter should still respect the editorconfig.