Switch to hard tabs

[caspervonb]

Currently deno fmt uses 2 spaces for indentation; I propose we switch to using hard tabs.

Tabs allow people in the same codebase to select their indentation widths across every tool including GitHub as even browsers support tab-width in stylesheets these days.

Now this isn't just "a preference", a preference would be what brace style to use but a narrow indentation width is an accessibility issue.

You can still easily parse the opening brace after a statement if you put them on the same line or the next one making it a stylistic preference but narrow whitespace tends to just disappear and blend in with the line when you have less than perfect sight.

This thread from Reddit comes to mind on the topic of accessibility of tabs

Lastly, please refrain from getting into the X is better than Y debates, I used to think X was better than Y too but then I had to get glasses 😉

[caspervonb]

cc @sebmck you were asking about this in discord the other day

[sebmck]

@caspervonb I did not. I searched the Deno Discord and the seb there is not me.

[caspervonb]

@sebmck apologies, it linked to your tweet so I wrongly made the assumption it was your account 😕

[kt3k]

ref: #3695

[ry]

We stick with JS conventions - which is basically prettier defaults - and I'm a 2-space type programmer.

[nayeemrmn]

I don't like editing with tabs. More generally, multi-column characters that can't be visibly told apart from another whitespace are annoying when they get shifted around unexpectedly, or I backspace/delete on them. This is merely the perspective of my personal convenience given my current physical circumstances so weigh it as you will. However, I don't think this thought should be discarded as a "preference vs an all-important accessibility issue". There can still be a discussion.

In particular, I'm curious about the current state of accessibility tools in editors. Isn't identifying an indent-space and rendering it differently an extremely simple problem? Doing it like that would seem more consistent with changing font sizes, regular space sizes, etc.

[andria-dev]

I agree with @caspervonb allowing the use of tabs is most definitely an accessibility issue. Tabs are inherently just characters that represent indentation. Due to that, any developer can configure their editor to be able to use any length they need to be able to work more efficiently.

And no, I have never seen an editor be able to represent a 2-space indentation as anything other than 2 spaces. Currently, it would have to change the number of spaces, which deno fmt would just change back, @nayeemrmn.

I think to say that 2-spaces is the JavaScript convention, @ry, is to force your opinion and inability to accept that tabs may help people with disabilities onto the rest of the community. Tabs can help lots of people.

Even if you prefer to stick to a so-called "convention" for indentation in the JavaScript community, saying no to tabs altogether is reductive. Tabs may not be as preferable to some — however, to other people, it could mean being able to use the built-in formatter for Deno at all.

[andria-dev]

I strongly believe the Deno team should consider providing a switch with the Deno formatter that allows for the use of tabs.

# Here are some options
deno fmt -t
deno fmt --tabs
deno fmt --use-tabs
deno fmt --with-tabs

# Or perhaps Deno could take a more simplistic approach of using existing indentation
deno fmt -d
deno fmt --detect
deno fmt --detect-indentation

Those were just some ideas, feel free to come up with your own ideas if you plan to implement this. Do, please, reopen this issue though. I don't believe there needs to be a total switch over just support for those who need hard tabs.

[nayeemrmn]

And no, I have never seen an editor be able to represent a 2-space indentation as anything other than 2 spaces. Currently, it would have to change the number of spaces, which deno fmt would just change back, @nayeemrmn.

I'm not saying it exists, I'm wondering why people don't request this feature from editors. It would solve the issue for a lot more people at the same time while allowing individual projects to stick to their preference. It would be like changing font size.

[andria-dev]

@nayeemrmn That sounds good but at the same time, that seems quite difficult. The editor would have to change the size only of spaces that it recognizes as indentation. If it changes the style of any other spaces then the code will look very weird and probably make it harder to work with.

Once you look at this idea from the perspective of writing the code to style indentation spaces separately, then it makes sense why they only support adjusting the width of \t hard tabs. It's easy and \t tabs were designed to be used this way.

[nayeemrmn]

That sounds good but at the same time, that seems quite difficult. The editor would have to change the size only of spaces that it recognizes as indentation. If it changes the style of any other spaces then the code will look very weird and probably make it harder to work with.

Again, recognising indent spaces is an extremely simple problem. Editors already handle indent spaces differently.

[andria-dev]

@nayeemrmn
https://www.reddit.com/r/vscode/comments/da5dtj/an_extension_to_view_files_with_my_own/

That is an example of someone attempting to create a plugin in VS Code. Recognizing indentation isn't the hard part, it's changing the width of the indentation only visually that's hard. I apologize for wording it poorly.

Even with their attempt to create a plugin for this, their solution is terribly inflexible.

[dsherret]

It seems there exists a VS code extension for changing the visual width of indentation spaces: https://marketplace.visualstudio.com/items?itemName=kylepaulsen.stretchy-spaces

[andria-dev]

@dsherret I'm assuming there are a lot of places that don't have this functionality available to them, including the web. On the web, if you want to change the size of hard \t tab indentation, you can set the tab-size CSS property and you're good to go. If you were using soft tabs, you would need to write your own syntax highlighting library/plugin specifically for giving only soft indent spaces an "indent" class.

How I view the accessibility of it

• Soft tabs (spaces) can be made accessible by implementing complex features across every tool that displays or edits code but this seems to be left up to plugin developers a lot and almost, if not never, included by default in an application.
• Hard tabs (\t) are generally accessible by default and if they aren't, it is often a very simple process to add a feature that changes the width of the tab character anyway.

I am glad that someone made the stretchy-spaces plugin but unless we can remake that plugin for every editor and implement it into every online syntax highlighter as a plugin then we're still ignoring the inaccessibility of soft tabs in comparison to hard tabs.

Solution

I still support the solution of adding a new switch for using hard tabs.

# Boolean flag
deno fmt -t
deno fmt --hard-tabs

# One of two values in: enum { soft, hard }
# This could allow future support for an auto mode `-t auto`
deno fmt -t hard
deno fmt --tabs=hard

[kitsonk]

We won't switch the Deno code or the std lib code away from two-spaces to hard-tabs.

We recognise though that formatting via deno fmt has strong personal, team, and accessibility concerns. @bartlomieju and I have a goal of addressing #3179 during the next quarter, which would address the deno fmt issue. At the moment we are leaning towards giving the same options that are available with prettier.

[andria-dev]

@kitsonk I'm not saying that the default has any need to change. A lot of people like 2 space tabs and it's convenient for a lot of neurotypical and able-bodied developers.

My solution was simply to add a flag that allows hard tabs as an additional option. Also, I see you want to stick to the same options/features as Prettier. Prettier also has the ability to use hard tabs. It supports the use of hard tabs via --use-tabs in the CLI and the useTabs property in the configuration file. If that is the road you go down, I believe that should completely solve this issue.

[kitsonk]

I understand what you are saying. I was just making it clear that we wouldn't be implementing what this issue originally requested, but implementing via a unified configuration file (and unlikely to implement via adding additional command line flags, but we might).