There's a thing called EditorConfig which is really useful for projects to have. Editors that are smart enough to read it (or can be made smart enough) will ensure that some basic parameters about the file are properly honored. Parameters like character set, what kind of line endings text files use, the never-ending argument over tabs/spaces, that sort of thing.
A list of common editors that directly use .editorconfig files:
Visual Studio
MonoDevelop
Github itself
Gitlab (a Github competitor)
Nova
BBEdit
Don't use any of those? How about the ones that can have it added then:
VSCode / VSCodium
Textmate
Notepad++
Atom
Coda
Code:Blocks
Eclipse
Emacs
Geany
jEdit
gedit
NetBeans
Pluma
SublimeText
Textadept
textmate
Vim / NeoVim
There's more, that's just the really obvious list. The old way of doing this is by including comments in the files that tell certain editors how to treat them, and by certain editors I mean vi/Vim/NeoVim and whatever flavor of Emacs is your fancy. None of you other people with your insignificant alternatives (😉) matter, only the true holy warriors of the vi and the dirty cultists of the Emacs mattered and we shall do battle until the one true faith is proved! And we all know how that one is going to turn out, don't we?
:wq
ahem Sorry, I got carried away there. 😁
Anyway, the old way of marking up files with stupid comment line noise telling a particular editor how to behave itself in every single file was … well, it was stupid. Someone came along and created EditorConfig as a standard which helps anyone who wants to work on a project do so. There's certainly nor rhyme or reason to how the legacy tag soup files of Agin's Inn were handled, but I've already started kind of enforcing some consistency and sanity upon them.
Here's what I've dropped in my working directory:
# This is the topmost .editorconfig file for this repo
root = true
[*]
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
charset = utf-8
[*.md]
trim_trailing_whitespace = false
[*.{html,css,php}]
indent_style = tab
indent_size = 4
Most of that is fairly self-explanatory even if you don't necessarily agree with it. I didn't specify a line length because line lengths on these old HTML files are "LOL" and "what's word wrap" anyway. I suppose I could set one on .md and .yaml files (I expect we'll be adding a yaml file for deployment on the Inn's web servers, which are managed by cPanel for those of you who know what that is.)
Anyway, I'll leave this here in case someone's got a compelling argument about how it should be different, but it's what I'm using and changing it means a mass commit later on, so hopefully if you want to speak up, you do it sooner than later.
There's a thing called EditorConfig which is really useful for projects to have. Editors that are smart enough to read it (or can be made smart enough) will ensure that some basic parameters about the file are properly honored. Parameters like character set, what kind of line endings text files use, the never-ending argument over tabs/spaces, that sort of thing.
A list of common editors that directly use .editorconfig files:
Don't use any of those? How about the ones that can have it added then:
There's more, that's just the really obvious list. The old way of doing this is by including comments in the files that tell certain editors how to treat them, and by certain editors I mean vi/Vim/NeoVim and whatever flavor of Emacs is your fancy. None of you other people with your insignificant alternatives (😉) matter, only the true holy warriors of the vi and the dirty cultists of the Emacs mattered and we shall do battle until the one true faith is proved! And we all know how that one is going to turn out, don't we?
:wq
ahem Sorry, I got carried away there. 😁
Anyway, the old way of marking up files with stupid comment line noise telling a particular editor how to behave itself in every single file was … well, it was stupid. Someone came along and created EditorConfig as a standard which helps anyone who wants to work on a project do so. There's certainly nor rhyme or reason to how the legacy tag soup files of Agin's Inn were handled, but I've already started kind of enforcing some consistency and sanity upon them.
Here's what I've dropped in my working directory:
Most of that is fairly self-explanatory even if you don't necessarily agree with it. I didn't specify a line length because line lengths on these old HTML files are "LOL" and "what's word wrap" anyway. I suppose I could set one on .md and .yaml files (I expect we'll be adding a yaml file for deployment on the Inn's web servers, which are managed by cPanel for those of you who know what that is.)
Anyway, I'll leave this here in case someone's got a compelling argument about how it should be different, but it's what I'm using and changing it means a mass commit later on, so hopefully if you want to speak up, you do it sooner than later.