Configure tab size when viewing a file #4353

@KaKi87 commented on GitHub (May 24, 2020):

Hello,

How can I change Gitea's global tab size from 8 to 4 ?

Thanks.

@KaKi87 commented on GitHub (May 24, 2020): Hello, How can I change Gitea's global tab size from 8 to 4 ? Thanks.

GiteaMirror commented

@Spongman commented on GitHub (Jun 25, 2020):

please reopen. (stalebot is bad project management)

does this mean that managing projects that use tabs is not supported on Gitea? it looks like .editorconfig is used when editing files, but ignored when viewing them.

workaround: add custom/templates/custom/header.tmpl:

<style>
.tab-size-8 {
        tab-size: 4 !important;
        -moz-tab-size: 4 !important;
}
</style>

edit: added -moz-tab-size after @tmont, below.

@Spongman commented on GitHub (Jun 25, 2020): please reopen. (stalebot is bad project management) does this mean that managing projects that use tabs is not supported on Gitea? it looks like `.editorconfig` is used when editing files, but ignored when viewing them. workaround: add `custom/templates/custom/header.tmpl`: ````css <style> .tab-size-8 { tab-size: 4 !important; -moz-tab-size: 4 !important; } </style> ```` edit: added `-moz-tab-size` after @tmont, below.

GiteaMirror commented

@stale[bot] commented on GitHub (Aug 31, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 31, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

@KaKi87 commented on GitHub (Aug 31, 2020):

up

@KaKi87 commented on GitHub (Aug 31, 2020): up

GiteaMirror commented

@stale[bot] commented on GitHub (Oct 31, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Oct 31, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

@KaKi87 commented on GitHub (Oct 31, 2020):

up

@KaKi87 commented on GitHub (Oct 31, 2020): up

GiteaMirror commented

@Exagone313 commented on GitHub (Nov 15, 2020):

I build Gitea with this patch:

diff --git a/modules/templates/helper.go b/modules/templates/helper.go
index e4107dfa9..38c4c661f 100644
--- a/modules/templates/helper.go
+++ b/modules/templates/helper.go
@@ -185,18 +185,18 @@ func NewFuncMap() []template.FuncMap {
 			)
 			if ec != nil {
 				if value, ok = ec.(*editorconfig.Editorconfig); !ok || value == nil {
-					return "tab-size-8"
+					return "tab-size-4"
 				}
 				def, err := value.GetDefinitionForFilename(filename)
 				if err != nil {
 					log.Error("tab size class: getting definition for filename: %v", err)
-					return "tab-size-8"
+					return "tab-size-4"
 				}
 				if def.TabWidth > 0 {
 					return fmt.Sprintf("tab-size-%d", def.TabWidth)
 				}
 			}
-			return "tab-size-8"
+			return "tab-size-4"
 		},
 		"SubJumpablePath": func(str string) []string {
 			var path []string

@Exagone313 commented on GitHub (Nov 15, 2020): I build Gitea with this patch: ```diff diff --git a/modules/templates/helper.go b/modules/templates/helper.go index e4107dfa9..38c4c661f 100644 --- a/modules/templates/helper.go +++ b/modules/templates/helper.go @@ -185,18 +185,18 @@ func NewFuncMap() []template.FuncMap { ) if ec != nil { if value, ok = ec.(*editorconfig.Editorconfig); !ok || value == nil { - return "tab-size-8" + return "tab-size-4" } def, err := value.GetDefinitionForFilename(filename) if err != nil { log.Error("tab size class: getting definition for filename: %v", err) - return "tab-size-8" + return "tab-size-4" } if def.TabWidth > 0 { return fmt.Sprintf("tab-size-%d", def.TabWidth) } } - return "tab-size-8" + return "tab-size-4" }, "SubJumpablePath": func(str string) []string { var path []string ```

GiteaMirror commented

@tmont commented on GitHub (Dec 20, 2020):

I had to add this to @Spongman's custom template to get things working in Firefox as it does not (yet) support un-prefixed tab-size:

<style>
.tab-size-8 {
        tab-size: 4 !important;
        -moz-tab-size: 4 !important;
}
</style>

@tmont commented on GitHub (Dec 20, 2020): I had to add this to @Spongman's custom template to get things working in Firefox as it [does not (yet) support](https://caniuse.com/?search=tab-size) un-prefixed `tab-size`: ```html <style> .tab-size-8 { tab-size: 4 !important; -moz-tab-size: 4 !important; } </style>

GiteaMirror commented

@vhscom commented on GitHub (Jan 19, 2022):

Here's a bookmarklet you can use to format the tab size for Gitea when viewing code in compare/diff view through the web interface.

javascript:document.querySelectorAll('table.chroma').forEach((el)=>el.style.tabSize=2)

Adjust to your liking. Alternative options are to (a) add an .editorconfig file to the repository as mentioned by @silverwind or (b) use a different diff viewer such as delta.

@vhscom commented on GitHub (Jan 19, 2022): Here's a bookmarklet you can use to format the tab size for Gitea when viewing code in compare/diff view through the web interface. ```js javascript:document.querySelectorAll('table.chroma').forEach((el)=>el.style.tabSize=2) ``` Adjust to your liking. Alternative options are to (a) add an `.editorconfig` file to the repository [as mentioned](https://github.com/go-gitea/gitea/issues/14225#issuecomment-753628646) by @silverwind or (b) use a different diff viewer [such as delta](https://github.com/dandavison/delta).

GiteaMirror commented

@KaKi87 commented on GitHub (Jan 19, 2022):

Well, you'd better use a userstyle rather than a bookmarklet

@KaKi87 commented on GitHub (Jan 19, 2022): Well, you'd better use a userstyle rather than a bookmarklet

GiteaMirror commented

@silverwind commented on GitHub (Jan 19, 2022):

I think this issue is still open because the code view doesn't respect the configured tab-size in .editorconfig. The web editor itself certainly already does.

@silverwind commented on GitHub (Jan 19, 2022): I think this issue is still open because the code view doesn't respect the configured tab-size in `.editorconfig`. The web editor itself certainly already does.

GiteaMirror commented

2025-11-02 05:47:42 -06:00

@KaKi87 commented on GitHub (Jan 19, 2022):

Requiring such file doesn't seem right.

@KaKi87 commented on GitHub (Jan 19, 2022): Requiring such file doesn't seem right.

GiteaMirror commented

@silverwind commented on GitHub (Jan 19, 2022):

Yes, I think a user setting for default tab size is also desirable. But .editorconfig should have precedence when present.

@silverwind commented on GitHub (Jan 19, 2022): Yes, I think a user setting for default tab size is also desirable. But `.editorconfig` should have precedence when present.

GiteaMirror commented

2025-11-02 05:47:42 -06:00

@markusamshove commented on GitHub (Jan 19, 2022):

I'd say:

User settings > editorconfig > highlighting lib > default

@markusamshove commented on GitHub (Jan 19, 2022): I'd say: User settings > editorconfig > highlighting lib > default

GiteaMirror commented

2025-11-02 05:47:42 -06:00

@danebou commented on GitHub (Feb 3, 2022):

Who the heck uses a tab size of 8 by default? lol. Really surprised this isn't fixed. In addition to this, the default tab size should be 4 since almost every IDE out of the box uses 4.

(Oh I guess this fight goes along with the Linux Kernel standards. Well since I doubt gitea is being used by the Linux Kernal peops, I still argue 4 is a good default)

@danebou commented on GitHub (Feb 3, 2022): Who the heck uses a tab size of 8 by default? lol. Really surprised this isn't fixed. In addition to this, the default tab size should be 4 since almost every IDE out of the box uses 4. (Oh I guess this fight goes along with the Linux Kernel standards. Well since I doubt gitea is being used by the Linux Kernal peops, I still argue 4 is a good default)

GiteaMirror commented

2025-11-02 05:47:43 -06:00

@vhscom commented on GitHub (Feb 3, 2022):

One thing to take into consideration is that I doubt many projects do, or would even want, to add an .editorconfig file if they're using prettier. I could see that causing headaches if they're not in perfect alignment. Besides, who wants to add another dotfile to their repo. A sensible default of 4 spaces would be fine. But it would be even better to give the user control straight from the interface.

@vhscom commented on GitHub (Feb 3, 2022): One thing to take into consideration is that I doubt many projects do, or would even want, to add an `.editorconfig` file if they're using prettier. I could see that causing headaches if they're not in perfect alignment. Besides, who wants to add another dotfile to their repo. A sensible default of 4 spaces would be fine. But it would be even better to give the user control straight from the interface.

GiteaMirror commented

2025-11-02 05:47:43 -06:00

@KaKi87 commented on GitHub (Feb 3, 2022):

Yes. Personally, I started using spaces as indentation character instead of tabs because of this issue. And this isn't right.

@KaKi87 commented on GitHub (Feb 3, 2022): Yes. Personally, I started using spaces as indentation character instead of tabs because of this issue. And this isn't right.

GiteaMirror commented

2025-11-02 05:47:43 -06:00

@silverwind commented on GitHub (Feb 4, 2022):

Who the heck uses a tab size of 8 by default? lol. Really surprised this isn't fixed. In addition to this, the default tab size should be 4 since almost every IDE out of the box uses 4.

FWIW, browsers are dictated by spec to use default size 8 thought I do agree 4 is a generally better default.

@silverwind commented on GitHub (Feb 4, 2022): > Who the heck uses a tab size of 8 by default? lol. Really surprised this isn't fixed. In addition to this, the default tab size should be 4 since almost every IDE out of the box uses 4. FWIW, browsers are dictated by spec to use [default size 8](https://drafts.csswg.org/css-text/#tab-size-property) thought I do agree 4 is a generally better default.

GiteaMirror commented

@Crystal-RainSlide commented on GitHub (Jun 23, 2022):

If we add this (?ts=4): https://github.com/tiimgreen/github-cheat-sheet#adjust-tab-space

Then we can just make the links with the different tab size parameter as the "Change tab size" button, and we also got permalink for them. If someone figured out the right tab size for a file, then he can just share the permalink to others and save their time by a little bit.

With some tab-size-changing JavaScript and history.pushState(), we can also save the navgation/reloading of the "Change tab size" link-buttons.

const setTabSize = tabSize => {

	if ( !Number.isInteger(tabSize) ) {
		tabSize = Number.parseInt(tabSize);
	}

	if (tabSize <= 0 || tabSize > 16) {
		throw new RangeError("tabSize must be an integer between 1 to 16!");
	}

	let otherSizes = new Array(16).fill(null).map( (_, i) =>  i + 1 );
	otherSizes.splice(tabSize - 1, 1);

	document.querySelectorAll(
		otherSizes.map( size => ".tab-size-" + size ).join(",")
	).forEach(
		elem => elem.classList.replace(
			[...elem.classList].find( cls => cls.startsWith("tab-size-") ),
			"tab-size-" + tabSize
		)
	);

};

document.addEventListener("DOMContentLoaded", () => {
	let ts = new URLSearchParams(location.search).get("ts");
	if (ts !== null) {
		ts = Number.parseInt(ts);
		if (ts <= 0 && ts > 16) {
			setTabSize(ts);
		}
	}
});

// Just one button as an example...
const button = Object.assign(
	document.createElement("button"), { textContent: "Change tab size to 4" }
);

button.addEventListener("click", () => {
	setTabSize(4);
	const url = new URL(location);
	url.searchParams.set("ts", "4");
	history.pushState({}, "", url);
});

// Put this button into the document with methods like append() to give it a try.

@Crystal-RainSlide commented on GitHub (Jun 23, 2022): If we add this (`?ts=4`): https://github.com/tiimgreen/github-cheat-sheet#adjust-tab-space Then we can just make the links with the different tab size parameter as the "Change tab size" button, and we also got permalink for them. If someone figured out the right tab size for a file, then he can just share the permalink to others and save their time by a little bit. With some tab-size-changing JavaScript and [`history.pushState()`](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState), we can also save the navgation/reloading of the "Change tab size" link-buttons. ``` JavaScript const setTabSize = tabSize => { if ( !Number.isInteger(tabSize) ) { tabSize = Number.parseInt(tabSize); } if (tabSize <= 0 || tabSize > 16) { throw new RangeError("tabSize must be an integer between 1 to 16!"); } let otherSizes = new Array(16).fill(null).map( (_, i) => i + 1 ); otherSizes.splice(tabSize - 1, 1); document.querySelectorAll( otherSizes.map( size => ".tab-size-" + size ).join(",") ).forEach( elem => elem.classList.replace( [...elem.classList].find( cls => cls.startsWith("tab-size-") ), "tab-size-" + tabSize ) ); }; document.addEventListener("DOMContentLoaded", () => { let ts = new URLSearchParams(location.search).get("ts"); if (ts !== null) { ts = Number.parseInt(ts); if (ts <= 0 && ts > 16) { setTabSize(ts); } } }); // Just one button as an example... const button = Object.assign( document.createElement("button"), { textContent: "Change tab size to 4" } ); button.addEventListener("click", () => { setTabSize(4); const url = new URL(location); url.searchParams.set("ts", "4"); history.pushState({}, "", url); }); // Put this button into the document with methods like append() to give it a try. ```

GiteaMirror commented

@delvh commented on GitHub (Jun 23, 2022):

While I can definitely see why adding it as a query param would be useful, how would it handle the whitespace for files with differing behavior defined in the editorconfig?
Should the editorconfig simply be ignored globally when that parameter is set?

@delvh commented on GitHub (Jun 23, 2022): While I can definitely see why adding it as a query param would be useful, how would it handle the whitespace for files with differing behavior defined in the `editorconfig`? Should the editorconfig simply be ignored globally when that parameter is set?

GiteaMirror commented

https://github.com/settings/appearance

@silverwind commented on GitHub (Jun 24, 2022):

I think in general we want a setting UI where user can set their preference, similar to what GitHub now has for tab size:

That setting should overrule .editorconfig. Only through the special value default would editorconfig then be applied.

We can du the url param too, but I think it's too obscure of a feature in general to be useful.

@silverwind commented on GitHub (Jun 24, 2022): I think in general we want a setting UI where user can set their preference, similar to what GitHub now has for tab size: https://github.com/settings/appearance That setting should overrule `.editorconfig`. Only through the special value `default` would editorconfig then be applied. We can du the url param too, but I think it's too obscure of a feature in general to be useful.

GiteaMirror commented

@Crystal-RainSlide commented on GitHub (Jun 25, 2022):

While I can definitely see why adding it as a query param would be useful, how would it handle the whitespace for files with differing behavior defined in the editorconfig? Should the editorconfig simply be ignored globally when that parameter is set?

That setting should overrule .editorconfig. Only through the special value default would editorconfig then be applied.

On GitHub: ts parameter > .editorconfig > tab size in the user settings. Everyone can check this by themselves.

This seems to be decided by the scope. ts parameter is specifc to a webpage, .editorconfig is specifc to a repo, and tab size in the user settings is specifc to everything a user sees, and the smaller the scope the higher the priority.

I think in general we want a setting UI where user can set their preference, similar to what GitHub now has for tab size:

github.com/settings/appearance

Yes.

We can du the url param too, but I think it's too obscure of a feature in general to be useful.

Obscure is what GitHub had done wrong, anyone else can get it right (GitHub itself included).

I'd already talked about the "Change tab size" button thing, but let's see if I can come up with some showcase...

Update: I'm trying to write a userscript to add a "Change tab size" button for both try.gitea.io and GitHub.

@Crystal-RainSlide commented on GitHub (Jun 25, 2022): > While I can definitely see why adding it as a query param would be useful, how would it handle the whitespace for files with differing behavior defined in the `editorconfig`? Should the editorconfig simply be ignored globally when that parameter is set? > That setting should overrule `.editorconfig`. Only through the special value `default` would editorconfig then be applied. On GitHub: `ts` parameter > `.editorconfig` > tab size in the user settings. Everyone can check this by themselves. This seems to be decided by the scope. `ts` parameter is specifc to a webpage, `.editorconfig` is specifc to a repo, and tab size in the user settings is specifc to everything a user sees, and the smaller the scope the higher the priority. --- > I think in general we want a setting UI where user can set their preference, similar to what GitHub now has for tab size: > > [github.com/settings/appearance](https://github.com/settings/appearance) Yes. --- > We can du the url param too, but I think it's too obscure of a feature in general to be useful. Obscure is what GitHub had done wrong, anyone else can get it right (GitHub itself included). I'd already talked about the "Change tab size" button thing, but let's see if I can come up with some showcase... Update: I'm trying to write a userscript to add a "Change tab size" button for both try.gitea.io and GitHub.

GiteaMirror commented

@Spongman commented on GitHub (Jun 28, 2022):

it should be simple for the user to easily, and permanently override whatever is in a repo's .editorconfig. the whole point of using tabs is that the indentation amount is configurable by the viewer, not baked into the source.

@Spongman commented on GitHub (Jun 28, 2022): it should be simple for the user to easily, and permanently override whatever is in a repo's .editorconfig. the whole point of using tabs is that the indentation amount is configurable by the viewer, _not_ baked into the source.

GiteaMirror commented

@UnlimitedCookies commented on GitHub (Sep 9, 2022):

please reopen. (stalebot is bad project management)

does this mean that managing projects that use tabs is not supported on Gitea? it looks like .editorconfig is used when editing files, but ignored when viewing them.

workaround: add custom/templates/custom/header.tmpl:
<style>
.tab-size-8 {
        tab-size: 4 !important;
        -moz-tab-size: 4 !important;
}
</style>
edit: added -moz-tab-size after @tmont, below.

Unfortunately, with this patch 4 spaces and 1 tab are not the same width 😨 .

@UnlimitedCookies commented on GitHub (Sep 9, 2022): > please reopen. (stalebot is bad project management) > > does this mean that managing projects that use tabs is not supported on Gitea? it looks like `.editorconfig` is used when editing files, but ignored when viewing them. > > workaround: add `custom/templates/custom/header.tmpl`: > > ```css > <style> > .tab-size-8 { > tab-size: 4 !important; > -moz-tab-size: 4 !important; > } > </style> > ``` > > edit: added `-moz-tab-size` after @tmont, below. ![image](https://user-images.githubusercontent.com/49200216/189356735-ae81f0eb-bb2e-4958-a7b2-6584fade294e.png) Unfortunately, with this patch 4 spaces and 1 tab are not the same width :fearful: .

GiteaMirror commented

@omenos commented on GitHub (Dec 4, 2022):

Both GitHub and GitLab have a user preference for defining the tabstop width for viewing files. As long as the .editorconfig preferences only apply to the editor view, it shouldn't be viewed as a solution here and other related issues.

Tabstop size is important for languages that enforce tabs over spaces, such as Go. I'm currently using the Stylus extension to override tabstops for forge sites, including my self-hosted instance, but this is a browser specific workaround on my desktop; it does not apply to mobile where screen real estate is even more valuable.

I understand the addition of this feature is not completely simple, but it would be greatly appreciated!

@omenos commented on GitHub (Dec 4, 2022): Both GitHub and GitLab have a user preference for defining the tabstop width for _viewing_ files. As long as the `.editorconfig` preferences only apply to the editor view, it shouldn't be viewed as a solution here and other related issues. Tabstop size is important for languages that enforce tabs over spaces, such as Go. I'm currently using the Stylus extension to override tabstops for forge sites, including my self-hosted instance, but this is a browser specific workaround on my desktop; it does not apply to mobile where screen real estate is even more valuable. I understand the addition of this feature is not completely simple, but it would be greatly appreciated!

GiteaMirror commented

@silverwind commented on GitHub (Dec 5, 2022):

I guess we can implement 2,4,8,auto options. Default being auto which derives from editorconfig, and possibly falls back to a default of 4 (or 8, which is still what browsers default to, but I think it's antiquated and 4 is a better default).

@silverwind commented on GitHub (Dec 5, 2022): I guess we can implement `2`,`4`,`8`,`auto` options. Default being `auto` which derives from editorconfig, and possibly falls back to a default of 4 (or 8, which is still what browsers default to, but I think it's antiquated and 4 is a better default).

GiteaMirror commented

@arkadiuszmakarenko commented on GitHub (Feb 17, 2023):

I guess we can implement 2,4,8,auto options. Default being auto which derives from editorconfig, and possibly falls back to a default of 4 (or 8, which is still what browsers default to, but I think it's antiquated and 4 is a better default).

This would be very welcomed change.

@arkadiuszmakarenko commented on GitHub (Feb 17, 2023): > I guess we can implement `2`,`4`,`8`,`auto` options. Default being `auto` which derives from editorconfig, and possibly falls back to a default of 4 (or 8, which is still what browsers default to, but I think it's antiquated and 4 is a better default). This would be very welcomed change.

GiteaMirror commented

@eliliam commented on GitHub (Aug 24, 2023):

How's this coming? Six months ago @silverwind indicated the setting could be added, has anyone been able to work on this yet?

@eliliam commented on GitHub (Aug 24, 2023): How's this coming? Six months ago @silverwind indicated the setting could be added, has anyone been able to work on this yet?

GiteaMirror commented

@Palid commented on GitHub (Jan 27, 2024):

@silverwind do you need help with someone taking this over? I'd gladly implement this change

@Palid commented on GitHub (Jan 27, 2024): @silverwind do you need help with someone taking this over? I'd gladly implement this change

GiteaMirror commented

@silverwind commented on GitHub (Mar 16, 2024):

Feel free to take a stab at implementing such a "indentation size" dropdown on top right side of file view which then would alter the CSS. The default option should be "auto", e.g. the current value that depends on .editorconfig with fallback to 4. Ideally the option value should sync into backend as a user setting so it's remembered between browsing sessions.

Personally I don't need this feature because I'm a strong proponent of .editorconfig.

@silverwind commented on GitHub (Mar 16, 2024): Feel free to take a stab at implementing such a "indentation size" dropdown on top right side of file view which then would alter the CSS. The default option should be "auto", e.g. the current value that depends on `.editorconfig` with fallback to `4`. Ideally the option value should sync into backend as a user setting so it's remembered between browsing sessions. Personally I don't need this feature because I'm a strong proponent of `.editorconfig`.

GiteaMirror commented

@jclsn commented on GitHub (Jan 22, 2025):

Would like to see this too. Such basic feature!

@jclsn commented on GitHub (Jan 22, 2025): Would like to see this too. Such basic feature!

GiteaMirror commented

@KaKi87 commented on GitHub (Jan 22, 2025):

Forgejo supports this btw

@KaKi87 commented on GitHub (Jan 22, 2025): [Forgejo](https://forgejo.org/) supports this btw

GiteaMirror commented

feat: tab size should be configurable #5672

@omenos commented on GitHub (Jan 22, 2025):

Forgejo supports this btw

Which part? Forgejo does default to a width of four characters for tabs, but as of Forgejo v10 I have not seen a user configurable tab size parameter available. I may have missed it, but there is a similar issue over on Forgejo about this same topic:

@omenos commented on GitHub (Jan 22, 2025): > [Forgejo](https://forgejo.org/) supports this btw Which part? Forgejo does default to a width of four characters for tabs, but as of Forgejo v10 I have not seen a user configurable tab size parameter available. I may have missed it, but there is a similar issue over on Forgejo about this same topic: [feat: tab size should be configurable #5672](https://codeberg.org/forgejo/forgejo/issues/5672)

GiteaMirror commented

@KaKi87 commented on GitHub (Jan 23, 2025):

Sorry for the ambiguity, I meant it supports .editorconfig, which is the majority request here.

@KaKi87 commented on GitHub (Jan 23, 2025): Sorry for the ambiguity, I meant it supports `.editorconfig`, which is the majority request here.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jan 23, 2025):

Sorry for the ambiguity, I meant it supports .editorconfig, which is the majority request here.

But forjoge ever largely copied Gitea's code, and new Gitea has many unique features that are not in forgejo.

For editorconfig part, there is no difference.

@wxiaoguang commented on GitHub (Jan 23, 2025): > Sorry for the ambiguity, I meant it supports `.editorconfig`, which is the majority request here. But forjoge ever largely copied Gitea's code, and new Gitea has many unique features that are not in forgejo. For `editorconfig` part, there is no difference.

GiteaMirror commented

@KaKi87 commented on GitHub (Jan 23, 2025):

Mea culpa, since users here requested for the file viewer to support .editorconfig but no one ever announced here this was implemented, I thought when seeing in that linked Forgejo issue someone saying it was implemented, that Forgejo maintainers did it. Sorry for the disturbance.

So it's still good to know for the people here though, that now they can configure tab size per-repo with .editorconfig.

Have a nice week

@KaKi87 commented on GitHub (Jan 23, 2025): Mea culpa, since users here requested for the file viewer to support `.editorconfig` but no one ever announced here this was implemented, I thought when seeing in that linked Forgejo issue someone saying it was implemented, that Forgejo maintainers did it. Sorry for the disturbance. So it's still good to know for the people here though, that now they can configure tab size per-repo with `.editorconfig`. Have a nice week

GiteaMirror commented

2025-11-02 05:47:48 -06:00

@wxiaoguang commented on GitHub (Jan 23, 2025):

Mea culpa, since users here requested for the file viewer to support .editorconfig but no one ever announced here this was implemented, I thought when seeing in that linked Forgejo issue someone saying it was implemented, that Forgejo maintainers did it. Sorry for the disturbance.

That code was also taken from Gitea.

For the author's question:

(DONE) "Normally I would expect 4 spaces for java, c# and similar languages": it has been resolved, because now 4 is the default width.
(DONE) To use repository-related config: editorconfig is supported
(TODO) To fully customize the tab width: it needs to involve the user setting related modules, and maybe we should refactor the user setting package first

@wxiaoguang commented on GitHub (Jan 23, 2025): > Mea culpa, since users here requested for the file viewer to support `.editorconfig` but no one ever announced here this was implemented, I thought when seeing in that linked Forgejo issue someone saying it was implemented, that Forgejo maintainers did it. Sorry for the disturbance. That code was also taken from Gitea. For the author's question: * [x] (DONE) "Normally I would expect 4 spaces for java, c# and similar languages": it has been resolved, because now 4 is the default width. * [x] (DONE) To use repository-related config: `editorconfig` is supported * [ ] (TODO) To fully customize the tab width: it needs to involve the user setting related modules, and maybe we should refactor the user setting package first

GiteaMirror commented

@omenos commented on GitHub (Jan 23, 2025):

(DONE) To use repository-related config: editorconfig is supported

As the idea was mentioned up in the Forgejo discussion, does Gitea supported rendering projects using nested editorconfig setups? I can see this as a useful feature for multi-language monorepos.

@omenos commented on GitHub (Jan 23, 2025): > (DONE) To use repository-related config: `editorconfig` is supported As the idea was mentioned up in the Forgejo discussion, does Gitea supported rendering projects using [nested `editorconfig`](https://learn.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options#file-hierarchy-and-precedence) setups? I can see this as a useful feature for multi-language monorepos.

GiteaMirror commented

2025-11-02 05:47:48 -06:00

@silverwind commented on GitHub (Jan 23, 2025):

(TODO) To fully customize the tab width: it needs to involve the user setting related modules, and maybe we should refactor the user setting package first

I don't think a user setting is strictly needed as the ideal tab size can differ based on file. One file might render better with 4, another one with 8.

I think we could simply add <select> elements to the file view and code editor that changes the tab size only on the current page, not remembering anything.

@silverwind commented on GitHub (Jan 23, 2025): > (TODO) To fully customize the tab width: it needs to involve the user setting related modules, and maybe we should refactor the user setting package first I don't think a user setting is strictly needed as the ideal tab size can differ based on file. One file might render better with 4, another one with 8. I think we could simply add `<select>` elements to the file view and code editor that changes the tab size only on the current page, not remembering anything.

GiteaMirror commented

2025-11-02 05:47:48 -06:00

@wxiaoguang commented on GitHub (Jan 23, 2025):

does Gitea supported rendering projects using nested editorconfig setups? I can see this as a useful feature for multi-language monorepos.

I think no at the moment.

It's not difficult to support this feature, the only concern is that it might slow down some pages slightly because it needs to check every parent dir to detect editorconfig and apply.

So IMO the issue looks like this at the moment:

The current 4-width tab should be good enough for most cases.
If there is a strong requirement to support editorconfig in mono-repo (many users need it):
- If it doesn't slow down the page too much, just do it.
- Otherwise, there could be a config option to enable or disable it.

@wxiaoguang commented on GitHub (Jan 23, 2025): > does Gitea supported rendering projects using [nested `editorconfig`](https://learn.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options#file-hierarchy-and-precedence) setups? I can see this as a useful feature for multi-language monorepos. I think no at the moment. It's not difficult to support this feature, the only concern is that it might slow down some pages slightly because it needs to check every parent dir to detect `editorconfig` and apply. So IMO the issue looks like this at the moment: 1. The current 4-width tab should be good enough for most cases. 1. If there is a strong requirement to support `editorconfig` in mono-repo (many users need it): * If it doesn't slow down the page too much, just do it. * Otherwise, there could be a config option to enable or disable it.

GiteaMirror commented

@silverwind commented on GitHub (Jan 23, 2025):

It's not difficult to support this feature, the only concern is that it might slow down some pages slightly because it needs to check every parent dir to detect editorconfig and apply.

I'm not sure how the editorconfig module does it, but ideally this is a O(n) operation, n being the number of parent directories of the viewed file.

@silverwind commented on GitHub (Jan 23, 2025): > It's not difficult to support this feature, the only concern is that it might slow down some pages slightly because it needs to check every parent dir to detect editorconfig and apply. I'm not sure how the editorconfig module does it, but ideally this is a O(n) operation, n being the number of parent directories of the viewed file.

GiteaMirror commented

@silverwind commented on GitHub (Jan 27, 2025):

I will look into adding these <select> boxes soon to file view and code editor.

@silverwind commented on GitHub (Jan 27, 2025): I will look into adding these `<select>` boxes soon to file view and code editor.

GiteaMirror commented

@adamel commented on GitHub (Mar 25, 2025):

Personally I would very much have the ability to configure a global .editorconfig config in Gitea to use for all repositories that does not have one.

We have different indent settings for different languages, but all repositories use the same styles, so adding a .editorconfig file to each of several hundred repositories does not really make sense.

@adamel commented on GitHub (Mar 25, 2025): Personally I would very much have the ability to configure a global .editorconfig config in Gitea to use for all repositories that does not have one. We have different indent settings for different languages, but all repositories use the same styles, so adding a .editorconfig file to each of several hundred repositories does not really make sense.

GiteaMirror commented

@silverwind commented on GitHub (Mar 25, 2025):

Makes sense to have such a file, but it may become challenging to merge multiple .editorconfig files, maybe https://github.com/editorconfig/editorconfig-core-go has some support.

Edit: It may support multiple files already, but I think we'd have shift the root=true statement to the new "root file" so that editorconfig-core-go does not stop at the repo root file.

@silverwind commented on GitHub (Mar 25, 2025): Makes sense to have such a file, but it may become challenging to merge multiple `.editorconfig` files, maybe https://github.com/editorconfig/editorconfig-core-go has some support. Edit: It may support multiple files already, but I think we'd have shift the `root=true` statement to the new "root file" so that `editorconfig-core-go` does not stop at the repo root file.

GiteaMirror commented