Golang source code view: tab width render preference?
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 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.
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!)
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:
- 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.
- 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!
Deleting a branch is permanent. It CANNOT be undone. Continue?