Add js-ts-mode' spec to editorconfig-indentation-alist' (#293)

Hi maintainer:

editorconfig-emacs missing the emacs-29's js-ts-mode indentation specification which I've made for this pull request.

Thanks.

Do you think it's worth a vote for editorconfig/editorconfig-vote? This is a pretty corner case: Is it a decision on changing the standard, or a lack of clarity in the document?

Add example for fillexceeding max_line_indicator (#218)

Sorry, I missed this in the docs when adding the new option value

Sorry, I missed this when adding the new option value

@Jorengarenar I don't see how EditorConfig is an ideal candidate. You are proposing to have a central place to save a configuration for all editors you use. As a matter of fact, as I said before:

the overwhelming majority of people stick to at most 2 or 3 editors, which often intentionally need to diverge on their configuration.

This is already pretty straightforward to maintain if you maintain your own dotfiles. There isn't really much incentive to add significant complexity to EditorConfig for something that's already easy and clean to achieve.

fix: do not treat directories as editable on VimEnter (#217)

Fixes #212

Fixes #212

Actually I don't think this is true. If the existing file has only 1 final newline, some editors will delete this final newline.

What if the file has multiple newlines and the plugin tells the editor to not add final new lines? I guess editors will do this in wildly different ways (not verified).

Context: https://github.com/editorconfig/editorconfig-vim/pull/213/files#r1133331533

Reproduction steps:

1. Place .editorconfig in current dir

root = true

[*]
max_line_length = 111

2. Open vim with plugin installed on new file in current directory, e.g., vim newfile.txt.
3. Observe that :echo &textwidth is 0 instead of 111.

When reverting the commit 6e2b092, the above correctly reproduces 111 instead.

Replace b:filetype with filetype (#216)

b:filetype is an invalid variable name

Fix #215

b:filetype is an invalid variable name

Fix #215

b:filetype is an invalid variable name

Fix #215

Ignore netrw buffers (#213)

Previously, when starting Neovim with a directory, opening a netrw buffer, it would encounter the following errors when trying to close (:q):

E37: No write since last change
E162: No write since last change for buffer "…"

https://github.com/editorconfig/editorconfig-vim/issues/212

Previously, when starting Neovim with a directory, opening a netrw buffer, it would encounter the following errors when trying to close (:q):

E37: No write since last change
E162: No write since last change for buffer "…"

Since editorconfig is concerned with source files, not directory listings (as in the case of netrw buffers), I thought it makes sense to not apply the config for such buffers.

For further details of the issue and my investigation, please see: #212

Thank you so much for this awesome project. 💚

The values are currently not checked. You can use every value you like e.g. foo for indent_size. This can lead to problems, when one uses get_properties() and assumes, that if no exception occurred, the data are totally valid. This PR adds a check that raises a exception, if something is not valid.

Thanks for the PR, but these checks should not be done. The purpose is to let editors and future EditorConfig standard be able to extend customized values without the need to upgrading the core library. The core library is supposed to remain stable. See the spec:

EditorConfig cores shall accept and report all syntactically valid key-value pairs, even if the key is not defined in this specification.

You are right, it need to be added to the spec first: spec.editorconfig.org. The plugin is a implementation of the spec for Vim.

I personally agree that indent_method is a better name than smart_tab. However, I don't see how the two paths conflict. We can still add smart_tab to the spec and decide on indent_method later. It'll take some time to get editor plugins to implement smart_tab.

I don't think they are the same. However, I don't think we'll implement exactly N new lines at EOF because this is not a feature that's widely available among editors (because, this feature doesn't have many use cases).

However, this issue should still be relevant to what you are looking for (exactly 1 EOL or only must end with EOL?)

Use Case

As a user of editorconfig, I frequently edit files with a long string of newlines at the end of the file or accidentally insert multiple newlines at the end of the file. It would be helpful to have a setting which would allow me to strip multiple newlines from the end of the file to ensure that it ends with one and only one newline.

Details

As a user, this is a minor annoyance to me. In the same way that trailing whitespace often accretes on lines in a text file, trailing newlines frequently end up at the end of a file, so that I save it with a single newline, the next time I check out a branch there are three trailing newlines, and by the third time I check it out there are a dozen.

I propose one of two ways to handle this:

trim_multiple_final_newlines = (true|false)

This would ensure that there is never more than a single newline at the end of a file. However, acknowledging that there may be valid use cases for multiple final newlines at the end of the file, a preferred method would be:

final_newline_count = N

N is the number of blank lines at the end of the file. In this case:

• N = 0 would leave no newlines at the end of the file.
• N = 1 would leave one and only one newline at the end of the file, simulating the insert_final_newline = true for a file without a trailing newline.
• N = 5 would leave five and only five newlines at the end of the file.
• Etc.

If either solution is approved for incorporation into editorconfig, the specific declaration name is not important, only the behavior (indeed, it should be aligned to current schema naming conventions).

Closing this, thank you for reporting!

Awesome! @Pittan Would you be able to help again :) Thank you!