egorius | Entries tagged with vi

Вот уже две недели, как на моем новеньком рабочем ноуте стоит ~~Ктулху~~Убунту.

Почему Убунта? Ну, в мире открытого и свободного программного обеспечения Микрософт считается моветоном. А в версиях линукса я совсем не разбираюсь, поэтому поставил то, что на слуху и уже попадалось.

Впечатление — жить можно.

Система установилась быстро, без лишних вопросов и вообще без единой проблемы. Респект.

К возможностям операционной системы как таковой нареканий, разумеется, нет. Наоборот, это в Виндоуз приходилось ставить cygwin, чтобы пользоваться командной строкой.

Зато неприятно удивила нестабильность: система падала уже дважды. Один раз тупо повисла посередине работы, другой — не осилила проснуться. Даже не знаю, что и думать.

Но основная работа происходит все-таки в программах:

Файловый менеджер Far. Аналог — Midnight Commander. Толком еще не приcпособился, но базовые потребности он удовлетворяет.
Текстовый редактор Vim. Единственной проблемой было найти нужный пакет с gvim, чтобы запускался из-под mc в отдельном окошке. Смутно чую в этом что-то неправильное.
Браузеры и почтовые клиенты. Тут проблем нет, пока использую штатный Firefox и к нему Thunderbird. Без нареканий.
Виртуалка VirtualBox. Тоже без проблем.
Микрософт Офис. Аналог — LibreOffice. Функциональность достаточно богатая, нашел все, что было нужно (пусть и не сразу). Но стабильность не на высоте: Микрософт тоже регулярно падает, но не так часто_как. И все время что-то подглючивает, хоть и некритично, но неприятно. Совместимость есть, но так себе: по ощущениям, микрософтовский документ открывается почти всегда, однако сохранение в таком формате убивает сколько-нибудь нетривиальное форматирование.

Пока больше ничего и не надо было.

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

Будем смотреть дальше.

Сегодня будем дружить Vim c SQL*Plusом. Для этого нам понадобится сущая безделица, такая вот функция:

function! SqlPlus()
   let l:fname = @%
   let l:sqlbuf = bufnr("%")
   if !exists("b:oraext_conn")
     let b:oraext_conn = ""
   endif
   let b:oraext_conn = input("Connect string: ",b:oraext_conn)
   echo "Executing..."
   let l:cmd = ":%! sqlplus ".b:oraext_conn." @".shellescape(l:fname)
   if !exists("b:oraext_resbuf") || !bufexists(b:oraext_resbuf) || bufwinnr(b:oraext_resbuf) == -1
     new
   else
     exe bufwinnr(b:oraext_resbuf)."wincmd w"
     if &modified
       new
     else
       exe "normal ggdG"
     endif
   endif
   exe l:cmd
   setlocal nonu
   set nomodified
   set efm=%-Poraext:\ fname=%f,%A%l/%c%m,%C%\\t%m
   cgetexpr ["oraext: fname=".fnameescape(l:fname)] + getline(1,'$')
   let l:resbuf = bufnr("%")
   exe bufwinnr(l:sqlbuf)."wincmd w"
   let b:oraext_resbuf = l:resbuf
   cc
   redrawstatus
endfunction

Небольшой комментарий_к. Допустим, сочиняем мы PL/SQL-пакет (кстати, на картинке видно, как мой плагин подсвечивает if, на котором стоит курсор):

Чтобы прогнать пакет через Плюс, говорим :call SqlPLus(). Естественно, это не надо набирать каждый раз. Во-первых, в ex-режиме (после нажатия двоеточия) работают стрелки вверх-вниз по истории команд, а также автокомплишн по табуляции, как в шелле. Во-вторых, можно просто повесить эту команду на какую-нибудь кнопку.

Первый раз у нас спросят строку соединения. Затем, после небольшой паузы, появится окошко с Плюсовым выводом. Если были ошибки, курсор будет позиционирован на первой из них, а командами :cn и :cp можно перемещаться к следующей или предыдущей (это vimовская фича™ quickfix, :help quickfix).

А что ещё надо от IDE? Самую малость: в следующий раз буду дружить Vim со своей OCI-программой, чтобы прямо из редактора выполнять запросы.

P. S. Кстати, вот отличная статья на тему продвинутых® IDE и удовольствия от кодирования™: Does Visual Studio Rot the Mind?

Я однажды жаловался, что нельзя-де сделать так, чтобы при открытии очередного файла из Фара он открывался бы в уже запущенном экземпляре vimа. Оказывается, можно и это.

Сначала запускается vim-сервер: vim --servername foo. Затем любая команда типа vim --servername foo --remote-tab bar.txt открывает bar.txt в серверном экземпляре, названном foo (в отдельном табе).

Для этого vim должен быть собран с фичей clentserver (:help remote.txt); для виндовой версии 7.2 это так.

Прусь несказанно.

Upd. Теперь у меня в Фаре стоит такой вызов внешнего редактора по Alt-F4:
start cmd /c vim --servername vim --remote-tab !.!

Одна из сил vimа в том, что называется {motion}, то есть некое движение. Например, нажимая w, я перемещаюсь к началу следующего слова. А 3w перескочит к началу третьего слова. Ну, этим никого не удивишь: в обычном редакторе можно нажать Ctrl и стрелку вправо. Три раза.

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

Но основная сила в том, что {motion} может комбинироваться с операторами. Если я жму yw, то оператор y (yank = copy) копирует текст от сих и до начала следующего слова. А если y% (например, на вызове функции), то от сих и до закрывающей круглой скобки (то есть весь вызов целиком, вместе со всеми вложенными скобками). А если yi" (i = inner), находясь где-нибудь внутри строки, ограниченной кавычками, то всё содержимое этой строки. Ну и так далее.

Идём дальше. Допустим, есть такой код:

if (check_err(errhp, OCIParamGet(stmtp, OCI_HTYPE_STMT, errhp, (dvoid**)&parmp, i) )) {

И захотел я заменить в нём выделенный вызов функции на другой, который предварительно скопировал (с помощью %, конечно). Встав на начало вызова (в начале строки для этого достаточно fO, что переместит нас к первой букве O), приходится сначала удалить ненужный вызов: d% (d = delete), а затем вставить скопированное. Но поскольку d сам по себе копирует удалённое (то есть работает как cut), то скопированное ранее надо извлечь из специального регистра "0: "0P (P = put, то есть paste).

Посчитаем нажатия: d%"0P, 5 штук. Много. Хочется такой оператор, чтобы удалял {motion} и сразу вставлял на его место скопированный текст. А такого почему-то нет. Хотя подобную операцию приходится проделывать довольно часто.

К счастью, у нас есть help :map-operator, а в хелпе есть прекрасные примеры, с помощью которых можно шаманить, даже не до конца всё понимая. В итоге рисуется такая функция:

function! PutInstead(type, ...)
  let sel_save = &selection
  let &selection = "inclusive"

  if a:0
    silent exe "normal! `<" . a:type . "`>d\"0P"
  elseif a:type == 'line'
    silent exe "normal! '[V']d\"0P"
  elseif a:type == 'block'
    silent exe "normal! `[\<C-V>`]d\"0P"
  else
    silent exe "normal! `[v`]d\"0P"
  endif

  let &selection = sel_save
endfunction

Она маппится на запятую:

nmap <silent> , :set opfunc=PutInsteadg@
vmap <silent> , :<C-U>call PutInstead(visualmode(), 1)

После этого вся процедура требует двух нажатий: ,%. Почему запятая? Ну просто все клавиши уже напичканы функциями, а запятая среди них самая ненужная.

Рассуждая в начале года про vim и dbext, я пришёл к выводу, что вызов sql*plus для выполнения запросов не годится, так как он некорректно обрабатывает «широкие» таблицы. И что надо писать свою программку.™

На чём её писать? Нужно что-то такое, чтобы работало на тех же платформах, где и vim. Причём не хотелось бы, чтобы потреблялось много ресурсов — ну неохота мне ждать, пока запустится какая-нибудь виртуальная машина только ради того, чтобы выбрать sysdate из dual. Так что пусть будет Си + OCI.

OCI оказался мудрёным, выборка sysdate вылилась чуть не в две сотни строчек, которые для истории лежат ( под катом )

Программка отлично скомпилировалась gcc под cygwin следующим образом:

gcc -o test.exe -I%ORACLE_HOME%\oci\include test.c %ORACLE_HOME%\bin\oci.dll

Но как же я привык к исключениям! Страдаю без них. И как же я отвык от вот этого:

   6585 [main] test 196 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  10471 [main] test 196 open_stackdumpfile: Dumping stack trace to test.exe.stackdump

PL/SQL forever! (Кстати, DB2 с недавних пор поддерживает PL/SQL, так что...)

Наступил на очередные vim-грабельки, на этот раз с кодировкой. Вообще-то, всё сделано логично. Есть три кодировки:

termencoding — в какой кодировке выводить символы на терминал,
encoding — в какой кодировке текст хранится внутри vimа,
fileencoding — в какой кодировке записан редактируемый файл.

Если какие-то кодировки не совпадают, на лету происходит преобразование. Как правило, нет нужды трогать ничего, кроме кодировки файла. Если её поменять на ходу (:e ++enc=iso-8859-5), на экране нарисуется перекодированный текст. Отлично.

Однако же на практике vim упорно отказывался правильно показывать исошный файл, радостно сообщая в строке состояния «NOT converted». Хотя некоторые файлы в некоторых кодировках всё-таки отображались.

Сломав всю голову, пошёл гуглить и выяснил, что такое сообщение вылезает, если преобразование невозможно. Как интересно. Беглый просмотр хелпа показал, что для перекодирования используется iconv. Посмотрел man iconv, попробовал перекодировать им файл — всё отлично работает. Ну не шайтан ли?

И только со второго захода нашёл в хелпе, что виндовые версии vimа могут быть скомпилированы с некой фичей +iconv/dyn, которая заставляет vim искать iconv в соответствующей dll-ке. Причём если таковой нет, то Vim will still work but some conversions won’t be possible.

Dll, естественно, отсутствовала. И стоило её найти и подсунуть vimу, как наступило счастье.

Внимание, вопрос: что заставило людей, собиравших дистрибутив vimа, не включить в него iconv? Всё, как обычно в unix: очень круто, но полдня вынь да убей.

Как я говорил в прошлый раз, Vim умеет раскрашивать синтаксис и умеет подсвечивать парные скобки, но не умеет подсвечивать конструкции наподобие begin–end. Задавшись целью настроить такую подсветку, я полез в документацию и к большому своему удивлению обнаружил, что подсветка синтаксиса и скобок — две совершенно разные вещи. Первая обеспечивается собственно Vimом на основе syntax-файлов, а второй занимается отдельностоящий (хотя и стандартный) плагин, никак не завязанный на тип файла. Документация радостно сообщает, что currently only single byte character pairs are allowed. Эх.

Но раз он плагин, то никто не мешает в него заглянуть. Всех-то дел 150 строчек кода на внутреннем скриптовом языке Vimа (весьма симпатичный, кстати говоря, оказался язык). И — о, чудо! — оказалось, что в Vimе есть прекрасная встроенная функция searchpair(), которая мало того, что ищет парные слова с учётом вложенности, но и позволяет задать их регэкспами, а ещё — вот ведь! — понимает конструкции типа if–else–fi, подсветки которых мне так не хватало в Фаре. Условно говоря, задавшись некоторой конструкцией и начальным словом, мы можем получить все слова, находящиеся с ним на одном уровне вложенности:

if if else fi else ... else ... fi

С такой-то функцией да не написать свой плагин? Сказано — сделано. Сложности в основном были вызваны тем, что я сначала пытался обойтись без регэкспов (по аналогии со стандартным плагином, типа поберечь ресурсы), но потом одумался и сделал всё по-человечески.

Интересный момент: как привязать подсветку к типу файла (а делать это, очевидно, надо: в разных языках используются разные конструкции)? Оказывается, в Vim можно на определённое событие повесить обработчик (автокоманду в его терминологии), причём поддерживается очередь таких обработчиков. Вполне удобно. Таким образом, сам плагин висит на событиях перемещения курсора, а по событию изменения типа файла можно подключать соответствующие языковые конструкции.

А теперь, на закуску, самая большая засада. Как, собственно, описать те слова, которые должны быть парными? В PL/SQL для счастья нужно, вроде бы, немного: begin–end, case–end, loop–end loop, if–end if. Но нельзя, например, просто сделать пару if–end if, поскольку получим такое:

if ... if ... end if; end if;

Аналогично, могут не поделить друг друга пары begin–end и if–end if:

begin if ... end if; end;

А ещё begin и case могут поспорить из-за endа:

begin if case ... end then ... end if; end;

Конкретно эти примеры, конечно, с помощью регэкспов легко решаются. Но вот как при этом сделать, чтобы if и case не отнимали друг у друга else? До сих пор ничего хорошего не придумал.

Резюме. За прошедшее время Vim прочно вытеснил Фаровский редактор, и вряд ли я теперь от него откажусь. Жизнь потихоньку налаживается, дальше буду ковырять dbext.

Особенно хочется отметить качество документации. Всё, что нужно, находится быстро и информация оказывается исчерпывающей, с хорошими жизненными примерами использования. И в очередной раз стали видны преимущества открытого, интерпретируемого кода. Фаром я пользуюсь уже очень давно, раза три порывался написать плагин, но необходимость где-то искать документацию и что-то компилировать меня останавливала. А в Vim всё под рукой: и хелп, и интерпретатор, и сам редактор в одном флаконе. Отлично.

Да, если кому интересно, вот он плагин. В vimrc полезно добавить строчку «:let loaded_matchparen = 1», чтобы стандартный плагин не путался под ногами.

Посидел несколько дней в vimе, погонял dbext, можно подводить первые результаты.

Vim понравился существенно больше, чем не понравился. Что полюбилось:

Классные команды, выделяющие область, ограниченную парными скобками, типа i( или a(. Они очень «интуитивные», гораздо приятнее, чем выделять область ручками.
PowerPointом, сиречь МогучейТочкой, следовало назвать точку в vimе. Экономит много сил и доставляет удовольствие.
Поиск с помощью / и * на порядок удобнее, чем всякие Ctrl-F или F7 с их всплывающими окошками.
Виндовый порт vimа оказался по делу: он худо-бедно поддерживает мышку (удобно в табы тыкать, вместо gt) и Ctrl-C, Ctrl-V работают с виндовым клипбордом. Загадка, почему простой yank не копирует в клипборд? Было бы проще, чем изобретать "*y.

Не очень удобно:

Отсутствие интеграции с Фаром. В Фаре Ctrl-Tab переключает между всеми окнами редактора и панельками. Но в качестве альтернативного редактора vim запускается в отдельном окошке. Второй файл удобнее было бы открывать в том же самом vimе (меньше окошек — больше кислорода, да и yank-put удобнее делать), но из Фара это уже никак не получится — запустится вторая копия vimа.
Не подсвечиваются парные комананды типа begin и end. Фаровский колорер это умеет. Не исключено, что можно научить и vim, надо будет поковыряться.

Подсаживаюсь! Пару раз уже пытался сказать cw в браузере. Пальцы ещё немного путаются в командах, скорость редактирования пока пониженная (честно лезу в хелп, когда хочется сделать что-нибудь эдакое, и есть подозрение, что можно), но это дело не столь большого времени. Зато сколько удовольствия!

Между делом починил ещё один напильник, связанный с русскими буквами: в обычном режиме vim по умолчанию понимает только английские буквы, поэтому в русской раскладке никакую команду ввести нельзя. Решается очень просто, созданием соответствующего langmapа. А ещё полезно объяснить vimу, что русские буквы тоже входят в состав слов, чтобы работали команды типа w. Делается заданием iskeyword.

Dbext не понравился существенно больше, чем понравился.

Попытка сделать инструмент для всех СУБД сразу привела к тому, что с Ораклом работать практически невозможно. Что плохо:

Как уже писал, не работает select * из «широких» таблиц. Есть мысль, что wrapperом над Плюсом тут не обойтись, надо писать свою программку взамен (привет, dbms_sql).
Много косяков, вызванных попытками подготовить текст для Плюса. Например, вырезание пустых строк (да, Плюс их не любит, но иногда они всё-таки нужны) или оборачивание запросов без удаления точки-с-запятой.
Нужен режим, когда редактируемый файл целиком, безо всяких изменений, скармливается Плюсу (например, серия команд для создания каких-нибудь объектов БД). Причём хорошо бы с возможностью прыгнуть в код на нужную строчку, если произошла ошибка.
Нет команды для просмотра плана запроса.
Нет возможности загрузить в редактор, например, тело пакета по его имени.

В общем, сырость и кривость. Попробую на досуге поковырять dbext. Если повезёт, и в vimовских плагинах разберусь, и что-нибудь юзабельное сделаю.

Начнём, пожалуй. Cygwin у меня уже стоял, vim, соответственно, тоже. Повесил пока его в Фаре на Alt-F4 как альтернативный редактор. Люблю, знаете ли, консольный режим, а gvim с менюшкой — увольте, это какой-то идеологический бредос.

Тут нас поджидает первый напильник: хайлайтинг. Такое ощущение, что в консольном режиме никто не работает, потому что ни одной приличной цветовой схемы мне обнаружить не удалось. Все пёстрые до тошноты, как будто специально для отсеивания слабых духом. Но мы-то понимаем, что схемы настраиваются вполне интуитивным образом: берём за образец какой-нибудь файл из /usr/share/vim/vim72/colors/ и подкручиваем его по собственному разумению. Лично я предпочитаю чёрный фон, серо-белый текст и синие комментарии, а яркие цвета приберегаю для отдельных случаев типа выделения слов при поиске. Дальше в .vimrc добавляются «:syntax on» и «:colo egorius» и временно наступает щастье.

Теперь скачиваем свежий dbext, копируем внуть vimа. Если не забыть сказать :helptags, как написано в инструкции по установке, то «:help dbext» не даст помереть дураком. А ещё лучше «:tab help».

Пробуем выполнить тестовый запросик: «:Select * from dual». Вот и второй напильник: в окошке результата получаем «SP2-0310: не в состоянии открыть файл "/tmp/v372235/dbext.sql"». Ну в самом деле, откуда виндовому Плюсу знать о файловой системе цыгвина?.. Лечим просто: скачиваем cвежий виндовый порт vimа, на текущий момент это версия 7.2.

И немедленно натыкаемся на третий напильник: неправильно отображаются русские буквы. Сначала я подумал, что проблема с кодировкой, но картинка выглядела странно: часть букв была на своих местах, а некоторых не было вовсе. Верный признак кривизны точечного шрифта в консоли, лечится заменой его на Lucida Console в свойствах окошка. Странно только, что цыгвиновский vim этим не болел.

Ну да ладно, копируем в новый vim файлик хайлайтинга и dbext, попутно отмечая, что для таких дел выделен специальный каталог vimfiles, а .vimrc зачем-то переименован в _vimrc (вроде винда ничего не имеет против файлов, начинающихся с точки).

Что на этот раз? «:Select * from dual»

D - X

Получилось! Ну-ка, ну-ка, попробуем describe. Для этого пишем в окошке «dual», встаём на него курсором и набираем \sdt (типа Sql Describe Table). Ой, в окошке результата пусто. Ну хорошо, селекты-то работают, попробуем вывести что-нибудь из моей любимой таблицы fa_books (118 столбцов). Опа, опять пусто. Вот и он, четвёртый напильник.

Что же происходит? Вспоминаем из второго напильника, что dbext создает временный файл, который скармливает Плюсу. Посмотрим, во что он превратил наш запрос. В винде временный файл нашёлся, что логично, в %TEMP% и помимо запроса содержал ещё несколько строк Плюсовых установок, из которых самые интересные «set wrap off» и «set linesize 10000». То есть товарищи полагают, что если установить потенциально бесконечную длину строки и отменить переносы, то Плюс отформатирует результаты так, чтобы одна строка таблицы была одной строкой текста. Щаз! Во-первых, он ломается на длинных строках и от огорчения не выводит вообще ничего, во-вторых, это неблаготворно сказывается на describe. Как расплывчато утверждает документация, «DESCRIBE output columns are typically allocated a proportion of the linesize... You can define LINESIZE as a value from 1 to a maximum that is system dependent».

К счастью, не составляет труда заглянуть в код плагина и понять, что заголовок, прилепляемый к запросу, задаётся переменной g:dbext_default_ORA_cmd_header, которую, следовательно, можно переопределить в .vimrc. К несчастью, непонятно, на что её переопределять. Вечер, потраченный на поиск волшебного сочетания параметров, результата не дал. Пока склоняюсь к мысли, что придётся делать wrap on и писать wrapper, который будет переформатировать Плюсовый вывод...

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

P.S. Зачем я, собственно, всё это описываю? А просто интересно стало, сколько напильников нужно, чтобы заставить работать vim+dbext так, как мне удобно.

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

Последние несколько лет я вплотную занимаюсь СУБД Oracle, а поскольку планирую заниматься ею и в дальнейшем, хочется делать это удобно, то есть иметь некую среду разработки «по руке». Попробовано было разное, но программы, открывавшие сессию дольше минуты или имевшие больше ста кнопок на тулбаре, незамедлительно стирались, так что выжили немногие. Во-первых, конечно, SQL*Plus — незаменимый тул, но в качестве среды по понятным причинам не катит. Во-вторых, SQL Navigator третьей версии (начиная с четвёртой перестал удовлетворять требованиям_к). Собственно, всё.

Как таковых претензий к Навигатору у меня немного, но вот «по руке» он не ложится. Если надо написать что-то достаточно большое, я перелезаю в Far и пишу во встроенном редакторе, где настроен хайлайтинг и есть замена по регулярным выражениям (плагины рулят). Но как-то поднадоело метаться из Фара в Навигатор, время от времени запуская explain plan в Плюсе.

Тут следует сделать лирическое отступление про мои отношения с Unix. Поначалу, после VAX/VMS, он показался мне угрюмо-молчаливым и вообще неинтересным. Впрочем, время всё расставило по местам, а с Юниксом меня подружил ранее упоминавшийся сисадмин Гоша. Он читал в Универе спецкурс про Юникс, причём рассказывал не столько про команды, сколько про то, почему и зачем он такой, какой есть.

С тех пор я Юникс уважаю, но в качестве ОС для рабочего компьютера он категорически не прижился. Юникс в умелых руках даёт безграничные возможности, но за всё надо платить. В данном случае — временем изучения, потому что ни одна уважающая себя программа под Юникс не заработает, пока её не доработаешь напильником, для чего обычно надо почитать пару-тройку манов, провести несколько экспериментов, на худой конец пересобрать ядро. А тратить время_на не всегда хочется и можется. Однако же сразу после Фара я всегда устанавливаю себе на компьютер Cygwin, благо пайпы и редиректы прекрасно работают и под виндой.

Вместе с Цыгвином в числе прочего ставится и редактор Vim. Неприязнь к оному излечил опять-таки Гоша, на одном из занятий рассказав про идеологическую подоплёку. В те славные времена, когда компьютеры были большими, а каналы связи медленными, каждый лишний передаваемый символ тормозил работу. Поэтому никто не гонял бездумно курсор по экрану, а наоборот, все старались минимизировать нажания и перерисовывания (привет, VT52!), и вообще работали построчно (отсюда exовские корни Vimа). Меню по понятным причинам также было непозволительной роскошью. Зато под рукой была клавиатура, каждая буковка на которой могла обозначать свою команду. А каждую из команд можно ещё и сопроводить модификатором (скажем, w переходит к следующему слову, 3w перескакивает на третье слово) или объединить несколько команд (d3w удалит три слова) ну и т. п., вот почитайте. Медленные каналы канули в прошлое, а хороший принцип остался: помочь пальцам успевать за мыслью.

Собственно, к чему я веду. Прочитал тут про плагин dbext к Vim. Принцип работы прост, как репа: берется текст или часть текста и скармливается Плюсу, а полученный результат показывается в отдельном окошке. Чем плохо? Ну кое-чем плохо, конечно, но попробовать всё-таки можно. Вот и пробую помаленьку, но об этом в следующий раз.

P.S. Дежавю? Да. Но на этот раз намерения посерьёзнее.

Правлю в ФАРе могучий скрипт на SQL. Колорер тихо загибается в попытках расцветить синтаксис: нажимаю на кнопку и вижу результат через секунду-полторы.

Мне это живо напомнило те славные времена, когда я из Универа телнетился на какой-то ЦЕРНовский VAX — ну точно такая же была задержка. Только тогда я мог сказать что-нибудь типа dt), а теперь не могу, приходится курсором лазить туда-сюда…

А что, собственно? Может, на vim перейти?