Golang source code view: tab width render preference? #641

Open
opened 1 month ago by gold · 2 comments
gold commented 1 month ago

Overview

Until recently, nearly all of my projects were written using spaces instead of tabs. (It's unnecessary here to discuss the pros and cons of each approach.)

However, I've recently been porting all of my Node / Deno server API projects to Go. And the Go language seems to force the use of tab characters for indentation.

No big deal; my editor environment is using formatting tools to make sure errant spaces don't mistakenly creep into the source code. (without such a tool, the tabs vs. space argument leans towards spaces preferable to tabs. But anyway...)

8 spaces for the human-required visual rendering of a single tab character has been the default for many years, going back decades.

One of the major benefits of using tabs is that the tab character performs the function of a markup code: it means to indent n number of spaces when the tab character is rendered in a visual display context, with n being configurable by the human to best accomodate the desired visual indent behaviour. And this visual display preference can be changed without having to correspondingly change the source code. It's a nice decoupling.

The Problem

The source code display at Codeberg defaults to 8 space rendering width per tab character.

Of course I searched in the UI for "source code display settings/options" (or something like that) and could not find such a setting.

The Solution

Provide a "source code display settings" in the preferences, per repo and/or globally for each user account.

(The minor saving grace for rendering each tab character stuck at 8 spaces is that it becomes (painfully) obvious that the source code has tabs for indents instead of spaces!)


Upstream: https://github.com/go-gitea/gitea/issues/9071

## Overview Until recently, nearly all of my projects were written using spaces instead of tabs. (It's unnecessary here to discuss the pros and cons of each approach.) However, I've recently been porting all of my Node / Deno server API projects to Go. And the Go language seems to force the use of tab characters for indentation. No big deal; my editor environment is using formatting tools to make sure errant spaces don't mistakenly creep into the source code. (without such a tool, the tabs vs. space argument leans towards spaces preferable to tabs. But anyway...) 8 spaces for the human-required visual rendering of a single tab character has been the default for many years, going back decades. One of the major benefits of using tabs is that the tab character performs the function of a markup code: it means to indent n number of spaces when the tab character is rendered in a visual display context, with n being configurable by the human to best accomodate the desired visual indent behaviour. And this visual display preference can be changed without having to correspondingly change the source code. It's a nice decoupling. ## The Problem The source code display at Codeberg defaults to 8 space rendering width per tab character. Of course I searched in the UI for "source code display settings/options" (or something like that) and could not find such a setting. ## The Solution Provide a "source code display settings" in the preferences, per repo and/or globally for each user account. (The minor saving grace for rendering each tab character stuck at 8 spaces is that it becomes (painfully) obvious that the source code has tabs for indents instead of spaces!) --- Upstream: https://github.com/go-gitea/gitea/issues/9071
Gusted added the
gitea-related
label 1 month ago
Collaborator

There's an open issue in Gitea about this, https://github.com/go-gitea/gitea/issues/9071

There's an open issue in Gitea about this, https://github.com/go-gitea/gitea/issues/9071
Poster

There's an open issue in Gitea about this, https://github.com/go-gitea/gitea/issues/9071

Thanks for referencing this ticket.

I read the entire thread. My observations:

  1. Several entries contained a comment to the effect that the ticket would be closed due to inactivity, e.g., "This issue has been automatically marked as stale because it has not had recent activity."

Hahahaha... that is the best way to close a ticket. Inactivity means that no action was taken at all, including any activity to fix the problem.

  1. Everyone misses the point of the tab character; several said it should be 4 instead of 8 spaces! That's just as dictatorial as preferring 8. The real benefit of the tab character is that it's up to each individual to set the rendering width. And if 98% want 4 spaces, they can do that. If 2% want 2 spaces (or 3 or 5 or 10!), they can do that as well! Everyone gets exactly what they want.

The browser CSS hacks are imperfect approaches.

I'm not holding my breath for a preference-based solution available in the UI for source code viewing. I'll adapt my visual expectations accordingly and accept 8.

Gusted, I appreciate your quick response!

> There's an open issue in Gitea about this, https://github.com/go-gitea/gitea/issues/9071 Thanks for referencing this ticket. I read the entire thread. My observations: 1. Several entries contained a comment to the effect that the ticket would be closed due to inactivity, e.g., "This issue has been automatically marked as stale because it has not had recent activity." Hahahaha... that is the best way to close a ticket. Inactivity means that no action was taken at all, including any activity to fix the problem. 2. Everyone misses the point of the tab character; several said it should be 4 instead of 8 spaces! That's just as dictatorial as preferring 8. The real benefit of the tab character is that it's up to each individual to set the rendering width. And if 98% want 4 spaces, they can do that. If 2% want 2 spaces (or 3 or 5 or 10!), they can do that as well! Everyone gets exactly what they want. The browser CSS hacks are imperfect approaches. I'm not holding my breath for a preference-based solution available in the UI for source code viewing. I'll adapt my visual expectations accordingly and accept 8. Gusted, I appreciate your quick response!
rwa added the
enhancement
label 1 month ago
6543 added the
upstream
label 3 days ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#641
Loading…
There is no content yet.