Инструменты пользователя

Инструменты сайта



// О PDF-просмотрщиках

Немного о наболевшем.

В PDF, обычно, распространяется документация.

В документации, обычно, есть перекрёстные ссылки.

По ссылкам неплохо иметь возможность переходить.

До сего момента речь шла, практически, о 100% доступных читалок для PDF.

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

Внезапно, но это, казалось бы простое требование просто фантастически прореживает стройные ряды просмотрщиков!

После длительных поисков и переборов остался такой набор:

  • Кроссплатформенные
    • Как это не парадоксально, но это PDF.js иными словами - Firefox. И он, пожалуй, единственный.
  • Linux
    • Тут тоже нет разнообразия, единственный представитель, который умеет эту простую фичу - KDEшный Okular. Evince и производные что-то пытаются делать, но работают очень странно. Другие не умеют вовсе.
  • Windows
    • Кто сказал - Acrobat Reader? Нет! Он не умеет. Из опробованных мной, с неперегруженным интерфейсом, только два варианта: STDUViewer и Sumatra PDF. Первый подглючивает временами, остановился на втором (на работе). Foxit Reader тоже, вроде, умеет, но его новомодный интерфейс мне непонятен и неприятен.

UPD: Сегодня появилась статья на Хабре, где человек соединил Qt, QWebEngineView и PDF.js, вот репозиторий на GitHub:

Про годность или негодность сего поделия напишу чуть позже.

// GeoCrop 1.0

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

Так что да будет так: https://github.com/h4tr3d/geocrop/releases/tag/v1.0

// GeoCrop и популярные привязки

Если у вас на входе привязанный GeoTIFF, то проблем нет никаких, но если у вас просто растр (.png, .jpeg, .gif) и привязка для него, то есть нюансы. Вообще, GeoCrop умеет работать с любыми данными, с которыми умеет общаться GDAL. Но в в некоторых случаях не всё получается гладко, так, например, только сегодня он научился читать файл проекции для world-привязок (пара .prj+.pgw).

На просторах интернета можно встретить различные описания привязок, самые популярные:

  • Ozi Explorer
  • World files3)
  • Global Mapper

рассмотрим более подробно.

Ozi Explorer

GDAL не умеет только шифрованные OZFX, а так привязанная карта представляет собой пару .map+растр, где растр - это, обычно, .gif, .jpg или .png, реже - .bmp. При наличии такой привязки geocrop можно вызвать без дополнительных приготовлений:

geocrop -f VRT -s 50k K-53-026-A.map K-53-026-A.vrt

Обратите внимание, что передаётся map файл, а не растр.

World files

Т.к. сама привязка состоит из двух файлов (.prj+.pgw), то не так просто сказать, что и откуда читать. Согласно документации .pgw, .pngw или .wld файл4) подтягивается автоматически, если на входе карта в PNG (про другие форматы - ниже), а вот .prj файл нужно читать самому. Для этого в последней версии GeoCrop сделана небольшая эвристика:

  • Если растр содержит пустую проекцию, то производится попытка прочитать проекцию (формат WKT или PROJ.4) из файла с таким же именем, но расширением .prj и .prf.
  • Либо файл проекции можно жестко задать при помощи новой опции -p srs_def

Т.е. при наличии привязки в виде world files GeoCrop так же можно вызвать без дополнительных приготовлений так:

geocrop -f VRT -s 50k K-53-026-A.png K-53-026-A.vrt

если файл проекции находится в K-53-026-A.prj или K-53-026-A.prf, или так:

geocrop -f VRT -s 50k -p K-53-026-A.wkt K-53-026-A.png K-53-026-A.vrt

Обратите внимание, что в обоих случаях в качестве входного источника передаётся сам растр, а не его привязка.

Если у вас растры отличные от PNG:

  • BMP - привязка ищется в .bpw, .bmpw или .wld.
  • GIF - привязка ищется в .gfw, .gifw или .wld.
  • TIFF - если это GeoTIFF со встроенной привязкой, то она и используется, если это просто растр, то привязка ищется в .tfw, .tifw/.tiffw или .wld, а так же в MapInfo .tab файле.
  • JPEG - привязка ищется в .jgw, .jpgw/.jpegw или .wld, а так же MapInfo .tab файле.

Полный и актуальный список всегда можно посмотреть тут: http://www.gdal.org/formats_list.html

Global Mapper

В данный момент GDAL не поддерживает данный формат, а значит не поддерживает и GeoCrop. Ищите способ как сконвертировать его во что-то удобочитаемое.

Вообще .gmw файлы достаточно простые для разбора, так что, возможно, появится у меня и их поддержка. Тем более, что для тех же карт GGC там сразу зашита информация об обрезке (только странно, что они сразу не сделали рамку прозрачной).

// Новый режим в GeoCrop

Теперь в GeoCrop появился новый режим: генерация полигона для обрезки рамки в формате CSV+WKT. Вывод на stdout, так что можно сохранить в любой удобный файл из скрипта, после чего использовать как аргумент для -cutline у gdalwarp в какой-то более сложной команде. Вызова gdalwarp при этом не происходит.

Активируется режим опцией -g (от [g]enerate). Указывать выходной файл при этом не нужно - он будет проигнорирован.

Так же, теперь появилась возможность указывать файл с описанием проекции: -p srs_file. Сама проекция должна быть в формате WKT или PROJ.4. Эта опция перезаписывает определение проекции в текущем файле. Полезна для преобразования файлов с привязками в виде world-файлов. Более того, если проекция в файле пустая, а опция не указана то произведётся попытка прочитать её автоматически из файла с таким же именем, но с расширением .prj или .prf (какой первый попадётся). Так что популярные карты ГГЦ с такими привязками теперь можно конвертировать так же просто, как и с привязками Ozi Explorer.

Чуть раньше реализована функциональность по передаче дополнительных параметров gdalwarp. Для этого нужно завершить опции приложения двойным минусом , опции после него будут переданы gdalwarp как есть без изменений:

geocrop -f VRT -s 200k K-53-07.map K-53-07.vrt -- -overwrite

опция -overwrite будет передана gdalwarp. Помимо этого, теперь можно переопределить и сам исполняемый файл gdalwarp - опция -w GDALWARP.

Кроме того изменился формат опций, стало возможным указывать выходной формат (опция -f FMT, как следствие, образовались такие возможности: Быстро и ненавязчиво готовим карту для открытия в QMapShack) или только обрезать рамку, не делая кроп (опция -n).

// MinGW GCC 5 в Trusty

Сделал PPA, куда положил MinGW GCC 5: https://launchpad.net/~adrozdoff/+archive/ubuntu/mingw

Версия GCC на момент написания поста: 5.3.0. Сборка зависит от репозитория https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages (если надумаете собирать сами).

Краткие характеристики сборки:

  • Модель потоков: только posix (требуется libwinpthreads), т.к. позволяет использовать все возможности C++11/C++14. Если будет спрос на win32, то нужно только добавить одну строчку и чуть подкорректировать альтернативы (т.е. сборка поддерживает, просто выключил win32).
  • Обработка исключений: sjlj для win32 и seh для win64
  • Сборка для Win32 и Win64

Добавление репозитория:

  sudo apt-add-repository ppa:adrozdoff/mingw

Установка:

  sudo apt-get install gcc-5-mingw-w64 g++-5-mingw-w64

Компилятор с суффиксом -5, что бы не конфликтовать с тем, что распространяется вместе с Ubuntu/Mint.

В этом же репозитории планирую выкладывать сборки библиотек.

// Android SDK/NDK в Linux Mint

Просто последовательность действий - на память (брать из PPA не хотелось). Как качать NDK, SDK и Android Studio я расписывать не буду. Распаковку всего этого добра произвёл в ~/Android. Имена директорий привёл к виду (или переименованием или созданием необходимых симлинков):

  • android-sdk
  • android-ndk
  • android-studio

По сути, этот рецепт подходит для любого дистрибутива, в большинстве случаев будет отличаться только первый пункт.

Итак…

Необходимое

  1. Ставим OpenJDK: sudo apt-get install openjdk-7-jdk libswt-cairo-gtk-3-jni libswt-cairo-gtk-3-jni ant
  2. В ~/.profile или ~/.bashrc_profile прописываем:
    export ANDROID_HOME=$HOME/Android/android-sdk
    export ANDROID_NDK=$HOME/Android/android-ndk
    # For compability
    export NDK_HOME=$ANDROID_NDK
    export ANDROID_SWT=/usr/share/java
    export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools:$ANDROID_NDK:$HOME/Android/android-studio/bin
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ANDROID_HOME/tools/lib
  3. Переходим в ~/Android/android-studio/bin и выполняем:
    ln -s studio.sh android-studio
  4. Добавляем следующие параметры в studio.vmoptions и studio64.vmoptions (предварительно сделайте резервные копии, пригодятся при обновлениях):
    -Dswing.aatext=true
  5. На этом шаге можно перелогиниться, вызвать android и поставить платформы, утилиты, потом запустить Android Studio и сделать необходимые настройки.

Опциональное

Ярлыки в меню

FIXME относительные пути к иконкам не воспринимаются, поэтому иконки не отображаются, только текст.

  1. Создаём файл: ~/.local/share/applications/android-sdk.desktop со следующим содержимым:
    [Desktop Entry]
    Encoding=UTF-8
    Name=Android SDK
    Comment=Android Sofware Development Kit
    Exec=android
    Icon=~/Android/android-sdk/tools/apps/SdkController/res/drawable-xhdpi/ic_launcher.png
    Terminal=false
    Type=Application
    Categories=IDE;Development;

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

  2. Извлекаем иконку Android Studio:
    unzip -o lib/resources.jar artwork/icon_AS_128.png

    Вызываем команду из корня android-studio

  3. Создаём файл: ~/.local/share/applications/android-studio.desktop:
    [Desktop Entry]
    Version=1.0
    Type=Application
    Name=Android Studio
    Exec=android-studio %f
    Icon=~/Android/android-studio/artwork/icon_AS_128.png
    Comment=Develop with pleasure!
    Categories=Development;IDE;
    Terminal=false
    StartupNotify=true
    StartupWMClass=jetbrains-android-studio
    MimeType=application/x-extension-iml;

Автодополнение BASH

Автодополнение для команд android, adb, emulator, fastboot и repo.

  1. Идём в ~/Android
  2. Забираем последнюю версию скрипта (предполагаю, что git уже установлен):
    git clone https://github.com/mbrubeck/android-completion.git
  3. Создаём файл ~/.bash_completion и помещаем в него:
    . $HOME/Android/android-completion/android
    . $HOME/Android/android-completion/repo
  4. Перелогиниваемся

// LyX в Linux Mint и русский

Что бы в LyX начали сходу работать русский нужно поставить пакеты: texlive-lang-cyrillic и cm-super. Точнее даже не так: набивать тексты вы сможете сразу, а вот генерировать PDF - только после установки пакетов.

// Firefox и быстрый поиск

Все - не все, но многие знают, что в Firefox, Google Chrome и, вроде, Опере можно в свойствах закладки указать т.н. ключевое слово (keyword), набрав которое в адресной строке браузера и нажав Ввод перейдёшь по ссылке, на которую указывает данная закладка.

Удобно? Кому как. Но! У этого функционала есть ещё одно одно применение.

Дело в том, что в самом адресе закладки можно указать подстановочную последовательность (плейсхолдер, placeholder, уж не знаю как более корректно перевести это слово на русский язык) %s. На это место будет подставлен весь текст который будет введён после ключевого слова.

На пальцах. Допустим, у нас есть закладка, у которой ключевое слово g, тогда, если в адресной строке введём:

g ябеда-корябеда солёный огурец

то вместо %s будет подставлено: «ябеда-корябеда солёный огурец»

Теперь чуете? Правильно! Мы можем вызывать какие-то URL с параметрами. Это общий случай, я же, в основном, использую это для поиска. К примеру, у меня такой набор (жирным выделены названия закладок):

Да, в самом Firefox можно ключевые слова задать для существующих поисковых систем (в Search bar), но вручную там нельзя добавить произвольную (задав только URL для поиска), только установкой соответствующего расширения, которого может не оказаться. Плюс метод работает во многих браузерах, так что импортировав закладки, получите и работающий поиск, к которому привыкли.

В luakit это сделано прямо и ровно через технологию Search Engine. Пример можно посмотреть прямо в коробке в файле globals.lua (или тут).

// ps2pdf и отрицательное смещение сверху

Если при преобразовании PS в PDF на выходе наблюдается отрицательное смещение (как бы часть листа срезана) сверху, то стоит попробовать явно задать формат страницы при преобразовании:

ps2pdf -sPAPERSIZE=a4 input.ps output.pdf

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

// Две утилиты для работы с картами: ozi2map и geocrop

На выходных готовил растровую карту для похода на Кодар, с последующей конвертацией оной в JNX.

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

В результате, подумал и написал за выходные две программы: ozi2map и geocrop

ozi2map

Данная утилита более не актуальна. Версия GDAL (>=1.10), входящая во все популярные дистрибутивы, уже умеет сама обрабатывать такие MAP файлы.

Первая, как можно понять из названия, предназначена для конвертации карты с привязкой OZI (сама карта в JPEG или GIF или другом распространённом растровом формате, который поддерживает OZI, но не OZFX/OZFX2/OZFX3, для них преобразования можно сделать средствами самого gdal (в прошлых статьях писал про это)).

Для чтения точек привязки и параметров проекции используется функция из недр GDAL: GDALReadOziMapFile(…), что, в отличии от питоновского ozi2geotiff.py, даёт корректные параметры проекции. Далее, не стал особо заморачиваться и подсовывая нужные параметры gdal_translate/gdalwarp вызываю их через system().

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

./ozi2map O-50-103.map O-50-103.jpg
./ozi2map O-50-103.map O-50-103.jpg O-50-103.tif

Если имя выходного файла не задано, имя будет сформировано из имени растра с заменой расширения на .tif.

Всё, пользоваться программой должно быть проще простого. Найти исходники (GPLv2) можно тут:
https://git.gitorious.org/h4tr3d-utils/ozi2map.git

Собирать просто:

make

Полученный бинарник можно запускать от куда угодно.

geocrop

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

Т.е. по сути, программе на вход нужен только масштаб листа (в виде 1M, 500k, 200k, 100k, 50k, 25k, 10k, 5k, 2k) и сам лист карты в формате, поддерживаемом GDAL с корректной привязкой.

Когда расчёты по привязке будут выполнены, вызывается gdalwarp через system(). Полигон для обрезки формируется в координатах листа (не в точках растра), для всех листов, кроме 1M, это 4х угольник (на будущее будет более качественно сделано, но и текущего результата хватит в 99.99% случаев).

Пользоваться программой не сложнее чем ozi2map:

./geocrop -s 100k O-50-103.tif O-50-103-crop.tif

Первым аргументом - стилизованное обозначение масштаба:

  • 1M - 1:1 000 000 (это масштаб используется, если мнемоника не распознана)
  • 500k - 1:500 000 («пятикилометровка»)
  • 200k - 1:200 000 («двухкилометровка»)
  • 100k - 1:100 000 («километровка»)
  • 50k - 1:50 000 («полукилометровка» или «пятисотметровка»)
  • 25k - 1:25 000 («двухсотпятидесятиметровка»)
  • 10k - 1:10 000 («стометровка», пока не реализовано)
  • 5k - 1:5000 («пятидесятиметровка», пока не реализовано)
  • 2k - 2:2000 («двадцатиметровка», пока не реализовано)

Если этот параметр пропущен, используется масштаб 100k.

Вторым аргрументом - входной файл, поддерживаемый GDAL.

Третий аргумент - выходной, кропнутый файл. По умолчанию - GeoTiff, но можно переопределить опцией «-f FORMAT», где FORMAT - любой поддерживаемый GDAL.

Если хотите обрезанные карты потом склеивать при помощи gdal_merge.py, и получить вразумительные результат, входной файл должен быть в цветовой палитре RGB, узнать это можно при помощи утилиты gdalinfo, если в выводе есть такое:

Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue

значит всё хорошо, если нет (выводится палитра из 255 цветов), то палитра индексированная, нужно преобразовать в RGB при помощи утилиты pct2rgb.py из комплекта GDAL.

Собирать просто:

mkdir build
cd build
cmake ..
make

Если на стадии cmake будут какие-то проблемы, стоит поставить dev-пакеты для GDAL и PROJ.4

Исходники можно взять тут (GPLv2):
https://github.com/h4tr3d/geocrop

// luakit: проблема со скролингом по PgUp/PgDown

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

Error: in bind call: /home/user/.config/luakit/webview.lua:341: attempt to perform arithmetic on local 'p' (a nil value)

Решение проблемы нашёл тут: https://github.com/mason-larobina/luakit/issues/68, нормальный рабочий вариант получается этот: https://github.com/mason-larobina/luakit/issues/68#issuecomment-5528890

// Однооконный Dia

Достаточно запустить:

dia --integrated

теперь вполне можно пользоваться.

Ну и чуть ярости: ну какого чёрта не вынести это в настройки!?

// Ищем замену OziExplorer на Linux

Решил таки переопубликовать свою статью в OpenSource (http://osa.samag.ru/info/OpenSource068.zip) и у себя в блоге. В журнале статья называется: «QLandKarte GT как замена OziExplorer в GNU/Linux», здесь же публикую под оригинальным.

// sdict - небольшой скрипт-оболочка для StarDict (qstardict и sdcv)

Могу напугать некоторых, но в стародавние времена со словарями (имеется в виду - удобные программы-оболочки и сами словари) в Linux было, мягко сказать, не густо. В то время я настроил у себя дома словарный сервер dictd (боле подробно на английском: dict), сначала просто на локальном хосте, потом, когда появилось ещё парочку компьютеров и достаточно дешёвый доступ в интернет сервер стал использоваться и на них, а так же с работы.

Удобным было почти всё:

  • приятная консольная программка dict - для быстрых запросов
  • возможность настроить словарную базу только в одном месте, а на остальных компьютерах указать только адрес сервера
  • прекрасная графическая программка kdict, которая, запускаясь, проверяла буфер обмена и если там что-то было - переводила его (программа проверяла запущенные копии, запускалась в одном экземпляре)

Время шло, начались появляться и недостатки:

  • много времени стало проводиться за нетбуком, да ещё в отстутствии интернета, иногда нужно было что-то быстро перевести
  • доступность домашнего сервера была явно не на высоте - и свет вырубали и связь рвалась
  • программа kdict со своими удобными свойствами канула в лету (уже и не знаю - вообще она существует, но переводить из буфера обмена она как-то перестала)

Пришлось искать дополнительное, оффлайн решение, желательно не менее функциональное. Благо, что при этом и прогресс не стоял на метсе, появилась чудная программа StarDict, словари для которой на ура переделывались формата dictd да и оболочки были разнообразны:

  • stardict - написана на Gtk+, каноническая версия
  • qstardict - оболочка на Qt4, по своими возможностям оказалась очень похожа на полюбившийся мне kdict, в частности возможности перевода содержимого буфера обмена, стоит ли говорить, что мой выбор остановился на ней? Плюс программа успешно управляется путём посылки DBus уведомлений, что и будет позже мной использовано.
  • sdcv - консольная программа для запроса перевода, по сути аналог dict

Теперь подробнее остановлюсь на qstardict, особенно на работе на переводе содержимого буфера обмена.

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

Мне показался такой вариант не очень удобным. Но не беда - благо программа может управляться по DBus, в частности, для показа этого самого всплывающего окна с переводом. Тут же вспоминаем про удобную программу xclip для работы с буфером обмена из состава Xorg, примешиваем немножно универсальности для работы из X11 или из консоли и получаем такой скрипт:

sdict.sh
#!/bin/sh
 
 
check_prog()
{
  local res
  prog=`which $1 2> /dev/null`
  res=$?
  if [ $res -ne 0 ]; then
    echo "Can't found program: " $1
    echo "Try to install it via your package manager"
    exit 1
  fi
 
  echo $prog
}
 
 
check_process()
{
  pidof "$1" > /dev/null 2>&1
}
 
 
sdict_x11()
{
  local res
  qstardict=`check_prog qstardict`
  qdbus=`check_prog qdbus`
 
  check_process "$qstardict"
  res=$?
  if [ $res -ne 0 ]; then
    # for begin - start qstardict
    "$qstardict" > /dev/null 2>&1 &
    sleep 2
  fi
 
  "$qdbus" org.qstardict.dbus /qstardict org.qstardict.dbus.showPopup "$@"
  "$qdbus" org.qstardict.dbus /qstardict org.qstardict.dbus.showTranslation "$@"
}
 
 
sdict_console()
{
  sdcv=`check_prog sdcv`
  $sdcv -n "$@"
}
 
# force no X11 version
no_x11="false"
if [ "$1" = "--no-x11" ]; then
  no_x11="true"
  shift
fi
 
# take word from commad line or from buffer
TRANSLATE=$@
if [ -z "$1" ]; then
  xclip=`check_prog xclip`
  TRANSLATE="`$xclip -o`"
fi
 
# run translation
if [ -z "$DISPLAY" -o "$no_x11" = "true" ]; then
  sdict_console "$TRANSLATE"
  exit $?
else
  sdict_x11 "$TRANSLATE"
  exit $?
fi

Как она работает?

Просто:

  • при запуске проверяет, что установлена переменная DISPLAY и начинает работать с qstardict
  • если переменная DISPLAY не задана, или первым аргументов в командной строке стоит –no-x11, то работа начинается с консольной версией sdcv
  • если в качестве аргументов sdict передаются какие-то слова - пытается их перевести
  • если список аргументов пуст - пытается получить содержимое буфера обмена при помощи xclip и перевести его
  • перед посылкой сообщения по DBus, проверяет, что qstardict запущен, если нет - то запускает его, ждёт 2 секунды и пытается вызвать его для перевода (тут может быть скрыт подводный камень: у нас на работе есть терминальный сервер на Linux, и графических сессий там может быть много, соответственно у каждого пользователя может быть запущена своя версия qstardict, тут проверка запущенности qstardict может отработать некорретно - исправляется легко, но для себя пока не вижу необходимости, поэтому просто информирую)
  • перед запросом команд xclip, qdbus, qstardict, sdcv производится проверка наличия их в пути поиска переменной окружения $PATH, если не находится - программа выдаёт сообщение об их отсутствии на стандартный вывод и завершает свою работу со статусом 1. Обычно эти программы есть почти в каждом дистрибутиве Linux в одноимённом пакете, в случае ArchLinux:
Команда Пакет Команда для устрановки Примечание
xclip xclip pacman -S xclip
qdbus qt pacman -S qt поставится как зависимость при установке qstardict
qstardict qstardict pacman -S qstardict
sdcv sdcv pacman -S sdcv

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

Пользуйтесь :)

// Клавитурные сокращения в vimdiff

ctrl+w ctrl+w Переключиться на другое окно.
ctrl+w Up/Down/Left/Right Переключиться на другое окно.
do Получить изменения из другого окна в текущее.
dp Вставить изменения из текущего окна в другое.
]c Перейти к следующему изменению.
[c Перейти к предыдущему изменению.
:diffupdate diff update
:syntax off выключить подсветку синтаксиса
zo раскрыть свернутый кусок текста
zc свернуть кусок текста