6 ms·

> For Windows Users: To create an .editorconfig file within Windows Explorer, you need to create a file named .editorconfig., which Windows Explorer will automa

> For Windows Users: To create an .editorconfig file within Windows Explorer, you need to create a file named .editorconfig., which Windows Explorer will automatically rename to .editorconfig What a neat trick I had no idea. Been renaming those files on the cli all this time. On a related note: Why has it gone the way that I must look at code your way. Is there no chance of decoupling the presentation with logic like the web has long preached us (not saying that worked). Tabs to spaces shouldn't be some messy commit regardless of your preference on the matter. Anyway, nice project. I understand your search preferences up from the project root not down from my preferences because it's controlling other people's coding standards.

Sujan 11y ago
You can _look_ at it whatevery way you want - that's the job of your IDE. But if you _edit_ (in) it, your changes should be saved in the way the author decided to keep one standard in one codebase. PS: Whooop on the Windows trick! So useful.
- mkohlmyr 11y ago
  That's assuming the code-base was still saved as a representation rather than a syntax tree that can be viewed in whatever way a given developer prefer. There's no reason that has to be the case. In fact intuitively i'd be inclined to say its probably easier to write a VCS for a syntax tree than a free text string?
  - qznc 11y ago
    The modern/popular way is to run a format tool before you commit. (gofmt, clang-format, etc) A VCS for syntax trees means you need the One True Data Format(tm) for syntax trees in any language. Finding consensus on formatting per project is easier than unifying all syntax tree representations globally.
    - WorldMaker 11y ago
      Additionally, there are many reasons you might want to commit work in progress code that doesn't/won't parse correctly to a "proper" syntax tree. While there are certainly workarounds (pseudo-trees for "malformed"/"unfinished" sections), there's entire neighborhoods of bikesheds to paint there. (Amongst the major compilers thus far the only ones I've seen invest useful time in mostly unified intermediate syntax trees is the Roslyn compilers for C#/VB, often compilers don't care but Roslyn had the opportunity/drive/interest to try to merge a lot of editor support directly into the compiler infrastructure.) (Aside: I built a cool proof of concept for what I think is the most useful "smart middle ground" here, which is to use syntax highlighting lexers (tokenizers) for a useful effect in creating smart character-based diffs. Syntax highlighting lexers are designed for intermediate code and with output as ordinary character diffs you don't have to bikeshed a universal token stream format. The tokenized diffs were cleaner and faster than the equivalent non-tokenized character diff. https://github.com/WorldMaker/tokdiff https://github.com/WorldMaker/tokdiff if anyone wants to play with it.)
  - Sujan 11y ago
    Last time I checked my codebases were all plain text files. But yes, having a syntax tree would solve this problem quite nicely. (But to make it work universally you have to decide on a representation of this syntax tree to be able to represent it in plain text files to make it work with all the editors and IDEs that don't support that syntax tree stuff... And then we're back to .editorconfig, aren't we?)
  - michaelmior 11y ago
    Performing merges and handling conflicts seems like a harder problem than for text.
  - e12e 11y ago
    The two examples I can think of is ColorForth[1] (not sure what the representation is there, or how/if one would couple it with a (D)VCS), and of course Smalltak with it's DVCS Monticello: http://news.squeak.org/2008/08/15/all-new-monticello-2/ http://news.squeak.org/2008/08/15/all-new-monticello-2/ I had no idea there was such a new rewrite (2008), but then I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years). [1] http://www.colorforth.com/cf.htm http://www.colorforth.com/cf.htm [It would appear that the on-disk representation is rather simple and straight forward, but you're only supposed to use a ColorForth aware editor (eg: ColorForth)]
    - jstanley 11y ago
      > I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years). Are you saying git is not popular, is not free software, or something else?
      - taejo 11y ago
        No, they're saying that unpopular, unfree DVCSes are less new.
      - e12e 11y ago
        I'm saying 10 years is new (and that eg: bitkeeper and monotone is older than git).
bsimpson 11y ago
I've often wondered this. I find columnar alignment of key:value pairs (in CSS, dictionaries, etc) to be much easier to read, but I find that I'm an outlier because most people get upset when they see whitespace changes in a diff. (FWIW, `?w=0` will hide whitespace changes on GitHub). It would be rad if an editor like Sublime or Atom understood columns and displayed code that way without needing to reindent everything in the file every time you add a longer key.
- 1wd 11y ago
  It's called elastic tabstops. [1] The page links some editors that implement this and some plugins for other editors. Apparently SublimeText's plugin is incorrect though. It does not mention Atom, but it was discussed in [2]. [1] http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/ [2] https://discuss.atom.io/t/elastic-tabstops/16/23 https://discuss.atom.io/t/elastic-tabstops/16/23
- Macha 11y ago
  I find it more readable up until the difference in key lengths becomes larger (font and text-decoration for example), at which point I have trouble matching the values with the shorter names.
  - oneeyedpigeon 11y ago
    Just right-align your property names. I know that sounds ridiculous, but give it a go: body { font-size: 16px; margin-bottom: 100px; padding-top: 40px; color: rgb(100, 100, 100); background-color: rgb( 90, 255, 3); }
    - Already__Taken 11y ago
      Oh way better yes. I sometimes like to indent dependent properties too: body { width: 400px; margin: 20px; position: absolute; bottom: 0; right: 0; background: #ccc; }

Sujan 11y ago

You can _look_ at it whatevery way you want - that's the job of your IDE. But if you _edit_ (in) it, your changes should be saved in the way the author decided to keep one standard in one codebase. PS: Whooop on the Windows trick! So useful.

mkohlmyr 11y ago
That's assuming the code-base was still saved as a representation rather than a syntax tree that can be viewed in whatever way a given developer prefer. There's no reason that has to be the case. In fact intuitively i'd be inclined to say its probably easier to write a VCS for a syntax tree than a free text string?
- qznc 11y ago
  The modern/popular way is to run a format tool before you commit. (gofmt, clang-format, etc) A VCS for syntax trees means you need the One True Data Format(tm) for syntax trees in any language. Finding consensus on formatting per project is easier than unifying all syntax tree representations globally.
  - WorldMaker 11y ago
    Additionally, there are many reasons you might want to commit work in progress code that doesn't/won't parse correctly to a "proper" syntax tree. While there are certainly workarounds (pseudo-trees for "malformed"/"unfinished" sections), there's entire neighborhoods of bikesheds to paint there. (Amongst the major compilers thus far the only ones I've seen invest useful time in mostly unified intermediate syntax trees is the Roslyn compilers for C#/VB, often compilers don't care but Roslyn had the opportunity/drive/interest to try to merge a lot of editor support directly into the compiler infrastructure.) (Aside: I built a cool proof of concept for what I think is the most useful "smart middle ground" here, which is to use syntax highlighting lexers (tokenizers) for a useful effect in creating smart character-based diffs. Syntax highlighting lexers are designed for intermediate code and with output as ordinary character diffs you don't have to bikeshed a universal token stream format. The tokenized diffs were cleaner and faster than the equivalent non-tokenized character diff. https://github.com/WorldMaker/tokdiff https://github.com/WorldMaker/tokdiff if anyone wants to play with it.)
- Sujan 11y ago
  Last time I checked my codebases were all plain text files. But yes, having a syntax tree would solve this problem quite nicely. (But to make it work universally you have to decide on a representation of this syntax tree to be able to represent it in plain text files to make it work with all the editors and IDEs that don't support that syntax tree stuff... And then we're back to .editorconfig, aren't we?)
- michaelmior 11y ago
  Performing merges and handling conflicts seems like a harder problem than for text.
- e12e 11y ago
  The two examples I can think of is ColorForth[1] (not sure what the representation is there, or how/if one would couple it with a (D)VCS), and of course Smalltak with it's DVCS Monticello: http://news.squeak.org/2008/08/15/all-new-monticello-2/ http://news.squeak.org/2008/08/15/all-new-monticello-2/ I had no idea there was such a new rewrite (2008), but then I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years). [1] http://www.colorforth.com/cf.htm http://www.colorforth.com/cf.htm [It would appear that the on-disk representation is rather simple and straight forward, but you're only supposed to use a ColorForth aware editor (eg: ColorForth)]
  - jstanley 11y ago
    > I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years). Are you saying git is not popular, is not free software, or something else?
    - taejo 11y ago
      No, they're saying that unpopular, unfree DVCSes are less new.
    - e12e 11y ago
      I'm saying 10 years is new (and that eg: bitkeeper and monotone is older than git).

bsimpson 11y ago

I've often wondered this. I find columnar alignment of key:value pairs (in CSS, dictionaries, etc) to be much easier to read, but I find that I'm an outlier because most people get upset when they see whitespace changes in a diff. (FWIW, `?w=0` will hide whitespace changes on GitHub). It would be rad if an editor like Sublime or Atom understood columns and displayed code that way without needing to reindent everything in the file every time you add a longer key.

1wd 11y ago
It's called elastic tabstops. [1] The page links some editors that implement this and some plugins for other editors. Apparently SublimeText's plugin is incorrect though. It does not mention Atom, but it was discussed in [2]. [1] http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/ [2] https://discuss.atom.io/t/elastic-tabstops/16/23 https://discuss.atom.io/t/elastic-tabstops/16/23
Macha 11y ago
I find it more readable up until the difference in key lengths becomes larger (font and text-decoration for example), at which point I have trouble matching the values with the shorter names.
- oneeyedpigeon 11y ago
  Just right-align your property names. I know that sounds ridiculous, but give it a go: body { font-size: 16px; margin-bottom: 100px; padding-top: 40px; color: rgb(100, 100, 100); background-color: rgb( 90, 255, 3); }
  - Already__Taken 11y ago
    Oh way better yes. I sometimes like to indent dependent properties too: body { width: 400px; margin: 20px; position: absolute; bottom: 0; right: 0; background: #ccc; }