Такой редактор называется «операционная система»

GNU Emacs. /thread

ну это что-то типа emacs'а ты придумал. Попробуй...

Только сразу скажу, что придётся подрезать хотя-бы до C++ & Qt. И придётся тебе это всё переписывать с Qt4 на Qt5.

емакерам проще — лисп он и в африке лисп, как и консоль. А вот тебе будет тяжелее.

GNU Emacs. /thread

Уверен, что ТС не врубается в код на LISP'е и не умеет пользоваться консолью. Т.ч. это для него принципиально новый велосипед. Не спеши закрывать, наверняка найдутся ещё такие же как ТС.

А вдруг взлетит?

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

Собственно первый вопрос — какие проблемы призван решать такой подход и чем он лучше обычного редактора с плагинами вроде Eclipse?

Ага. В XEmacs, ЕМНИП, даже запилили что-то для обработки графики.

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

Главная ошибка здесь :)

http://1010.co.uk/gneve.html

Такой редактор называется «операционная система»

Была такая шутка у коллеги :) но мое поделие обещает быть намного более простым и, как следствие, способным к написанию и поддержке одним рылом

GNU Emacs. /thread

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

5:56:34

Иди проспись.

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

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

Это называется Eclipse Rich Client Platform. :-D
Дальше можно что угодно навернуть )

Чем ближе к концу твоего поста, тем больше вещества проглядывают ;)

И лисп. Принципиально другая философия, по сравнению с процедурными (классическими) ЯП.

Что может быть классическее лиспа?

верд или пейнт или корел или гимп
KISS

Хотя нет, не иди спать, посмеши нас и дальше.

ну это что-то типа emacs'а ты придумал.

Это что-то типа vim он придумал.

emulek, C++-программист — наркоман!

pihter, PHP-программист — наркоман!

Борще-архитектор, Java-программист — наркоман!

Откажись от наркотиков — выбери Lisp!

Попробуй...

Вне всякого сомнения попробую: хотя бы и из научного интересу :)

Только сразу скажу, что придётся подрезать хотя-бы до C++ & Qt. И придётся тебе это всё переписывать с Qt4 на Qt5.

что значит «подрезать» в этом контексте?

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

А вот тебе будет тяжелее.

Не думаю: разделяемые библиотеки - они тоже очень не разные.

Уверен, что ТС не врубается в код на LISP'е

Это ты правильно уверен

и не умеет пользоваться консолью

А вот тут ты не прав.

Т.ч. это для него принципиально новый велосипед

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

А вдруг взлетит?

Гарантирую. Но не гарантирую, что оно кому-то, кроме меня, станет нужно :)

Безопасность — не проблема. Код можно выполнять в песочнице, проверять подпись и т.д

Вот тут поподробней, что за тд? Какие есть методы? Как в песочнице? Есть кроссплатформенные (хотя бы вин/лин) решения? Лицензия?

Проблемы в устаревании кода, обратной совместимости.

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

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

Он будет накапливать готовые динамические библиотеки, в разы ускоряя среднее время открытия документа - раз. Так проще поддерживать гомогенную среду для разработки «плагинов» - два. Он должен содержать набор компиляторов, которые специфичны для платформы, - три. И может еще что-то, я только денек как придумал, толком еще не обтясал :)

Собственно первый вопрос — какие проблемы призван решать такой подход и чем он лучше обычного редактора с плагинами вроде Eclipse?

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

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

Главная ошибка здесь :)

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

Не, я к тому, что делать это на компилируемых ЯП - тлен.

Ну сильно он страшный :) Мой отец не осилит даже при желании

5:56:34

Иди проспись.

Присядь, анон. Во-первых, Деда Мороза - нет, а во-вторых, этот шарик - круглый и, когда в ДС 6 утра, в другом месте может быть уже и не 6 утра.

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

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

А почему именно динамическую библиотеку? Исполняемый файл был бы гораздо удобнее. Тогда не придется писать библиотеки обработки для уже существующих форматов. Так каждый графический файл будет содержать исходный код GIMP, каждая HTML-страница — исходный код Firefox, каждый текстовый документ — исходники Emacs или vim. А лучше включать в каждый файл несколько исходников разных обработчиков, чтобы пользователь смог выбрать на свой вкус.

Ух-ты. Походу ты браузер изобрел.

Ни разу не браузер. Браузер - это клиент HTTP. Я предлагаю на обсуждение концепцию редактора локального файла.

А вообще если заменить либу на (как уже сказали) песочницу с декларативным байткодом может что-то и получится

В таком случае теряется много ключевых преимуществ.

но целевое применение не ясно

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

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

Тут люди нормальную IDE под несколько ЯП запилить не могут, а ты замахнулся на все-про-все.

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

А знаешь, в этом есть толк.

Это называется Eclipse Rich Client Platform. :-D

Дальше можно что угодно навернуть )

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

Чем ближе к концу твоего поста, тем больше вещества проглядывают ;)

Аргументированнее, товарищ! От простого тухлого помидора мне пользы нет, а вот если ты к нему записку привяжешь - я благодарен буду! :)

Что может быть классическее лиспа?

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

KISS

Кисс я написал чтоб показать, чем оно лучше емакса.

Хотя нет, не иди спать, посмеши нас и дальше.

Да здравствуют конструктивные комментарии! Пердежу в лужи - нет!

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

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

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

ну это что-то типа emacs'а ты придумал.

Это что-то типа vim он придумал.

И тут понеслась! :) вы мне еще тулкит и ДЕ посоветуйте!

// и дистрибутив :) самый лучший

// // и лицензию :D

что значит «подрезать» в этом контексте?

ну то, что не взлетит, если будешь разбрасываться на несколько тулкитов и ЯП.

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

а минус в том, что задолбаешься писать обёртки, если захочешь засунуть скажем glibc в php. И получится в итоге нечто жуткое (php уже есть).

Не думаю: разделяемые библиотеки - они тоже очень не разные.

ну попробовать-то никто не мешает.

и не умеет пользоваться консолью

А вот тут ты не прав.

прав. Иначе ты-бы уже был емакером или вимером, и не страдал-бы х*ёй.

emulek, C++-программист — наркоман!

pihter, PHP-программист — наркоман!

Борще-архитектор, Java-программист — наркоман!

Откажись от наркотиков — выбери Lisp!

тогда отпустит? А то у меня, куда ни глань, на экране слово «наркоман!» :)

Вот тут поподробней, что за тд? Какие есть методы?

ну типа подпись есть GnuPG. Песочниц — увы, нет. Даже в линуксах везде по своему.

То есть документ гарантированно сработает в этом редакторе, не смотря на версии.

как он сработает на Qt5 без Qt4? Или ты весь кьют за собой будешь тащить? Типа хэлловорлд на 300Мб? Упрлс?

не знаю как там в емаксе, поправьте, если что

дык этот LISP уже лет 40 не меняется. Как раз именно потому. (тот лисп, что в емаксе)

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

у меня одни и те же либы и так УЖЕ загружены.

Не, я к тому, что делать это на компилируемых ЯП - тлен.

в этих словах ИМХО есть смысл. ТСу бы задуматься...

Какими известными механизмами сегодня можно

Ну тут действительно тебе eclipse в руки. Только интерфейс там наркоманы делали и ты больше времени потратишь на разработку плагина к этому бегемоту чем на игру.

Я вас умоляю, что может быть проще?

vagrant и не лохматить бабушку.

динамические библиотеки же все умеют писать

например я не умею DLL. Увы. Я даже по-русски «привет мир!» не нарисую, ибо уверен, что wchar_t — годный контейнер для юникода. А на пользователей говноосей мне насрано. Но эти 95% пользователей почему-то меня не любят...

Точнее ЛЮТО БЕШЕНО НЕНАВИДЯТ за моё УМВР.

Зачем мусорить кодом?

Есть простой способ показать файл тому, у кого нет редактора:

adduser ктотодругой && mail -s 'посмотри файл' 'ктотодругой@где.он.там' <<<ssh -X ктотодругой@$HOSTNAME мойредактор мойфайл

pihter, PHP-программист: Вот этой проблемы как раз нет в принципе: каждый документ несет в себе необходимый для его обработки код.
emulek, C++-прогрммист: как он сработает на Qt5 без Qt4?
pihter, PHP-программист: Я реквестирую способы борьбы с этим на фундаментальном уровне.
emulek, C++-прогрммист: в этих словах ИМХО есть смысл.
Lisp-программист: (пожимает плечами)

Жесть =) Только жаль, что в зависимостях патченный mplayer

Не, я к тому, что делать это на компилируемых ЯП - тлен.

Это почему? Из преимуществ: кроссплатформенность непревзойденная - раз, не привязанность к ЯП и, как следствие, больший круг заинтересованных разработчиков - два, проприетарщине - нет - три, скорость работы - три с половиной и еще может че-нить придумаю :)

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

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

Из преимуществ: кроссплатформенность непревзойденная - раз

Как раз таки нет.

не привязанность к ЯП

Как раз таки да

А почему именно динамическую библиотеку? Исполняемый файл был бы гораздо удобнее.

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

Тогда не придется писать библиотеки обработки для уже существующих форматов

Так не интересно :)

Так каждый графический файл будет содержать исходный код GIMP, каждая HTML-страница — исходный код Firefox, каждый текстовый документ — исходники Emacs или vim

Ну, если очень грубо говорить - да. Но, повторюсь, если правильно организовать работу с ресурсами (избежать включения иконок и тд в каждый файл) то код, сам по себе, не так уж и объемен, особенно, учитывая что я, by design, собираюсь по каждому файлу еще и gzip'ом проходиться. Ну сколько могут весить исходники гимпа? Ну 20 мб - потолок! Это совсем не убийственно, по современным меркам.

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

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

Во-первых, не такой уж он и большой (код-то), думаю там больше ресурсы, а это все можно будет продумать

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

А знаешь, в этом есть толк.

Не конструктивная критика :)

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

Да я не привязался... Просто пока думаю делать так, а ничего ловчее, никто не предложил. Предложи - я отвяжусь, я суда за тем и написал.

И зачем писать все с нуля?

А уже где-то реализовано что-то подобное?

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

Исходники редактора (той его части, что отвечает именно за файл игры) - минимально необходимы, для решения описанной мной задачи, а виртуальной машины и ОС - нет. Петросянство не в тему получилось, но, спасибо за критику.