После трёх лет разработки и после более 10 лет развития ветки 7.x состоялся (https://groups.google.com/forum/#!topic/vim_announce/EKTuhjF...) релиз текстового редактора Vim 8.0 (http://www.vim.org/). Код Vim распространяется (https://github.com/vim/vim/) под собственной копилефт лицензией (http://vimdoc.sourceforge.net/htmldoc/uganda.html#license), совместимой с GPL, и позволяющей без ограничений использовать, распространять и перерабатывать код. Основная особенность лицензии Vim связана с возвратом изменений - реализованные в сторонних продуктах улучшения должны быть переданы в исходный проект, если мэйнтейнер Vim посчитает эти улучшения заслуживающими внимания и отправит соответствующий запрос. По типу распространения, Vim относится к Сharityware, т.е. вместо продажи программы или сбора пожертвований на нужды проекта, авторы Vim просят перечислить любую сумму на благотворительность, если программа понравится пользователю.
Основные новшества (https://raw.githubusercontent.com/vim/vim/master/runtime/doc...):- Поддержка асинхронного ввода/вывода и каналов, позволяющих обмениваться сообщениями с другими процессами в фоновом режиме, что даёт возможность отправлять задания отдельным серверным обработчикам и принимать результаты не прерывая работу основного процесса Vim. Данные при взаимодействии между процессами могут передаваться в формате JSON, что позволяет создавать достаточно сложные плагины на любом языке программирования, работающие в форме отдельно выполняемых серверных процессов;
- Концепция работ, позволяющая запустить работу, взаимодействовать с ней и остановить при необходимости. Например, в форме работы можно запустить специальный процесс для проверки синтаксиса или автодополнения кода. Работы могут записывать и читать содержимое буфера или файла, а также взаимодействовать с основным процессом через каналы;
- Таймеры, которые позволяют запускать функции через определённое время или через повторяющиеся промежутки времени;
- Дополнительные средства для косвенного вызова функций - "Partial", которые в отличие от Funcref кроме ссылки на функцию дополнительно прикрепляют к запросу аргументы и словари, что удобно для совершения callback-обращений через каналы и таймеры;
- Поддержка лямбда-выражений и замыканий для быстрого создания пользовательских функций ("{args -> expr}");- Реализация пакетов для установки, обновления и управления плагинами;
- Возможность обращения к окнам по привязанным к ним уникальным идентификаторам, а не по порядковому номеру окна;
- Из viminfo информация теперь извлекается на основании времени записи, а не последнего добавленного элемента;
- Добавлена опция 'breakindent' для смещения строк без нарушения отступов;- Добавлена опция 'renderoptions', позволяющая задействовать DirectX (DirectWrite) для отрисовки вывода в Windows;
- Поддержка сборки графического интерфейса с GTK+ 3. При наличии GTK+ 2 и GTK+ 3 по умолчанию по-прежнему используется GTK+ 2.
URL: https://groups.google.com/forum/#!topic/vim_announce/EKTuhjF...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45128
Лучше бы сделали настройку длительности и частоты бибиканья. А то каких-то замкнутых лямбд понапихивали, а как что-то полезное сделать -- хренушки.
за бибиканье отвечает твой эмулятор tty
Я знаю, но про удобство как всегда никто не думает. Это же vim!
Типичный дилетант. Не знает, что такое замыкания и лямбды. Делает неграмотные замечания, и каждый раз когда ему на это указывают, говорит "Я знаю, я знаю", и оправдывается тем, что якобы его беспокоило всего лишь какое-то неопределенное "удобство". Зачем тогда ему нужен vim? Ему лучше пользоваться Notepad и Word - там как раз созданы все "удобства" для таких грамотеев.
унылый зануда.
> унылый зануда.Если бы это было просто чьё-то занудство, вас бы это так не беспокоило.
Кто-то забыл, что Linux - это fun?Веселее, товарищи! )
>Веселее, товарищи! )Угу, вспоминается как лет 17 назад пришлось через подключение по (кажись) COM-порту голым ed'ом shell-портянку (ок. 900 строк) редактировать. После 2-х дней бухания всей конторой. Я пытаюсь попасть в клавишу, а под столом, с комментариями откуда-то со входной арки (дверь кончилась) идет спор, что мне набирать на клаве. Из 5 присутсвтующих только я изучал английский и никто не мог внятно говорить.
Да ладно, знаем мы что такое короткие замыкания и лямбда-зонды ;)
Это у вас в мозгу зонд невежества, помогающий вам оправдывать вашу неспособность к обучению.
> Лучше бы сделали настройку длительности и частоты бибиканья. А то каких-то замкнутых
> лямбд понапихивали, а как что-то полезное сделать -- хренушки.setterm -bfreq
Лучше сделайте настройку частоты бесмысленных комментариев, вами генерируемых.
Хороший редактор, рад что он продолжает развиваться.
многопоточности так и нет. Это хорошо или плохо?
> Поддержка асинхронного ввода/вывода и каналов, позволяющих обмениваться сообщениями с другими процессами в фоновом режимеА это чем не многопоточность?
>> Поддержка асинхронного ввода/вывода и каналов,
>> позволяющих обмениваться сообщениями с другими процессами в фоновом режиме
> А это чем не многопоточность?Это про IPC разного рода, а не про multithreading; впрочем, Редактору как-то за глаза хватало и одного ядра на всём, что у меня бывало под *nix, начиная с 486.
PS: "Данные при взаимодействии между процессами могут передаваться в формате JSON" напомнило недавнее обсуждение насчёт структурированных пайпов.
Почему не на Rust?
уже другой есть:
https://github.com/google/xi-editor
>You need Xcode 7.3 (only on Mac)Nope, thanks.
It is initially built for Mac OS X, using Cocoa for the user interface, but other targets are planned.
Ну хоть бы написали тогда примерно через сколько лет имеет смысл заглянуть посмотреть не добавили ли поддержку Linux...
> Ну хоть бы написали тогда примерно через сколько лет имеет смысл заглянуть
> посмотреть не добавили ли поддержку Linux...Насколько я понял, там они разделили core и front-end. Core платформонезависимое и его, похоже, можно собрать под linux хоть сейчас.
И в описании они там еще дают ссылку на экспериментальный front-end на rust:https://github.com/potocpav/xi_glium
Ну то такое, Rust это очень интересно, но тема то про Vim :)
Зыс минз ю онли нид икскоуд иф ю а он э мэк. Озэрвайз, джисиси шуд би джаст окей.Ай персоналли дид нот трай ий, зоу.
Студент МГИМО ?
Аск.
В советском союзе линукс не может русифицировать пользователей.
Rust устареет через год. Снова переписывать?
Конечно! А зачем ещё нужны программисты?
Согласно по твоей логике тебе можно каждые полгода ломать ногу или заражать опасным вирусом, пусть врачи лечат, а иначе зачем они нужны. Как вариант каждый день выгружать машину с мусором под твоим окном, пусть дворники убирают. И так далее....
Когда писали Vim Rust`а даже в далеких планах не было. С 1991 года появилось много новых языков программирования, о многих из них уже и забыли. Остается неизменным лишь положение с C/C++. Хочешь гарантию не переписывать программу каждые N-лет - пиши на проверенных временем языках программирования, а таких можно пересчитать по палцем...
Потому что вим не для рустеров.
Emacs...
Пока только RC.
Нет, vim.
Нет, emacs.
Вот эти самые "каналы" и "работы" давно пора стандартизировать на уровне ОС. А то их только ленивый не переизобрёл ещё - от разных самопальных IPC в оконных менеджерах до D-Bus.
DBus уже давно стал стандартом.
D-Dub - г-но.
DCOP - рулит
Я бы сказал про DCOP "устарело", но оно настолько устарело, что даже говорить про него "устарело" уже устарело.
Но добавлять в vim зависимоть от dbus - глупо
Надо сделать опциональной фичей.
> Но добавлять в vim зависимоть от dbus - глупоА зависимость тут причём, это ж не библиотека, а стандарт на передачу данных.
Плюсую предыдущего оратора, DBus - гoвно.http://gentooexperimental.org/~patrick/weblog/archives/2014-...
И как показало обсуждение kdbus - ещё и медленное гoвно.
kdbus уже выкинули и не вспоминают. Неудачная реализация. Даже Линус хотел бы иметь такой IPC в ядре, но kdbus он опустил
Можно бинарный RPC https://zeroc.com/, точнее даже ORPC. К тому же кроссплатформенный.
Зато он чёртов монстр
Во-первых, он стал стандартом в разных DE. Где DE и где тот же vim?Во-вторых, плагины для редактора или, скажем, IDE? реализованные через D-Bus? Как-то странно это выглядит.
В-третьих, не уверен в производительности D-Bus.
В-четвёртых, это шина. Я говорил скорее про двунаправленное взаимодействие.
На уровне ОС есть процессы, и каналы :) . То что реализована здесь, должно быть в пространстве пользователя
Скорее всего - да. Но - например, в glibc. То есть чтобы было на любом мало-мальски полноценном линуксе, и чтобы была понятная заявка, что именно это - стандарт.
Форк тебе дает "работы", а сокеты "каналы". Так чего именно тебе не хватает от ОС?
стандартного протокола взаимодействия, независимого от языка, вестимо.
> стандартного протокола взаимодействия, независимого от языка, вестимо."открытый протокол ... упрощения интеграции поддержки новых языков ... обеспечена поддержка более 150 языков ... может использоваться в разных ... Продвижение нового протокола производится совместно"
Уже скоро в vim! http://www.opennet.ru/opennews/art.shtml?num=44682
Есть сокеты, они позволяют посылать и принимать произвольные данные. Эта функциональность от языка не зависит. Поверх сокетов уже лежит конкретный протокол обмена данными, например такие весьма различные протоколы как http и ssh. Надо ли объяснять, что нельзя все эти различные протоколы заменить неким универсальным?
Интересный вопрос - повлияет ли этот релиз на развитие neovim
Там вроде тоже неплохие идеи были: libuv, отвязка от прибитого гвоздями интерфейса. Пацанам нужно было делать работу этапами, чтобы можно было влить ее обратно в вим, а они галопом по европам зарефакторили все, и всё
>Пацанам нужно было делать работу этапами, чтобы можно было влить ее обратно в вимneovim появился по тем же причинам, что libav и io.js - люди пытались контрибьютить в vim, но их пулл реквесты долго рассматривали и отклоняли без объяснения. Сейчас neovim развивается без оглядки на совместимость, там даже .vimrc переименовали в init.vim и перенесли в $XDG_CONFIG_HOME
никак не повлияет, neovim лучше во всех отношениях. Там уже есть куча популярных асинхронных плагинов, куча фронтендов на чем угодно, и т.п.
Где посмотреть эту кучу? На neovim.io последняя новость почти год назад
Нашёл, https://github.com/neovim/neovim/wiki/Related-projects
Честно говоря, эта 'куча' не впечатляет, даже не рядом с Вимом. Лет через 5 при сохранениии темпов может и будет сравнимо.
Как это ещё никто не "пошутил" про 2 режима работы vim?
Как никто? Я же это сделал в самом первом сообщении к новости!
Кто-нибудь ещё не шутил про два режима работы vim?
Уверен, что да. Существует довольно большое множество людей, которые ещё пока не знакомы с трагикомическим дуализмом vim`а. Соответственно никто из них не мог ещё пошутить по поводу двух режимов.
> Уверен, что да. Существует довольно большое множество людей, которые ещё пока не
> знакомы с трагикомическим дуализмом vim`а. Соответственно никто из них не мог
> ещё пошутить по поводу двух режимов.вообще-то у vim режима 3. а то, про что вы рассуждаете - vi.
И какой третий? Издевательски ожидать пока пользователь поймёт как выйти из этого бибикающего ада?
> И какой третий? Издевательски ожидать пока пользователь поймёт как выйти из этого
> бибикающего ада?разукрасить, вообще-то.
а что до "выйти из ада" так это про nano, к примеру.
В nano выход подсвечен и очевиден, насколько помню...
Это не помогает. Я не смог выйти. Пришлось закрыть консоль…
Зачем тебе текстовый редактор если ты не умеешь читать? В nano же основные хоткеи в нижнем меню всегда прописаны.
Ему это не нужно, он умеет писать.
Это вы из joe не пытались выйти. Я, лет эдак 18 назад, умел из joe выходить только по Ctrl+Z, а потом kill. А из vi/vim научился сразу. Так что vi/vim это не страшно, это прекрасно.
^K X?
Разве ты не знаешь, что удобство редактора обратно пропорционально адекватности иго интерфейса? Именно поэтому vim и emacs считаются самыми удобными. Joe`s мог бы с ними посоперничать, но он почему-то малоизвестен. Не могу понять почему. Корявое и невменяемое управление есть, а больше для хорошего редактора ничего и не нужно...
> Это вы из joe не пытались выйти. Я, лет эдак 18 назадТоже с 1998? :)
В 1997 году, как познакомился с joe, так и не мог из него выйти :)
> В 1997 году, как познакомился с joe, так и не мог из
> него выйти :)Я им пользовался какое-то время на Слаке, ещё на 2.4 ведре. Как раз тогда vi мне казался сложным через чур. Вроде нормально всё было. Сейчас правда уже не помню как там было чего.
> Я им пользовался какое-то время на Слаке, ещё на 2.4 ведреВ 1997 году, когда я познакомился с joe на FreeBSD 2.2.5, до ядра Linux 2.4 было еще, как до Китая раком, линуховое ядро в то время было 2.0.чего-то-там и FreeBSD еще была удобней для десктопа, чем линуховые дистрибы. Я на GNU/Linux сбежал в 2000 году только.
> Это вы из joe не пытались выйти. Я, лет эдак 18 назад,
> умел из joe выходить только по Ctrl+Z, а потом kill. АУ него 18 лет назад в правом верхнем углу не было ссылки на Help?
> У него 18 лет назад в правом верхнем углу не было ссылки
> на Help?Нет, не было.
>> У него 18 лет назад в правом верхнем углу не было ссылки
>> на Help?
> Нет, не было.Врёте. Даже в версии 1.0.8 в 1992-м году было. Опенсорс не даст соврать - https://sourceforge.net/projects/joe-editor/files/Historic/
> Это вы из joe не пытались выйти. Я, лет эдак 18 назад,
> умел из joe выходить только по Ctrl+Z, а потом kill.а нечего в наш wordstar лазить наобум. на интервью со звездой надо приходить подготовленным.
Запаситесь корвалолом, ибо это - режим командной строки, также известный как ex-mode. Перейти в него чтобы, надо нажать gQ.
normal, insert, visual + ex mode (ed tool)
> normal, insert, visual + ex mode (ed tool)это что за заклинание, откуда? дьявола вызываете?
> это что за заклинание, откуда? дьявола вызываете?это еще без визуального режима блоком
> Кто-нибудь ещё не шутил про два режима работы vim?о каких двух из 12-ти ты говоришь?
https://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Modes
>> Кто-нибудь ещё не шутил про два режима работы vim?
> о каких двух из 12-ти ты говоришь?sorry, не ту ссылку вставил
вот правильнаяhttp://vimdoc.sourceforge.net/htmldoc/intro.html#vim-modes-i...
Кстати, а где облигатное упоминание systemd?vim-systemd, anyone?
Наоборот же, vimd!
> Кстати, а где облигатное упоминание systemd?
> vim-systemd, anyone?Ещё один клиндэ словивший.
> Кстати, а где облигатное упоминание systemd?
> vim-systemd, anyone?Присоединяюсь. Хочется послушать очередную порцию искрометного юмора опеннета про systemd.
> Присоединяюсь. Хочется послушать очередную порцию искрометного юмора опеннета про systemd.уже одно упоминание systemd вслух может считается за юмор
Я так понимаю, вим теперь содержит всё необходимое для написания аналога любого emacs-плагина? Или остались ещё неохваченные области?
Vim не умеет выводить пиксельную графику.
> Vim не умеет выводить пиксельную графикуславянский текстовый редактор TEA - умеет!
TEA не славянский редактор, а обыкновенный мудаческий. Ничего «славянского» там нет, есть только шутки психически больного автора.
Неа, при таком подходе, конечно, можно наладить взаимодействие с любой программой, но тем не менее нельзя добиться той же степени взаимопроникновения модулей (плагинов), которое есть в emacs.Вот например, есть два модуля, которые могут работать раздельно: bbdb и gnus. Первый - база данных для всего на свете с интерфейсами поиска и вставки в нужное место. Второй - почтовый клиент. Но если поставить их вместе, то gnus внезапно как по волшебству обогатится функционалом поиска по адресной книге. А если поставить w3m (интерфейс emacs к одноимённому консольному рендереру/браузеру веб-страниц), то html-письма внезапно начнут прилично отображаться на экране.
Такое возможно именно что за счёт хуков да за счёт целостности базовой платформы Emacs.
А можно уточнить, плагины для этого знают друг о друге? Или gnus выводит данные с неким типом «html», а их уже подбирает плагин w3m?Ну или ссылочку на краткое описание этих механизмов, если можно, желательно на английском. Я и сам погуглю, конечно, но был бы благодарен за точную ссыль.
> А можно уточнить, плагины для этого знают друг о друге?Разумеется, они должны знать друг о друге. По крайней мере один модуль
должен знать о существовании другого и в какие хуки что можно
добавить.bbdb при запуске проверяет наличие gnus и добавляет нужные функции в
хуки gnus. Аналогичное поведение у него и для других почтовых клиентов
в emacs.> Или gnus выводит данные с неким типом «html», а их уже подбирает
> плагин w3m?За w3m не скажу сходу, но я полагаю, что у gnus есть специальный хук,
который дёргается перед тем, как вывести html-письмо на экран.
то бишь, никакой «цельной системы» и «интеграции плугинов» нет.
> то бишь, никакой «цельной системы» и «интеграции плугинов» нет.arisu, Вы как всегда ничего не поняли.
Система цельная потому что все её программы выполняются в lisp-машине внутри Emacs и написаны на elisp.
Тесная интеграция плагинов достигается именно за счёт многочисленных хуков, которыми изобилует любой модуль.
А, ну такое и в виме вполне можно устроить. Афаик, плагины вполне учитывают существование наиболее популярных из собратьев, например файлменеджера (nerdtree, вроде бы). Правда, не уверен, что этот подход сильно развит, да и неудобство vimscript все-таки не способствует.Язык же как раз не помеха — лишь бы функции из плагинов экспортировались в главное вимовское окружение vimscript'а, а оттуда их можно вызывать опять же любым из поддерживаемых языков.
Я было понадеялся на более универсальный механизм со стороны самого емакса, потому что как раз тянет позырить в его лиспоту и систему плагинов.
Уточню: взаимодействие между языками работает без межпроцессной возни, а на встроенной в вим поддержке питона, перла и т.д. (Что там сейчас сделано между процессами — не знаю.)
> А, ну такое и в виме вполне можно устроить. Афаик, плагины вполне
> учитывают существование наиболее популярных из собратьев.Ну тут весь вопрос: кто и с какой стороны должен это существование учитывать.
> Язык же как раз не помеха — лишь бы функции из плагинов
> экспортировались в главное вимовское окружение vimscript'а, а оттуда их можно вызывать
> опять же любым из поддерживаемых языков.Прежде, чем ответить, хочу всё-таки уточнить: плагины импортируют свои функции в некое общее окружение, а другие модули проверяют, есть ли эти функции в окружении, и если есть, то расширяют свой функционал ими?
Если я всё понял правильно, и всё так, как я только что уточнил выше, то в emacs ситуация прямо противоположная. Каждый плагин помимо основного функционала, предоставляет некоторое количество хуков - грубо говоря, мест, где можно складировать функции. Когда происходит какое-то действие, связанное с хуком, все функции хука последовательно выполняются.
Таким образом gnus ничего не знает о существовании bbdb, и со стороны gnus никакой поддержки не требуется. А вот bbdb знает о существовании gnus и вставляет свои функции в его хуки. Эти функции, как правило, добавляют какому-нибудь режиму работы (с которым связан хук) дополнительные клавиатурные сочетания. Я это к тому, что не gnus проверяет, доступны ли функции, предоставляемые bbdb, а bbdb подставляет свои функции в gnus.
Гибкость проявляется вот ещё в чём: даже если бы bbdb и gnus ничего друг о друге не знали бы, пользователь всегда может сам вставить нужную функцию в нужный хук.
> bbdb знает о существовании gnusНу не самое элегантное решение. Работает только пока существует лишь полтора плагина типа gnus, о которых должен знать bbdb. Как только число таких плагинов переваливает за сотню, код bbdb для поддержки их всех становится грустным.
> пользователь всегда может сам вставить нужную функцию в нужный хук
Это уже лучше, но явно подразумевает, что пользователь прочитал существенную часть документации (и что документация по хукам и функциям вообще существует).
Идеальным был бы вариант, по которому привязку функций к хукам каким-то образом выполнял редактор. А не пользователь и не сами плагины.
>> bbdb знает о существовании gnus
> Ну не самое элегантное решение. Работает только пока существует лишь
> полтора плагина типа gnus, о которых должен знать bbdb. Как только
> число таких плагинов переваливает за сотню, код bbdb для поддержки
> их всех становится грустным.Ну, на данный момент bbdb поддерживает порядка 6-7 разнообразных
почтовиков, если мне память не изменяет. Из них я о нескольких даже не
слышал.>> пользователь всегда может сам вставить нужную функцию в нужный хук
> Это уже лучше, но явно подразумевает, что пользователь прочитал существенную часть документацииЭто слабая сторона Emacs. Приходится читать и писать очень много документации.
> (и что документация по хукам и функциям вообще существует).
Это сильная сторона Emacs. В большинстве случаев документация есть.
> Идеальным был бы вариант, по которому привязку функций к хукам каким-то образом
> выполнял редактор. А не пользователь и не сами плагины.Сомневаюсь, что это возможно. Вот уж кто точно ничего не знает о
конкретных хуках и функциях, так это сам emacs. О предназначении оных
известно только разработчикам (и пользователям).
Механим хуков я понимаю. Усомнился было, можно ли в виме привязать несколько функций на один хук, но оказывается, vimscript позволяет функции first-class, хоть и опять же неудобным манером.
Это теоретически — использует ли кто-нибудь хуки на самом деле, не знаю.Точно знаю, что в виме плагины экспортируют глобальные функции, а их можно вызывать хоть по своим хоткеям, хоть из кода. Например, файлменеджер nerdtree предоставляет функции, по которым показывает свою навигацию по файлам, а плагины-иде для разных языков дергают эти функции в своем «интерфейсе».
Конкретный
>[оверквотинг удален]
> все функции хука последовательно выполняются.
> Таким образом gnus ничего не знает о существовании bbdb, и со стороны
> gnus никакой поддержки не требуется. А вот bbdb знает о существовании
> gnus и вставляет свои функции в его хуки. Эти функции, как
> правило, добавляют какому-нибудь режиму работы (с которым связан хук) дополнительные клавиатурные
> сочетания. Я это к тому, что не gnus проверяет, доступны ли
> функции, предоставляемые bbdb, а bbdb подставляет свои функции в gnus.
> Гибкость проявляется вот ещё в чём: даже если бы bbdb и gnus
> ничего друг о друге не знали бы, пользователь всегда может сам
> вставить нужную функцию в нужный хук.
Прошу прощения за кривой коммент.Конкретный пример с gnus и bbdb мне кажется странным — вроде как база это более низкоуровневый функционал, и почтовику лучше знать, где в его интерфейсе понадобится поиск по базе.
> Прошу прощения за кривой коммент.
> Конкретный пример с gnus и bbdb мне кажется странным — вроде как
> база это более низкоуровневый функционал, и почтовику лучше знать, где в
> его интерфейсе понадобится поиск по базе.Не думаю, что это более низкоуровневый функционал. Они на равных, и могут работать друг без друга прекрасно. К тому же, bbdb лучше знать точки входа gnus, в которые можно себя подпихнуть.
Впрочем, идея с обратным направлением подключения плагинов ясна — пользователь может установить bbdb, а может какую-нибудь другую базу.Осталось выяснить, насколько «общая» эта система и можно ли со стороны почтовика тоже сменить gnus на что-нибудь другое, оставив хуки «тут нужен поиск по имеилам». Теоретически, конечно, можно это сделать если не просто более общими названиями хуков, то некими шаблонами в их названиях. Но подозреваю, что такая система быстро разваливается под требованиями к своей гибкости.
> Впрочем, идея с обратным направлением подключения плагинов ясна — пользователь может
> установить bbdb, а может какую-нибудь другую базу.Более того, он может установить какой-нибудь другой почтовик, и всё,
что потребуется - подпихнуть те же самые функции bbdb в хуки этого
самого почтовика (если bbdb, конечно, не сделает этого при загрузке
автоматом).> Осталось выяснить, насколько «общая» эта система и можно ли со стороны почтовика
> тоже сменить gnus на что-нибудь другое, оставив хуки «тут нужен поиск
> по имеилам».Не знаю, это сильно зависит от почтовика. Gnus, например, для
написания сообщений включает message-mode. У него одни хуки. Другие же
почтовики могут использовать, например, дефолтный (iirc он
поставляется с emacs) mail-mode. И у него уже свои хуки.> Теоретически, конечно, можно это сделать если не просто более
> общими названиями хуков, то некими шаблонами в их названиях. Но подозреваю,
> что такая система быстро разваливается под требованиями к своей гибкости.Не думаю, что это хорошая идея. Возникнет путаница между хуками. Лучше
будет, если каждый режим работы будет использовать свои хуки.
Я бы сказал так: когда пользователь конфигурирует свой emacs, он
именно тем и занимается, что добавляет разные функции в разные
хуки. Так что совсем "по волшебству", чтобы всё само заработало,
обычно не бывает (bbdb и gnus просто такое редкое исключение).Но с другой стороны, это предоставляет пользователю интересные
возможности. Так, например, при включении message-mode дыргается
message-mode-hook, и я в своём конфигу emacs добавил в него
auto-fill-mode (который автоматом переносит строку при превышении
какой-то ширины текста) и turn-on-flyspell, который проверяет
правописание.Я не уверен, что пользователи в 100% случаев могут хотеть
auto-fill-mode при написании письма, равно как некоторые прекрасно
обходятся без flyspell.Так что хуки в данном случае - механизм очень удобный.
> Не знаю, это сильно зависит от почтовика. Gnus, например, для
> написания сообщений включает message-mode. У него одни хуки. Другие же
> почтовики могут использовать, например, дефолтный (iirc он
> поставляется с emacs) mail-mode. И у него уже свои хуки.вот это и называется «стройная система костылей».
Это называется: arisu не нравится emacs. ;)
это называется: «arisu не нравится, когда городят чушь». такой «механизм интеграции» — поделка из палок и жёлудей. и неважно, хуки ли, или экспорты: что совой об пень, что пнём об сову. удобная расширяемая система — это компоненты и message passing. и вот тогда действительно получается гибко и расширяемо, и не надо в каждую фигню забивать знание о куче других фиговин и их эрогенных зонах.
> это называется: «arisu не нравится, когда городят чушь».arisu считает, что городить чушь - исключительно его прерогатива?
> удобная расширяемая система — это компоненты и message passing. и
> вот тогда действительно получается гибко и расширяемо, и не надо в
> каждую фигню забивать знание о куче других фиговин и их эрогенных
> зонах.Message passing, чтобы передать произвольную *функцию*, которая будет
вызвана при наступлении события в произвольном модуле -- это довольно
сложно, порождает оверхед в виде дополнительных syscall-ов, и к тому
же предполагает знание об этих самых событиях (а следовательно и
знание о существовании модулей, которые их генерируют).И Вы думаете, что это удобнее? :)
"arisu не нравится emacs, зато arisu нравится dbus"
Поправлю: message passing не подразумевает разделение процессов, его можно устроить и внутри одного рантайма. См. Smalltalk и ObjC, напр.
Правда, оно будет примерно равнофиолетово подписке на хуки, разве что вынесено в общий код.Но вообще я, как мимокрокодил, не понимаю, зачем вы кормите троллей. Комментарии к новостям опеннета из-за этого крайне бесполезны.
> Поправлю: message passing не подразумевает разделение процессов, его можно устроить и внутри
> одного рантайма. См. Smalltalk и ObjC, напр.
> Правда, оно будет примерно равнофиолетово подписке на хуки, разве что вынесено в
> общий код.А. Это объясняет, почему вызов методов объектов в Racket называется send. Забыл.
Ну что ж, тогда это действительно равносильно хукам.> Но вообще я, как мимокрокодил, не понимаю, зачем вы кормите троллей.
Эх, да разве ж это тролли. Так, пытаются воду помутить. Смотреть жалко.
> Комментарии к новостям опеннета из-за этого крайне бесполезны.
Мне кажется, что от этого комментарии к новостям становятся чуточку веселее.
> не перестаёте радовать. проснулся, думаю: скука — ан нет! два говорящих <censored> булькают.Ну всё, пожалуй, уже хватит. Вы забываете, что я тут всё-таки модератор.
Gnu/vim
Чем отличаются Редакторы -- надо зело исхитриться, чтоб хоть краешком макушки упереться в потолок.
> Чем отличаются Редакторы -- надо зело исхитриться, чтоб хоть краешком макушки упереться
> в потолок.?
>> Чем отличаются Редакторы -- надо зело исхитриться, чтоб хоть краешком макушки упереться
>> в потолок.
> ?В какой-нить штуке из тех, которые многие писали в детстве -- упереться в пределы очень просто (начиная с банального конца массива, а то и края строки). В чём-то вроде mcedit -- тоже несложно выяснить, что чего-то не хватает. А вот в матёрых инструментищах ухитриться найти что-то, что действительно нужно, но ещё не реализовано (вообще никак) -- по крайней мере для меня оказывалось нетривиально :)
Ждём ебилдов... Точнее PPA для Xenial...
Вроде нашёл: https://launchpad.net/~jonathonf/+archive/ubuntu/vim
Ждём ебилдов... Точнее PPA для Xenial...
Вроде нашёл: https://launchpad.net/~jonathonf/+archive/ubuntu/vim
Давй ещё раз, теперь контрольный!
Приятные вести...
Как по мне - так самый удобный ТЕКСТОВЫЙ РЕДАКТОР.
К тому же присутствует практически во всех дистрибутивах.
Я, конечно, пользуюсь лишь малой частью его возможностей, так - конфиги поправить, но зато часто. И то, что для выхода из него с сохранением введённых изменений, нужно нажать не одну кнопку, не раз выручало.
А уж возможности множественных многострочных поисков с заменой - песня.
Благодарю создателей VIM за удобный и качественный текстовый редактор.
хороший редактор если нужно что-то по мелочи поправить или быстренько написать.
vim 6.4: последний редактор, который на ещё том железе быстро работал с автодополнением. Потом был добавлен питон, тормозящие даже на текущем рабочем i7 розавенькие выпадающие списки, которые ещё надо отключать, хипстота как оно есть. Не очень удивляет появление json.
Скорее всего виной тому не вим, а скрипты синтаксического разбора.
Если сильно тормозит, на время редактирования отключите синтаксис или введите ограничение на обрабатываемые строки так:
:syn sync minlines=20
:syn sync maxlines=300
Т.о. vim будет стараться обрабатывать синтаксис, начиная с 20-ой строки над видимым экраном, но если обработка окажется невоможной и потребуется заглядывать ещё выше, заглядывание не превысит 300 строк над видимым экраном.
мне лично дико удивительно, каким местом надо писать подсветку синтаксиса, чтобы она так тормозила. у меня на моём i3 мой же самопальный редактор двадцать мегабайт текста расцвечивает полностью сверху донизу меньше чем за 400 миллисекунд. полностью, подчёркиваю. то есть, на исходниках нормальных размеров можно было даже не заморачиваться с кэшированием и «умной» перекраской при изменении текста.
> двадцать мегабайт текста расцвечивает полностью сверху донизу меньше чем за 400Вижу фатальный недостаток json-а в!
> миллисекунд. полностью, подчёркиваю. то есть, на исходниках нормальных размеров можно
>> двадцать мегабайт текста расцвечивает полностью сверху донизу меньше чем за 400
> Вижу фатальный недостаток json-а в!да ладно. двадцать мегов — это, конечно, был синтетический тест. но килобайт триста — такие монстрики есть. обычно результат амальгамизации после того, как разработка более‐менее завершена.
А функциональность ты сравнить не забыл? Или как в анекдоте: "печатаю со скоростью 800 символов в минуту...только ерунда какая-то получается". Ну и 400мс это очень даже заметно при редактировании, особенно для тех, кто вводит больше двух символов в секунду.
> А функциональность ты сравнить не забыл?какую? варку кофе, пока текст раскрашивается? у меня поддерживается несколько языков, естественно, вложенные комментарии (где надо), закавыченые строки «с продолжениями» и прочие гитики. новый язык добавляется, фактически, перечислением кейвордов и флажков. местами даже контекст понимает.
и да, функциональность самого редактора совершенно не зависит от раскрашивателя. если, конечно, редактор писать руками, а не ногами мёртвого соседа. базовая механика изменения текста — это ровно одна операция: «заменить кусок текста на другой». всё. остальная функциональность — сколь угодно сложная — строится на этой. угу: подсвечивание всяких скобок есть, мгновенная динамическая перекраска есть, даже вертикальные линии для блоков рисует.
> Ну и 400мс
> это очень даже заметно при редактировании, особенно для тех, кто вводит
> больше двух символов в секунду.угу. это, конечно, дикий недостаток: мы ж каждый день исходники по двадцать мегабайт редактируем — и тут такие тормоза. беда просто. простейшая арифметика даст скорость примерно пятьдесят тысяч символов в миллисекунду. я мягко намекаю, что при такой скорости я мог тупо просто красить всё заново при добавлении каждого символа, и никто бы тормозов не заметил.
впрочем, даже эти несчастные четыреста миллисекунд возможно заметить только если открыть двадцатимеговый файл и сразу прыгнуть в его конец. и это будут однократные тормоза, потому что дальше вступает в дело система «умной ленивой перекраски».
p.s. впрочем, эту систему я потом сильно порезал, потому что дофига кода без пользы: вырезал три четверти, тормозов так и не прибавилось, зато стало намного понятней и прозрачней.
Вполне возможно, что имеющегося хватает для тех языков, что ты выбрал. Но ведь есть языки вроде perl, где закавыченые строки «с продолжениями» это отнюдь не самое сложное, а учет контекста должен быть не местами. Да даже keyword'ы не так просты, как некоторым кажется, ведь часть из них может быть не настоящими keyword, а просто предопределенными идентификаторами, а значит могут быть переопределены пользователем и без контекста для их подсветки ты уже никак не обойдешься.
Всё это ни к тому, что твой раскрашиватель плох, а к тому, что говорить о сравнении по скорости можно только при близком функционале. А то re2 тоже значительно быстрее pcre и в большинстве случаев достаточны, но в меньшинстве случаев просто не имеют нужного функционала.
(пожимает плечами) абсолютно всё, что способен покрасить вим своими синтакс‐файлами, могу покрасить и я, только значительно быстрее. а разгадка одна: регэкспами красят только дебилы.
- Мой сосед говорит, что с женой ежедневно, а ему 95!
- Ну так и вы говорите!!!
(снова пожимает плечами) натурально, автор вима — гений на все времена. никто и никогда не может сделать движок редактора быстрее, раскраска регулярками — лучшй метод, ура‐ура.
>Реализация пакетов для установки, обновления и управления плагинами;Это значит что ставить плагины из репозиториев можно из коробки? Где про это почитать?
Походу, пацаны pathogen не осилили
Vundle обратно совместим с Pathogen и лучше по всем параметрам.
Отличная новость. Спасибо создателей за отличный редактор.
>Поддержка сборки графического интерфейса с GTK+ 3. При наличии GTK+ 2 и GTK+ 3 о умолчанию по-прежнему используется GTK+ 2.Ну а QVim или KVim, или PVim будет? ;)
Wim еще
С 2007 года vi/vim мне ни разу не понадобился. Переменная окружения $EDITOR перенастроена на ee(1). Чем vi/vim лучше ee(1)? Стоит ли на него перейти?
Vim хотя бы utf-8 поддерживает
То-есть с 2007 таких вопросов не возникало, а тут раз и прозрение ?
> Добавлена опция 'renderoptions', позволяющая задействовать DirectX (DirectWrite) для отрисовки вывода в Windows;Т. е. в винде теперь relativenumber и cursorline не будут тормозить?
крон есть, пакетная система есть, работа с графикой есть, IPC есть. к 9 версии нужен загрузчик.
Обновил, выйти для перезапуска всё так же не могу?
Немного юзал Vim. Не намного легче Vi. Пока только в одной команде разницу нашёл. Насколько помню переход в режим команд по разному происходит. А у вас установка только на новые Linux?
> Немного юзал Vim. Не намного легче Vi. Пока только в одной команде
> разницу нашёл. Насколько помню переход в режим команд по разному происходит.Вам явно попался какой-то ужасно собранный vim -- попробуйте vi и vim на альтовых стартеркитах (в том же дебиане, к сожалению, "из коробки" vim и впрямь неприглядный).
Вообще же есть полезный vimtutor :)
Debian 2.0. Хороший Vim не помешает.
Не осилил. Расскажите как управляете хоткеями при наборе кириллицей - я у танке. Не работало - приходилось постоянно переключаться на латиницу - плюнул, сбежал.
> как управляете хоткеями при наборе кириллицейlangmap
В поиске нашел Альтовый Vim, а страница ftp не открылась.
Установил Vim-5.6 на Debian. Приятно удивлён.