мини IDE

[ev]

потихоньку пишу мини IDE (на Lazarus)
aналоги: Notepad++, Geany, Scite
основные отличия:

• работа с проектами
• улучшенная эргономичность интерфейса

остальное стандартно:

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

полно идей на развитие

хотелось бы обсудить нужный функционал, нюансы и т.д.
есть заинтересованные пользователи (или вдруг даже разработчики)?

[v-t-l]

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

[B4rr4cuda]

Поддержка скриптов планируется? Главная прелесть Scite именно в интеграции с скриптовым движком, благодаря которому функционал расширяется неимоверно.

[ev]

Оформить бы его в виде гуишной замены FP IDE, с теми же меню, диалогами, хоткеями, встроенным терминалом и цветами .

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

Поддержка скриптов планируется?

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

[B4rr4cuda]

интересно услышать, какие реальные задачи решаются подобными расширениями?

Ну, вот например - http://scite.ruteam.ru/category/skripty
Есть целые сборки скриптов, превращающие простой редактор в мощную IDE. С управлением проектом, прикруткой cvs, автоподстановкой кода, сниппетами, индексацией классов и процедур и тд.. и все на базе скриптов.

[ev]

Есть целые сборки скриптов, превращающие простой редактор в мощную IDE. С управлением проектом, прикруткой cvs, автоподстановкой кода, сниппетами, индексацией классов и процедур и тд.. и все на базе скриптов.

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

[B4rr4cuda]

Дело хозяйское, но, имхо, стоит предусмотреть возможность расширения заранее. Практика показывает, что всегда будет энное кол-во юзверей, которым текущих возможностей не будет хватать, а лезть в код проекта (если есть исходники, конечно) довольно грустное занятие, которое к тому же придется повторять в случае обновлений, при которых патч будет несовместим. Расширение (плагин или скрипт) позволяет расширять функционал извне. Учитывая, что основной категорией пользователей, как ни крути, будут подкованные в разработке люди, то данная возможность была бы весьма актуальна.
Хотя, возможно, я просто избалован софтом типа Scite, TC, Awesome, Ion3 и тд, для которых написание скриптов и плагинов для нужной тебе фичи (или поиск уже написанных) - это норма и "так и задумано".

Добавлено спустя 4 минуты 27 секунд:
И еще один аргумент: нельзя обьять необьятное) Наличие системы скриптов/плагинов, позволит расширять проект силами стороних разработчиков, которые будут делать функционал под свои цели, но работа которых будет идти на пользу проекту добавляя ему возможностей. Короля делает свита...

[alexey38]

Дело хозяйское, но, имхо, стоит предусмотреть возможность расширения заранее. Практика показывает, что всегда будет энное кол-во юзверей, которым текущих возможностей не будет хватать, а лезть в код проекта (если есть исходники, конечно) довольно грустное занятие, которое к тому же придется повторять в случае обновлений, при которых патч будет несовместим. Расширение (плагин или скрипт) позволяет расширять функционал извне. Учитывая, что основной категорией пользователей, как ни крути, будут подкованные в разработке люди, то данная возможность была бы весьма актуальна.
Хотя, возможно, я просто избалован софтом типа Scite, TC, Awesome, Ion3 и тд, для которых написание скриптов и плагинов для нужной тебе фичи (или поиск уже написанных) - это норма и "так и задумано".

Добавлено спустя 4 минуты 27 секунд:
И еще один аргумент: нельзя обьять необьятное) Наличие системы скриптов/плагинов, позволит расширять проект силами стороних разработчиков, которые будут делать функционал под свои цели, но работа которых будет идти на пользу проекту добавляя ему возможностей. Короля делает свита...

1. А смысл делать еще один Scite? Чем он конкретно Вас не устраивает?
2. Если и делать продукт, то со своей нишей. Лично мне нравиться продукты с нужным функционалом из коробки, т.к. нет времени изучать все подряд, у меня хватает неизученных вопросов еще на 100 лет в своей предметной области.
3. Если честно, то не понимаю зачем в OpenSource продуктах нужно привешивать еще и скрипты? Написать на родном паскале функционал скрипта будет быстрее, лучше и надежнее (при условии правильной архитектуры). А так как среда для программирования, то пересобрать проект не составляет труда. Скрипт нужен только если компилятор недоступен. А если не нравиться паскаль, как язык, а, например, нравится скриптовый язык, то сразу пишите приложение на нем, например, на Питоне. Зачем все это смешивание языков, которое кроем "гемора" и громоздкости ничего не дает полезного?

[ev]

стоит предусмотреть возможность расширения заранее

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

[WAYFARER]

Идея хорошая. Пользуюсь Geany, но он меня не вполне устраивает функционал.
Хотелось бы увидеть навигацию по коду и что то аналогичное codetools в Lazarus.

[ev]

Хотелось бы увидеть навигацию по коду

какую именно? по пунктам бы

[B4rr4cuda]

1. А смысл делать еще один Scite? Чем он конкретно Вас не устраивает?

"Больше велосипедов, хороших и разных" (с) Легкий дискомфорт присутствует..

2. Если и делать продукт, то со своей нишей. Лично мне нравиться продукты с нужным функционалом из коробки, т.к. нет времени изучать все подряд, у меня хватает неизученных вопросов еще на 100 лет в своей предметной области.

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

3. Если честно, то не понимаю зачем в OpenSource продуктах нужно привешивать еще и скрипты? Написать на родном паскале функционал скрипта будет быстрее, лучше и надежнее (при условии правильной архитектуры). А так как среда для программирования, то пересобрать проект не составляет труда. Скрипт нужен только если компилятор недоступен. А если не нравиться паскаль, как язык, а, например, нравится скриптовый язык, то сразу пишите приложение на нем, например, на Питоне. Зачем все это смешивание языков, которое кроем "гемора" и громоздкости ничего не дает полезного?

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

именно поэтому я пока не особо рассматривал этот вопрос - оставил на потом

Логично)

[alexey38]

3. Если честно, то не понимаю зачем в OpenSource продуктах нужно привешивать еще и скрипты? Написать на родном паскале функционал скрипта будет быстрее, лучше и надежнее (при условии правильной архитектуры). А так как среда для программирования, то пересобрать проект не составляет труда. Скрипт нужен только если компилятор недоступен. А если не нравиться паскаль, как язык, а, например, нравится скриптовый язык, то сразу пишите приложение на нем, например, на Питоне. Зачем все это смешивание языков, которое кроем "гемора" и громоздкости ничего не дает полезного?

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

Думаю, что всем понятно, что сам по себе скриптовый движок, прикрученный к паскалевской программе, ничего не будет делать, т.е. скрипт будет выполняться, но это ни на что не будет влиять.
Соответственно, чтобы был смысл, то на уровне основной программы разрабатывается некий внутренний API с функционалом основной программы, который привязывается к скриптам. Фактически однозначно определяется то, что может сделать скрипт по отношению к основной программе. При этом API обязательно документирован, иначе никто не догадается, как его использовать в скрипте.

Так вот, что имеем: код основной программы (OpenSource), API с документацией, известно место, где можно и нужно вызывать скрипт для работы с API.
Вопрос: чем легче писать код на скрипте, и чем сложнее его писать на паскале, когда известен API, место вызова и т.п.?

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

[ev]

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

у скрипта есть 2 важных преимущества

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

остальное - только минусы
особенно скорость (а самые вкусности обычно требуют много обработки)

[alexey38]

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

у скрипта есть 2 важных преимущества

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

остальное - только минусы
особенно скорость (а самые вкусности обычно требуют много обработки)

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

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