editorconfig / editorconfig Goto Github PK

Unit test is preferred for the two current cores.

@treyhunner

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

As mentioned in this mailing list thread, this project needs a nice logo.

How should we unify the behavior?

The notepad++ plugin is in need of a README file with compilation/installation instructions.

We need a descriptive README file that is sufficient for developers to use for creating plugins and users to use for compiling and installing if no binary files are included with their plugin of choice.

I'll create this file soon.

I think we should add test cases for the EditorConfig core to ensure that future changes maintain backwards compatibility and do not any break current functionality.

It looks like cmake is bundled with a test suite called ctest. Maybe we should use that.

I think of some more file firmat properties, which could by provided by this project.

• charset
• BOM allowed/ use BOM (ByteOrderMark)

Those properties came into my mind, because i thought about problems sometimes occur with code which was contributed by some community members in our project.

Building procedure:

mkdir build
cd build
cmake .. -G "NMake Makefiles"
nmake

Error message:

[ 11%] Building C object src/lib/CMakeFiles/editorconfig_shared.dir/editorconfig.obj

D:\Users\user\Documents\src\editorconfig\src\lib\editorconfig.c(267) : error C2373: 'editorconfig_is_standard_c
onformed' : redefinition; different type modifiers
D:\Users\user\Documents\src\editorconfig\src\include\editorconfig/editorconfig.h(118) : see declaration
of 'editorconfig_is_standard_conformed'

Weird problem. The source could be built successfully on gcc and OpenWatcom.

The Python EditorConfig core needs to be packaged for easier distribution and use.

The current plan is to use an external parser to handle file parsing. This parser would be called by editor plugins, accepting the current file name, and then pass back the applicable configuration options for the file.

Other details should still need to be decided.

Possible features:

• Allowing pattern negation in section names (possibly using a ! prefix like gitignore uses.)
• Match files in directory of config file or in subdirectories when pattern does not contain a / (like gitignore)
• Match paths in the config file directory only when a pattern starts with / (also like gitignore)
• Define comment format for config files (probably ;)

This is just a question to see if there is one (or one in the works, or one for another editor but still compatible) for TextMate. Otherwise, if none exist, it's a feature request for a TextMate plugin.

The editorconfig core code currently passes information found for indent_style and tab_width properties, but any other properties are ignored. Currently this code would have to be updated every time a property is added to the Editorconfig file format. To avoid this coupling, all properties found by the editorconfig core should be output, even unrecognized ones.

Issue migrated from editorconfig/editorconfig-vim#6. Originally created by xuhdev at 2011-11-21T03:22:45Z.

Should we always set softtabwidth to indent_size in this plugin? If so, should we put a note on the document: "If possible, editor plugins should set soft tab size to be indent_size"?

We need to add an uninstall mechanism

We should allow test cases to be run on external EditorConfig-equivalent commands. This would allow a codebase that reproduces functionality of EditorConfig core to be more easily tested for equivalence to the EditorConfig core.

Should we ignore empty values?

consider this:

[*]
end_of_line=crlf

[.git/**]
end_of_line=

Thus we could ignore all files in .git.

This is not urgent, but it would be very pleasant if emacs have an editorconfig mode that does the syntax highlighting, or other useful things. Currently the vim plugin does this by highlighting .editorconfig files as dosini files. I don't know whether there is a way for emacs to do so. If there isn't, this issue should be closed.

If a value is found for indent_size but tab_width has no defined value, tab_width should be set to the value of indent_size.

"Memory error." is printed. Seems "realloc" function causes this problem.

This issue is a continuation of a discussion on a vim plugin commit.

The two tests are: star_over_slash and windows_separator

Instead of adding more documentation to the README, we should probably create dedicated documentation files or a website for the documentation. We use Sphinx and/or Pycco for this.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

We need to add a packaging mechanism

The page has some display problem. Don't know a way to fix.

In Vim, if the EditorConfig file is changed for a currently open file the only way to refresh the indentation currently is to close the file and then reopen it in Vim. We should make a command to refresh the EditorConfig file behavior.

At the end of every sentence in the man page for editorconfig.h there is an apostrophe just before the period. For example:

Function Documentation
   const char* editorconfig_get_error_msg (interr_num)
       Get the error message from the error number returned by editorconfig_parse()'. An example
       is available at src/bin/main'.c in editorconfig source code'.

       Parameters:
           err_num The error number that is used to obtain the error message'.

       Returns:
           The error message corresponding to err_num'.

Since EditorConfig should be a common standard, we must consider EBCDIC based systems.

First of all, we need to explicitly point out that the .editorconfig should be in ASCII code in the document;
secondly, we have to make EditorConfig core support EBCDIC based systems. But I do not have such a system installed. Hope anyone could offer some help on this.

We should add version numbers to each EditorConfig plugin and increment these version numbers appropriately (per this mailing list discussion).

Issue migrated from editorconfig/editorconfig-vim#4. Originally created by treyhunner at 2011-11-08T15:07:20Z.

Downloadable archives can be uploaded to the "Downloads" section (under the "Code" tab).

I think we should create Linux, Windows, and Mac archives containing the vim plugin, the editorconfig binary file compiled for their system from the core code, and an installation script that will copy these files to the appropriate locations.

This would make the code considerably more accessible.

By bundling non-C/C++ plugins with the python core code, users could avoid install the EditorConfig Core separately.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Our current explanation of how to create a plugin is very brief and does not mention the difference between creating a plugin using the cli utility and creating a plugin using the C module. We should fix this description on the website.

We may also want to add an even more detailed description in the core documentation, in the wiki, or in the core README file.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Add documentation to website for this behavior:

1. When a pattern contains / characters, match the end of the file's directory path (can be matched as far up as the path of the found .editorconfig file)
2. When a pattern starts with /, match paths in the config file directory only

Currently, the default file name is .editorconfig. However, this is inconvenient on Windows: file name starts with a dot cannot be created by Windows Explorer, which is usually done by Windows users, including programmers. I suggest to add another file name editorconfig.txt, thus windows only projects would feel better. EditorConfig core first searches for .editorconfig, if found, read this file and skip to next directory; if not found, searches for editorconfig.txt.

Plugins should let user to custom the path to editorconfig executable file.

The EditorConfig core documentation on the website should be split into version-specific documentation (as mentioned here).

This would be easier for testing, and more flexible to use EditorConfig Core.

These two rules should to be implemented in the EditorConfig core:

1. When a pattern contains / characters, match the end of the file's directory path (can be matched as far up as the path of the found .editorconfig file)
2. When a pattern starts with /, match paths in the config file directory only

I believe 1 can be resolved by passing the full file path to fnmatch instead of just the filename.

Currently it seems that the exception ParsingError, PathError and VersionError do not provide much info. Maybe they could provide the following info:

ParsingError: error file path, line number
PathError: the wrong path
VersionError: the wrong version

@treyhunner Do you think it's necessary?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

The below issues need to be resolved before a generic method for parsing can be defined.

1. Should [ and ] characters be escaped in file globs? Section headers are surrounded by these characters so it might be confusing, but this shouldn't lead to parsing ambiguity because a command (";") or a newline denote the end of the section header as well (both optionally preceded by whitespace).
2. How will asterisk's be escaped in filenames? Git follows the format of fnmatch which is based on glob and allows [*] to denote an escaped asterisk. Vim's [globpath](http://vimdoc.sourceforge.net/htmldoc/eval.html#globpath(\)) supports this notation as well.
3. What types of wildcards should be supported? Should ? be supported as a single character wildcard? Should [...] expressions be used to match a single character any of the characters between the square brackets? C`s fnmatch and Vim's globpath both allow these constructs.
4. Should ** work for matching over file path separators? Vim's globpath supports this but C's fnmatch does not.

Allowing more flexibility in pattern matching means more power for users typing in file globs but it also may make plugin creation more difficult if a glob matching function is not already available in the language/framework used to write the plugin.

The single page website layout has become lengthy. We should split the website into multiple pages and use Jekyll for templating.

We need to decide how we want to split up the site into pages and what layout we want to use for navigation.

The root=true will set current .editorconfig file as the top level file. This has been implemented and the documentation needs to be updated.67fcecf33fc2b57f23283052f3e3e29fbd0575f7

By this comment, I came up with this idea. Adding hooks to change the default behavior for some advanced editors is meaningful. For example, in the issue mentioned above, we could add a property such as c_compilation_flags, and provide a hook function EditorConfig#AddHook('property', function('new_behavior') to append a new behavior to that property. For other advanced editors, such as Emacs, we could do something similar.

Without a README, I have no idea of the stage of editorconfig-py, and don't know whether it is ready for use, have no idea where I should start to use it and include it in the vim plugin (and other non-C/C++ plugins). Maybe we should add a README first?

Editors that allow plugins to be written in languages that can use C libraries (e.g. gedit, TextMate, and Notepad++) could use the editorconfig core code directly if it is formatted as a C library.

We should break the main function into logical parts, structure the code as a library, and document how the library can be used.

Many important functions that the C core has is not available in the python version. For example, editorconfig_get_version is an important one. editorconfig_get_err_msg is another one.

Issue migrated from editorconfig/editorconfig-emacs#1. Originally created by treyhunner at 2011-11-05T04:57:28Z.

This plugin currently supports setting indentation in text mode, but many other modes override indent-line-function to change the way the TAB key behaves. These overrides often use special variables to set the indentation tab width for soft tab indentation.

In all the modes I've seen, the number of spaces used for space-based indentation can be set with a specific variable. For example Python mode uses the "python-indent" variable to set the tab width.

I think we should include tab width overrides for common modes (all of these modes) and create a hook that can be used for specifying indentation for custom/unknown modes.

Any properties specified in closer EditorConfig file should take precedence over more distant EditorConfig files.

Nothing is different from initial settings when .editorconfig file is present.

Whitespace in front of section names and section properties should be ignored. Any indentation may be used in the EditorConfig INI file format without problems.