ни один пример полезного применения макросов мне пока что не смогли привести

Делал биндинг C++ => .Net с помощью вимовых макросов, на 30-40 обёрточных классов ушло около одного дня с заготовкой этих самых макросов, плюс было не так скучно.

В общем и целом от редактора нужно - чтобы ручки и глазки не болели когда в нём набираешь, а самое главное читаешь кодик. Последнее время, я сделал себе vim-подобных биндингов в раскладке клавы и мне по-большому счёту базовый набор текста почти везде удобно, навигация ток недотягивает.

Что вам больше всего нужно в обычном редакторе/IDE?

Постоянно это говорю: поддержка современных средств для работы с исходным кодом.

Три-ситтер(подсветка синтаксиса), ЛСП(автокомплит, анализ кода, переход к определению), буферы, (нормальная) поддержка плагинов, простая работа с отступами, это то, что должно поддерживаться в редакторе.

Остальное — расширения.

А, ещё, редактор/иде не должно фокусироваться на одном ЯП.

Делал биндинг C++ => .Net с помощью вимовых макросов, на 30-40 обёрточных классов ушло около одного дня с заготовкой этих самых макросов, плюс было не так скучно

Ну и ты можешь привести пример драгоценных макросов, без которых нельзя прожить, решая эту задачу?

Что вам больше всего нужно в обычном редакторе

Мощные инструменты навигации по тексту:

• поиск в файле
• поиск в каталоге
• переход к слову
• переход к символу
• манипуляция выделением
• etc.

IDE?

Всё вышесказанное + мощные инструменты навигации по коду:

• поиск в scope
• поиск в translation unit
• поиск в проекте
• переход к объявлению/определению/использованию
• минимальная верификация кода на лету

Синтаксис, скобки, отступы и прочую фигню сейчас только виндовый блокнот не поддерживает.

Мне нужно:

1. Навигация по коду

• переходы интерфейс<->реализации;

• поиск всех использований класса/метода/переменных;

• структура текущего файла.

2. Рефакторинг/генерация кода

• Автопереименовывание переменных/классов везде где они упоминаются;

• Генерация бойлерплейта – геттеры/конструкторы/hashCode;

• Операции со строками: camelCase -> snake_case и т.п.

• Присваивание значения выражения в переменную/параметр/поле.

3. Нормальный интерфейс для просмотра диффов и слияния изменений.

Без дебага, сборки проекта, интеграции со всякой хурмой можно прожить.

Автодополнение само собой разумеется в наше время.

Три-ситтер(подсветка синтаксиса), ЛСП(автокомплит, анализ кода, переход к определению)

Да, правда, tree-sitter является далеко не единственным инструментом для подсветки, анализирующим семантику кода.

буферы

Что это?

(нормальная) поддержка плагинов

Ах, мечты-мечты.

Плюсую эту сосиску.

Мощные инструменты навигации по тексту (поиск в файле, поиск в каталоге, переход к слову, переход к символу, etc)
Всё вышесказанное + мощные инструменты навигации по коду (поиск в scope, поиск в translation unit, поиск в проекте, переход к объявлению/определению/использованию) + минимальная верификация кода на лету

Ты IntelliJ IDEA описал. Почему-то в списке твоих фич нет собственно самого редактирования кода.

Ты IntelliJ IDEA описал

Ей и пользуюсь (точнее, деривативами — CLion, PyCharm).

Почему-то

Потому что я не предполагал, что ТС будет разводить тупняк на ровном месте. Извини, ошибся.

Да, правда, tree-sitter является далеко не единственным инструментом для подсветки, анализирующим семантику кода.

Он просто сейчас неплохо развивается. Всё жду, когда вскод будет его поддерживать.

Что это?

https://vim.fandom.com/wiki/Buffers

Ах, мечты-мечты.

Мечты мечтами, но относительно нормальная поддержка плагинов есть в вскоде и неовиме.

самая обожаемая фича в VS, которую не может повторить никто — это возможность выстроить ручными или полуручными переходами иерархию связанного кода в одном окне прямо в коде

Это речь про IDE VS или VS Code? Можешь скрин кинуть как это выглядит.

структура текущего файла

Этот пункт редко кто вспоминает, и почему-то я им ни разу не пользовался, хотя тот же VS Code или Qt Creator структуру текущего файла показывают.

Генерация бойлерплейта – геттеры/конструкторы/hashCode

Ты жавист? Никогда не мог понять этого инструмента.

Операции со строками: camelCase -> snake_case и т.п
Присваивание значения выражения в переменную/параметр/поле.

А это зачем?

Нормальный интерфейс для просмотра диффов и слияния изменений

Да, это полезная штука, особенно если позволяет смотреть разницу по трем файлам, как это нужно при решении конфликтов, чего не умеет делать гитовый плагин для VS Code (или во что там этот просмотрщик встроен). Другое дело, что для генерации отличий прежде всего нужна интеграция с VCS, что уже не так-то просто, и по итогу есть смысл использовать внешний инструмент, как это делает, например, TortoiseSVN, который можно научить применять любой просмотрщик дифов. То, что у git стабильно неюзабельный пользовательский интерфейс, не значит, что все редакторы должны пытаться этот недостаток исправить.

Чтобы сделать по-настоящему продвинутый инструмент слияния, нужно как бы открывать три разных проекта (или даже четыре), позволяя полноценно смотреть семантику каждого из них в отдельности. Я не исключаю, что это сделать можно, и даже кто-то уже что-то подобное сделал, но это нужно очень тесно интегрироваться с VCS, тратить кучу ресурсов компа на запрос и парсинг всех этих проектов.

Без дебага, сборки проекта, интеграции со всякой хурмой можно прожить

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

Семантические подсветка и редактирование.

Что это?

https://vim.fandom.com/wiki/Buffers

И зачем это? Создавать текстовые файлы в пустоте? Ну да, Notepad++ и VS Code умеют это делать, причем, автоматически сохраняют их в свое хранилище, потому содержимое несохраненных файлов не теряется при перезапуске.

Это речь про IDE VS или VS Code? Можешь скрин кинуть как это выглядит

И Visual Studio, и VS Code умеют это делать:

https://i.ytimg.com/vi/LjoXtkFpkAc/maxresdefault.jpg

подсветка синтаксиса, пар скобок

На лиспе что ли программируешь?

На лиспе что ли программируешь?

Почти — JS.

Заплутать в скобках легче где угодно, кроме лиспа.

Заплутать в скобках легче где угодно, кроме лиспа

А самые надежные и безопасные программы, как мы знаем, написаны на ассемблере.

Этот пункт редко кто вспоминает, и почему-то я им ни разу не пользовался, хотя тот же VS Code или Qt Creator структуру текущего файла показывают.

Удобно сразу видеть, что в классе есть: какие методы/поля, какие сигнатуры у методов. Прыгнуть к интересующему методу тоже быстро можно.

Ты жавист? Никогда не мог понять этого инструмента.

Да.

А это зачем?

Присваивание это очень удобно. Например, есть у тебя сервис и в нём метод fileService.getRecentFiles(). Ты пишешь вызов этой функции, потом нажимаешь C-A-v и IDE присваивает результат вызова локальной переменной: List<File> recentFiles = fileService.getRecentFiles();, а можно нажать C-A-f и оно присвоится полю класса. Тип и название переменной подставляется автоматом.

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

Ну все-таки меня вымораживает, когда нельзя просто посмотреть ошибки сборки в редакторе

А меня бесит, что оно всё красным чиркает во время редактирования. Ну не закрыл я ещё эту сраную скобку, что ж теперь весь файл красным разукрашивать. Я допишу и нажму хоткей Recompile Current File.

Ну там применялся определённый ноухау для managed c++ и ряд обёрточного кода отличался в зависимости от различных факторов(нужно было значительно быстрее чем pInvoke, т.к. накладные расходы от него были сопоставимы местами с самими вызовами), я делал примерно так:

100@d удаляет все комментарии и вайтспейсы из хидера, потом смотрел на глаз количество методов в каждой секции и делал 5@s в начале первого метода, на операторах делал 5@o на конструкторах 5@c и т.п., плюс было записано пару макросов для поиска различных блоков, деталей уже не понмю, но в вручную один файл так проходился за час примерно если аккуратно (учитывая вложенные файлы, неймспейсы и разные обёртки для некоторых разных по своей сути методов). Перед этим я конечно же выгрузил файлы для конвертации в индекс по которому можно было ходить через gf и сделал пару макросов типа вернуться в индекс, и прыгнуть на следующий файл.

Наверное, если сесть и делать просто руками, то первые 20 классов было-бы сопоставимо по времени сделать втупую, но блин, это же скучно… да и классов было поболее, точно не считал, но наверное 50-70.

Удобно сразу видеть, что в классе есть: какие методы/поля, какие сигнатуры у методов. Прыгнуть к интересующему методу тоже быстро можно

Каким образом структура текущего файла тебе поможет найти «интересующий метод»? Или ты из тех, кто каждую строчку кода оформляет в отдельный метод? Потому что я в последнее время на JS пишу так, что внутри одного файла вызовы функций встречаются довольно редко, чаще всего это вложенная асинхронщина, которая банально не имеет имени.

Ты жавист? Никогда не мог понять этого инструмента.

Да

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

Ты пишешь вызов этой функции, потом нажимаешь C-A-v и IDE присваивает результат вызова локальной переменной: List<File> recentFiles = fileService.getRecentFiles();, а можно нажать C-A-f и оно присвоится полю класса. Тип и название переменной подставляется автоматом

var recentFiles = fileService.getRecentFiles()

Опять же, только начиная с десятки.

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

Мне кажется, что у тебя какая-то очень специфичная специфика, потому что перекраивание связанных идентификаторов в разных местах проекта — это очень губительный для поддержки ход. Или у тебя IDE при поиске snake_case, умеет по этой же строке находить также snake-case, SnakeCase, и snakeCase? Сомневаюсь.

Я первый раз такое порно увидел во Vue.js, который, как я говорил, написан совершенно бездарным архитектором. Там один и тот же идентификатор может быть записан в cebab-case и в camelCase, а иногда и в PascalCase. Просто потому что. Потому ковыряться в этой срани весьма проблематично, а вопросы чтения и поддержки своего софта Эвана не волнует, он предпочитает софт только писать и потом переходить в другой проект.

А меня бесит, что оно всё красным чиркает во время редактирования

Ой, линты — это дичь, я их отключаю совсем, потому что бесит. Qt Creator еще при незакрытых скобках начинает весь код разукрашивать фиолетовым — это вообще ад.

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

100@d удаляет все комментарии и вайтспейсы из хидера

Изич делается заменой по регулярке.

потом смотрел на глаз количество методов в каждой секции и делал 5@s в начале первого метода, на операторах делал 5@o на конструкторах 5@c

Я не знаю, что оно делает, но подозреваю, что примерно то же, что и замена по регулярке.

Каким образом структура текущего файла тебе поможет найти «интересующий метод»?

Ну смотри, я открываю какой-нибудь API класс впервые. Мне нужно, скажем, найти подходящий метод для обработки коллекции элементов. Со структурой я увижу, что в классе есть несколько методов для этого и выберу подходящий, не прокручивая код. Прыгну к нему, убедюсь, что реализация делает то, что мне нужно и пойду его использовать. Мне такой способ помогает разобраться в легаси-говне, которое бывает очень не логичным.

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

Да, но с кодовой базой такого размера, как у нас, выкидывание будет идти бесконечно.

у тебя какая-то очень специфичная специфика

Да, я, бывает, переписываю на яву прототипы на питоне. Берешь название на питоне, копируешь, переделываешь в ява стиль и сидишь довольный.

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

Ну приличная IDE умеет парсить билд-лог в своем терминале и прыгать сама на место ошибки. Я так мавен дергаю в консоли и потом прыгаю из лога в IDE.

Так вроде противники лиспа говорят, что основная беда в нём это скобки.

Изич делается заменой по регулярке

Да, но я вспомнил ещё нюанс(хотя оно тоже регулярками делается частично, построчно в зависимости от типа комментария) - нужно было ещё сконвертировать doxygen в .Net формат доки не помню как называется.

Я не знаю, что оно делает, но подозреваю, что примерно то же, что и замена по регулярке.

Не, это я просто упростил немного, по факту нужно было ведь ещё параметры конвертировать, аттрибуты всякие проставлять. В общем поверь на слово - если бы оно просто решалось бы регулярками, оно бы так и решалось. Частично - регулярками оно и решалось, но их применение было как раз включено в макросы. Т.е. один макрос одну или несколько регулярок + ряд телодвижений которые не получается ей выразить делает, второй другую и всё в зависимости от контекста(под каждый контекст свой макрос). Такой себе - второй набор кейбиндингов который не затирает основной и заточен под конкретную задачу и при этом супер быстро делается на коленке.

Просто попробуй написать одну или несколько регулярок и потом последовательно их в нужном порядке применить(в своём любимом текстовом редакторе без макросов) чтобы сконвертировать что-то в духе:

uint64_t Hell::welcome_to_hell(const std::string& name) const {
    std::cout << "Welcome:" << name << std::endl;
    return 666u;
}

в

[cpubound=false]
System::Uint64 Hell::welcome(System::String^ name) const {
    return _this->welcome_to_hell(convert(name));
}

Потом сравни насколько быстрее это переписать руками, чем переключаться между файлом с кодом и с регулярками и искать каждый раз нужную для конкретной ситуации когда вариантов таких функций - много. А с макросами это делается в пару комбинаций уровня @a, @s, @c, 1@p (примерно столько раз я бы нажал для этой функи наверное).

Ну смотри, я открываю какой-нибудь API класс впервые. Мне нужно, скажем, найти подходящий метод для обработки коллекции элементов. Со структурой я увижу, что в классе есть несколько методов для этого и выберу подходящий, не прокручивая код. Прыгну к нему, убедюсь, что реализация делает то, что мне нужно и пойду его использовать. Мне такой способ помогает разобраться в легаси-говне, которое бывает очень не логичным

Да, легаси-говно, нелогичное, засчитывается. Просто, все-таки тред был про текстовые редакторы общего назначения, а не про инструменты ковыряния в легаси-говне. Специфика твоего ответа как бы намекала на легаси-говно, но я все-таки уточнил.

Да, но с кодовой базой такого размера, как у нас, выкидывание будет идти бесконечно

Ага, то есть и тут тоже легаси.

Да, я, бывает, переписываю на яву прототипы на питоне. Берешь название на питоне, копируешь, переделываешь в ява стиль и сидишь довольный

А это вообще порно какое-то.

Оффтопик, но

Когда в следующий раз будешь говорить по мобилке или платить карточкой - имей ввиду что оно так быстренько и чётенько всё работает, т.к. обрабатывается легаси говном а хипстота уровня «всё переписать на новом модном фреймворке за пару месяцев изиж и будет круче» там даже полы мыть не допускается ;)

Когда в следующий раз будешь говорить по мобилке или платить карточкой - имей ввиду что оно так быстренько и чётенько всё работает

Ошибка заключается в «оно так быстренько и чётенько всё работает» — потому что на самом деле нет. Сейчас опсосы массово переходят на безлимитные тарифы, потому биллинг чудовищно неэффективен. А при оплате карточкой возникают такие забавные ситуации, когда ты заплатил ровно 0 рублей, но банк считает, что ты потратил весь свой лимит, потому что лимиты резервирования пересчитываются раз в день и их не колышет, что ты так и не смог провести платеж.

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

Обычно - старая система таки работает стабильно, потому что, а не вопреки тому, что она старая :)

Шоп девки сами прыгали ко мне в койку, когда видят мой редактор, конечно же!

VSCode не умеет в перекодирование текста как Notepad++ (Notepadqq)

VSCode не умеет в перекодирование текста как Notepad++ (Notepadqq)

Вообще-то есть. Может не настолько мощно, как в Notepad++, но есть — в нижнем правом углу при нажатии на кодировку. То же меню можно открыть из палитры команд (Change File Encoding), и этой команде можно назначить хоткей.

Замечательно, будем знать.

Скажу про консольные редакторы.

Главное что требуется от редактора - это понятность интерфейса и возможность выполнить редкие действия без чтения мануала. А это значит наличие меню, ничего лучшего человечество пока не придумало. Плюс основные действия должны выполняться устоявшимися в современном десктопном окружении способом: курсор гоняться стрелочками, выделение через Shift+стрелки, кнопки Home/End двигают курсор в начало/конец строки, кнопка Esc служит для закрытия диалоговых окон и для выхода из редактора, копипаст кнопками Ctrl+C/V и.т.д. Еще от редактора ожидаешь работы с вертикальными блоками и мультикурсором. Vim и Emacs к этим требованиям совершенно не подходят.

Во времена Dos был такой консольный редактор - MultiEdit (вроде бы дорос до 8-й версии). Сейчас его вообще невозможно найти в интернете, он исчез с концами. Это был обычный консольный редактор с менюшкой, вызываемой по F10, с набором горячих клавиш, актуальных на момент отсутствия Windows. Он был лучше встроенного редактора в DosNavigator потому, что использовал подгрузку в память и позволял редактировать текстовые файлы размером 2Gb на компьютере с 4Мб ОЗУ. Редактор DosNavigator-а так не умел.

Сейчас до сих пор таковой редактор под Linux еще не написан. Редактор Micro мог быть хорошим кандидатом, в нем авторы хотя бы поддержали попервачу стандартные сочетания клавиш. Но в нем нет меню, и он скатывается в какую-то дикую смесь Nano и Vim-а. И в нем вечно отваливается буфер обмена (вот просто не копируется текст и все. Надо закрывать редактор и открывать заново), а у авторов проблема не воспроизводится.

Еще хороший кандидат - редактор из Far Manager (обсуждение), но он под винду, а в консольном бэкэнде практически неюзабелен.

Главное что требуется от редактора - это понятность интерфейса и возможность выполнить редкие действия без чтения мануала

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

Еще от редактора ожидаешь работы с вертикальными блоками и мультикурсором

Не помню, когда бы мне захотелось мультикурсора.

Во времена Dos был такой консольный редактор - MultiEdit (вроде бы дорос до 8-й версии). Сейчас его вообще невозможно найти в интернете, он исчез с концами. Это был обычный консольный редактор с менюшкой, вызываемой по F10, с набором горячих клавиш, актуальных на момент отсутствия Windows

Он умел в поиск инкрементальный поиск по названию команд как VS Code? Потому что просто клацать стрелками в бесконечном меню — это такое себе удовольствие.

ни один пример полезного применения макросов мне пока что не смогли привести

https://vimeo.com/146871249 же.

устоявшимися в современном десктопном окружении способом

Вы же осознаёте, что они ни фига не интуитивны и им Вы тоже когда-то обучились?

ни один пример полезного применения макросов мне пока что не смогли привести

https://vimeo.com/146871249 же

Дичь какая-то, зачем я должен хотеть это сделать?

Затем же, зачем в принципе хардкодят какие-то предрасчитанные константы: ради производительности?

Не во многих языках в принципе есть препроцессинг.

Затем же, зачем в принципе хардкодят какие-то предрасчитанные константы: ради производительности?
Не во многих языках в принципе есть препроцессинг

Дело не в хардкоде констант, дело в хардкоде бессмысленного жмыха из нулей.

Раз он там есть, то очевидно, что нужен был?

Разбирайтесь, Мы спустя столько лет уже не помним :P

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

Ты про VSCode? Как это выглядит? Есть скриншоты? Или хотяб комбинации клавиш скажи чтоб я потыкал.

> Главное что требуется от редактора - это понятность интерфейса и возможность выполнить редкие действия без чтения мануала
Таких не существует. В консольные времена даже простая встроенная документация была непозволительной роскошью, потому доки были на бумаге.

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

Предстваления о временах текстмода и DOS у тебя явно искаженные.

Он умел в поиск инкрементальный поиск по названию команд как VS Code?

Ты совсем неадекват? Этот редактор использовался четверть века назад.

> устоявшимися в современном десктопном окружении способом
Вы же осознаёте, что они ни фига не интуитивны и им Вы тоже когда-то обучились?

Не только я обучился, но и миллиарды пользователей на земле. Поэтому с «устоявшимися в современном десктопном окружении способами» приходится считаться. А не так как в Vi - в DE мы работаем так, а в Vi для тех же действий мы делаем эдак.

возможность выстроить ручными или полуручными переходами иерархию связанного кода в одном окне прямо в коде

А можно поподробнее что за фича такая?

Просто, все-таки тред был про текстовые редакторы общего назначения, а не про инструменты ковыряния в легаси-говне

Но ведь любой проект, чуть больше хеловорда на 90% состоит из легаси-говна.

Мои пожелания к редактору текста:

1. Возможность работы с файлами любого размера, строками любого размера (например файл размером в терабайт со строкой длиной в терабайт) с минимальным потреблением памяти.

2. Желателен встроенный hex-редактор.

3. Абсолютно минимальный функционал по поддержке типовых ЯП, как-то:

3.1. Подсветка ключевых слов популярных ЯП.

3.2. Поддержка отступов (не обязательно привязанных к синтаксису).

4. Автоматическое сохранение изменений при выходе из программы без дополнительных вопросов (не в оригинальные файлы, а во «временные» файлы). Т.е. я могу открыть редактор, открыть в нём 10 файлов, ещё 10 новых создать, что-то изменить и закрыть редактор без каких-либо вопросов. При следующем открытии я ожидаю всё увидеть ровно в том же состоянии, в котором оно было перед закрытием.

5. Работа с read-only файлами в режиме логов: следование за концом файла, подсветка и фильтрация по регэкспам.

6. Ну в целом весь базовый функционал, который ожидаешь от редактора - отмена/повтор действий, поиск/замена, в том числе с регэкспами и тд.

Пока такого редактора я не нашёл, если что.

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

Куча расширений, от браузера до кофеварки!

Ты про VSCode? Как это выглядит? Есть скриншоты? Или хотяб комбинации клавиш скажи чтоб я потыкал

Alt+F12 или контекстное меню->Peek. Естественно, должны стоять плагины для языка.