z6Dabrata 21 апр 2014 в 06:45

EditorConfig — Одни Настройки для всех Редакторов/IDE

7 мин

106K

Веб-разработка * Программирование * Качество кода *

+70

Комментарии 32

shock_one 21 апр 2014 в 07:36

Вы разработчик? Хорошо бы иметь возможность экспортировать мои текущие настройки в .editorconfig.

z6Dabrata 21 апр 2014 в 15:04

Я не разработчик, идея хорошая.
На данный момент можно отформатировать несколько файлов существующего кода с существующими настройками, а потом использовать eclint для генерации конфига.

Насколько я понимаю, вы предлагаете научить плагины экспортировать настройки из IDE? Думаю, что это заслуживает отдельного issue в багтрекере.

KindDragon 21 апр 2014 в 07:38

Спасибо за статью! Как раз хотел про него написать после того как они наконец обновили extension для Visual Studio, исправили в нем проблемы с VS2013.

kekekeks 21 апр 2014 в 08:08

Там проблема была в кривой сборке. Я когда решил разобраться, что же там такое, его сам скомпилил из исходников и обнаружил, что всё работает. Другое дело, что зависящая от него TabSanity почему-то ломает автокомплит в Nemerle.

KindDragon 21 апр 2014 в 07:53

* — Любое количество символов кроме разделителя пути (/)
Пример: [*.js]
lib/source.js // Нет совпадения

Live демо показывает что это не так

KindDragon 21 апр 2014 в 08:01

Зато
[lib/*.js]
lib/source.js // Совпадения
lib/another_lib/source.js // Нет совпадения

[lib/**.js]
lib/source.js // Совпадения
lib/another_lib/source.js // Совпадения

z6Dabrata 21 апр 2014 в 15:14

Это похоже на поведение описанное в статье.

z6Dabrata 21 апр 2014 в 15:13

Вы правы, похоже демо неправильно понимает символ *, сделаю issue.

btd 21 апр 2014 в 08:05

Хороший проект но плагины немного глючные.

z6Dabrata 21 апр 2014 в 15:14

Все в наших руках!

НЛО прилетело и опубликовало эту надпись здесь

rhamdeew 21 апр 2014 в 08:29

Ммм… какой у вас шрифт в подзаголовках крутой (Menlo) =)

А под Eclipse будет подобный плагин? Что-то в посте не нашел его упоминания.

KindDragon 21 апр 2014 в 08:37

Пока не получается найти энтузиастов для этого
bugs.eclipse.org/bugs/show_bug.cgi?id=389139

Delphinum 21 апр 2014 в 08:36

Изначальная задача EditorConfig — создать минимальный набор свойств, который работал бы во всех основных IDE.

Думаю идти надо было от обратного. Реализовать все известные на сегодняшний день настройки, а будут ли они поддерживаться IDE, проблема самой IDE. Зачем ограничивать формат?

KindDragon 21 апр 2014 в 08:40

Смысл же как раз в использование настроек во всех IDE которыми вы пользуетесь. Не будет от него пользы, если настройка есть в файл но нигде не поддерживается.

Delphinum 21 апр 2014 в 08:46

Если именно нигде не поддерживается, то смысла не будет, но если не поддерживается в тех IDE, которые в принципе не умеют, на пример, разукрашивать синтаксис, то это нормально.
Представим ситуацию, работаю я на Eclipse и хорошенько ее под себя настроил. Теперь хочу перейти на vim, перенеся все настройки туда. Какой прок от EC, если он эти настройки не поддерживает, хотя оба IDE их смогут прекрасно воспроизвести? Зачем я должен беспокоится о том, что какой нить там nodepad++ мои настройки не поймет? Когда он научится с ними работать, вам не нужно будет добавлять их в EC, а достаточно будет просто заставить nodepad++ читать уже существующую конфигурацию.

Если честно, я просто не понимаю смысла вашей цели — использовать настройки во всех IDE — а может вы сами не понимаете своей цели )

KindDragon 21 апр 2014 в 09:31

Я говорю не про все IDE в мире, а все редакторы которые используют программисты в проекте. Например: Visual Studio, Notepad++, Sublime Text, под Linux скажем Vim или Geany. Моя цель чтобы программисты под всем этими редакторами использовали одинаковые отступы в коде, одинакового размера.

Delphinum 21 апр 2014 в 10:09

А какую цель вы преследовали, ограничивая формат? Что плохого в том, что переходя на другую IDE мой конфигурационный файл не будет работать в полной мере с учетом того, что проблема здесь не в файле, а в возможностях самой IDE?

KindDragon 21 апр 2014 в 11:08

Во первых, я не разработчик EditorConfig. Только немного контрибьютил в VS etension. Я не ограничивал формат :)

Цель преследовалось чтобы пользователь мог ожидать во всех редакторах с EditorConfig все основные свойства будут работать. Я лично не вижу смысла в десятках свойств из которых только несколько будет работать в нужных тебе редакторах. Это только усложнит реализацию и поддержку плагинов.

Delphinum 21 апр 2014 в 11:10

Я так не думаю. Если редактор не поддерживает то или иное свойство, плагин его просто не обработает, это нисколько не усложняет логику, а если редактор может обработать свойство, то мы намеренно не позволяем ему это сделать, что не есть хорошо.

KindDragon 21 апр 2014 в 11:34

Никто никому не запрещает расширять формат. Просто это большая работа.
`trim_trailing_whitespace` вроде не так давно добавился.

Envek 21 апр 2014 в 11:37

Вы не поняли цель, которую преследовали разработчики EditorConfig. Их задачей было не позволить вам переносить настройки и цветовые схемы между лично вашими IDE (ваши вкусы — только ваше дело). Их задачей было сделать формат, который позволял бы убедиться, что ВСЕ разработчики в рамках ОДНОГО проекта одинаково форматируют код, всё. Каждый пусть сам настраивает свою IDE под себя, но проблема «Табы vs пробелы» должна быть решена на корню, здесь, в этом файле в корне репозитория.

Delphinum 21 апр 2014 в 11:42

Если речь только о «Табы vs пробелы», то да, я не понял цели и все вполне оправдано, один формат, одно свойство, больше ничего не нужно. Если речь идет не только о табах и пробелах, то на мой вопрос выше ответа я не получил. Повторю — как быть если ВСЕ разработчики в рамках ОДНОГО проекта используют разные IDE, часть форматов которых не поддерживается в EC?

Envek 21 апр 2014 в 11:58

Ну на самом деле кроме табов/пробелов (у нас пробелы), кодировки (у нас только UTF-8), завершающих строку пробелов (у нас их быть не должно) и завершающего перевода строки в конце файла (у нас он быть должен) других трений с коллегами нет (больше всего доставляет новая строка в конце файла, а Sublime он почему-то по дефорлту выключен, а ты потом делай git add -p и отделяй свои изменения от изменённых последних строк). Всё остальное уж совсем язык-специфично и просто кому как нравится. Т.е. лично меня уже устраивает функциональность EC.

В принципе народ там хочет впилить крутилки для конкретных языков, посмотрим, что у них получится.

Какие именно нужные вам форматы не поддерживаются в ЕС сейчас?

Delphinum 21 апр 2014 в 12:01

Все же сомневаюсь, что дело именно в этих трех мелочах. Ради этого создавать новый формат? Не думаю. От того и возник вопрос — почему пошли путем ограничения? Ответа пока не увидел. Последим за проектом, может нароем собаку.

Envek 21 апр 2014 в 12:08

Ну, я думаю, что это головная боль для многих популярных open-source проектов — как заставить всех отправляющих патчи людей хоть более-менее одинаково форматировать код?

Пишешь в CONTRIBUTING.md — не помогает, пишешь в README.md КАПСОМ — не помогает, приходится изобретать велосипеды.

z6Dabrata 21 апр 2014 в 15:23

Думаю разработчики решили следовать принципу KISS и начать с минимальными настройками. Таким образом не один разработчик получает один конфиг для разных IDE, а все разработчики получают общие минимальные настройки.
Именно легкость понимания и минимальное количество действий необходимое для того, чтобы начать использовать EditorConfig позволяет разработчикам быстро начать использовать его на проектах.

Ваш подход решает другую задачу — позволить разработчику менять IDE, сохраняя настройки. Это интересная задача, решение которой может помочь другим разработчикам, и, возможно, ее можно решить расширив формат EditorConfig, если найдется кто-то, кому это будет интересно сделать.

Delphinum 22 апр 2014 в 05:33

В этом то и загвоздка. Вот вы считаете, что если EC будет поддерживать больше конфигов (каких не поддерживает несколько IDE), то некоторые разработчики (использующие эти самые IDE) вылетят из пользователей EC. Это не верно. Все разработчики так же получат полный функционал EC, просто некоторые из них, кто пользуется более современными (назовем их так) IDE, получать больший функционал, а другие меньший.

bubuq 21 апр 2014 в 10:40

в конце строк должно быть либо CRLF либо LF.

Отдельные программы для мака всё ещё используют CR для конца строки.

z6Dabrata 21 апр 2014 в 15:28

Это было осознанное решение команды EditorConfig, оно распространяется только на сам файл .editorconfig
Внутри вашего проекта вы можете использовать:

end_of_line = CR

IamKarlson 21 апр 2014 в 11:09

Эх. А хоткеи я так понял и не планируются? Было бы так хорошо подобную штуку для них…

z6Dabrata 21 апр 2014 в 15:42

Думаю, что название проекта (и заголовок, который я придумал) немного всех запутали.
Задача EditorConfig — общий конфиг между разработчиками одного проекта. Не думаю, что кто-то захочет менять горячие клавиши для каждого проекта.

Хотя идея классная, я бы покопал на эту тему. EditorShortcutConfig?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий