LINUX.ORG.RU

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

 not emacs, not vim


0

1

Здравствуйте, хочу найти текстовый редактор-конструктор, который будет удобно расширять и модернизировать (посредством написания расширений, например на Python). Но не vim или emacs, а со стандартным поведением редактора: один режим, стандартные сочетания клавиш ctrl+v, ctrl+c etc.

Перемещено beastie из development

Ответ на: комментарий от drBatty

ты всё делаешь правильно

Следующий пример:

1. Я открываю в Emacs список песен.
2. Песни отображаются и подсвечиваются.
3. Я перехожу к нужной мне песне.
4. Я нажимаю определенное сочетание.
5. Песня проигрывается.

Что неправильно?

anonymous
()
Ответ на: комментарий от anonymous

Что неправильно?

вот один из моих любимых принципов:

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

1. Простота. Есть плеер, есть песни. Имена песен должны быть в плеере. Редактор — лишняя сущность, усложняет систему. Простота реализации несколько важнее простоты интерфейса, который даёт emacs, к тому-же, никто не запрещает делать встроенный интерфейс плеера таким-же простым (а значит и удобным).

2. Правильность. Правило тут в том, что имя трека приколочено гвоздями к самому треку. Это правило внешнее, и задаётся ТЗ. Нарушая это правило мы получаем проблемы с синхронизацией(текст в редакторе может не совпадать с текстом в плеере)

3. логичность. Нелогичность emacs'а заметна невооружённым взглядом. Даже самое элементарное действие — выход, и то требует лишних телодвижений. Мало того, редактор предназначен для редактирования, а функция просмотра/навигации является вспомогательной. Для плеера наоборот. Функций «играть/перемотать/и т.д.» в редакторе в принципе нет

4. Полнота — основные функции плеера отсутствуют в редакторе, ибо не имеют там смысла. Но это ещё не всё, если стоп/плей можно накостылять, то «поставить рейтинг альбому 8 и сохранить в СУБД» уже скорее всего нельзя. Даже если в оригинальном интерфейсе какого-то аморока и можно. Но ты можешь конечно сказать, что «полнота не нужна». Другие фичи ты не сможешь реализовать по другим причинам, например в текстовом виде очевидно нельзя показать обложку альбома.

drBatty ★★
()
Ответ на: комментарий от drBatty

1. Простота. Есть компилятор, есть функции. Имена функций должны быть в компиляторе. Редактор — лишняя сущность, усложняет систему. Простота реализации несколько важнее простоты интерфейса, который даёт vim, к тому-же, никто не запрещает делать встроенный интерфейс компилятора таким-же простым (а значит и удобным).

2. Правильность. Правило тут в том, что имя функции приколочено гвоздями к самой функции. Это правило внешнее, и задаётся ТЗ. Нарушая это правило мы получаем проблемы с синхронизацией(текст в редакторе может не совпадать с текстом в компиляторе)

3. логичность. Нелогичность vim'а заметна невооружённым взглядом. Даже самое элементарное действие — выход, и то требует лишних телодвижений. Мало того, редактор предназначен для редактирования, а функция просмотра/навигации является вспомогательной. Для компилятора наоборот. Функций «компилировать/перейти к функции/и т.д.» в редакторе в принципе нет

4. Полнота — основные функции компилятора отсутствуют в редакторе, ибо не имеют там смысла. Но это ещё не всё, если компиляцию/переход можно накостылять, то «автоматом сделать коммит в DVCS» уже скорее всего нельзя. Даже если в оригинальном интерфейсе какого-то Eclipse и можно. Но ты можешь конечно сказать, что «полнота не нужна». Другие фичи ты не сможешь реализовать по другим причинам, например в текстовом виде очевидно нельзя показать машинный код.

Следовательно, редактировать код в vim'е неправильно.

anonymous
()
Ответ на: комментарий от anonymous

Что неправильно?

Подстраивание сверху (см. embedding) - в итоге комбайн. Здесь нахрен весь редактор не нужен, достаточно view-mode (ну может + «linewise» killring).

Гипотетический пример «extending»: есть приложение с текстовым вводом, буффер делегируется (ну пусть передается текст как rope или даже ast и события ввода) например демону, отвечающему за org-mode - он перехватывает C-c .., остальное делегируется отдельному демону редактирования C-a / C-e. Оба используют общую библиотеку для редактирования текста.

anonymous
()
Ответ на: комментарий от anonymous

Подстраивание сверху (см. embedding) - в итоге комбайн.

Гипотетический пример «extending»

Непонятно, о чем ты говоришь. Откуда эти термины?

Здесь нахрен весь редактор не нужен

Что конкретно ненужно?

Гипотетический пример

Гипотетическая муть не интересна. Приктические примеры давай.

anonymous
()
Ответ на: комментарий от anonymous

Приктические примеры давай.

Ну вим вполне встраивается: вроде в luakit что-то такое было.

Откуда эти термины?

Ну погугли: «embedding extending lua». Термины устоявшиеся, правда здесь контекст другой, но тоже применимо: либо приложение (высокоуровневое, решающее конечную задачу) встраивается в редактор, либо редактор в приложение (тот же luakit).

anonymous
()
Ответ на: комментарий от anonymous

Имена функций должны быть в компиляторе. Редактор — лишняя сущность.

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

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

В данном случае простоты реализации ты не получишь, если засунешь vim в gcc. Как раз наоборот: vim придётся засунуть не только в gcc, но и во _все_ компиляторы/интерпретаторы. А их нужно много, причём в большинстве из них мне вообще vim не нужен, в качестве пример приведу программку cpp. Знаешь такую? Твоя идея хороша с т.з. интерфейса, но нереализуема по иным причинам. Я просто вынужден разделить vim/cpp/gcc/ld, потому-что в таком порядке они идут исключительно в хэлловорлде, который к тому же ещё и пишется один раз, и не использует hg/make.

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

а мы НЕ нарушаем это правило. Имя функции задаётся в редакторе, и так и уходит оттуда в компилятор. Что касается плеера, то имя трека хранится в двух местах, и передаётся в обоих направлениях. В отличие от плеера, компилятор никогда не задаёт имён функций в моём коде.

Даже самое элементарное действие — выход, и то требует лишних телодвижений. Мало того, редактор предназначен для редактирования, а функция просмотра/навигации является вспомогательной. Для компилятора наоборот. Функций «компилировать/перейти к функции/и т.д.» в редакторе в принципе нет

функции «компилировать функцию, ЭТУ» действительно нет. За то есть функция «обработать этот файл этой программой». Функция «перейти на точку в программе, в т.ч. и на функцию» в редакторе есть. Для компилятора вообще нет функций «перейти на» и «отредактировать строку». Он лишь файлы жрёт. Целиком. Часто несколько сразу.

4. Полнота — основные функции компилятора отсутствуют в редакторе, ибо не имеют там смысла.

основная функция компилятора «компилировать». Т.е. выполнить этот компилятор. Такая функция имеется у любого редактора. Сейчас посмотрел mcedit, дык там теперь не только компиляция есть, но даже встроенная искароппки ОТЛАДКА

Но это ещё не всё, если компиляцию/переход можно накостылять, то «автоматом сделать коммит в DVCS» уже скорее всего нельзя. Даже если в оригинальном интерфейсе какого-то Eclipse и можно.

почему-же «нельзя»? Можно. Также вбить в Makefile после линковки через &&. Ага, это shell. Можно и в .vimrc сделать.

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

4.2

Машинный код показать можно, и это тоже самое что и компиляция, только не до конца. Если ты хочешь видеть ассемблер. А если ты желаешь бинарник, то это тоже можно в vim.

Следовательно, редактировать код в vim'е неправильно.

если ты заметил, то как раз правильно. Вот в notepad.exe не правильно, ты прав. Например там нельзя выполнить gcc для файла, а тем более make для проекта. Просто задача у блокнота другая. А вот у vim — именно такая, редактировать код. Он заточен на это by design. Причём по большей части это никакие не самописные костыли, а встроенная поддержка.

drBatty ★★
()
Ответ на: комментарий от anonymous

Ну вим вполне встраивается: вроде в luakit что-то такое было.

Что и куда конкретно я должен встроить? И главное зачем?

anonymous
()
Ответ на: комментарий от anonymous

Здесь нахрен весь редактор не нужен

Что конкретно ненужно?

тебе же сказали: редактор тут не нужен. Даже навигация тут нужна не обычная(как у блокнота), и уж тем более не как в VIM с Over9000 фичами, а вообще исключительно построчная. AFAIK такой навигации в емаксе отродясь не было. Редактирование тоже нужно специализированное, тебе только одну строку надо редактировать, а в идеале даже не строку, а ячейку СУБД(или таблицы типа ексель, если тебе так привычнее). Или тебе придётся 20 раз вбивать название альбома(пусть и автоматически,и но тоже неудобно) в каждую песню.

А проблема в том, что правила тегов совершенно другие, чем правила текста. Т.е. теги != не текст, если ты с ним работаешь иначе, чем целиком (а оно и надо).

А вот код программы на C таки текст, который обрабатывают кусками с помощью vim'а. При этом компилятор его весь глотает и сразу.

drBatty ★★
()
Ответ на: комментарий от anonymous

либо приложение (высокоуровневое, решающее конечную задачу) встраивается в редактор, либо редактор в приложение (тот же luakit).

(*)ну вот gcc встраивается в vim

(**)а vim встраивается в mercurial

(***)также можно и mercurial встроить в make

В случае (*)внутренний gcc работает молча, и не требует реакций юзера(вся работа на уровне смогла/не смогла), а работаю я с редактором. В случае(**) я должен работать с mercurial, но оно не умеет редактирование(и не должно умет), потому редактирую я встроенным vim'ом, а в случае (***) возможен вариант когда я работаю в одном vim, который запускает mercurial, который запускает другой vim для нужд mercurial'а.

Всё это реализуется ПРОСТЫМ способом, который понятен даже дебилу, просто перед командой shell'а надо поставить "!" внутри конфига vimrc.

ЗЫЖ костыли нужны в vim'е что-бы реализовать прыжки по ошибкам, но я этим не пользуюсь, стараюсь писать без ошибок. Ну а прыгнуть на очепятку я и так могу, по номеру строки и имени файла. Нефиг косоручить.

drBatty ★★
()
Ответ на: комментарий от drBatty

Я не умею вбивать функции прямо в компилятор.

А я не умею вбивать песни прямо в проигрыватель.

В данном случае простоты реализации ты не получишь, если засунешь vim в gcc. Как раз наоборот: vim придётся засунуть не только в gcc, но и во _все_ компиляторы/интерпретаторы.

А ты не получишь простоты реализации, если засунешь emacs в mplayer. Как раз наоборот: emacs придётся засунуть не только в mplayer, но и во _все_ проигрыватели.

а мы НЕ нарушаем это правило. Имя функции задаётся в редакторе, и так и уходит оттуда в компилятор.

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

функции «компилировать функцию, ЭТУ» действительно нет.

А у меня есть. У тебя претензий по предыдущему примеру не было.

Функция «перейти на точку в программе, в т.ч. и на функцию» в редакторе есть.

Вот и у меня в редакторе есть функция перейти на песню.

основная функция компилятора «компилировать».

А основная функция проигрывателя - проигрывать.

почему-же «нельзя»? Можно. Также вбить в Makefile после линковки через &&. Ага, это shell. Можно и в .vimrc сделать.

Вот и мне тоже можно.

anonymous
()
Ответ на: комментарий от drBatty

Даже навигация тут нужна не обычная(как у блокнота), и уж тем более не как в VIM с Over9000 фичами, а вообще исключительно построчная. AFAIK такой навигации в емаксе отродясь не было.

Что это за бред, построчная навигация есть везде.

Редактирование тоже нужно специализированное, тебе только одну строку надо редактировать

Какое нахрен специализированное редактирование? Перечитай внимательно пример.

а в идеале даже не строку, а ячейку СУБД(или таблицы типа ексель, если тебе так привычнее).

Редактировать «ячейку СУБД»? Полный бред.

Или тебе придётся 20 раз вбивать название альбома(пусть и автоматически,и но тоже неудобно) в каждую песню.

Чего мне надо вбивать? Ты обкурился?

А проблема в том, что правила тегов совершенно другие, чем правила текста. Т.е. теги != не текст, если ты с ним работаешь иначе, чем целиком (а оно и надо).

Иди читай заново пример. Нет там никаких тегов.

anonymous
()
Ответ на: комментарий от anonymous

А я не умею вбивать песни прямо в проигрыватель.

а я — умею. Не сами песни, а их названия.

А ты не получишь простоты реализации, если засунешь emacs в mplayer. Как раз наоборот: emacs придётся засунуть не только в mplayer, но и во _все_ проигрыватели.

а в проигрыватели и не нужно. Но вот во всякие visudo,crontab,mercurial и ещё 100500 программ я уже давно засунул. Также и в mutt. Тебе про что другой анонимус и говорит, это интеграция «снизу», а у тебя только «сверху». Т.е. ты можешь засовывать в emacs mercurial, но никак не наоборот.

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

а вот хрен, имя песни задаётся в файле, и оттуда приходит в emacs, а потом идёт обратно. А это не нужно в 95% случаев, обычно нужен только просмотр и выбор. И даже если и нужно, то нужно редактировать одно имя для песни и одно название но уже для альбома. Нужна иерархическая СУБД. Мало того, она должна быть ещё и реляционной, например иметь индекс задающий порядок(называемый «плейлист») А также индекс задающий имя/жанр/каталог альбома, по отношению к треку. Кроме того желательны и другие индексы для обеспечения запросов ORDER BY и GROUP BY, например рейтинги и возможность например слушать «только любимые». Согласись, простой текстовый файл это не лучшая реализации реляционной СУБД. Со всех т.з. и главное, с т.з. удобства слушателя.

А у меня есть. У тебя претензий по предыдущему примеру не было.

это только в лиспе возможно. В других ЯП функции слишком сильно связаны друг с другом и с другими объектами. Часто сборка функции отдельно просто лишена смысла (если она inlin'овая например).

Функция «перейти на точку в программе, в т.ч. и на функцию» в редакторе есть.

Вот и у меня в редакторе есть функция перейти на песню.

у тебя есть функция «перейти на строку», но нет функции «отправить строку или её ID внешней программе» Мой компилятор вообще не волнует, где у меня курсор. Опять-таки нужны хитрые костыли для передачи этого во внешнюю программу. И опять-таки это надстройка сверху, т.к. внешняя программа может быть только внутри. По уму тебе надо было-бы сделать внутри одного emacs'а который readonly СУБД, для прыганья между треками и отображения БД, ну и ещё один маленький emacs'ик для редактирования поля, по требованию. Второй уже должен ессно снизу к СУБД присосаться.

А основная функция проигрывателя - проигрывать.

да, но трек, а вовсе не весь плейлист. Это уже должен emacs делать интерфейс и СУБД.

Вот и мне тоже можно.

а тебе — нельзя. Ибо встраиваемого режима у емакса нет.

drBatty ★★
()
Ответ на: комментарий от anonymous

Что это за бред, построчная навигация есть везде.

нет её не где. Это как в плеере, когда курсор размером во всю строку. В vim такое костылями делается, в emacs AFAIK тоже.

Редактировать «ячейку СУБД»? Полный бред.

не бред, а именно так оно и должно быть. Тыкаешь на название песни, и у тебя появляется окошко _только_ с названием песни. выше/ниже/левее/правее тупо не двигается курсор. Тыкаешь по названию альбома, меняешь название альбома, в _каждом_ треке этого альбома. Тыкаешь «плейлист№17», треки выстраиваются в нужном порядке №17. Причём не все, а только те, что в №17(т.е. у каждого трека есть индекс №17, но он равен NULL если этого трека нет в №17).

Чего мне надо вбивать? Ты обкурился?

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

Иди читай заново пример. Нет там никаких тегов.

в твоём примере нет никаких тегов, рейтингов, обложек и текстов песен. Это потому, что у тебя не плеер, а говно. Также как троллейбус из буханки, и по той же причине.

drBatty ★★
()
Ответ на: комментарий от drBatty

а я — умею. Не сами песни, а их названия.

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

а в проигрыватели и не нужно.

Нужно. Надо песню из списка выбрать.

а вот хрен, имя песни задаётся в файле, и оттуда приходит в emacs, а потом идёт обратно.

Без разницы, где оно задается. Никаких проблем нет.

а вот хрен, имя песни задаётся в файле, и оттуда приходит в emacs, а потом идёт обратно.

Да без разницы, где оно задается. Никаких проблем нет.

у тебя есть функция «перейти на строку», но нет функции «отправить строку или её ID внешней программе»

У меня есть «отправить функцию», поэтому и с «отправить песню» проблем нет.

да, но трек, а вовсе не весь плейлист. Это уже должен emacs делать интерфейс и СУБД.

Что-что Emacs должен делать?

anonymous
()
Ответ на: комментарий от drBatty

нет её не где. Это как в плеере, когда курсор размером во всю строку. В vim такое костылями делается, в emacs AFAIK тоже.

Я даже боюсь спрашивать, почему тебе нужен курсор размеров во всю строку.

Все, эту ветку закрываем. А то сейчас тебя с твоими «ячейками СУБД», «курсорами во всю строку» и «плелистами№17» еще на двадцать страниц понесет.

anonymous
()
Ответ на: комментарий от drBatty

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

RCV ★★★★
()
Ответ на: комментарий от drBatty

Имена песен должны быть в плеере. Редактор — лишняя сущность, усложняет систему.

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

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

А где и кто нарушает это правило?

Даже самое элементарное действие — выход, и то требует лишних телодвижений.

Из емакса можно выйти либо нажатием одного хоткея, либо нажатием «крестика» в окне (если используется гуевый интерфейс). Укажи приложение, в котором надо делать _меньше_ телодвижений для выхода, или ты просто балабол.

основные функции плеера отсутствуют в редакторе, ибо не имеют там смысла.

В ВМ основные функции плеера тоже отсутствуют, потому что не имеют там смысла. Но, представь себе, основные функции плеера есть в плеере!

anonymous
()
Ответ на: комментарий от anonymous

Здесь нахрен весь редактор не нужен, достаточно view-mode (ну может + «linewise» killring).

Редактор окон в WM тоже, видимо, не нужен - достаточно view-mode, одно окно на весь экран и хорош, нехуй их ресайзить/двигать/отображать по нескольку штук и т.п.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от drBatty

В данном случае простоты реализации ты не получишь, если засунешь vim в gcc.

почему ты считаешь, что не получишь простоты при засовывании вима в гцц, но получишь эту простоту при засовывании вима в плеер?

Что касается плеера, то имя трека хранится в двух местах, и передаётся в обоих направлениях.

Это в каких двух? В одном месте оно и хранится.

основная функция компилятора «компилировать». Т.е. выполнить этот компилятор.

А основная функция проигрывателя - проигрывать. Т.е. выполнить этот проигрыватель.

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

anonymous
()
Ответ на: комментарий от drBatty

тебе же сказали: редактор тут не нужен.

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

anonymous
()
Ответ на: комментарий от anonymous

Как раз наоборот: emacs придётся засунуть не только в mplayer, но и во _все_ проигрыватели.

Так батя за это и ратует. В каждом проигрывателе завелосипежен свой собственный недоредактор. Юниксвей во все поля, лол.

anonymous
()
Ответ на: комментарий от drBatty

Нужна иерархическая СУБД

Для проигрывателя.

И этот человек еще смеет чтото кукарекать про юниксвей и ненужности чего-либо?

anonymous
()
Ответ на: комментарий от drBatty

у тебя есть функция «перейти на строку», но нет функции «отправить строку или её ID внешней программе»

Конечно, есть. А как по-твоему плагин плеера работает в емаксе? Отправляет строку внешней программе.

anonymous
()
Ответ на: комментарий от drBatty

Это уже должен emacs делать интерфейс

Вот он и делает. Интерфейс в виде текстового буфера с плейлистом.

anonymous
()
Ответ на: комментарий от drBatty

в твоём примере нет никаких тегов, рейтингов, обложек и текстов песен.

Представь себе, все есть. И для этого не надо СУБД и прочей ненужной никому хуеты, которую ты придумал.

anonymous
()
Ответ на: комментарий от anonymous

Да можно все. Под вим тоже есть плееры ВНЕЗАПНО.

Вот уж действительно ВНЕЗАПНО. Как же доктор батый живет?

RCV ★★★★
()
Ответ на: комментарий от anonymous

Это уже должен emacs делать интерфейс

Вот он и делает. Интерфейс в виде текстового буфера с плейлистом.

До него походу начинает доходить.

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

anonymous
()
Ответ на: комментарий от RCV

Вот уж действительно ВНЕЗАПНО. Как же доктор батый живет?

Не считается! Ведь они написаны в страдании на говно-vimscript, а вот в вашем Emacs все пишется легко и просто. Так нечестно!

anonymous
()
Ответ на: комментарий от anonymous

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

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

Да без разницы, где оно задается. Никаких проблем нет.

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

Что-что Emacs должен делать?

да ничего не должен делать, успокойся. Должен хранить плейлист в текстовом файле, я что, против?

drBatty ★★
()
Ответ на: комментарий от anonymous

Я даже боюсь спрашивать, почему тебе нужен курсор размеров во всю строку.

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

Все, эту ветку закрываем. А то сейчас тебя с твоими «ячейками СУБД», «курсорами во всю строку» и «плелистами№17» еще на двадцать страниц понесет.

забей, мне уже всё ясно, emacs няшный.

drBatty ★★
()
Ответ на: комментарий от RCV

http://lightbird.net/pysuite/

для Ъ

PySuite - a collection of vim scripts written in Python. Note that you need Vim compiled with Python to use these. Some Vim distributions come with Python already included, you can test by running this command: :python print 'hi' . If it prints 'hi' in command line, you have Python, otherwise you'll see an error.

Vimp3 Music player for vim, featuring regular commands like play, stop, pause, seek, next, previous; multiple playlists per file; track scores and random mode that takes scores into account and an option to set specify pause time between tracks. NOTE: other scripts will work in windows and linux, vimp3 will only work in linux because it needs to use command line mplayer for backend.

это первая ссылка, их ещё Over9000, вроде и на обычном vimscript было.

drBatty ★★
()
Ответ на: комментарий от drBatty

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

То есть надо, чтобы нельзя было выделить отдельный символ описания трека? А если я кусок названия песни захотел выделить, то мне что делать?

anonymous
()
Ответ на: комментарий от anonymous

Так батя за это и ратует. В каждом проигрывателе завелосипежен свой собственный недоредактор.

на самом деле этот недоредактор входит в толкит. Например в qt если мы про KDE. Т.ч. проблем нет, и emacs не нужен. Так то.

drBatty ★★
()
Ответ на: комментарий от anonymous

Для проигрывателя. И этот человек еще смеет чтото кукарекать про юниксвей и ненужности чего-либо?

дурачёк, зачем ты предлагаешь делать свою велосипедную недоБД на текстовых файлах для каждого проигрывателя? Не проще-ли взять одну на ВСЁ? Это и есть UNIX Way. А твой emacs с ворохом текстовых файлов-плейлистов оставь в 80х годах прошлого века.

drBatty ★★
()
Ответ на: комментарий от anonymous

Конечно, есть. А как по-твоему плагин плеера работает в емаксе? Отправляет строку внешней программе.

каким боком это относится к ТЕКСТОВОМУ РЕДАКТОРУ?

drBatty ★★
()
Ответ на: комментарий от RCV

Вот уж действительно ВНЕЗАПНО. Как же доктор батый живет?

ВНЕЗАПНО: правит редактором файлы, и слушает музыку плеером.

А вы продолжайте лепить троллейбусы.

drBatty ★★
()
Ответ на: комментарий от anonymous

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

признаю. Из буханки ДЕЙСТВИТЕЛЬНО можно сделать троллейбус.

Но зачем?

drBatty ★★
()
Ответ на: комментарий от anonymous

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

естественно. Ибо редактирование тега, это ДРУГОЕ действие. Никак не связанное с выбором. Боюсь фанатегу СУБД на текстовых файлах этого не понять.

А если я кусок названия песни захотел выделить, то мне что делать?

А если я поеду на твоём троллейбусе, и мне кушать захочется? Я отломаю кусок тормоза, и покушаю. Отсюда вывод: все троллейбусы УГ, кроме того, который из буханки. Ибо кушать хотят все.

drBatty ★★
()
Ответ на: комментарий от drBatty

на самом деле этот недоредактор входит в толкит. Например в qt если мы про KDE. Т.ч. проблем нет, и emacs не нужен. Так то.

Лол, Батти уже совсем забыл про свой хваленый unix way и предлагает кодить однотипные комбайны на C++, молодец.

anonymous
()
Ответ на: комментарий от drBatty

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

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

anonymous
()
Ответ на: комментарий от drBatty

каким боком это относится к ТЕКСТОВОМУ РЕДАКТОРУ?

Таким же боком как и отправка функции компилятору.

anonymous
()
Ответ на: комментарий от drBatty

признаю. Из буханки ДЕЙСТВИТЕЛЬНО можно сделать троллейбус.

Ну значит связка «редактор + компилятор» тоже троллейбус, и весь unix way троллейбус. Не удивидетльно, ведь Батти уже предлагает писать все каждый раз с нуля на C++ - болезнь прогрессирует.

anonymous
()
Ответ на: комментарий от drBatty

естественно. Ибо редактирование тега, это ДРУГОЕ действие. Никак не связанное с выбором. Боюсь фанатегу СУБД на текстовых файлах этого не понять.

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

anonymous
()
Ответ на: комментарий от anonymous

уже совсем забыл про свой хваленый unix way и предлагает кодить однотипные комбайны на C++,

при чём тут «комбайны»? У меня Over9000 приложений KDE, и ни в одном из них нет никакого недоредактора. Есть один, и он в qt, выполняет одну задачу, и делает это хорошо.

drBatty ★★
()
Ответ на: комментарий от anonymous

Никто про БД на текстовых файлах не говорил, это твое больное воображение разыгралось

по твоему плейлист это не база данных? А что тогда? Вечерняя молитва?

drBatty ★★
()
Ответ на: комментарий от anonymous

каким боком это относится к ТЕКСТОВОМУ РЕДАКТОРУ?

Таким же боком как и отправка функции компилятору.

обработка файла какой-то утилитой — стандартная функция редактора. А вот обработка строки — это не совсем «текстовый редактор».

drBatty ★★
()
Ответ на: комментарий от drBatty

при чём тут «комбайны»?

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

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

Есть один, и он в qt, выполняет одну задачу, и делает это хорошо.

Зачем ты тогда пользуешься vim? Выкинь vim или балабол.

anonymous
()
Ответ на: комментарий от anonymous

Ну значит связка «редактор + компилятор» тоже троллейбус

нет. Эта связка необходима потому, что IRL схема НАМНОГО сложнее. Даже в тривиальном случае ты забыл препроцессор, make, и линкер.

Если-бы нужен был один единственный компилятор, и если-бы текстовый редактор нужен был-бы _только_ для этого компилятора, то по unix way да, надо было-бы засунуть vim в gcc. А бабушка была-бы дедушкой.

Не удивидетльно, ведь Батти уже предлагает писать все каждый раз с нуля на C++ - болезнь прогрессирует.

да. Прими таблетку, а то глюки замучают.

drBatty ★★
()
Ответ на: комментарий от drBatty

по твоему плейлист это не база данных? А что тогда? Вечерняя молитва?

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

anonymous
()
Ответ на: комментарий от anonymous

Название песни, дурень

дурень, при чём тут название песни? Плеер по твоему должен все файлы открыть, и найти файл с тегом «Печаль моя светла»?

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

при чём тут mc, причём dried, причём клипбоард???

Шизофазия, или речевая разорванность (в отличие от словесной окрошки, потока несвязанных слов) — психиатрический симптом, выражающийся в нарушении структуры речи, при котором фразы строятся правильно, однако не несут никакой смысловой нагрузки, иногда с повторяющимися речевыми оборотами. Шизофазия наблюдается при различных расстройствах психики (является негативным симптомом шизофрении), иногда, также, в состоянии опьянения. Слово «шизофазия» вошло в интернет-сленг, став ярлыком для бессмысленных «псевдофилософских» текстов в стиле I Am the Walrus.

drBatty ★★
()
Ответ на: комментарий от drBatty

обработка файла какой-то утилитой — стандартная функция редактора. А вот обработка строки — это не совсем «текстовый редактор».

Любая unix программа может отправлять и принимать текст, текстовый редактор не исключение.

По предыдущему примеру у тебя претензий не было. Если появились - предъявляй.

anonymous
()
Ответ на: комментарий от drBatty

при чём тут название песни?

Тебе говорили про копирование названия песни. Вот список песен, тебе надо скопировать название одной песни.

anonymous
()
Ответ на: комментарий от anonymous

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

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

столько слов... Ну дык вылазь из криокамеры, это всё УЖЕ написали. Есть KDE, оно торт. Твой емакс тупо не нужен.

Зачем ты тогда пользуешься vim? Выкинь vim или балабол.

изменить название песни и поправить исходный код — разные задачи. Я не смогу править qt'шным editbox'ом код. Задолбаюсь. Потому выкидывать вим преждевременно.

drBatty ★★
()
Ответ на: комментарий от anonymous

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

я же говорю — мы о разном. Смотри текст дальше, а я музыку слушаю.

drBatty ★★
()
Ответ на: комментарий от drBatty

столько слов... Ну дык вылазь из криокамеры, это всё УЖЕ написали. Есть KDE, оно торт. Твой емакс тупо не нужен.

Посмотрите-ка, как закукарекал наш петушок! Полностью забыл про unix way! Ну разве это не прекрасно? Балабол Батя настолько забалаболился, что уже по кругу противоречит сам себе.

KDE - говномонолит, ты там ничего не решаешь, ты только ждешь годами пока кодеры наговнокодят тебе какую-то фичу.

Unix way - это конструктор, для любой своей задачи ты можешь быстро собрать рабочее решение.

anonymous
()
Ответ на: комментарий от drBatty

я же говорю — мы о разном. Смотри текст дальше, а я музыку слушаю.

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

anonymous
()
Ответ на: комментарий от anonymous

Любая unix программа может отправлять и принимать текст, текстовый редактор не исключение.

Любая

что, правда? А сделать sed из emacs слабо? Или твой навороченный emacs не в состоянии работать как тривиальный текстовый фильтр?

По предыдущему примеру у тебя претензий не было. Если появились - предъявляй.

потому-что редактирование исходных текстов — одна из задач текстового редактора.

А изготовление из редактора плеера === создание троллейбуса из буханки.

drBatty ★★
()
Ответ на: комментарий от anonymous

Посмотрите-ка, как закукарекал наш петушок!

брысь на стоплинукс, деточка.

Полностью забыл про unix way!

4.2

что уже по кругу противоречит сам себе.

тебе. Но да, по кругу.

KDE - говномонолит, ты там ничего не решаешь, ты только ждешь годами пока кодеры наговнокодят тебе какую-то фичу.

4.2

фичу я могу сам наговнокодить, а могу и чужую взять. Могу и использовать только из KDE. Никто не заставляет, я не гей и не маздайщик. Мне например не нравится их редактор (больно много жрёт, и вообще вим удобнее), и их терминал. Ну я ими и не пользуюсь. А вот скриншотилка там лучше всех.

Unix way - это конструктор, для любой своей задачи ты можешь быстро собрать рабочее решение.

но я не обязан ПОСТОЯННО всё быстро собирать. Если тебя от этого прёт — собирай, хоть вместе с иксами, я не против. У меня нет времени и желания.

drBatty ★★
()
Ответ на: комментарий от anonymous

я же говорю — мы о разном. Смотри текст дальше, а я музыку слушаю.

Балабол Батя применяет свой любимый метод: слился?

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

drBatty ★★
()
Ответ на: комментарий от drBatty

на самом деле этот недоредактор входит в толкит. Например в qt если мы про KDE. Т.ч. проблем нет, и emacs не нужен. Так то.

Ну и в емаксе этот редактор входит в саму ВМ (емакс). И в итоге кде не нужен, так-то.

anonymous
()
Ответ на: комментарий от anonymous

Ну и в емаксе этот редактор входит в саму ВМ (емакс). И в итоге кде не нужен, так-то.

в KDE ещё кроме этого много нужного. Был-бы там один недоредактор, не юзал-бы.

drBatty ★★
()
Ответ на: комментарий от drBatty

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

Какую еще велосипедную недобд? Проигрывателю вообще ненужна никакая бд. Совсем.

Не проще-ли взять одну на ВСЁ?

Всмысле - прибить плеер к бд намертво? Нет, это не юникс-вей, потому нинужно.

anonymous
()
Ответ на: комментарий от drBatty

каким боком это относится к ТЕКСТОВОМУ РЕДАКТОРУ?

Если не относится - то нехуй запускать тогда сорцы из редактора.

anonymous
()
Ответ на: комментарий от drBatty

А если я поеду на твоём троллейбусе, и мне кушать захочется? Я отломаю кусок тормоза, и покушаю. Отсюда вывод: все троллейбусы УГ, кроме того, который из буханки. Ибо кушать хотят все.

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

anonymous
()
Ответ на: комментарий от drBatty

естественно. Ибо редактирование тега, это ДРУГОЕ действие. Никак не связанное с выбором. Боюсь фанатегу СУБД на текстовых файлах этого не понять.

При чем тут редактирование тега? я назвал конкретный юзкейс - мне надо выделить часть название трека/песни (потом скопировать и поискать по нему, например).

И, да, еще раз - зачем плееру БД? Если вся информация о треке хранится _в самом треке_? То есть ее зачем-то надо продублировать, а потом следить за корректностью и синхронизацией? Зачем такие усложнения?

anonymous
()
Ответ на: комментарий от drBatty

при чём тут «комбайны»? У меня Over9000 приложений KDE, и ни в одном из них нет никакого недоредактора. Есть один, и он в qt, выполняет одну задачу, и делает это хорошо.

Ты ебанашка чтоли? Не существует никакого «однго единственного редактора в qt». Во всех этих приложениях он велосипедится заново. Да, там юзаются какие-то кутешные контролы, но это нихуя не редактор, и даже не недо.

anonymous
()
Ответ на: комментарий от drBatty

по твоему плейлист это не база данных? А что тогда? Вечерняя молитва?

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

anonymous
()
Ответ на: комментарий от drBatty

обработка файла какой-то утилитой — стандартная функция редактора. А вот обработка строки — это не совсем «текстовый редактор».

То есть, файл на компиляцию отправить можно, а отправить на компиляцию определенную в этом файле функцию - уже нет? Все охуеннее и охуеннее, что еще придумаешь?

anonymous
()
Ответ на: комментарий от drBatty

Есть KDE, оно торт. Твой емакс тупо не нужен.

А зачем КДЕ, если есть емакс?

Зачем мне слушать плеер амароком, если в емаксе есть более функциональный проигрыватель?

anonymous
()
Ответ на: комментарий от drBatty

что, правда? А сделать sed из emacs слабо? Или твой навороченный emacs не в состоянии работать как тривиальный текстовый фильтр?

Делать сед в емаксе - не юникс-вей, юникс-вей - исопользовать сед из емакса. При этом емакс и сед работаюбт совершенно независимо.

потому-что редактирование исходных текстов — одна из задач текстового редактора.

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

anonymous
()
Ответ на: комментарий от drBatty

фичу я могу сам наговнокодить, а могу и чужую взять. Могу и использовать только из KDE. Никто не заставляет, я не гей и не маздайщик.

чо, правда можно? Я хочу амарок, но только для какой-нибудь альтернативный ВМ вместо иксов и, конечно же, прикрутить к нему другую БД. Ну и в качестве встроенного редактора не то кутешное поделие, а старый банальный nano. если амарок - юниксвеен, то это, очевидно, легко можно сделать, можешь пояснить, как?

anonymous
()
Ответ на: комментарий от drBatty

но я не обязан ПОСТОЯННО всё быстро собирать.

Да никто и не собирает. Главное чтобы была _возможность_ собрать и поменять в конструкторе одну деталь на другую. Во тв том же амароке нету такой возможности, по-этому амарок - не юниксвеен. А в плеерах емакса - есть такая возможность, по-этому емаксовые плееры юникс-вейны.

anonymous
()
Ответ на: комментарий от drBatty

Emacs хороший текстовый редактор, из него даже _можно_ сделать плеер. Но не нужно.

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

anonymous
()
Ответ на: комментарий от drBatty

в KDE ещё кроме этого много нужного. Был-бы там один недоредактор, не юзал-бы.

не знаю, мне консольного емакса вполне хватает.

anonymous
()
Ответ на: комментарий от anonymous

Зачем мне слушать плеер амароком, если в емаксе есть более функциональный проигрыватель?

признайся, про функционал ты пошутил или просто не в курсе?

drBatty ★★
()
Ответ на: комментарий от anonymous

Делать сед в емаксе - не юникс-вей, юникс-вей - исопользовать сед из емакса.

Это ты сказал? Дык перелогинся, я запишу данное авторитетное высказывание самого... А кого, простите?

При этом емакс и сед работаюбт совершенно независимо.

правильно. Потому-что наоборот придётся костылить sed на elisp'е. А всё потому, что emacs это не unix way(в твоих кривых руках. Нормальные люди просто не решают другие задачи этим инструментом).

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

потому-что плейлист != простой текст. Смирись.

drBatty ★★
()
Ответ на: комментарий от anonymous

Я хочу амарок, но только для какой-нибудь альтернативный ВМ вместо иксов

учи матчасть — иксы это не WM. А вот в IceWM амарок таки работает.

конечно же, прикрутить к нему другую БД.

наверное можно, а зачем?

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

зачем менять совершенно нефункциональной editbox из qt, на такой же нефункциональный nano? К тому-же, nano для этого не предназначен.

drBatty ★★
()
Ответ на: комментарий от anonymous

Emacs хороший текстовый редактор, из него даже _можно_ сделать плеер. Но не нужно.

почему? Ты можешь это как-то обосновать?

man unix way

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

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

Заметь:

1. я не запрещаю делать тебе троллейбус

2. я не говорил, что у тебя плохой тролейбус

3. моя религия индифферентна к троллейбусам: в Завете об этом ничего не сказано. Значит _можно_ по Канону.

4. я предпочитаю нормальные троллейбусы, ибо они дают подходящий мне функционал.

drBatty ★★
()
Ответ на: комментарий от drBatty

Нет, я не шутил. В текстовом буфере емакса искаробки есть ф-и, которых нету в амароке.

anonymous
()
Ответ на: комментарий от drBatty

Это ты сказал?

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

правильно. Потому-что наоборот придётся костылить sed на elisp'е.

Да ничего не надо костылить. Sed уже написан, все. А емакс предоставляет интерфейс, в том числе к sed. Естественно, вместо сед можно будет использовать и какую-то другую утилиту. Равно как и другой интерфейс вместо емакса. Чистый юниксвей.

потому-что плейлист != простой текст.

В том и дело что плейлист - это простой текст.

anonymous
()
Ответ на: комментарий от drBatty

учи матчасть — иксы это не WM.

Иксы - это вм, учи матчасть.

А вот в IceWM амарок таки работает.

Прекрасно. Как мне теперь заставить заработать амарок в IceWM, но не под иксами, а под другой базовой ВМ?

наверное можно, а зачем?

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

зачем менять совершенно нефункциональной editbox из qt, на такой же нефункциональный nano?

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

anonymous
()
Ответ на: комментарий от drBatty

man unix way

Ответ будет? Юникс-вей не запрещает использовать ВМ и ДЕ.

в данном случае здравый смысл.

Повторю вопрос:

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

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

anonymous
()
Ответ на: комментарий от drBatty

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

anonymous
()
Ответ на: комментарий от anonymous

Нет, я не шутил. В текстовом буфере емакса искаробки есть ф-и, которых нету в амароке.

не думаю, что там есть рейтинги и например поиск через ФМ, и прочая ерунда.

drBatty ★★
()
Ответ на: комментарий от drBatty

Потому-что наоборот придётся костылить sed на elisp'е.

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

Использовать емакс в качестве интерфейса к внешнему независимому приложению (сед, плееру, компилятору, жабберу etc.) - юниксвей, встраивать нечто в емакс намертво (реализовывать плеер/сед/компилятор/жаббер/етц. на елиспе) - не юниксвей. Обратное (встраивать намертво редактор в плеер/компилятор/жаббер/сед), кстати, точно так же не юниксвей.

То есть любая ИДЕ - не юниксвей (юниксвейно это три отдельных приложения - редактор + компилятор + анализатор кода, которые должны уметь работать независимо), любой жаббер-клиент - не юниксвей (он должен отправлять/принимать сообщения, а редактор/лист контактов - это уже два независимых приложения), любой плеер - не юниксвей (то же самое - отдельная софтина должна собственно проигрывать нужный файл, другая - давать возможности редактирования плейлистов, управления плеером).

anonymous
()
Ответ на: комментарий от anonymous

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

нет, ты врёшь. ибо emacs <- sed можно, а sed <- emacs нельзя.

Да ничего не надо костылить. Sed уже написан, все. А емакс предоставляет интерфейс, в том числе к sed.

это всё круто, но когда я делаю hg ci, мне не нужен интерфейс. Мне нужен просто текстовый редактор.

И да, я ещё и консоль люблю. В KDE я могу легко набрать однострок на перле, а зачем мне его набирать внутри емакса? Ну и опять-таки, если внутри емакса набрать hg ci, то вывалится второй емакс? Или опять костыли нужны?

Равно как и другой интерфейс вместо емакса. Чистый юниксвей.

sed это юниксвей. Можно её запускать откуда хочешь, и ей запускать что хочешь. Также можно текст гонять в/из неё, и в/из файл(файлы).

В том и дело что плейлист - это простой текст.

ну HTML тоже просто текст, почему-же ты простым wget'ом не смотришь web? Он разве плохо текст выводит?

drBatty ★★
()
Ответ на: комментарий от drBatty

Дело в том, что этих плееров дохерища

http://www.emacswiki.org/emacs/MusicPlayers

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

но не под иксами, а под другой базовой ВМ?

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

наверное можно, а зачем?

Это юникс-вей.

нет. ЭТО задротство. Не путай пожалуйста. Юниксвейная прога тебе ничего не должна, кроме как выполнять _свою_ задачу хорошо. Быть конструктором чего угодно она не должна, если это конечно не емакс.

Я например не хочу тащить за собой куте, я хочу чтобы все работало в консоли с нано.

ага, амарок? Пошутил?

drBatty ★★
()
Ответ на: комментарий от drBatty

Нет, это общеизвестная философия емакса.

Тьфу ты блять. Юниксвея, конечно, а не емакса, оговорился.

нет, ты врёшь. ибо emacs <- sed можно, а sed <- emacs нельзя.

Ты никак не поймешь. И emacs <- sed и sed <- emacs - это одинаково не юниксвей. Юниксвей, это когда сед и емакс работают ОТДЕЛЬНО. При этом в данной связке оба звена могут быть заменены. То есть использовать емакс с другой аналогичной седу утилитой или сед с другим редактором. Условно говоря - емакс в данном случае вообще не знает (и не должен!), что он работает с седом, а сед - что он работает с емаксом.

Мне нужен просто текстовый редактор.

Это и есть интерфейс.

В KDE я могу легко набрать однострок на перле, а зачем мне его набирать внутри емакса?

Не понял вопроса. Зачем использовать терминал? Ну а как еще без терминала работать с консолью?

Ну и опять-таки, если внутри емакса набрать hg ci, то вывалится второй емакс? Или опять костыли нужны?

Будет то же самое, как если ты наберешь hg ci в любом другом терминале.

sed это юниксвей. Можно её запускать откуда хочешь, и ей запускать что хочешь. Также можно текст гонять в/из неё, и в/из файл(файлы).

Именно.

ну HTML тоже просто текст, почему-же ты простым wget'ом не смотришь web?

Потому что мне не надо смотреть html, мне его надо рендерить.

anonymous
()
Ответ на: комментарий от drBatty

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

Ну как как? Ставшиь емакс и запускаешь, например. Как мне запустить амарок под емаксом, без иксов и чтобы ничего лишнего не тянуть (если тянуть - то таки запустить можно и без иксов, да)?

anonymous
()
Ответ на: комментарий от anonymous

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

ну я не считаю, что чисто текстовый www и плеер — верх функционала. Да, я работал. Да, оно работает, ЛОР читается, музыка играется. Да, для 80х годов прошлого века идеально. Но здравый смысл помноженный на опыт мне подсказывает, что audacious & firefox таки лучше. Если я хочу что-то сделать с файлами, то мне удобнее простая консоль с bash. А если я захочу вы*нуться, то я возьму BrainFuck. А то на LISP'е любой дурак может.

drBatty ★★
()
Ответ на: комментарий от drBatty

Быть конструктором чего угодно она не должна

Именно в это и состоит юникс-вей. Быть конструктором с взаимозаменяемыми деталями.

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

Обрати внимание на второй пункт. Он строго требует быть конструкторомиз независимо работающих компонентов.

anonymous
()
Ответ на: комментарий от drBatty

ага, амарок? Пошутил?

Нет. Кстати, еще раз - амарок под емаксом вместо иксов впонле можно заставить работать.

anonymous
()
Ответ на: комментарий от drBatty

ну я не считаю, что чисто текстовый www

При чем тут чисто текстовый www? Хватит подменять понятия.

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

Если юникс-вейный плеер из 80-х годов обладает большим функционалом, чем современный комбайн типа амарока - ну и нахуй тогда мне амарок?

anonymous
()
Ответ на: комментарий от anonymous

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

а что ты предлагаешь, если твой емакс только «сверху» интегрироваться умеет?

Обратное (встраивать намертво редактор в плеер/компилятор/жаббер/сед), кстати, точно так же не юниксвей.

а если не намертво?

То есть любая ИДЕ - не юниксвей (юниксвейно это три отдельных приложения - редактор + компилятор + анализатор кода, которые должны уметь работать независимо)

vim|emacs + gcc таки юниксвей.

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

нет. редактирование плейлистов входит в задачу плеера.

drBatty ★★
()
Ответ на: комментарий от drBatty

а если не намертво?

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

а что ты предлагаешь, если твой емакс только «сверху» интегрироваться умеет?

Ты совсем тупой? интегрироваться - это вообще не юниксвей. Юниксвей - работать независимо.

Выбор между интеграцией сверху и интеграцией снизу в этом плане - это выбор между большой клизмой и гамбургером с говном.

anonymous
()
Ответ на: комментарий от drBatty

Чем же это плохо? Это хорошо, причем очень хорошо - каждый может выбрать приложение по своему вкусу.

anonymous
()
Ответ на: комментарий от anonymous

Потому что мне не надо смотреть html, мне его надо рендерить.

по твоему тебе ещё значит нужен отдельный рендер...

drBatty ★★
()
Ответ на: комментарий от drBatty

Если следовать юниксвею - да, нужен отдельный рендер.

Браузеры неюниксвейны. Но они удобны, а я не религиозен.

anonymous
()
Ответ на: комментарий от anonymous

Обрати внимание на второй пункт. Он строго требует быть конструкторомиз независимо работающих компонентов.

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

drBatty ★★
()
Ответ на: комментарий от drBatty

нет. редактирование плейлистов входит в задачу плеера.

в задачу плеера входит получить плейлист (в виде текста) и играть его.

vim|emacs + gcc таки юниксвей.

Тут отдельно редактор, а отдельно - компилятор, о чем я и говорю. Причем емакс/вим прекрансо работают с другими компиляторами, а гцц - с другими редакторами.

anonymous
()
Ответ на: комментарий от anonymous

Чем же это плохо? Это хорошо, причем очень хорошо - каждый может выбрать приложение по своему вкусу.

я скорее свой напишу. С рейтингами и MySQL

drBatty ★★
()
Последнее исправление: drBatty (всего исправлений: 1)
Ответ на: комментарий от drBatty

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

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

anonymous
()
Ответ на: комментарий от anonymous

в задачу плеера входит получить плейлист (в виде текста) и играть его.

это да, но как мне этот плейлист редактировать? Почему сразу нельзя?

drBatty ★★
()
Ответ на: комментарий от anonymous

Ради бога, пиши. но вроде амарок уже написан, нет?

амарок — да. Но он не работает полностью в емаксе. А мне быстрее самому написать на елиспе, чем искать. А ещё проще амарок.

drBatty ★★
()
Ответ на: комментарий от drBatty

это да, но как мне этот плейлист редактировать?

Любым редактором, который тебе нравится.

Почему сразу нельзя?

с чего ты взял, что нельзя?

anonymous
()
Ответ на: комментарий от drBatty

http://www.emacswiki.org/emacs-fr/Amarok

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

anonymous
()
Ответ на: комментарий от drBatty

Я как-то по диагонали просмотрел тред. Можно кратко в чем суть претензий к emacs?
Если это не флуда/тролинга ради, конечно.

Kostafey
()
Ответ на: комментарий от Kostafey

Можно кратко в чем суть претензий к emacs?

ну не юниксвейно пихать в редактор браузер, плеер, кофемашину и проч. ИМХО

Если это не флуда/тролинга ради, конечно.

/0

drBatty ★★
()
Ответ на: комментарий от drBatty

ну не юниксвейно пихать в редактор браузер, плеер, кофемашину и проч. ИМХО

Да это все существует по-моему больше хохмы ради. Ну вроде как игра такая «Сделай мир». Т.е. если редактор имеет в своем составе интерпретатор, позволяющий что угодно состряпать - почему бы и нет? Можно с таким же успехом говорить, что, например python - не unix-way. Да, и, потом, в vim - все то же самое ведь. Да и в любом другом гипотетическом редакторе может быть, будь у него развитый язык расширений.

Kostafey
()
Ответ на: комментарий от Kostafey

Да это все существует по-моему больше хохмы ради.

я тоже так думал. Но вот аноны мну тут чуть не пожрали :)

Да, и, потом, в vim - все то же самое ведь

конечно. Вот только я vim юзаю, а всякую ерунду типа браузера в редакторе — нет.

drBatty ★★
()
Ответ на: комментарий от Kostafey

Можно с таким же успехом говорить, что, например python - не unix-way

Вот оно содержание этого треда. Несколько страниц умный анон пытался это объяснить drbatt'ору, но последний не преклонен.

RCV ★★★★
()
Ответ на: комментарий от drBatty

я тоже так думал. Но вот аноны мну тут чуть не пожрали :)

Ну тут 2 варианта: либо троллинг, либо... Ну да, есть же люди со своеобразными вкусами. ;)

конечно. Вот только я vim юзаю, а всякую ерунду типа браузера в редакторе — нет.

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

Kostafey
()
Ответ на: комментарий от Kostafey

Но если бы он там появился?

ну появится и появится. Какая разница-то? Я с самого начала говорил о том, что Emacs — годная и правильная вещь. Неправильно туда засовывать всякое УГ, вроде плеера с браузером. Т.е. засовывать just for fun конечно можно, но зачем это юзать и другим советовать? И ещё кричать, что дескать «плеер внутри емакса это юниксвей!».

ИМХО.

drBatty ★★
()
Ответ на: комментарий от drBatty

ну появится и появится. Какая разница-то? Я с самого начала говорил о том, что Emacs — годная и правильная вещь.

Ок, я о vim того же мнения. Так что предмета спора нет, судя по всему ;).

Неправильно туда засовывать всякое УГ, вроде плеера с браузером. Т.е. засовывать just for fun конечно можно, но зачем это юзать и другим советовать?

Советовать - нет. Предлагать (авось кому понравиться) - почему бы и нет? Мало ли вкусы совпадут.

И ещё кричать, что дескать «плеер внутри емакса это юниксвей!».

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

Kostafey
()
Ответ на: комментарий от Kostafey

Ок, я о vim того же мнения. Так что предмета спора нет, судя по всему ;).

именно.

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

это всё верно конечно, но всё же. Делать из редактора непонятный комбайн ИМХО неправильно. Особенно учитывая наличие WM/DE, которых достаточно много, и которые работают сейчас на любой железяке.

Хотя, если кому нравится, я не против конечно.

drBatty ★★
()
Ответ на: комментарий от drBatty

ну не юниксвейно пихать в редактор браузер, плеер, кофемашину и проч. ИМХО

Сколько раз еще тебе сказать, что никто не пихает в емакс браузер, плеер, кофемашину и проч? Плееры, браузер и т.п. - это ОТДЕЛЬНЫЕ приложения, как компилятор, например. Они вполне могут работать без емакса. Или с другими редакторами вместо емакса. Как и в емаксе можно заменить эти приложения на любые другие. Полный юникс-вей.

Да, _есть_ плагины прибитые к емаксу напрочь, я об этом уже говорил. Но они считаются не ъ.

anonymous
()
Ответ на: комментарий от drBatty

Делать из редактора непонятный комбайн ИМХО неправильно. Особенно учитывая наличие WM/DE

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

anonymous
()
Ответ на: комментарий от anonymous

Но нету такой ДЕ, которая бы давала функционал емакса.

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

anonymous
()
Ответ на: комментарий от anonymous

Плееры, браузер и т.п. - это ОТДЕЛЬНЫЕ приложения, как компилятор, например. Они вполне могут работать без емакса. Или с другими редакторами вместо емакса. Как и в емаксе можно заменить эти приложения на любые другие. Полный юникс-вей.

Вы не могли бы авторизоваться и показать вашу конфигурацию emacs?

Kostafey
()
Ответ на: комментарий от Kostafey

А зачем? Что ты там хочешь увидеть?

anonymous
()
Ответ на: комментарий от drBatty

ну не юниксвейно пихать в редактор браузер, плеер, кофемашину и проч. ИМХО

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

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

anonymous
()
Ответ на: комментарий от Kostafey

Я как-то по диагонали просмотрел тред. Можно кратко в чем суть претензий к emacs?

Этот идиот орет, что в Emacs зашиты какие-то браузеры и плееры, и что это не unix way. Когда до него начинает доходить, что все-таки ничего зашитого там нет и unix way это никак не противоречит, он начинает орать, что на самом деле unix way - это KDE и C++. И так по кругу.

Просто он вендузятник и быдлокодер, и не понимает, что это все просто отдельные процессы, обменивающиеся текстовыми данными. Он же, как и все виндузятники, мыслит так: «Создаем форму, кидаем на нее кнопку, пишем в обработчике кнопки запросы к СУБД».

anonymous
()
Ответ на: комментарий от anonymous

Даже самые ярые приверженцы Unix Way давно согласились

я согласен

//closed

drBatty ★★
()
Ответ на: комментарий от anonymous

Даже самые ярые приверженцы Unix Way давно согласились с нами.

Не было такого (по-крайней мере в такой категоричности). Какой еще unix-way? ежели там вполне используется приличное количество клея (причем на узкоспециализированном диалекте малораспостраненного языка) и чрезмерное увлечение magic-string там где нужно и не нужно.

anonymous
()
Ответ на: комментарий от drBatty

Ну и опять-таки, если внутри емакса набрать hg ci, то вывалится второй емакс?

Запускаешь eshell, вбиваешь hg ci. И редактируешь в том же емаксе. А зачем тебе второй-то?

iVS ★★★★★
()
Ответ на: комментарий от drBatty

Дело в том, что этих плееров дохерища

тоже плохо.

Много форков плохо. Опенсурс плохо, т.к. позволяет делать много форков. Как-то так по твоей логике.

iVS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.