swiftlang / sourcekit-lsp

Language Server Protocol implementation for Swift and C-based languages
Apache License 2.0
3.31k stars 275 forks source link

Formatting this project with tabs for indentation? #979

Closed heygarrett closed 10 months ago

heygarrett commented 11 months ago

Apologies if this is an unwelcome question, but has there been any consideration into using tabs for indentation in this project? I ask because I have trouble reading code with two-space indents; using tabs would allow contributors (both potential and existing) to set their own indentation width, making it more accessible.

ahoppen commented 11 months ago

Tracked in Apple’s issue tracker as rdar://118759664

ahoppen commented 10 months ago

Tabs vs spaces (and how many spaces) is always a matter of taste. Most other repos in the Swift compiler ecosystem (for example swift-syntax and the compiler) use 2 spaces for indentation and sourcekit-lsp should be consistent with those.

heygarrett commented 10 months ago

While I can understand striving to maintain consistency, this is disappointing to hear:

Tabs vs spaces (and how many spaces) is always a matter of taste.

My opposition to two-space indents is not a matter of taste; I physically struggle to read code with two-space indents. In my case it's a mental processing limitation, but I can only imagine the difficulty experienced by some folks with visual impairments.

bnbarham commented 10 months ago

sourcekit-lsp has a verification check that it has been formatted using swift-format. So a workaround here would be to swift-format to tabs when working on the codebase and then swift-format back to 2 spaces when necessary (eg. if opening a PR).

heygarrett commented 10 months ago

@bnbarham I appreciate the suggestion, and I had considered that. Unfortunately it doesn't make the project any more accessible to contributors; although I'm not (yet) a contributor, I'd no longer be able to rely on my editor for inline git diffs (I believe Xcode has a similar feature) since nearly every line would be changed by the reformat. It trades one issue for another. And I don't want to assume what trade offs it would ask of other developers based on their setups.

Full disclosure: I don't know a lot about Swift, but I have a lot of interest in it. Ideally I'd love to one day help implement background indexing, because it would improve my own experience with the language. But my motivation to learn more about Swift and someday contribute is hampered by my inability to comfortably parse the existing code.

I know that tabs vs spaces has long been a debate in which folks have generally agreed to disagree. But for some of us the accessibility of tabs (being able to choose one's own indentation width) is a necessity, not a preference.