Yi очередная попытка использования

кстати оно так и разделяет экран только по вертикали? Горизонтальный сплит они вобще осиливать собираются не?

cast ethercrow он мейнтенер и основной контрибьютор щас.

cast ethercrow

Хм, видел ник на #yi - буду надеятся, что тогда он пропустил сообщения.

кстати оно так и разделяет экран только по вертикали?

Это был следующий пункт: пока не смотрел. В принципе на небольшой хак исходников (как с цветами) еще могу пойти.

Судя по Window.hs пока только вертикально..

Похоже в vty-интерфейсе пока не реализовано.

Для pango - вроде (не пробовал) можно посредством layout-manager, то есть несколько другой уровень абстракции - ближе к xmonad, чем к emacs (возможно той же гибкости не будет, но простые конфигурации покроет).

И YiM () странно стекуются: два «promptFile» ожидают ввод в обратном порядке: как по-нормальному выполнить два интерактивных действия?

09:00 < dormi> hello, I couldn't figure out how to synchroniously compose YiM: using two prompFile expects input for second
09:01 < dormi> and is there a way to run user "hooks" on change-current-buffer
               (use case: changing cursor color depending on top/insert mode)
13:54 < ethercrow> dormi: hello
13:55 < ethercrow> http://hpaste.org/89945 - is this what you want regarding promptFile composition?
13:56 < ethercrow> looks like lambda got escaped while pasting

кстати оно так и разделяет экран только по вертикали? Горизонтальный сплит они вобще осиливать собираются не?

Похоже в vty-интерфейсе пока не реализовано.

Для pango - вроде (не пробовал) можно посредством layout-manager, то есть несколько другой уровень абстракции - ближе к xmonad, чем к emacs (возможно той же гибкости не будет, но простые конфигурации покроет).

Да, Vty пока не умеет. Было бы здорово, если бы Vty и Pango раскладывали интерфейс одним и тем же кодом.

переключение цвета курсора (для vim очень привык) в зависимости от top/insert режима для одного буфера прикрутил, но нужны хуки при переключении между буферами - как можно реализовать?

Заведи тикет, чтобы не потерялось. Еще есть гугл-группа yi-devel, ее читает больше живых людей, чем сидит в #yi.

13:54 < ethercrow> dormi: hello

thx, не дождался - пошел на #haskell спрашивать

http://hpaste.org/89945

Даже так: promptFile "..." >> promptFile "...". Например сначала удалить буффер с подтверждением, потом открыть новый - вроде find-alternate-file из emacs-a => но приглашение сначала для второго. Вроде код пробовал читать, так и не вник почему.

Тогда еще пара моментов:

1) Есть прикрепленный ghci, если его закрыть в редакторе - то лишь потом будет ошибка вроде «findBuffer ..». Но перед «reload» - не успевает(?) закрыться, появляется зомби. Пришлось прокидывать наружу Core.onYiVar (для получения ProcessHandle) и Core.waitForExit.

2) Есть shiftIndentOfRegion, если хочется сдвинуть на «неродной» shiftWidth: то нашел только Buffer.Misc.modifyMode, но там еще «reset the keymap process». (может можно было через --ghc-option добавить mtl и использовать «modify» - но выглядит как совсем грязный хак)

3) Колонки в режиме expandTab после вставленного таба ^Q^I начинаются с 0 - но тут наверное можно сразу тикет.

Заведи тикет, чтобы не потерялось.

Хорошо. Просто если этого сразу нет, то вероятно потребуются более абстрактные корректировки: вроде добавления «bufferFocusHook».

На всякий случай, вдруг пригодится, такая трансяция elisp использовалась для цветов http://hpaste.org/90403 (ну и для своего фиксированного окружения просто поменял UI.Vty.colorToAttr).

Правда там проблемы были c vty: он делает отображение цветового пространства в 240, для urxvt-256 - кривые цвета получились. Наверное надо устанавливать t_Co (или что-то вроде перед запуском), я просто прибил: http://hpaste.org/90404 (там еще enter на привычный).

И еще момент: чтобы получить разные ^J / ^M делал stty -icrnl перед запуском. Какая у вас «полиси»: должны быть одинаковы, а если нет, кто из них Enter?

Еще :)

modeToggleCommentSelection :: BufferM ()

Выглядит как «гвозди», вроде вполне можно

:: Region -> BufferM ()

modeToggleCommentSelection :: BufferM ()
Выглядит как «гвозди», вроде вполне можно
:: Region -> BufferM ()

Завел https://github.com/yi-editor/yi/issues/441

> http://hpaste.org/89945

Даже так: promptFile "..." >> promptFile "...". Например сначала удалить буффер с подтверждением, потом открыть новый - вроде find-alternate-file из emacs-a => но приглашение сначала для второго. Вроде код пробовал читать, так и не вник почему.

В том-то и дело, что последовательные promptFile надо писать не через >>, а так, как в пасте, потому что они принимают континуацию.

На всякий случай, вдруг пригодится, такая трансяция elisp использовалась для цветов http://hpaste.org/90403 (ну и для своего фиксированного окружения просто поменял UI.Vty.colorToAttr).

Спасибо, надо будет внедрить.

И еще момент: чтобы получить разные ^J / ^M делал stty -icrnl перед запуском. Какая у вас «полиси»: должны быть одинаковы, а если нет, кто из них Enter?

Лично мне бы хотелось, чтобы ^M был enter, а ^J свободен для биндов, чтобы было как в нормальном виме. В емаксе так же?

Есть shiftIndentOfRegion, если хочется сдвинуть на «неродной» shiftWidth: то нашел только Buffer.Misc.modifyMode, но там еще «reset the keymap process». (может можно было через --ghc-option добавить mtl и использовать «modify» - но выглядит как совсем грязный хак)

Я чото не совсем понял, что надо. Если надо возможность сдвигать строки на число пробелов некратное shiftWidth, то наверное проще всего сделать shiftRegionCharWiseB :: Int -> Region -> BufferM (), который будет принимать размер в символах.

а так, как в пасте, потому что они принимают континуацию

Понял, но ведь часто нужен не голый promptFile, а уже обернутое: например, Keymap.Emacs.killBuffeE. А теперь, допустим, нужна ф-ия, удаляющая два буфера. Тогда ведь нельзя будет просто воспользоваться готовым?

как в нормальном виме. В емаксе так же?

Да, так: собственно подгонял к этому поведению 1) поменял ^J -> ^M в «vty» Graphics.Vty.LLInput; 2) stty -icrnl: убрал «translate CR to NL» (обе комбинации давали ^J)

Лично мне бы хотелось, чтобы ^M был enter, а ^J свободен для биндов

Насколько понимаю, если не править (апстрим в виде vty): то достаточно будет: убрать System.Posix.Terminal.MapCRtoLF (родная реализация stty -icrnl) и поменять: ^M <-> ^J в UI.Vty.fromVtyKey

Я чото не совсем понял, что надо ... проще всего сделать shiftRegionCharWiseB

В этом конкретно случае - наверное проще. Но может быть добавить, скажем:

withModifiedModeB (forall syn. Mode syn -> Mode syn) -> BufferM a -> BufferM a

А забыл ведь самое главное... : можно ли теоретически «подлючиться» к syntax?
Скажем, для нормальной реализации skipCommentForward :: BufferM / или сделать аналог emacs-paredit но на уровне выражений, а не скобок.

А забыл ведь самое главное... : можно ли теоретически «подлючиться» к syntax?
Скажем, для нормальной реализации skipCommentForward :: BufferM / или сделать аналог emacs-paredit но на уровне выражений, а не скобок.

Я ни разу не пробовал, мне пока приоритетнее допил новой вимоэмуляции. Для начала, наверное, надо почитать диссер про javascript mode http://publications.lib.chalmers.se/records/fulltext/112284.pdf или код precise haskell mode.

Вообще разбор редактируемого кода в yi - это такая тема, в которой понимает только Жан-Филип, который всегда занят. Прозреваю, что с практической точки зрения было бы лучше не вкомпиливать парсеры в редактор, а иметь интерфейс для внешних парсеров. Хотя бы для того, чтобы иметь возможность переиспользовать libclang для разбора C++.

^M <-> ^J в UI.Vty.fromVtyKey

в смыслe Event KEnter [] <-> Event (KASCII 'j') [MCtrl]

Для начала, наверное, надо почитать диссер про javascript mode http://publications.lib.chalmers.se/records/fulltext/112284.pdf или код precise haskell mode.

Эх.. все намного сложнее, чем хотелось бы). Спасибо за ссылки.

Тем временем тихо и незаметно готовится включение нового виморежима в master: https://github.com/yi-editor/yi/pull/442

Добровольцы, тестировщики и просто сочувствующие приветствуются.