pingdotgg / pingdotgg/t3code

[Feature]: Honor .editorconfig tab width and optionally render whitespace in file and diff views

Open
#11,076 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement via-triage
Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

Problem

Projects that use tab characters can be difficult to read in T3 Code because tabs are currently always rendered at a fixed width of two spaces.

If a project's .editorconfig defines a different tab width, code that is correctly aligned in other editors appears compressed or misaligned in T3 Code. Deeply nested code becomes difficult to scan, and alignment based on tab stops can appear broken.

This affects both file and diff views. It is also difficult to distinguish tabs from spaces when reviewing formatting-sensitive changes.

Proposed solution

Have T3 Code's file and diff views honor the applicable .editorconfig settings for each file:

  • Use tab_width when specified.
  • Fall back to indent_size when tab_width is not specified.
  • Resolve the nearest applicable .editorconfig section based on the file path.

This should only affect how existing tab characters are displayed. It should not rewrite files or convert tabs to spaces.

Additionally, add a Show whitespace characters setting for file and diff views:

  • When disabled, whitespace is rendered normally.
  • When enabled, spaces are shown with dot markers and tabs with arrow markers.
  • The setting applies consistently to both file and diff views.
  • The setting is disabled by default.
Expected behavior

Given this .editorconfig:

root = true

[*]
indent_style = tab
indent_size = 4
tab_width = 4

[*.md]
indent_style = space
indent_size = 2

Tab characters in source files should occupy four columns in file and diff views.

When Show whitespace characters is enabled, spaces and tabs should have distinct visible markers so indentation and whitespace-only changes can be reviewed accurately.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the file and diff view rendering entry points and the existing settings implementation. Trace how each file's applicable .editorconfig section could be resolved, then verify tab width fallback and whitespace markers in both views; done means the setting is off by default and does not modify files.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.