ujihisa
ujihisa
/Users/ujihisa/git/ruby192/local/bin/ruby test/markdown_test.rb (in /Users/ujihisa/git/rpeg-markdown) Loaded suite test/markdown_test Started ...........................................F...... Finished in 0.059146 seconds. 1) Failure: test_that_extension_methods_are_present_on_markdown_class(MarkdownTest) [test/markdown_test.rb:11]: Markdown class should respond to #to_html 50 tests, 62 assertions, 1 failures, 0...
``` $ gem install rpeg-markdown Building native extensions. This could take a while... ERROR: Error installing rpeg-markdown: ERROR: Failed to build gem native extension. /Users/ujihisa/git/ruby/local/bin/ruby extconf.rb checking for pkg-config... yes...
https://github.com/vim-jp/vital.vim/pull/764
Vital: ```vim function! s:f() abort let s:D = vital#vital#new().import('DateTime') echo s:D.from_unix_time(1325441045, 9).hour() endfunction call s:f() "=> 2 " ↑ I expect 3 ``` Ruby: ```ruby p Time.at(1325441045, in: '+09:00').hour #=>...
前にgist貼ってたやつです。travisでは環境設定でうまくいっているので、ローカル開発環境でもそんな感じでアレできると便利そうです。 ``` $ themis --runtimepath ~/.vimbundles/vimproc --reporter dot .....................................................................................................................................................................................................................................................F...............F..F...............FFFFFF...................................FFFF...............FF..........................................................................................................................P...................................................................................................................... Pending: 1) Text.Sexp parse Vital.Text.Sexp: any function call needs if_lua Failures: 1) Data.OrderedSet Fn_identifier stringifies to a key name of a...
Lingrにて、「devブランチがある方がよいのではないか」「ホイホイpullreqマージしちゃって大丈夫なのか」という議論がありました。 僕の意見は「devブランチ不要。実験的新機能はExperimental. namespace以下に配置。実験的な既存モジュールの書き換えはそのたびにtopic branchをつくる」です。 一般に、devブランチがある方がよいのは、masterブランチが常に安定している必然性があるプロジェクトです。vitalの場合は比較的masterブランチの新規不安定moduleの追加に関しては緩やかでよい、というのが僕の意見です。新しいmoduleが入っても、vitalを利用してるプラギンがVitalizeで利用中moduleをアップデートしたところで、なにも壊れないからです。 masterブランチにある新しいmoduleを試してみようというとき、そのmoduleに高い安定性を期待するかしないか。vital開発者側の立場としては「どの程度期待するかは自己判断でお願いします」で良いと思います。というのも、安定度を高めるためには実際にプラギンから使った上でフィードバックをもらうのが不可欠だと考えるからです。vitalでプラギンに利用可能にすることが、安定度を高めるよりも重要だと思います。 TODO: 汎用目的のdevブランチを作るのと、特定module(複数の場合も)の実験的な大幅な改変のためにtopicブランチを作るのの違いについて、反論があれば僕の意見もここにまとめる
> vital 本体の API のドキュメントを書こうと思ったけど、import() とか load() の仕様の議論がまだ収束してないことに気付くなど。 > えーと、load の as 機能について。現状の load(['Foo']) がわかりづらいとの話だった気がする。 > 個人的には短く書けて気に入っているのだけど。 > 仕様整理。 > 1. load するとモジュールが V に置かれてそこからアクセスできるようになる。 > > ``` > V.load('Foo.Bar.Buz')...
## 不具合の内容 :terminal への出力に細かく改行文字が入り込み、最終的に一行一文字になって何も読めなくなる。 ### 現象・ログ :terminal への出力に細かく改行文字が入り込む。後述の数秒のyoutube動画での:terminalの様子が一目瞭然で便利です。 ### 再現手順 `:terminal` でいくらか出力がある状態で、terminal bufferはterminal modeのまま (= terminal-normal modeにしないで) windowをリサイズする。 https://youtu.be/ayypfp3N1FE ### 期待動作 前述のyoutube動画のように、window幅を広くしたときに元に戻り、文字が読める。 ## Vimのバージョン 8.2.1704 ( `:version` で確認できます) ``` :version...
## 不具合の内容 LinuxとMacのGVimの:terminalで `` を入力しても `;2u` を入力したことになる ### 現象・ログ LinuxとMacのGVimの:terminalで `` を入力しても `;2u` を入力したことになり、 `` 自体を入力できない ### 再現手順 Linuxで `gvim -u NONE -U NONE` して `:terminal` して `` する。 ###...
# 5と似て非なるissue。まあ仕様なら仕様ということでよいですが、毎回結構驚かされるというか。