vi - unixway

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

он

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

> emacs: как редактор он не настолько продуман,

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

выдыхай

> ну давай рассказывай чем тебе емакс не угодил?

он решил его не ставить, но осуждает )

вот сектант...

повезло ещё что юниксвей не обязывает головой в пол биться...

>в них упор идёт на графические объекты, а не текстовые потоки.

ну разумеется, а ты как думал ? юниксвей изобретён в 70х, на железе слабее сегодняшних калькуляторов, и сегодня как системный фреймворк никем из разумных не рассматривается... так, для find . |grep сойдёт...

vi - не UnixWay(tm), вот (s)ed это самое то ! :)

http://cm.bell-labs.com/magic/man2html/1/emacs

> всё основано на текстовых потоках

4.2 текстовые данные

>чем тебе емакс не угодил? >ugoday

я хоть не он, но тоже отвечу: vim ближе к телепатическому интерфейсу. В emacs'е лично я никогда не успеваю запомнить все эти аккорды, Esc-Meta-Alt-Ctrl-Shift, C-x C-t M-x wtf-keybinding

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

В vim'е как-то всё просто: если не помнишь биндинг есть логичные команды и модификаторы буква/слово/предложение/абзац/функция, остальное всё по аналогии. А в EMACS толком не запоминается, приходится сваливаться через каждые 3 минуты в M-x describe-key, искать как эту vim команду в лиспе обозвали, итп.

команды vim у меня "помещаются в голове", емаксовые распальцовки и функции -- нет. Хотя, конечно вопрос практики.

Единственная прелесть что можно слиться с консолью и командовать кофеваркой в Emacs'е.

и да, Climacs круче Emacs потому что на правильном CL :))

sed для автоматизации рчень хорошо подходит.
но, для интерактивного редактирования _текстовых_ файлов vi/vim - самое то.
большой минус emacs'а как редактора - буферная реализация.
чуть что - начинают появляться новые и новые, разбивая рабочее пространство.
а это не есть хорошо. да и lisp в нём никчему. остальное см. выше.

почему так важны _текстовые_ файлы?
это не из-за того, что железо тогда было слабее.
бинарниками и тогда манипулировать можно было.
суть - в человекочитаемости. скрипты/конфиги/файлы данных - пишет человек.
и они должны быть ему понятны. всё для удобства человека.
машине, наоборот, всё как раз бинарниками удобней.
но, весь unixway вертится вокруг юзера. чтобы ему было удобней.
работать и _автоматизировать_ свою деятельность.

Отсыпь?

>но, для интерактивного редактирования _текстовых_ файлов

Есть ed :) Керниганом написанный. То есть "Ъ"!

>почему так важны _текстовые_ файлы?

Именно, потому в Plan9 интерфейс основанный на тексте. Текст более понятен и однозначно трактуется, в отличие от картинок :)

>Есть ed
>> ed -- первый стандартный текстовый редактор операционной системы UNIX,
>> применялся в начале 1970-х. Расширенная его версия, известная как ex,
>> послужила основой редактора vi.
почему таки был создан vi когда уже был ed? потому, что ed...
>> создавался в те
>> времена, когда мониторов не существовало и стандартным средством
>> ввода-вывода был телетайп.
>> После появления экранно-ориентированных редакторов ed стал
>> использоваться в первую очередь для автоматической обработки с помощью
>> командной оболочки UNIX, например, для применения патчей. В этом
>> смысле, он является родоначальником семейства потоковых редакторов,
>> таких, как sed.
во-о-от. а для именно _интерактивного_ редактирования был создан vi.

>ЗЫ. также замечу, что vi изначально был _стандартным_ текстовым редактором unix

4.2

"критика консольного разума":

> где в lynx, vi и иже с ними юниксвэйность?

надо не vi, бери уж сразу ex. И cat cmdfile.ex |ex editfile.txt > result.txt :))

> GUI - прежде всего для манипуляции с объектами. графическими объектами.

не обяз. графическими, но некими завершенными, целостными. при этом редко какой объект-документ состоит из одного сплошного куска, чаще таки есть "нелинейная", 2D, дерево, 3d структура, которая лучше представляет контент. Например, картинка -- "слои" в gimp. На уровне imagemagick никаких слоёв нет, "абстракции слипаются" в сплошной блоб.

> в то время, как unixway делает упор на текстовые потоки.

"We have persistent objects. They're called files" (c) Ken Thompson

заметь, потоки -- это 1D, без разбора "структуры"

> те, кому главное не рюшечки, а ехать, предпочитают клавиатуру мыши.

быстрее просто :))

> текст - это суть. графика - это рюшечки.

Рюшечки-завитушечки.. не всё так просто. Текст программы в Eclipse или в смоллтоковом браузере, -- линейный 1D или 2D (функции, классы, объекты) или 3d (аспекты, слои приложения)?

Эти рюшечки отражают адекватно структуру контента. В HTML DOM узлы отражают структуру, состав единиц (разделы/параграфы/предложения/слова) , и связи между единицами (ссылки)

> 0) всё строить из "кубиков" и никак иначе.

как из квадратных, круглых и треугольных кубиков с буквами АПОЖ слепить слово "СЧАСТЬЕ" ? :))

> vi/vim/lynx - один кубик.

а по моему, 2-3 разных :P

кстати, vim -- правильный кубик. Есть команды перемещения по 2d структуре, разделы/абзацы/предложения/слова. В Опере тоже есть, по уровням заголовков "вглубину". А в lynx?

> GUI софт не может быть unixway'ным по определению. т.к. в них упор идёт на графические объекты, а не текстовые потоки

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

Вот например удобный gui интерфейс:

1. гипертекст http://en.wikipedia.org/wiki/Project_Xanadu

2. данные http://xanadu.com/zigzag/

> ЗЫ. также замечу, что vi изначально был _стандартным_ текстовым редактором

а sam и acme -- стандартные в plan9, и интерфейс там с plumbing'ом, мышиными жестами и интеркликами мышью (ужос-ужос). Мало ли, может "мыши плакали, кололись.."

В принципе, согласен с оратором.

Еще несколько соображений насчет текста:

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

2. ИМХО наиболее ценное свойство текста для ПО в том, что он позволяет написанному приложению не иметь представления о том, как используют выходные данные и откуда оно берет свои входные данные. Формат текстовых данных всегда можно поправить, пропустив их через sed/awk и пр.

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

Примерно то же относится к емаксу с его расширениями.

А вот фильтры типа sort будут отлично работать и отдельно и в составе скриптов и с текстовым редактором и т.д.

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

p.s. /me юзает иксы

p.p.s. вещества - зло

бросай это дерьмо

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

Могу привести примеры, из которых видно, что с картинками _можно_ работать как с текстом. Например, SVG -- вроде и текст, а вроде и картинка.

Или же формат PNM -- тоже текстовый файл.

Или вот ещё отрывок из файла картинки, созданного программой tkpaint. Как видим,

.c create rectangle 102.0 86.0 413.0 285.0 -disabledwidth 0 -tags {Rectangle obj utag1}
.c create oval 199.0 3.0 469.0 101.0 -disabledwidth 0 -tags {Ellipse obj utag2}
.c create oval 143.0 95.0 281.0 167.0 -disabledwidth 0 -fill #bf08bf -tags {Ellipse obj utag3}
.c create text 330.0 169.0 -font {Helvetica 10 {}} -text Жопа -tags {text obj utag4}

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

> Могу привести примеры, из которых видно, что с картинками _можно_ работать как с текстом. Например, SVG -- вроде и текст, а вроде и картинка.

SVG веркторный формат, просто разметка - XML ... при чем тут текст ?)

>как из квадратных, круглых и треугольных кубиков с буквами АПОЖ слепить слово "СЧАСТЬЕ" ? :))

вы явно недооцениваете юниксвей... http://feb14.imgshare.us/KKL.png

> SVG веркторный формат, просто разметка - XML ... при чем тут текст ?)

XML это текст. Правда, структура у него плохогрепабельная.

это не картинки. картинки это битовые карты.

к тому же, текстовость этих "представлений" на самом деле бесполезна... текстом без специализированного редактора такое http://www.croczilla.com/svg/samples/tiger/tiger.svg не нарисуешь...

а xml, хрен из командной стоки распарсишь... проще будет скрипт на каком-нибудь пистоне написать...

т.е. парсить XML не Ъ ?

> повезло ещё что юниксвей не обязывает головой в пол биться...

ой-вей, юниксвей... Ж))

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

Эрик Ре(й)дмонд на тему текстовых метаданных и их прозрачности, расширяемости целую главу написал в "Art Of Unix Programming"

вдоль.

> т.е. парсить XML не Ъ ?

пока нет нормального, заюзываемого из шелла парсера, действительно не ѣ

> вы явно недооцениваете юниксвей... http://feb14.imgshare.us/KKL.png

аплодисменты :)) а теперь -- то же в 3D :)

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

┴PNG  ��� IHDR��h���┴��� S��IDATx°МщOH[ыъгЯШDМбf╔▓E╤╨pvSP╗⌡Q(╤I$#╓▀aDp.╓*Q┐бD*A╛ЮP├am#4ED*&N 7E▓бl╡╟▀┌┼cj┐$Я╥ЬДyЗ<ф$Гчs▌}©vчЫЩ╬ГцВ·sO∙Шг0��������������������������─>ЧКБ ЪЭЖМшЪu╓╚╚К┌Ц╨т╘■╛qUкёзy╓bКTJ╣Э╨ВAw╙²Gн���������������`▒/oрЩ:КХ·_TщС▀╙ё{~Qutо /╙▌jЫeQ╜Vж╠]╡P█≥ЛvШТТТЖЖЖннN,СЫ|Uq:²╘TЙ▐╘TйАpтЛ▓└Д(╛╜╜]╩vм0▄x<Нt:

файрфукс жжот

> Могу привести примеры, из которых видно, что с картинками _можно_ работать как с текстом. Например, SVG -- вроде и текст, а вроде и картинка.

могу привести примеры, когда 1D текст теряет внутреннюю структуру 2D-3D контента.

Тот же сорец в эклипсе, слои, рефакторинг.

Слои в картинках.

"Структурные тексты" вроде составленных из кусочков, со ссылками/цитатами с точностью до слова/предложения/абзаца (ссылками "по содержимому", где оно там в тексте находится -- дело десятое). "Правильный" гипертекст в стиле Xanadu.

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

Фрактальная фиговина, такая, чтобы сначала всё свернулось, а потом опять развернулось... и глазищами так, амор... ^U тьфу, о чём бишь это я..

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

с текстовыми 1D нельзя, ага. Ну так напиши 2D, 3D или N-мерные как в ZigZag во Xanadu.

> qUкёз

кукез десу

Открой для себя цыгвин

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

Ибо два начала - доброе и злое, не происходят одно от другого, и во всем отличны. Темное начало в определенный момент времени захотело захватить доброе, и напав внезапно, смогло поглотить некоторые частицы света. С целью вернуть свет обратно в царство света, добрые силы послали сначала Первочеловека, который принес в жертву пять своих сыновей, и доныне распятых во всем мироздании (т.н. Крест Первослаки), после чего никсоидскими силами был построен смешанный мир как тюрьма для архонтов-вендузятников, поглотивших свет. Светлые силы огнём красноглазия освобождают свет из смешанного мира и направляют его в мир подлинного света, для чего, в частности, проповедуют многообразные религии, сущность которых заключается только в том, чтобы забрать свет обратно. Когда весь свет, который может быть захвачен Машинами Спасения, будет выжат, Патрег обрушит структуры смешанного мира одну на другую, и подожжет оставшееся, чтобы наступил МИРОВОЙ ПОЖАР. В этом пожаре последний свет будет выбит из смешанного мира огнем, а темный остаток упадет вниз и так разделение двух начал будет восстановлено.

Лишь в МИРОВОМ ПОЖАРЕ голубоватым сиянием разгоряццо настоющие труЪ-программы, истинный vim, истинный emacs и т.д. Патрег! Зажигай!

причем здесь он ?

Поставь экстеншен "Open in browser" - у тебя будет выбор, как открывать - как веб-страницу, как текст, как картинку, или ещё как-то.

>аплодисменты :)) а теперь -- то же в 3D :)

таки триде - это как раз гуевые рюшечки и нефиг им в base делать %) а ежели шибко надо кому будет - пущай модули ваяют %))

> те, кому главное не рюшечки, а ехать, предпочитают...

ну так и езжай в /dev/null, а vi - не Ъ, ex - Ъ

Попытки реализовать поточность/прозрачность для GUI предпринимались в NeXT и BeOS

>vi - не Ъ, ex - Ъ
vi == ex -v

Нaдeюсь это предсмертная записка?

// :(

> vi == ex -v

Ну так неюзабелен со своими режимами бибиканья и порчи, а также нескриптабелен именно vi. А ex очень удобен, даже поудобнее emacs'овского M-x. Без ex'а vi не конкурент emacsen. К тому же некорректно сравнивать emacs и vi, сравнивать надо vim и emacs, кои оба работают в tui и gui и оба жирные на код (очень жирные, но слава богу модульные). Если vi и сравнивать с чем-то, то с ee или mg (тот что из openbsd).

ps, lynx научился нормально рисовать формы и таблицы по сравнению с w3m? если нет, то втопку это убожество.

Vim это форк vi?
Vim это полноценная замена vi?
Или Vim всего лишь навороченный вариант vi, для мощных машин?
Есть ли консольный Emacs? :)

> Есть ли консольный Emacs? :)

Нет, сынок, это фантастика.

>неюзабелен со своими режимами бибиканья и порчи
как минимум screen позволяет выбирать между писком динамика, морганием экрана
и полным отсутствием обоих.
а если речь идёт про многорежимность - это часть философии vi, которая и делает
его удобным.
>Без ex'а vi не конкурент
еще раз повторяю, что vi - VIsual режим ex'а. vi без ex'а не бывает.
ибо vi - это и есть ex в VIsual режиме.
>lynx научился нормально рисовать формы и таблицы по сравнению с w3m?
незнаю как рисует их w3m, но таблицы и фреймы lynx как неподдерживал
так и не поддерживает.
>Vim это форк vi?
да
>Vim это полноценная замена vi?
да. возможно и обратное, но не всегда.
>Или Vim всего лишь навороченный вариант vi, для мощных машин?
vim летает на i486DX4 с 12-ю метрами оперативки
>Есть ли консольный Emacs?
да

Он позволяет использовать юниксовые тулзы, работая не поверх юникса