Hi, im interested in picking this up, can I get assigned this issue?

I've gotten to work on this, but it looks really out of place.. Is it possible if I could have input from the core developer team? @tidy-dev

An option would be to put it in the drop down menu on the diff page. There's already options regarding whitespace and diff appearance. This menu can be found both under Changes and History when displaying a diff.

An option would be to put it in the drop down menu on the diff page. There's already options regarding whitespace and diff appearance. This menu can be found both under Changes and History when displaying a diff.

Thank you! I'll start working on this now.

If you guys end up on a decision for the future of this issue, can I be notified? You can also contact me via email on my GitHub profile if you would like to move things forward in private.

@novialriptide We got a chance to discuss this issue again and think that what you had suggested before for the Appearance preferences is a good place for it to live.

However, we would like to see headings added of "Theme" above the theme settings and "Diff" above your new tab preference setting. You can check out the Advanced section for example of headings

In addition to that, we would like this to be feature flagged to beta. As we think the appearance tab could use a refactor to update the theme section to take up less space and follow other app conventions. Additionally, the new tab preference could be condensed to have a left aligned label. Thus, we would like to update this before this feature ships to prod (This work is not expected as part of your PR tho, just adding the feature flag).

Would be nice to support the TabWidth defaults entry on macOS, so it's possible to have an OS-wide tab width setting (defaults write -g "TabWidth" 4)

@novialriptide Any update on this, since the Appearance page has been redesigned?

Also, instead of replacing tabs with spaces like in #15841, it would probably be better to use the tab-size CSS property.

bumping to get an update on this issue

Is there any progress with the decision here? It would be very useful if the tab width could be freely defined so that I can set it to the project specifications, which is not 8 spaces. Support for EditorConfig would be even better, because then you could set it separately for each repo and would therefore be project-specific.

It seems that the dev team is more concerned with adding pretty check marks and moving staging buttons around.

Support for EditorConfig would be even better, because then you could set it separately for each repo and would therefore be project-specific.

Maybe support for EditorConfig could be an option, but it really should be in the hands of the user to specify the spacing they prefer to support the visually impaired.

Maybe support for EditorConfig could be an option, but it really should be in the hands of the user to specify the spacing they prefer to support the visually impaired.

But not in projects where this is defined as a fixed project specification in order to get easily interchangeable code that looks the same for everyone. As developers, we have strict guidelines that we have to adhere to and with EditorConfig we can easily take this into account project-wide. For example, it is also strictly specified which type of indentation (tabs or spaces) must be used for which file format and also the exact width. Also which line ending must be used and other things. If these guidelines are not followed, code is either rejected or adapted accordingly so that the code complies with the guidelines.

In other words: I don't make these guidelines, I just have to follow them. ^^ That's why it would be immensely helpful if GH Desktop offered this in the same way that GitHub already offers itself.

In this case too, you could freely choose whether to use the project-specific .editorconfig file in the repo or not. But at the moment you don't have that choice because EditorConfig is not supported.

But not in projects where this is defined as a fixed project specification in order to get easily interchangeable code that looks the same for everyone.

The tab-width setting is purely visual and completely personal—it has no functional impact on the project or the code. People who are visually impaired may require tab-widths of 4, 8, 16 or greater to help them read the code, whereas others may wish to set tabs to be displayed as the equivalent of 2 spaces. This is why this feature is important.

.editorconfig is for defining formatting consistency of the code, not for defining the visual representation of code within the editor.

(Defining a tab-width does not apply when spaces are used as indentation, so it has no bearing on this feature.)

The tab-width setting is purely visual and completely personal—it has no functional impact on the project or the code.

I know that. ;) But it has nothing to do with project-wide specifications.

People who are visually impaired may require tab-widths of 4, 8, 16 or greater to help them read the code, whereas others may wish to set tabs to be displayed as the equivalent of 2 spaces. This is why this feature is important.

But that only applies to the first indentation level. As soon as you have more than one indentation level in a line, the width of an indentation is relevant. That's why it's necessary to be able to define the standard width of an indentation project-wide, because otherwise, depending on the individual settings, you'll see code that looks "frayed" from the second indentation level onwards, and that makes reading it much more difficult depending on the code.

.editorconfig is for defining formatting consistency of the code, not for defining the visual representation of code within the editor.

That's not correct. EditorConfig is also used for the visual representation of the code and that's one of the main reasons why I use EditorConfig. Otherwise, EditorConfig wouldn't have the indent_size property. That works exactly as it should with GH Web, but unfortunately not with GH Desktop, which makes viewing diffs unnecessarily difficult. And that works exactly the same in all programs that support EditorConfig; with Notepad++, for example, EditorConfig always has priority.

But okay, your last comment has now made it clear to me that your wish and mine is not an OR question, but an AND question. ^^ I will create a separate issue, since these are two independent properties.