Текстовый редактор с удобной системой расширений

Там его и никогда не было, откуда эти байки? Опять drBatty напел?

Да нет, один анонимус заливал о наколенной сборке файлового менеджера из емакса, ls, cp, mv и т. д.

Да нет, один анонимус заливал о наколенной сборке файлового менеджера из емакса, ls, cp, mv и т. д.

Так это и есть unix way - это конструктор из которого можно быстро собрать все, что тебе надо. Хоть плеер, хоть файловый менеджер, что угодно.

Так это и есть unix way - это конструктор из которого можно быстро собрать все, что тебе надо. Хоть плеер, хоть файловый менеджер, что угодно.

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

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

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

Плеер - это одна совокупность программ, файловый менеджер - другая.

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

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

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

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

Firefox открывает много сайтов в одном процессе, и никто же не говорит, что один из процессов ЛОРа косвенно управляет базой данных Хабра. Опять же, можешь открывать каждый сайт в отдельном процессе.

ааа, то есть вим его не прёт
хм, ок

Приложение у меня и так есть (тот же плеер). Но мне хотелось бы работать с этим приложением через удобный интерфейс.

Теоретически можно, но на практике, brain fuck ничем не хуже.

Ну как раз практика и подтверждает, что брейнфак на порядки хуже.

как и любой ОС — предоставить стандартный API ко всем железкам этого локалхоста. Ну и все основные функции в виде glibc и других либ. Ну и кроме того возможность запускать приложения тоже нужна.

Но под линукс есть тетрис. Тетрис не помогает предоставлять апи к железкам. Запускать приложения он тоже не помогает. Как быть?

ну я как-то обхожусь без emacs'а?

Так же как многие обходятся без машин, например.

проблема в том, что задача закачки — неотъемлемая подзадача просмотра

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

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

Я имею ввиду с чего вдруг ты взял что они не осилили? Потому что это неправда, вполне осилили. Собственно, тут и осиливать-то нечего было.

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

Тогда какие претензии к емаксу? Он ведь именно это и делает. Работает с текстом. И нету ни одного плагина для емакс, который бы делал нечто другое.

Так в емакс плеер никто не сует. Он там и есть отдельно.

То есть ты балабол и альтернатив не привел.

в vim|Emacs можно гулять по коду программы? перескаивая на реализацию\определение функций, классов, и прочих частей программы? Автодополнение строится в зависимости от контекста? Есть поиск по всему проекту?

Конечно.

потому что никаких других задач, кроме описанных, в области прослушивания музыки емакс и НЕ ВЫПОЛНЯЕТ.

Плеер не в состоянии предоставить удобный способ редактирования этих файлов, например.

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

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

Да почему же? Можешь точно так же управлять и отбивать команды в консоли руками.

Ну ты не смотришь, а я смотрю. Значит тебе этот функционал не нужен, а мне нужен. Какие проблемы-то?

Ну охуеть теперь. То есть если у меня поддержка хоткеев в терминале есть, то это гуй.

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

Теперь и любые оконные менеджеры - это тоже плохо. Все охуеннее и охуенне.

Из этого интерпретатора елиспа можно вырезать текстовый редактор, так, чтобы в нём работал только файловый менеджер?

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

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

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

Касательно qt и gtk - их необходимость для графических приложений очевидна, в отличии от необходимости текстового редактора для файлового менеджера.

Файловому менеджеру не нужен интерфейс?

Да нет, это просто вопрос банального удобства.

Мы не о удобстве спорим.

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

То есть каждое приложение надо запускать в собственной оконном менеджере? Не жирно будет?

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

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

Ты не правильно ставишь вопрос. Правильный вопрос «Можно ли из кед вырезать kate, так чтобы был только dolphin?»

То есть каждое приложение надо запускать в собственной оконном менеджере? Не жирно будет?

Ты что, для каждой программы отдельный оконный менеджер запускаешь? Отдельного окна вполне достаточно.

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

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

Нет, аналог твоему вопросу будет «можно ли из емакса вырезать плагин Х, чтобы остался только Y», и ответ очевидно «да» (ну если только создатели самого плагина не сделали явную зависимость).

Емакс предоставляет свой уникальный подход к интерфейсу - вместо окон текстовые буферы. Которые можно просматривать, редактировать и т.д.

Если ты вырежешь редактор - то как же ты будешь просматривать, редактировать и т.д. эти буферы?

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

У каждого будет свой буфер. Эти буферы можно отображать в разных окнах. Данными они не обмениваются.

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

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

То есть если текстовый редактор позволяет написать такой плагин - то это уже не текстовый редактор?

То есть если текстовый редактор позволяет написать такой плагин - то это уже не текстовый редактор?

Нет. Когда ты в тексовый редактор воткнёшь плагин для проигрывания музыки, получится комбайн.

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

Получится плеер. mplayer + плагин + emacs = плеер.

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

Если ты вырежешь редактор - то как же ты будешь просматривать, редактировать и т.д. эти буферы?

Тоесть емакс по сути можно рассматривать как интерпретатор елиспа с намертво замурованном в нём текстовым редактором?

Получится плеер. mplayer + плагин + emacs = плеер.

Хорошо, получится плеер.

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

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

Так ты опять заявляешь, что плеер = emacs. плеер = mplayer + плагин + emacs. плеер != emacs.

Тебе что нужно? Разные окна? Разные процессы? Никаких проблем. Можешь использовать плеер и файловый менеджер в разных окнах или в разных процессах, на твой вкус.

Но ведь в емаксе нету плагинов для проигрывания музыки.

Так ты опять заявляешь, что плеер = emacs.

Нет.

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

Тоесть емакс по сути можно рассматривать как интерпретатор елиспа с намертво замурованном в нём текстовым редактором?

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

Если все трое торчат у тебя в одном в одном окне и в одном процессе - это будет один большой комбайн.

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

Но ведь в емаксе нету плагинов для проигрывания музыки.

Ну и отлично, значит собрать комбайн у тебя не получится.

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

Пока они находятся в разных окнах на уровне вм и в разных процессах никаких претензий нет.

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

Пока они находятся в разных окнах на уровне вм и в разных процессах никаких претензий нет.

Никакой вм тут нет, откуда ты ее взял?

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

Если емакс не обрабатывает текст для именно этого приложения и выдачу именно этого приложения как-то по особенному, не так, как любые другие текст и выдачу, то всё нормально.

Никакой вм тут нет, откуда ты ее взял?
Если все трое торчат у тебя в одном в одном окне ... - это будет один большой комбайн.