I'd love to see an editor that let me see the code in the way I preferred (perhaps even as far as rendering Java as Lisp), but wrote the code to disk according to the EditorConfig.
EditorConfig
21–30 of 40 posts
Re: EditorConfig
#22I'd love to see an editor that let me see the code in the way I preferred (perhaps even as far as rendering Java as Lisp), but wrote the code to disk according to the EditorConfig.
From what I've seen, people sometimes accomplish this with git hooks. Well, not exactly what you want, but the basic: you see something different as is eventually saved to repository (and vice versa).
Re: EditorConfig
#23The idea seems very cool, but I wonder if there is anything like this that could have more language specific stuff like "in JS (or Ruby, or ...) format your hashes/object literals/arrays/constants/... like so." I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say someth…
What are you looking to do with "language styles" that you can't do based on file extension?
Re: EditorConfig
#24The idea seems very cool, but I wonder if there is anything like this that could have more language specific stuff like "in JS (or Ruby, or ...) format your hashes/object literals/arrays/constants/... like so." I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say someth…
Typically those are done using configuration files of code-checking tools, such as .jshintrc[1] or .pylintrc. [1]: https://gist.github.com/connor/1597131
I guess I just figure these two are sort of overlapping. If you use .jshintrc why do you need this tool?
(The neat idea being: if a project has many languages, you can share code conventions for all of them in one place.)
Re: EditorConfig
#25The idea seems very cool, but I wonder if there is anything like this that could have more language specific stuff like "in JS (or Ruby, or ...) format your hashes/object literals/arrays/constants/... like so." I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say someth…
.editorconfig supports domain specific properties: https://github.com/editorconfig/editorconfig/wiki/EditorConf... . Its encouraged that other extensions/tooling take a dependency on .editorconfig to introduce their own configuration.
Interesting. I'll take a look to see what domain specific properties exist.
Re: EditorConfig
#26The idea seems very cool, but I wonder if there is anything like this that could have more language specific stuff like "in JS (or Ruby, or ...) format your hashes/object literals/arrays/constants/... like so." I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say someth…
.editorconfig supports domain specific properties: https://github.com/editorconfig/editorconfig/wiki/EditorConf... . Its encouraged that other extensions/tooling take a dependency on .editorconfig to introduce their own configuration.
Re: EditorConfig
#27Combine with something like https://github.com/schorfES/grunt-lintspaces to check that all code complies + some tests before or after you push your code upstream to eg. Git and you'll get a much more consistent code base when it comes to whitespaces.
Re: EditorConfig
#28Combine with something like https://github.com/schorfES/grunt-lintspaces to check that all code complies + some tests before or after you push your code upstream to eg. Git and you'll get a much more consistent code base when it comes to whitespaces.
If your project doesn't use Grunt, but you do use Vim, you can put the following in your .vimrc
" Remove trailing whitespace for everything but markdown.
let whitespace_blacklist = ['markdown']
autocmd BufWritePre * if index(whitespace_blacklist, &ft) Re: EditorConfig
#29I loved EditorConfig until tools like clang-format[1] and gofmt[2] showed up. Combine those with Git's hooks and you really got something.
Re: EditorConfig
#30Earlier quoted context omitted.
Typically those are done using configuration files of code-checking tools, such as .jshintrc[1] or .pylintrc. [1]: https://gist.github.com/connor/1597131
I guess I just figure these two are sort of overlapping. If you use .jshintrc why do you need this tool? (The neat idea being: if a project has many languages, you can share code conventions for all of them in one place.)
The nice thing about EditorConfig is that it fixes some problems before they occur instead of requiring you to manually fix things after running a linter (e.g. spaces vs tabs)