Hong Xu
I understand this feature request. However, EditorConfig has been focused on general formatting, i.e. not related to specific languages. **But, editors are allowed to make their own extension.** I guess...
My thought is that we should only do this once we have the first backward-incompatible change...
@sindresorhus Yes, it would require a lot of effort to make it reliable for EditorConfig. In my opinion, EditorConfig should try to take advantage of the formatting features of the...
@sindresorhus In fact we are currently take advantage of editor-provided features to handle tab, space, indent, etc. right? Why would you think it's inconsistent? At least for Java and C++,...
No, this is too langauge-specific and too detailed that it's hard to get some editors to support this feature.
I agree on this. But it's not widely supported by editors, but we can still consider it.
If you set `insert_final_newline=false`, final newlines should be removed. If it is unset or set to something random such as `none`, then it should not be touched.
Ah, sorry I didn't notice that you meant extra newlines! I can look into this, but this feature is probably limited by what editors provide us.
If we use a new name, how would we deal with its compatibility with `insert_final_newline` then? The best way for me is add a new legal value `single` to `insert_final_newline`...
Yeah, definitely. But we can push the doc first so people can work on it.