Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't apply to the code viewer #3

Closed
sindresorhus opened this issue Oct 23, 2014 · 10 comments
Closed

Don't apply to the code viewer #3

sindresorhus opened this issue Oct 23, 2014 · 10 comments

Comments

@sindresorhus
Copy link
Contributor

The code viewer is for viewing code and I don't think the repo project should decide how I view its code.

Applying to the editor makes sense, but for the code viewer it should be some default values. Might add an option page to change them. The code viewer should not be affected by the .editorconfig config.

@RReverser
Copy link
Owner

Disagree here. Having proper indentation is important for both viewing and editing code. In desktop editors those are just not meant to split.

If repo owner sets tab_width=2, then you do want to see code properly indented, and you want it to look exactly as it looks in editor. Indentation should not be broken with default GitHub's tab_width=8 or any other value, and you should definitely see the code in the same way in your desktop editor, online editor, code viewer, whatever.

@sindresorhus
Copy link
Contributor Author

If repo owner sets tab_width=2, then you do want to see code properly indented, and you want it to look exactly as it looks in editor.

No I really really don't. What I want is for the saved code to have the project set indentation, but I would much prefer to view the file with my preferred indentation. The only reason EditorConfig doesn't work like that is because most editors couple those concepts. On GitHub you actually have the opportunity to not be limited by this.

I prefer indent 4 when reading code. Why should some project for no good reason dictate I read their code with indent 2?

@williamboman
Copy link

I agree with @sindresorhus. This is the first thing that hit my mind when I saw this repo.

Reading code on gh != committing code

@stephenplusplus
Copy link

Agree with Sindre. Thanks for this making this, @RReverser!

@RReverser
Copy link
Owner

Why should some project for no good reason dictate I read their code with indent 2?

Because our world is not ideal and much projects don't distinguish "indentation" and "alignment" and often mix spaces and tabs, and if you have wrong tab size configured in viewer, entire code looks screwed up.

I definitely don't say it's alright, but I can't fix every such project, and respecting EditorConfig at least gives ability to normally read such code.

For example, one company I'm working with, uses tab_width=8 (yes, I also didn't believe that there are companies that use Unix default size), and without this setting reading code becomes almost impossible. At the same time I prefer to see my own code with tab_width=4. Ruby code should be indented with tab_width=2 according to language spec (and Ruby devs want to see it like that, but at the same time they want to see code in other languages indented differently).

This variety of possible configurations is exactly the problem that EditorConfig solves perfectly, allowing to see any code properly indented and never broken. This was demanded not just me but by other developers as well (at least, I can mention @narirou, @rlidwka, @izaakschroeder and @genbit from isaacs/github#170, but there was a lot of others).

So reading code was a main reason why I created this extension - as that's what I do 90% time on GitHub and use online editor for only really simple fixes.

However, I do want to find solution that would suit everybody's needs.

Do you think adding a dropdown on viewer page would help? (same on as in editor - with 1,2,4,8 indentation and one selected as "auto")

Or do you want just a checkbox in options page that would turn EditorConfig on/off for viewer completely?

Thank you in advance.

P.S. Would be interesting to hear @jedmao's thoughts here as well.

@jednano
Copy link
Contributor

jednano commented Oct 24, 2014

I think @sindresorhus brings up valid points, but I can see both sides. It's unfortunate that some projects use tabs for alignment, which creates the problems you have mentioned. It's even more unfortunate that this can't be fixed from a tooling perspective (as of yet).

Perhaps a bigger question is, "Why does EditorConfig even support a tab_width? Why should the EditorConfig file ever dictate how tabs should be viewed in one's editor?" You'll find the answer to that question is that @treyhunner, the creator of EditorConfig, even has some regrets about the setting himself, if my memory serves me correctly.

That said, if someone has gone through the trouble of adding a tab_width setting, maybe it's for the same reasons that @RReverser has pointed out (i.e., they have to view horribly aligned code all day). If that's the case, at least there's an extension here that they can use to solve the problem, not just in their editor, but on the GitHub viewer. @sindresorhus doesn't have to download it, in the same way I don't have to download his github-tab-size extension if I don't want to view all tab widths at a setting of 4. But I do use his extension, actually, and I love it.

All I'm saying is that some people want this feature, others don't. For those who want it, download it. For those who don't, don't.

@treyhunner
Copy link
Contributor

A couple thoughts:

  1. I disagree that tab_width and indent_size should be ignored when viewing code. We discourage setting indent_size/tab_width when indent_style = tab unless it's necessary. However, when it is necessary it's important to maintain that size.
  2. I don't think this extension should set indent_size by default. When viewing JavaScript code that uses tabs, I should see it in the default format (or in my own custom format if I use at extension like @sindresorhus' github-tab-size). If you must set indent_size by default, I think you should at least set tab_width = tab to disable setting a default size for tabs unless the user prefers to customize that option.

Here's an example from the vim source code which uses tabs for alignment.

With a rule setting indent_size to 4:

selection_232

With no indentation specified (tab width defaults to 8):

selection_233

@jednano
Copy link
Contributor

jednano commented Oct 24, 2014

Silly VIM source code >_<

@RReverser
Copy link
Owner

@treyhunner I'm somewhat confused.

  1. I disagree that tab_width and indent_size should be ignored when viewing code.
  2. I don't think this extension should set indent_size by default.

Those statements look opposite to me. What am I missing?

Are you saying that tab size for viewing should be set only when EditorConfig manually sets tab_width and not indent_size? But that's already so.

I think you should at least set tab_width = tab to disable setting a default size for tabs unless user prefers to customize that option.

That doesn't seem to be allowed value for tab_width according to spec on website. Did you mean indent_size = tab?

If you must set indent_size by default

If you mean extension defaults (and not repo's .editorconfig), then they are easy to change in options page. I added it by default to easily incorporate #1 (so it does the same as @sindresorhus' github-tab-size by default for repos without custom .editorconfig) and at the same time to give flexibility in setting own defaults on options page:

@treyhunner
Copy link
Contributor

The core library defaults tab_width to the value of indent_size.

In my statement about tab_width I meant it should be set to an unrecognized value, but that would actually cause the indentation to use mixed tabs and spaces strangely I think or the behavior might be undefined. Ignore that statement...

I think indent_size and tab_width should left unspecified by default for all files so that code assuming a historical tab stop width of 8 will show up correctly. It's easy for users to change the default behavior. However, in my opinion, it's nice to not break currently working behavior when possible and leave it up to the user to choose whether to improve the look of some repositories while breaking the look of others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants