Аналог emacs --daemon (есть ли такое в vim?)
Модератор: /dev/random
Аналог emacs --daemon
Для arm-а 400 МГц emacs всё-таки немного медленноват. В целом спасает режим демона, появившийся в 23-й версии: редактор стартует единожды, а потом каждый раз подключаешься к нему. Но при открытии больших (десятки тысяч строк) исходников всё равно на пару секунд задумывается. Не критично, конечно, но не очень удобно.
А моя непереносимость вимовских режимов относится в первую очередь к редактированию текстов околотвоческих (очень сбивает вот это «тудым-сюдым», вдохновение теряется). Вот и возникла мысль попробовать для исходников и прочих «технических» вещей использовать vim.
Но тут я поймал себя на том, что «серверный» режим emacs, оказывается, очень удобен не только скоростью запуска «клиентов» (что для vim-а совершенно некритично). Удобен сам тот факт, что все окна редактора, как открытые параллельно, так и по очереди, — это один и тот же процесс. Например, скопировать кусок давно открытого локального файла в сообщение на форуме, редактирование которого открывается прямо из браузера. Или, открывая по очереди несколько писем в mutt, перемещать текст между ними. Всё это гораздо удобнее делать через kill-ring редактора, чем, скажем, через буфер screen-а.
Вот и интересуюсь: есть ли у vim такой «серверный» режим? Сам найти не смог, а тут много вимеров, может быть подскажете. Интересует вариант именно как в emacs23: внешне выглядит так же, как открытие отдельных копий редактора, но внутри все эти «копии» могут обмениваться текстом между собой и отображать все открытые буфера. До этого emacsclient работал иначе: открывал указанные файлы в уже существующем окне редактора. Такой вариант никуда не годится.
А моя непереносимость вимовских режимов относится в первую очередь к редактированию текстов околотвоческих (очень сбивает вот это «тудым-сюдым», вдохновение теряется). Вот и возникла мысль попробовать для исходников и прочих «технических» вещей использовать vim.
Но тут я поймал себя на том, что «серверный» режим emacs, оказывается, очень удобен не только скоростью запуска «клиентов» (что для vim-а совершенно некритично). Удобен сам тот факт, что все окна редактора, как открытые параллельно, так и по очереди, — это один и тот же процесс. Например, скопировать кусок давно открытого локального файла в сообщение на форуме, редактирование которого открывается прямо из браузера. Или, открывая по очереди несколько писем в mutt, перемещать текст между ними. Всё это гораздо удобнее делать через kill-ring редактора, чем, скажем, через буфер screen-а.
Вот и интересуюсь: есть ли у vim такой «серверный» режим? Сам найти не смог, а тут много вимеров, может быть подскажете. Интересует вариант именно как в emacs23: внешне выглядит так же, как открытие отдельных копий редактора, но внутри все эти «копии» могут обмениваться текстом между собой и отображать все открытые буфера. До этого emacsclient работал иначе: открывал указанные файлы в уже существующем окне редактора. Такой вариант никуда не годится.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
нет, vim daemon'а нет, и ЕМНИП не предвидится, из-за особенностей архитектуры самого vim'а
Re: Аналог emacs --daemon
Такой негодный сервер есть:
Код: Выделить всё
vim --servername aaa file.1
vim --servername aaa --remote-tab file.2
А такого демона как emacs или rxvt вроде бы, к сожалению, нет.
Re: Аналог emacs --daemon
c другой стороны скорость запуска у него достаточно большая, если он не пытается подсвечивать огромные фалы, конечно.
Re: Аналог emacs --daemon
liaonau писал(а): ↑08.03.2011 11:47
Такой негодный сервер есть:
Код: Выделить всё
vim --servername aaa file.1 vim --servername aaa --remote-tab file.2
А такого демона как emacs или rxvt вроде бы, к сожалению, нет.
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 25 2010 06:58:57)
Unknown option argument: "--servername"
Причём в мане есть:
Код: Выделить всё
$ man -P 'grep -- --server' vim
--serverlist
--servername {имя}
Впрочем, это всё равно не то, что нужно, увы.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Скорость запуска — да, аргумент. Впрочем, я уже попытался пояснить, почему это не единственный аргумент в вопросе клиент-серверной модели. А для меня и не самый важный.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
ну в принципе, открыть несолько файлов одновременно можно, даже очень по-разному можно. Организовать общий буфер обмена между разными vim'ами, в принципе тоже можно, по крайней мере через какой-нить отдельный файл, не знаю может есть что-то на эту тему прямо из коробки.
Re: Аналог emacs --daemon
Можно через буфер X сервера, конечно. Либо в * регистр, либо, чтобы по умолчанию
Код: Выделить всё
set clipboard=unnamed,exclude:cons\\\|linux
Недостатки, правда, очевидны — ограничение одним X сервером, изменение буфера выделением текста в других клиентах.
Re: Аналог emacs --daemon
Код: Выделить всё
:h todo
Priority classification:
…
7 as soon as possible
…
7 When starting Vim several times, instantiate a Vim server, that allows
communication between the different Vims. Feels like one Vim running with
multiple top-level windows. Esp. useful when Vim is started from an IDE
too. Requires some form of inter process communication.
Re: Аналог emacs --daemon
liaonau писал(а): ↑08.03.2011 12:52
Можно через буфер X сервера, конечно. Либо в * регистр, либо, чтобы по умолчанию
Код: Выделить всё
set clipboard=unnamed,exclude:cons\\\|linux
Недостатки, правда, очевидны — ограничение одним X сервером, изменение буфера выделением текста в других клиентах.
нет, я имел ввиду: можно скидывать содержимое регистра(регистров) в файл(ы) и соответственно попытаться читать эти файлы при вставке из другого запущенно инстанса вима.
Re: Аналог emacs --daemon
Нет, что костыли придумать можно, я понимаю. Но когда подставлю костыль для копирования текста, станет не хватать, скажем, возможности активировать в текущем экземпляре редактора буфер, открытый из другого экземпляра. Если придумаю костыль и для этого, вылезет что-то ещё.
При том, что я и так сомневаюсь, насколько удобно будет параллельно использовать для разных целей редакторы с принципиально разным управлением, мысли о сооружении такой системы подпорок убивают все остатки энтузиазма.
А вот то, что в планах создание такого серверного режима есть, не может не радовать.
При том, что я и так сомневаюсь, насколько удобно будет параллельно использовать для разных целей редакторы с принципиально разным управлением, мысли о сооружении такой системы подпорок убивают все остатки энтузиазма.
А вот то, что в планах создание такого серверного режима есть, не может не радовать.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Ох… Посмотрел на умолчательную подсветку синтаксиса в консольном vim — и сразу как-то передумал пробовать. Там придётся всё с нуля переделывать, я только два режима по несколько секунд глянул (си и xml), и то чуть глаза не сломал. Может быть, на белом фоне это нормально выглядит, но на чёрном страх и ужас какой-то. В емаксе умолчательная цветовая гамма смотрится вполне органично после mutt, elinks, finch и прочего. Так что всё-таки вряд ли я буду вим пробовать, слишком много мороки. Проще потерпеть несколько секунд при открытии больших файлов с подсветкой синтаксиса. Всем спасибо за ответы.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
t.t писал(а): ↑08.03.2011 13:50Ох… Посмотрел на умолчательную подсветку синтаксиса в консольном vim — и сразу как-то передумал пробовать. Там придётся всё с нуля переделывать, я только два режима по несколько секунд глянул (си и xml), и то чуть глаза не сломал. Может быть, на белом фоне это нормально выглядит, но на чёрном страх и ужас какой-то. В емаксе умолчательная цветовая гамма смотрится вполне органично после mutt, elinks, finch и прочего. Так что всё-таки вряд ли я буду вим пробовать, слишком много мороки. Проще потерпеть несколько секунд при открытии больших файлов с подсветкой синтаксиса. Всем спасибо за ответы.
xterm16 посмотри, там разные варианты есть для разных случаев: http://www.vim.org/scripts/script.php?script_id=795
Re: Аналог emacs --daemon
Посмотрел. С цветами чуть лучше (хотя всё равно не идеально), но дело не только в цветах, а и в том, что подсвечивается. Вот несколько картинок для примера:
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Ну схем подсветки в vim очень много. Вот здесь можно сравнить:
http://vimcolorschemetest.googlecode.com/s...ml/index-c.html
Есть например emacs, может будет похоже на то к чему вы привыкли?
http://vimcolorschemetest.googlecode.com/s...ml/index-c.html
Есть например emacs, может будет похоже на то к чему вы привыкли?
Re: Аналог emacs --daemon
Я о том и говорю, что не в схемах дело, а в том, что именно подсвечивается. Например, на всех картинках по ссылке вся строка «#define UNICODE» одинакового цвета, а в emacs имя директивы одного, а имя макроса — другого. Выше я постарался подобрать именно такие примеры.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Да, похоже что встроенного решения нет. Для подсветки определены Define, Macro (то же самое), Include и PreProc. Define подсвечивает и имя тоже.
Re: Аналог emacs --daemon
Имя — это ещё пол-беды. На моих картинках есть пример интереснее: макрос, раскрывающийся в кусок сишного кода. В емаксе код подсвечивается как и везде. А в виме только то, что выделено специальными цветами, этими цветами и подсвечено, а всё остальное — синее. Совсем не наглядно.
Вообще, если переходить на вим, по-хорошему нужно подсветку серьёзно дорабатывать.
Вообще, если переходить на вим, по-хорошему нужно подсветку серьёзно дорабатывать.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Другие примеры с этих же картинок: знаки начала и конца комментария — и сам текст комментария; имена функций — и имена аргументов и переменных; имена типов (int, char) — и спецификаторы типов (extern, static). Возможно, что-то из этого и разделимо, а с другой стороны это только то, что сразу попалось на глаза, т.е. список может быть неполным.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Да, некоторые разделимы. А вообще цветов-то не так уж много (на виртуальном терминале, по крайней мере) одинаковый цвет для for и switch это не проблема, а вот вышеозначенное с кодом в макросе — это скверно.
Я не знаю, но предположу, что подсветка работает просто по регулярным выражениям, ими всего не охватишь. Хорошо было бы чтобы подсвечивало (как бы выразиться?) «рефакторингом» — в общем чтобы vim точно понимал что есть что не в плане текста, а «структурно». Но такого в vim нет.
Я не знаю, но предположу, что подсветка работает просто по регулярным выражениям, ими всего не охватишь. Хорошо было бы чтобы подсвечивало (как бы выразиться?) «рефакторингом» — в общем чтобы vim точно понимал что есть что не в плане текста, а «структурно». Но такого в vim нет.
Re: Аналог emacs --daemon
А т.е. переделывать надо не шаблоны подсветки, а реализацию? Да, это скверно. И странно. Подсветка всё же достаточно важная вещь.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Так разве такое вообще где-то за исключением IDE для отдельных языков есть? В emacs, вроде, бы тоже font-lock по регулярным выражения подсвечивает (знаю только из google, сам не пользовался)? Это я просто размечтался немного.
Но то, что подсветку в vim стоит доработать, это факт. Она еще и имеет у меня тенденцию заглючить при фолдинге. Точно не воспроизведу, но как-то так: иногда (закономерности не улавливаю) в строке открывается комментарий, следующая строка — закрытый блок, внутри которого комментарий заканчивается… и все последующие строки подсвечены как комментарии. Раскрыл/закрыл — все нормализовалось. Хотя, быть может, я его готовить не умею, не знаю.
Re: Аналог emacs --daemon
Не только по регулярным выражениям, гораздо шире:
font-lock-keywords
[…]
Documentation:
A list of the keywords to highlight.
There are two kinds of values: user-level, and compiled.
[…]
Each element in a user-level keywords list should have one of these forms:
MATCHER
(MATCHER . SUBEXP)
(MATCHER . FACENAME)
(MATCHER . HIGHLIGHT)
(MATCHER HIGHLIGHT ...)
(eval . FORM)
where MATCHER can be either the regexp to search for, or the function name to
call to make the search (called with one argument, the limit of the search;
it should return non-nil, move point, and set `match-data' appropriately if
it succeeds; like `re-search-forward' would).
MATCHER regexps can be generated via the function `regexp-opt'.
[…]
HIGHLIGHT should be either MATCH-HIGHLIGHT or MATCH-ANCHORED.
For highlighting single items, for example each instance of the word "foo",
typically only MATCH-HIGHLIGHT is required.
However, if an item or (typically) items are to be highlighted following the
instance of another item (the anchor), for example each instance of the
word "bar" following the word "anchor" then MATCH-ANCHORED may be required.
MATCH-HIGHLIGHT should be of the form:
(SUBEXP FACENAME [OVERRIDE [LAXMATCH]])
SUBEXP is the number of the subexpression of MATCHER to be highlighted.
[…]
MATCH-ANCHORED should be of the form:
(MATCHER PRE-MATCH-FORM POST-MATCH-FORM MATCH-HIGHLIGHT ...)
where MATCHER is a regexp to search for or the function name to call to make
the search, as for MATCH-HIGHLIGHT above, but with one exception; see below.
PRE-MATCH-FORM and POST-MATCH-FORM are evaluated before the first, and after
the last, instance MATCH-ANCHORED's MATCHER is used. Therefore they can be
used to initialize before, and cleanup after, MATCHER is used. Typically,
PRE-MATCH-FORM is used to move to some position relative to the original
MATCHER, before starting with MATCH-ANCHORED's MATCHER. POST-MATCH-FORM might
be used to move back, before resuming with MATCH-ANCHORED's parent's MATCHER.
[…]
A compiled keywords list starts with t. It is produced internal
by `font-lock-compile-keywords' from a user-level keywords list.
Its second element is the user-level keywords list that was
compiled. The remaining elements have the same form as
user-level keywords, but normally their values have been
optimized.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Если в виме подсветка действительно только по регэкспам, то шаблонами, увы, не обойдёшься — менять надо именно реализацию. Сравни с цитатами из справки емакса выше.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Re: Аналог emacs --daemon
Emacs — это IDE. (: Если совсем точно, то emacs+make+… (нужное дописать). И я всегда был уверен, что vim — тоже.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
- /dev/random
- Администратор
- Сообщения: 5282
- ОС: Gentoo
Re: Аналог emacs --daemon
В общем-то, можно. Никто не мешает написать функцию, которая будет динамически модифицировать шаблоны подсветки в зависимости от содержимого, и повесить её, скажем, на CursorHold / CursorHoldI (события, выполняемые в тот момент, когда пользователь на секунду приостанавливает ввод).
Upd: Вот только писать функцию на интерпретируемом языке, которая должна постояно обрабатывать весь текст в процессе его набора... Ты, кажется, хотел _уйти_ от тормозов? Ты их себе возвращаешь.
Re: Аналог emacs --daemon
/dev/random писал(а): ↑09.03.2011 10:46
В общем-то, можно. Никто не мешает написать функцию, которая будет динамически модифицировать шаблоны подсветки в зависимости от содержимого, и повесить её, скажем, на CursorHold / CursorHoldI (события, выполняемые в тот момент, когда пользователь на секунду приостанавливает ввод).
Опять костыль. Ждать по секунде каждый раз, когда нужно обновить подсветку… Уж проще подождать несколько секунд при открытии файла.
/dev/random писал(а): ↑09.03.2011 10:46Upd: Вот только писать функцию на интерпретируемом языке, которая должна постояно обрабатывать весь текст в процессе его набора... Ты, кажется, хотел _уйти_ от тормозов? Ты их себе возвращаешь.
А нельзя обрабатывать не весь текст, а только текущую строку или строки начиная с текущей, пока не «конец выражения» (ну и назад до начала так же)? Емаксовая подсветка по умолчанию так и делает (не перепарсивает файл от начала при редактировании). Правда, «фабричные» фонт-локи скомпилированы, да и пользовательские компилировать можно. А vimscripts, насколько я понимаю, не компилируется в принципе.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
- /dev/random
- Администратор
- Сообщения: 5282
- ОС: Gentoo
Re: Аналог emacs --daemon
t.t писал(а): ↑09.03.2011 12:06А нельзя обрабатывать не весь текст, а только текущую строку или строки начиная с текущей, пока не «конец выражения» (ну и назад до начала так же)? Емаксовая подсветка по умолчанию так и делает (не перепарсивает файл от начала при редактировании). Правда, «фабричные» фонт-локи скомпилированы, да и пользовательские компилировать можно. А vimscripts, насколько я понимаю, не компилируется в принципе.
Можно, конечно. С выражениями так и делается. Но вот функции придётся самой решать, что обрабатывать, а что - нет.
Кстати, просмотрел всю тему, не увидел из твоих "претензий" ничего, что требовало бы функций. Всё это решается выражениями. Может, ты что-то просто не назвал?