Atom: Add support for .editorconfig file

[daviwil]

_From @terrycloth on March 13, 2017 22:27_

Prerequisites

• [x] Put an X between the brackets on this line if you have done all of the following:
  
  
  
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  
  
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  
  
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  
  
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  
  
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages
  
  

Description

EditorConfig is an attempt at standardizing certain configurations across text/code editors, to help keep things consistent, no matter who is editing the file or with what program. You can configure settings for a whole project, a directory, or specific files matched using globbing patterns, with rules set in standard INI format.

In particular, I think it would be helpful if Autoflow followed the max_line_length directive, which defines what should be the maximum number of characters per line. EditorConfig currently only uses the value here to set the placement of a visual text wrapping guide --- i.e., a hint, rather than forcing hard-wrap. However, I think "maximum line length" is semantically related enough that it would make sense for Autoflow to use this directive when determining how to rewrap text in the current context.

Versions

• Fedora 25 Workstation x86_64
• Atom 1.15.0
• Autoflow 0.29.0
• Electron 1.3.13
• Chrome 52.0.2743.82
• Node 6.5.0
• apm 1.13.0
• npm 3.10.10
• node 6.9.5
• python 2.7.13
• git 2.9.3

_Copied from original issue: atom/autoflow#58_

[Redsandro]

This issue is now almost 4 years old. No one with the technical know-how is interested in this feature.

The author of the plugin atom-editorconfig that saved us all thusfar, has thrown in the towel:

Atom-Editorconfig is now Unmaintained

(..) i started disliking Atom as a platform for plugin-developers. (..) the Atom API lacks of two very important points to be able to rely on (..) changes in the API which were announced but introduced breaking changes without any assistance (..) the whole API is badly documented for plugin-developers. There is no stability-indicator which would help to rely on "stable" functions. The API-team missed the opportunity to create a good abstraction for the plugin-API everything may change whenever they decide to do something.

I think this is the moment to realize that our love and sentiment for Atom only takes us so far. We should assimilate into vscode. Resistance is futile.

I'm assuming paid Atom devs have been assimilated into vscode anyway, since the acquisition.

[stale[bot]]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of Atom
2. Comment that the issue is still reproducible and include:
   
   
   
   • What version of Atom you reproduced the issue on
   
   
   • What OS and version you reproduced the issue on
   
   
   • What steps you followed to reproduce the issue
   
   

Issues that are labeled as triaged will not be automatically marked as stale.

[Redsandro]

Dear @stale bot,

Please show us the PR where this was fixed. AFAIK, we still need the editorconfig plugin, and it's been a continuous dance of it breaking with an Atom update, and it being fixed later.

This should be a system package in my opinion.

Thanks!