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

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

Это же ложь. Вот твои сообщения:

ты хоть их понимаешь?

Вангую, что ваш говноредактор так до сих пор и считает «Ф» за две буквы, и что Ёлка перед Аура.

Это беда чуть менее чем всех комбайнов — в них очень сложно вносить изменения. Проще и быстрее всего было научить понимать utf-8 редактор sed, ибо unix way. Но чем дальше от этого пути, тем хуже.

А твой емакс это такой лопатомолоток.

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

Потому emacs это комбайн by design.

ну если это не комбайн, за чем туда засунули самый мощный по части абстракций ЯП? На котором так просто писать что угодно?

В нём есть что-то похожее на браузер, что-то похожее на эмулятор, и что-то похожее на кофе-машину. Но всё нерабочее и не нужное.

можно подумать, что тот же браузер там хоть для чего-то годен.

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

что я должен признать? Что гибрид браузера, кофемашины, плеера и ещё Over9000 НЁХ является unix way'ем? И при чём тут IE? IE это и есть «интернет» для этих твоих «многих».

Хорошо, я готов закрыть глаза на все эти цитаты и противоречия. Просто четко ответь на вопрос:

Ты согласен, что Emacs - полезный и годный текстовый редактор, который не противоречит unix way?

Боже мой. С кем я спорил.

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

Что касается меня, то я свою компетенцию изначально отметил как «низкую» в вопросе использования emacs'а. Я его не использую.

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

про доменное имя не слышал?

Поздно встрял: уже ответили.

Хорошо, я готов закрыть глаза на все эти цитаты и противоречия.

нет там никаких противоречий, ты просто что-то там понял неправильно. Я плохо объяснил видимо. И ты не очень вникал. Вот и всё.

Просто четко ответь на вопрос: Ты согласен, что Emacs - полезный и годный текстовый редактор, который не противоречит unix way?

Конечно да. До тех пор, пока из него не начинают делать кофемашину с недоФМ, и доказывать, что это всё тоже нужно и годно, и вообще юниксвейно.

который не противоречит unix way?

Я что-то пропустил? Может он «еще и следует ..»?

Я что-то пропустил?

Приведи примеры, что противоречит.

Дай определение «юниксвею». Хочу поржать.

Ты согласен, что Emacs - полезный и годный текстовый редактор, который не противоречит unix way?

Конечно да.

С этим разобрались.

Теперь насчет «кофемашин». Я буду по шагам описывать пример, а ты покажи, в каких случаях я делаю неправильно:

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

Вот именно. Не используешь, ничего о нем не знаешь, но мнение иметь смеешь.

Обычная демагогия. Называется «доведение до абсурда» (Reductio ad absurdum) Из неиспользования никак не следует моё незнание. У меня может быть скобки сломались)))

И так во всем.

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

Не было еще ни одной темы, где ты бы не обосрался грязно.

не было ни одной темы с моим участием, где ты-бы не насрал, ты это хотел сказать? Да, почти не было.

Напомнить тебе твой бред про L1, например?

Зачем? Я и сам помню: из моих слов, что L1 быстрее L2 и L3 ты сделал глубокомысленный вывод, что я щитаю L1 быстрее всего, даже регистров и мыслей. А потом 10 страниц это опровергал, с истерикой и ненормативной лексикой. Не нужно.

Дай определение «юниксвею». Хочу поржать.

у тебя гугол сломался? Лови: http://ru.wikipedia.org/wiki/Философия_UNIX

Теперь насчет «кофемашин». Я буду по шагам описывать пример, а ты покажи, в каких случаях я делаю неправильно:

ты всё делаешь правильно, в точности также, как это делаю я. У меня, правда, если компиляция удачная, то автоматом делается коммит в DVCS(в Makefile так обычно прописано). А где тут кофемашина?

Я просто быдлокодер, каких много.

Какой из тебя на хер быдлокодер, если ты даже не знаешь стоимости доступа к L1? Ты просто быдло, без «кодера».

Обычная демагогия. Называется «доведение до абсурда» (Reductio ad absurdum)

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

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

Зачем? Я и сам помню: из моих слов, что L1 быстрее L2 и L3 ты сделал глубокомысленный вывод, что я щитаю L1 быстрее всего, даже регистров и мыслей. А потом 10 страниц это опровергал, с истерикой и ненормативной лексикой. Не нужно.

Нет, ничтожество, не виляй жопой и не пытайся переиначить свой бред. Ты тогда воняло, что дополнительные регистры не нужны и ничем не помогут, и что L1 на x86 и так охерительно оптимизированный. То есть, ты утверждало, что скорость доступа к L1 не ниже чем к регистрам. Это ты теперь, когда поняло, насоколько ты обосралось, пытаешься выставить все в другом свете, но тогда-то ты, грязное животное, верещало, что у AMD64 нет преимуществ перед IA32.

Вот точно также STL является доказательством того, что все ЯП кроме одного — полное говно. В том числе и LISP. Ибо ибо даже несмотря на то, что по слухам первое STL было на схеме, всё равно работает оно IRL исключительно в C++.

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

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

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

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

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

Какой из тебя быдлокодер, если ты даже не знаешь стоимости доступа к L1?

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

Ты просто быдло, без «кодера».

быдло это ты, ибо не знаешь азов. Например слов того же Кнута про преждевременную оптимизацию. Ага, он как раз про таких как ты это говорил, которые такты к L1 считают. И в итоге получают код, который работает только на их локалхосте. Причём не сложнее хэлловорлда.

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

валидный он при адекватном применении. А при неадекватном это демагогия.

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

именно то самое и написано. Я проверял, потому-что вики***ы часто искажают суть. В данном случае они написали именно то, что я думаю. Совпадение наверное.

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

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

но тогда-то ты, грязное животное, верещало, что у AMD64 нет преимуществ перед IA32.

ради прикола возьми собери любую программу для IA32 и для amd64, и поменяй скорость. Если ты будешь собирать для одного и того же процессора, то скорость будет не сильно отличаться. Хотя регистров и меньше. Я конечно быдло, но я проверял. Да и не только я.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простота реализации несколько важнее простоты интерфейса, который даёт 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. Причём по большей части это никакие не самописные костыли, а встроенная поддержка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

то купи себе мак, и фапай на здоровье. Круче не бывает, я гарантирую это! Вот только годного текстового редактора там нет, его надо отдельно ставить, а проще поставить целиком ОС, где все эти _инструменты_ уже поставлены и готовы к использованию. Как например Slackware Linux, в котором есть настроенные и готовые vim & emacs

очередное вранье.
в макоси vim & emacs изкоробки

тред прекрасен

Grep тебе всё равно не нужна, да ты её в iMac и не найдёшь(я задолбался там консоль искать).

1. не в iMac (это железо), а в os x
2. -rwxr-xr-x 1 root wheel 29664 июл 28 2012 /usr/bin/grep
какое неочевидное расположение!

для меня это было не слишком элементарно. И уж тем более, я не понял, как там репозиторий с sshd подключить. Тупой же.

изкоробки

which sshd
/usr/sbin/sshd

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

Ну а как оболочка для интегрирования других программ emacs попросту устарел.

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

Неправда, переносят же на weston / mir, процесс потихоньку идет.

Ну так «переносят», а не «работает под другим ВМ». То есть переписывают. Так и плагины емакса можно переписать под что-нибудь другое.

Не-а, не принимается, в случае емакса это лишь как xfree -> xorg. В случае gui приложений больше абстракции.

Никто не мешает писать с тем же уровнем абстракции на елиспе.

что я должен признать? Что гибрид браузера, кофемашины, плеера и ещё Over9000 НЁХ является unix way'ем? И при чём тут IE? IE это и есть «интернет» для этих твоих «многих».

То есть любая ДЕ не юникс-вейна, так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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