Частично поможет Preferences -> Editor -> Code Style -> Swift -> Wrapping and braces -> Method call arguments -> Align when multiline, но сделать indent для аргументов с помощью этой опции не получится. Вообще, для форматтера Swift пока есть достаточно много нереализованного и в ближайшее время мы этими задачами с большой вероятностью заняться не сможем.
Тогда — т.к. с памятью все вроде бы ок — быстрого решения найти не получится, нужно снять CPU snapshot и сделать тикет здесь. Если получится сам проект приложить, было бы совсем хорошо.
1. Поддержать дополнения в Swift 2.2 (OC-13365)
2. Научиться отображать те же сообщения типа warning/error, что и Xcode в окне редактора (по сути переиспользовав их)
3. Улучшить resolve в mixed-code (типы Swift из Objc и наоборот), что в прикладном плане должно улучшить навигацию, Find Usages, Rename, да и просто необходимо для корректной реализации рефакторингов в будущем.
4. Сделать часть рефакторингов — Introduce variable, Inline variable.
Плюсом нужно доработать часть задач по generics в Objective-C (в основном это кейзы вроде OC-13178) и performance в редакторе для Swift. То, о чем вы спрашивали — parameter placeholders — понятно, что необходимо сделать, но пока то, о чем я сказал выше, для нас более приоритетно. Сделать постараемся, но гарантировать здесь что-либо сложно — в силу сложности всех остальных задач.
Видимо, такое еще не встречалось. Давайте заведем тикет вместе с логом из IDE — для того, чтобы стало чуть более понятно, что происходит, постараемся помочь.
Давайте попробуем проверить, достаточно ли памяти для IDE. Можете включить Preferences -> Appearance -> Show memory indicator (в правом нижнем углу должен появиться индикатор памяти, доступной для IDE) и сказать — насколько этот объем использован (доступно vs использовано)?
Подскажите пожалуйста, вы про Swift или есть проблемы в Objective-C? Если Objective-C, то пример был бы полезен. По Swift — после текущих задач поймем, сможем ли мы это выдать в будущем релизе или нет.
Пока похоже на вот эту проблему, причину пока точно установить не удалось. Если сможете в тот же тикет приложить лог из Help -> Show log in finder для момента, когда устанавливали gem, это бы нам помогло.
Вот если проект не собирается — тогда обязательно нужен тикет по его поводу. Проект собираться должен и с текущей версией (в случае, если xcode его собирает). По поводу ежедневных билдов — пока нет, не получится.
Если под "потерей" индекса имеется в виду его перестроение при смене бранчей в гите — да, оно происходит в этом случае. И для корректной работы без него не обойтись в общем случае.
Здесь хорошо бы нам иметь пример кода, для того, чтобы сказать — есть ли для него сейчас проблемы с completion или они исправлены. Суть в целом такова — мы активно работаем над парсером, если есть проблема в парсере — то это отражается на resolve и completion. Поэтому нужен пример кода, чтобы понять причину.
многие участки кода не подчеркивает красным, что они с ошибкой (например, что забыл unwrap optional сделать) и чтобы увидеть ошибку нужно скомпилировать
Отображение ошибок в коде до компиляции в редакторе (по тому же принципу, как сейчас это делает Xcode) сейчас в работе (OC-13024). Итерация тестирования уже прошла — возникла необходимость доработать, пока в процессе. После того как сделаем — описанные вами проблемы должны уйти.
компиляция swift через AppCode идет в разы дольше чем через Xcode
Здесь опять же, хорошо бы пример конкретного проекта, но в общем — Xcode собирает проект через свой внутренний toolchain, который умеет параллелить компиляцию отдельных файлов с исходным кодом. Документации по нему нет, как его использовать — непонятно. Мы собираем проекты через xcodebuild, он параллелить сборку, насколько мне известно, не умеет. Поэтому время компиляции может быть дольше и пока непонятно, как можно такую задачу решить в разумные сроки.
Пока мы ее тестируем вместе с десятком связанных задач, там крайне непростая часть функциональности. В текущем релизе это не появится — опять же, потому что изменений достаточно много и их необходимо проверить в рамках EAP. К слову, переход задачи между спринтами означает в данном случае, что мы над ней активно работаем, но пока она еще не завершена для выдачи в каком-либо билде )
Получается бой двух IDE, а у меня нет такой задачи. Но ок )
1) FuzzyAutocomplete
А у нас еще Smart Completion, и все «из коробки»
2) Auto-Importer / Peckham
Ну ок, optimize imports все-таки только у нас )
3) Уже есть в Xcode
А у нас сразу же можно увидеть в отдельном окне, как именно используется символ, который ищем и поиск можно стартовать шорткатом без пассов мышью. А это быстрее.
На самом деле нет, дальше я не буду сравнивать, контекст этого треда не верен. Дело не в том, чем мы лучше Xcode — ибо мы с ним не воюем. Дело в том, чем мы хороши для программирования под iOS. А это правда, тема для отдельной статьи.
А кстати, была бы такая статья интересна тут, на хабре?
Есть такая проблема — пока пытаемся понять, как ее стабильно воспроизвести и исправить. Хороший кейз в том, что она как правило воспроизводится нечасто.
Если вдруг еще раз сможете воспроизвести — то будет отлично, если напишете, как это получилось здесь
Резонный вопрос. Попробую кратко пояснить на примерах, по личному опыту — приходилось программировать под разные платформы, в том числе достаточно много под iOS. Есть одна существенная особенность в мобильной разработке — ты всегда зависишь от того, кто делает мобильную платформу и обычно — перестраховываясь — всегда используешь ту IDE, которая считается официальной для конкретной платформы. Альтернативных вариантов обычно нет, поэтому к особенностям той или иной IDE приходится привыкать, а менять потом привычки — сложно.
Например, при разработке под iOS вырабатывается стойкая привычка ко вполне определенному типу автодополнения кода — «набери начало того, что хочешь подставить». В случае какого-нибудь UITableViewCellStyleValue2 — придется набирать почти до конца, а у нас можно просто использовать camel humps и набрать UITVCSV2 (или в нижнем регистре, если в настройках отключить case-sensitive). То же самое с middle matching.
Импорты. Хочешь использовать конкретный класс — сначала пропиши импорт, всегда. Рутина? Да, рутина, но к ней привыкаешь. А у нас можно просто прописать название класса, увидеть подсказку и добавить нужный импорт по Alt+Enter. Так же привыкаешь к тому, что код в среднем или крупном проекте никогда не будет очищен от неиспользуемых импортов, потому что нет времени, есть более серьезные задачи итп. А главное — потому что если это нужно сделать, то придется это делать руками. В AppCode для этого достаточно выбрать одну операцию в меню — и все.
Поиск использований. Берем какой-нибудь ReactiveCocoa и пробуем найти в нем все использования какого-нибудь метода, например, map из RacStream (пример взят с потолка, просто проект под рукой). И хотим мы найти использования только метода, а не всех текстовых вхождений. У нас это можно сделать просто выделив map и нажав Alt+F7. И для этого не нужно никуда переходить.
Контроль версий. Не берем работу с VCS в командной строке — что делать, если хочется работать с ним через UI? Большинство знакомых iOS-программистов просто по дефолту ставят что-нибудь вроде SourceTree. А большинство знакомых Android-программистов, использующих Android Studio — не ставят, потому что встроенного в IDEA-based продукты функционала по контролю версий вполне достаточно. То же самое относится и к AppCode.
Debugger. У нас есть Inline view — и это в ряде случаев удобнее.
Рефакторинги. Здесь я пожалуй, все-таки просто вставлю скриншот .
Это если коротко — более подробно я думаю можно только в отдельной статье. Или нескольких. И я думаю, мы их скоро напишем.
P.S. Случайно запостил не туда, это был ответ на предыдущий комментарий.
1. Поддержать дополнения в Swift 2.2 (OC-13365)
2. Научиться отображать те же сообщения типа warning/error, что и Xcode в окне редактора (по сути переиспользовав их)
3. Улучшить resolve в mixed-code (типы Swift из Objc и наоборот), что в прикладном плане должно улучшить навигацию, Find Usages, Rename, да и просто необходимо для корректной реализации рефакторингов в будущем.
4. Сделать часть рефакторингов — Introduce variable, Inline variable.
Плюсом нужно доработать часть задач по generics в Objective-C (в основном это кейзы вроде OC-13178) и performance в редакторе для Swift. То, о чем вы спрашивали — parameter placeholders — понятно, что необходимо сделать, но пока то, о чем я сказал выше, для нас более приоритетно. Сделать постараемся, но гарантировать здесь что-либо сложно — в силу сложности всех остальных задач.
1. На какой версии наблюдаете такое поведение?
2. Код на каком языке преобладает в проекте (ObjC/C++/Swift)?
3. В коде на каком языке воспроизводится?
Здесь хорошо бы нам иметь пример кода, для того, чтобы сказать — есть ли для него сейчас проблемы с completion или они исправлены. Суть в целом такова — мы активно работаем над парсером, если есть проблема в парсере — то это отражается на resolve и completion. Поэтому нужен пример кода, чтобы понять причину.
Отображение ошибок в коде до компиляции в редакторе (по тому же принципу, как сейчас это делает Xcode) сейчас в работе (OC-13024). Итерация тестирования уже прошла — возникла необходимость доработать, пока в процессе. После того как сделаем — описанные вами проблемы должны уйти.
Здесь опять же, хорошо бы пример конкретного проекта, но в общем — Xcode собирает проект через свой внутренний toolchain, который умеет параллелить компиляцию отдельных файлов с исходным кодом. Документации по нему нет, как его использовать — непонятно. Мы собираем проекты через xcodebuild, он параллелить сборку, насколько мне известно, не умеет. Поэтому время компиляции может быть дольше и пока непонятно, как можно такую задачу решить в разумные сроки.
Скоро появится — пока на подходе RC2 с исправлениями.
А у нас еще Smart Completion, и все «из коробки»
Ну ок, optimize imports все-таки только у нас )
А у нас сразу же можно увидеть в отдельном окне, как именно используется символ, который ищем и поиск можно стартовать шорткатом без пассов мышью. А это быстрее.
На самом деле нет, дальше я не буду сравнивать, контекст этого треда не верен. Дело не в том, чем мы лучше Xcode — ибо мы с ним не воюем. Дело в том, чем мы хороши для программирования под iOS. А это правда, тема для отдельной статьи.
А кстати, была бы такая статья интересна тут, на хабре?
Если вдруг еще раз сможете воспроизвести — то будет отлично, если напишете, как это получилось здесь
Например, при разработке под iOS вырабатывается стойкая привычка ко вполне определенному типу автодополнения кода — «набери начало того, что хочешь подставить». В случае какого-нибудь UITableViewCellStyleValue2 — придется набирать почти до конца, а у нас можно просто использовать camel humps и набрать UITVCSV2 (или в нижнем регистре, если в настройках отключить case-sensitive). То же самое с middle matching.
Импорты. Хочешь использовать конкретный класс — сначала пропиши импорт, всегда. Рутина? Да, рутина, но к ней привыкаешь. А у нас можно просто прописать название класса, увидеть подсказку и добавить нужный импорт по Alt+Enter. Так же привыкаешь к тому, что код в среднем или крупном проекте никогда не будет очищен от неиспользуемых импортов, потому что нет времени, есть более серьезные задачи итп. А главное — потому что если это нужно сделать, то придется это делать руками. В AppCode для этого достаточно выбрать одну операцию в меню — и все.
Поиск использований. Берем какой-нибудь ReactiveCocoa и пробуем найти в нем все использования какого-нибудь метода, например, map из RacStream (пример взят с потолка, просто проект под рукой). И хотим мы найти использования только метода, а не всех текстовых вхождений. У нас это можно сделать просто выделив map и нажав Alt+F7. И для этого не нужно никуда переходить.
Контроль версий. Не берем работу с VCS в командной строке — что делать, если хочется работать с ним через UI? Большинство знакомых iOS-программистов просто по дефолту ставят что-нибудь вроде SourceTree. А большинство знакомых Android-программистов, использующих Android Studio — не ставят, потому что встроенного в IDEA-based продукты функционала по контролю версий вполне достаточно. То же самое относится и к AppCode.
Debugger. У нас есть Inline view — и это в ряде случаев удобнее.
Рефакторинги. Здесь я пожалуй, все-таки просто вставлю скриншот
Это если коротко — более подробно я думаю можно только в отдельной статье. Или нескольких. И я думаю, мы их скоро напишем.
P.S. Случайно запостил не туда, это был ответ на предыдущий комментарий.