LINUX.ORG.RU

vi, давай, до свиданья!

 , , ,


3

2

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

Что сказать?! Когда-то, я залез в технический раздел ЛОРа (каюсь, да, правила не читал, модераторы справедливо всё потёрли и шкворцов поубавилось, больше так не делаю) и развел там небольшой, но весёлый срачик на тему Vi vs Nano, где тулил за то, что nano это хорошо, удобно, просто и всем зайдет, а vi наоборот и с этим надо что-то делать.

И что теперь?! А вот что, в категории ChangeAcceptedF33 мы видим UseNanoByDefault, такие дела. И какие рассуждения там встречаем? А вот.

<...> You need to spend time learning how to use it, for even basic editing tasks. This increases the barrier to entry for those who are switching to Fedora and don't know how to use vi. It also makes things hard for those who don't particularly want to learn how to use vi. <...>

In contrast, Nano offers the kind of graphical text editing experience that people are used to, and therefore doesn't require specialist knowledge to use. <...>

Why make Nano default and vi optional, rather than the other way round? Because Nano is the option that everyone can use. 

Походу будет создан пакетик nano-default-editor, который вытянет nano и установит $EDITOR=nano, которая в федоре была не определена по умолчанию.

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

Ваши мнения. Что в других дистрах? Знаю что в дебиане nano всегда устанавливается, но по умолчанию кажется вызывается vi. В федоре его и ставить-то стали недавно, если не ошибаюсь ещё в 30-ке его не было, а тут раз – и такой поворот.

Для Ъ: https://fedoraproject.org/wiki/Changes/UseNanoByDefault

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

Шел 2020-й… в линункс всё еще не могли завезти аналог edit.com…

В 2020 году консольные анахронизмы никому не нужны. Для аварийных случаев nano хватает. Уже 30 лет как графика является обыденностью. Дальше ещё больше анахронизмов будет выпилено, прокрутку ядерной консоли уже выпилили.

Любители могут запустить оригинальный edit.com в DosBox или Wine NTVDM.

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

Медицина тут бессильна

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

Обмазывайтесь и наслаждайтесь.

Любителям нестандартных удовольствий еще рекомендую почитать сорцы parcellite на десерт. Вам понравится.

wandrien ★★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: Медицина тут бессильна от wandrien

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

Она хотя бы 33 МБ на диске не занимает. И без этого барахла хватает. Сейчас даже минимальные дистрибутивы Линукса без GUI жирнее старых полноценных графических ОС. А vi слишком криворукий, как тут писали (прибито гвоздями 80x25, нет поддержки Юникода).

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)

Редактор с копированием по Alt-6 это «большая психиатрия» уже.

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

yu-boot ★★★★★
()
Ответ на: комментарий от X512

В 2020 году консольные анахронизмы никому не нужны.

Уже выбросил эмулятор допотопного VT100? Покажи свой список пакетов, и если найдем там xterm или *-terminal, будем считать тебя балаболом.

bread
()
Последнее исправление: bread (всего исправлений: 2)
Ответ на: комментарий от X512

В 2020 году консольные анахронизмы никому не нужны.

Увы, всё гуёвое в линуксе дальше фуррифокса вызывает неиллюзорную боль. Без консоли и редактора никуда. Особенно сервисы какие-то крутить.

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

Увы, всё гуёвое в линуксе дальше фуррифокса вызывает неиллюзорную боль. Без консоли и редактора никуда. Особенно сервисы какие-то крутить.

+1

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

Уже выбросил эмулятор допотопного VT100?

Оно особо не мешает. В принципе всё, что не требуется для ввода команд и вывода цветного текста (чтобы ошибки компилятора показывать) можно выпилить.

X512 ★★★★★
()
Ответ на: комментарий от yu-boot

Без консоли и редактора никуда.

Консольный редактор то зачем?

Особенно сервисы какие-то крутить.

Зачем там псевдографика? systemctl без псевдографики работает.

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

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

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

Консольный редактор то зачем?

А зачем не-консольный? Что мне в том же gvim дадут эти иконки сверху и белый фон по умолчанию?

Зачем там псевдографика?

А где она в vim? То, что по Shift-V? А как ещё выделение обозначать-то? Нет, я знаю, есть уникумы, которые в консоли через mplayer(?) видеомонтажом занимаются, но это опять же большая психиатрия.

systemctl без псевдографики работает

Я не про эти сервисы. АТС крупную или бордер поадминь через GUI/web и через текстовый редактор. Незабываемый опыт. Возможно, у тех, кто мегабайты кода пишет, другие ощущения, у меня консоль и текст это именно ковыряние в конфигах в 99% случаев.

yu-boot ★★★★★
()
Ответ на: комментарий от bread

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

Выпилить доисторические escape последовательности и сигналы по изменению размеров окна, а также сделать нормальный перенос слов и будет не древний. В компьютерных играх тоже иногда терминал реализуют и там нет escape последовательностей VT100. Есть ещё подход «текст как интерфейс» когда команды можно писать в любом текстовом поле и stdout направлен в отдельное окно.

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

Это ты сейчас curses изобрел поверх ста слоёв жира aka гуи-тулкит? Продолжай, очень интересно. А зачем так страдать? Чтобы ты смог заработать на разработке и поддержке этого дерьмища?

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

Есть ещё подход «текст как интерфейс»

Вы это пробовали? И как результат?

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

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

А вроде умный парень.

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

Это ты сейчас curses изобрел поверх ста слоёв жира aka гуи-тулкит?

Оберон намного легковеснее и меньше по размеру, чем ваши ncurses и vim. Он даже на FPGA работает.

поверх ста слоёв жира aka гуи-тулкит

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

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

Это ваше nano ничуть не менее упоротое, чем vi. Шило на мыло.

^^^^

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

Ладно, что-то я разбухтелся. Каждый сам выбирает игрушки. Лишь бы это было не в стиле редхата: «мы подумали, и я решил».

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

Зачем тебе ввод команд? Это же консольный анахронизм.

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

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

Мне нравятся эксплуатационные качества псевдографики.

Она выглядит ясно и унифицированно. Как терминал настроил, так и выглядит.

Имунна к заскокам так называемых дизайнеров UI/UX без образования.

Переносима. Работает на всем что только можно придумать и будет работать еще много десятков лет.

Не зависит от лапши развесистых библиотек, в которых отваливается то одно, то другое.

Сразу готова к применению по сети.

Текст с любого элемента UI при необходимости можно скопировать — а не только то, что предусмотрели в тулките.

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

Никакое GUI и рядом не валялось.

И все что ты можешь сказать — «устарело». Это из области религиозных представлений. Кому ехать, а кому наяривать на новизну.

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

Переносима. Работает на всем что только можно придумать и будет работать еще много десятков лет.

C чего бы это, большинство tui библиотек отстой, которые не работают нигде кроме как у авторов. В отличие от GUI тулкитов. кроссплатформенных TUI тулкитов и нет, разве что Curses.

Но и то, это нужно писать под 3 вида Curses , на их общем подмножестве: PDCurses, NCurses, BSDCurses.

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

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

Никакое Tui и рядом не валялось.

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

Дружище подскажи плиз, есть ли в BlackBox многострочное поле вводa/вывода теста, на подобии компонента Memo в Дельфях. А то я чтот в BlackBox его не могу найти.

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

Мне нравятся эксплуатационные качества псевдографики.

Да я не против личных предпочтений. Тред о принятии nano как консольного редактора по умолчанию, который запросто меняется одной командой. Тащить 33 МБ или кривой vi и принуждать пользоваться редактором из которого даже непонятно как выйти - это никуда не годится. nano не идеален, но подходит лучше vi/vim как стандартный редактор. Есть редакторы возможно лучше nano, но они менее распространены, тяжеловесны либо требуют особых зависимостей при сборке.

Имунна к заскокам так называемых дизайнеров UI/UX без образования.

Переносима. Работает на всем что только можно придумать и будет работать еще много десятков лет.

Не зависит от лапши развесистых библиотек, в которых отваливается то одно, то другое.

Сразу готова к применению по сети.

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

X11 прекрасно удовлетворяет всем этим критериям. Даже Athena Widgets лучше псевдографики. Там нету знакогенераторной сетки и есть нормальный ввод. Я не понимаю почему псевдографика - это нормально, а Athena/Motif - нет. Либо доисторический VT100, либо жирные GTK3/Qt.

Текст с любого элемента UI при необходимости можно скопировать — а не только то, что предусмотрели в тулките.

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

Никакое GUI и рядом не валялось.

Мир не ограничивается GTK3/Qt.

Кому ехать, а кому наяривать на новизну.

Есть новизна, а есть прогресс. Переход от знакогенераторного интерфейса к графическому - это прогресс, а Motif -> GTK3 - это новизна. Также как переход от лошадей к автомобилям и от голубиной почты к телеграфу/интернету. Любой, даже старый автомобиль прогрессивнее лошади. Прогресс вытесняет предыдущие практики, оставляя их уделом фанатов.

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

кроссплатформенных

GUI приложения получаются с более компактным и простым кодом

Хотеть! Не подскажешь парочку, а то Qt что-то никак не подходит подходит под такое описание.

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

Дружище подскажи плиз, есть ли в BlackBox многострочное поле вводa/вывода теста, на подобии компонента Memo в Дельфях.

В свойствах текстового поля есть переключатель «Multi line». Есть ещё более мощный TextViews.View, к нему можно программно обращаться.

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

а то Qt что-то никак не подходит подходит под такое описание.

https://github.com/Immediate-Mode-UI/Nuklear

А вообще и Qt подходит под описание. В NCurses тебе почти все виджеты придётся писать самому, а в Qt использовать существующие. Понятно, что код на Qt будет проще, так как не нужно будет изобретать колёсо в сотый раз.

Просто нужно сравнивать сравнимое. То какой UI рисуют на TUI на GUI можно реализовать очень компактно.

То что с помощью GUI реализуют сложный UI, так это лишь потому что это возможно, а на TUI это просто не возможно.

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

То что с помощью GUI реализуют сложный UI, так это лишь потому что это возможно, а на TUI это просто не возможно.

Я вижу в этом преимущество TUI. Получившие сложный инструмент делают всё сложным тормозным и прожорливым. А с примитивной псевдографикой — хочешь-не хочешь, а сильно испортить не получится.

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

В свойствах текстового поля есть переключатель «Multi line». Есть ещё более мощный TextViews.View, к нему можно программно обращаться.

Спасибо

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

Инструмент должен быть адекватен задаче.

И поэтому нужно учить интерфейсы с принципиально другим управлением из другого измерения? Есть стандарт поведения текстового редактора и всё что ему не соответствует отправляется на помойку. Никто не мешает сделать простой не прожорливый GUI текстовый редактор и более того такие существуют.

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

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

И поэтому нужно учить интерфейсы с принципиально другим управлением из другого измерения?

Мне это начинает напоминать срач про WM/DE. Дружок, а с чего ты взял, что это инструменты инопланетные, а не ты сам из другого измерения? Тебе, о властелин своего непомерного ЭГО, кто такое право вообще дал?))

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

И поэтому нужно учить интерфейсы с принципиально другим управлением из другого измерения?

И именно по этому нано не нуно.

Vim не умеет редактировать большие файлы с подсветкой синтаксиса, а GUI редакторы умеют.

Не могу не согласиться: emacs во всём лучшем vim.

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

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

В текстовом поле, где вы прямо сейчас набрали сообщение, какой интерфейс? Как в Vim или всё-таки стандартный? Подавляющее большинство текстовых полей и редакторов реализуют стандартное поведение.

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

Есть стандарт поведения текстового редактора и всё что ему не соответствует отправляется на помойку

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

Никто не мешает сделать простой не прожорливый GUI текстовый редактор и более того такие существуют.

Шлицевые отвертки не умеют откручивать саморезы с головками PZ2. Надо запретить шлицевые отвертки?

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

одавляющее большинство текстовых полей и редакторов реализуют стандартное поведение.

И что дальше?

Давай все упростим. Подавляющее большинство десктопов занимает оффтопик. Онтопик фтопку?

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

Не могу не согласиться: emacs во всём лучшем vim.

Я ждал этого комментария. Emacs конечно лучше Vim: он графический, не тормозит, поддерживает пропорциональный текст и даже картинки вставлять можно.

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

Шлицевые отвертки не умеют откручивать саморезы с головками PZ2.

Шлицевые отвёртки - это тоже анахронизм и не нужны.

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

Шлицевые отвёртки - это тоже анахронизм и не нужны.

Все с тобой ясно.

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

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

Существует стопицот редакторов для терминала, из них найти хуже нано – это еще поискать надо. Опять 4.2. про «особые зависимости при сборке»…

X11 прекрасно удовлетворяет всем этим критериям.

Тот самый, который вот-вот объявят устаревшим и выкинут на мороз?

Что там насчёт простоты конструкции: сорцы XOrg почитайте – расскажите. Я читал.

Что там насчёт живучести экосистемы: существует ровно одна опенсорсная реализация X11 и полторы коммерческих.

Там нету знакогенераторной сетки

А сетка плохо, потому что … ?

и есть нормальный ввод

Чем в xterm/urxvt/тысячи_их ввод не нормальный?

Специальными инструментами это легко делается

Будем называть вещи своими именами. У русскоговорящих разработчиков это называется «костыли».

Даже Athena Widgets лучше псевдографики. […] Есть новизна, а есть прогресс. Переход от знакогенераторного интерфейса к графическому - это прогресс, а Motif -> GTK3 - это новизна.

Допустим, я в 2020 упорюсь и сделаю GUI приложение на Athena Widgets или Motif. Допустим, пользователи не отправят меня в дурку сразу, а даже будут им пользоваться. Теперь вопрос: какие преимущества получит моё приложение за счёт того, что оно сделано на Motif, а не на TUI? Какие конкретно? Приложение обрабатывает текстовую информацию, картинки ему не нужны.

Хотелось бы обнаружить зримые факторы «прогресса».

к графическому - это прогресс, а Motif -> GTK3 - это новизна. Также как переход от лошадей к автомобилям и от голубиной почты к телеграфу/интернету. Любой, даже старый автомобиль прогрессивнее лошади. Прогресс вытесняет предыдущие практики, оставляя их уделом фанатов.

Вот только Motif сдох настолько, что не остался даже уделом фанатов.

А софт с TUI не только не умер, но и процветает – постоянно появляются новые приложения, дорабатываются существующие. Этот софт, который в последние годы развивается динамичнее, чем GUI, назвать «уделом фанатов» – это быть начисто оторванным от реальности.

Существует причина, почему TUI пережило десятилетия, а десятки тулкитов GUI и приложений под них появились и исчезли, и выжили только пара основных тулкитов, в которых корпорации вкидывают деньги. У процессов должны быть объективные основания. Часть этих оснований я назвал выше. Но ты эти основания игнорируешь.

Еще из того, что я не упомянул ранее:

Приложения с командной строкой легко дорабатываются до TUI, а приложения с TUI легко дорабатываются до командной строки и пакетного исполнения. Это создаёт единую среду без дублирования функциональности, кода и усилий разработчика. В отличие от этого, софт с GUI создаёт заметно отличающийся режим как на уровне кода, так и использования. А режимы UI – это плохо.

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

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

Тут же где-то приводили ссылку. Как раз сравнение vim vs. GUI редакторы на больших файлах: https://devpew.com/blog/vim, см. Пример #2. Большой файл. так что не нужно распространять злостное 4.2 тут, уж что-то а vim неплохо взаимодействует с файлами больших размеров. Уж точно лучше тупого Kate из состава KDE, которым я тоже часто пользуюсь и который постоянно сыпет ошибками и тормозит на больших файлах. Лимиты у него исчёрпываются на 10000 LOC || 10 MiB.

Emacs конечно лучше Vim: он графический

Нет. Он без проблем может быть консольным. И много кто из Emacs’еров его так и юзают, например, на серверах.

Emacs конечно лучше Vim: не тормозит

Emacs всегда работал несколько медленнее Vim. Испокон веков. Там внутри интерпретатор диалекта Lisp, ELisp, не слишком быстрый. Но emacs был, конечно, всегда более функциональным.

Emacs конечно лучше Vim: поддерживает пропорциональный текст и даже картинки вставлять можно.

Это конечно так нужно в редакторе для программистов и IT-специалистов. Киллер-фича. Да, я знаю, что господин RMS неоднократно заявлял о том, что было бы круто из Emacs сделать текстовый процессор и офисный пакет. Однако, как видно, Emacs убийцей Microsoft Office и MS WordPad так и не стал.

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

Emacs … не тормозит

4.2 лютое. Но хотя с чем сравнивать конечно. И для емакса графика опциональна, он вполне себе работает в консоли. Еще одно подтверждение, что графика редактору как собаке пятая нога.

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

Шлицевые отвёртки - это тоже анахронизм и не нужны.

Ну с этим я полностью согласен. Только PH и PZ тоже заберите на задворки истории. Оставьте Torx’ы и шестигранники. И люди скажут вам спасибо.

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

Нет. Он без проблем может быть консольным. И много кто из Emacs’еров его так и юзают, например, на серверах.

Только новички, которые ещё не дочитали до tramp-mode. Технически

emacs -nw

всё ещё работает, но только как дань совместимости.

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

Даже Athena Widgets лучше псевдографики. Там нету знакогенераторной сетки и есть нормальный ввод. Я не понимаю почему псевдографика - это нормально, а Athena/Motif - нет.

Потому что псевдографика может выглядеть так:

https://github.com/Swordfish90/cool-retro-term

Ты на пседвографику можешь натянуть свой люмибый моноширинный векторный шрифт и эстетически наслаждаться филигранным текстом в терминале на HiDPI 4K-дисплее.

А Athena/Motif всегда будет выглядеть вот так вот вырвиглазно:

https://upload.wikimedia.org/wikipedia/commons/2/24/Screenshot_of_%22Xman%22_program.png

https://guidebookgallery.org/pics/gui/desktop/firstrun/cde15solaris9.png

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

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

всё ещё работает, но только как дань совместимости.

Я недавно запускал emacs на сервере, без всяких -nw, может быть он делает fallback на этот режим, если не обнаруживает X.Org или Wayland?

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

А Athena/Motif всегда будет выглядеть вот так вот вырвиглазно. И ничего этим тулкитам больше не поможет. Они застыли во времени.

Не ну… теоретически, их можно пропатчить. И писать на них какие-нибудь мелкие тулзы just for fun. Где-то были даже подобные проекты.

Но без заметного вливания сил ничего не сделать с отсутствием поддержки юникода. Это останавливает от такого fun.

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