hi
vim-users.jp
February 03, 2010
224 messages
> 関連付けで開くはそれこそ環境によって方法がまちまちなので、こうやって組み込むより、起動コマンドを指定するオプションを用意して、その初期値をよしなにした方が良さそうではある。
¶
そうすれば今回みたいに対応漏れがあっても本体のソース書き換えずに設定変更だけでとりあえず対応できるし。
> 関連付けで開くはそれこそ環境によって方法がまちまちなので、こうやって組み込むより、起動コマンドを指定するオプションを用意して、その初期値をよしなにした方が良さそうではある。
¶
そうすれば今回みたいに対応漏れがあっても本体のソース書き換えずに設定変更だけでとりあえず対応できるし。
call vimfiler#set_execute_file('vim', 'vim')
call vimfiler#set_execute_file('txt', 'notepad')
call vimfiler#set_execute_file('vim', 'vim')
call vimfiler#set_execute_file('txt', 'notepad')
これだけでも「おぉ!」と思いましたが、同じような機能はautocomplpopでもできるんですよね。
>ただ、以下のような理由からautocomplpopを選択しました。
>日本人の方が作成されているので、ドキュメントが日本語
>カスタマイズ項目が豊富
>プラグインで拡張が可能
>snipmateのトリガーを補完リストに表示できる
これだけでも「おぉ!」と思いましたが、同じような機能はautocomplpopでもできるんですよね。
>ただ、以下のような理由からautocomplpopを選択しました。
>日本人の方が作成されているので、ドキュメントが日本語
>カスタマイズ項目が豊富
>プラグインで拡張が可能
>snipmateのトリガーを補完リストに表示できる
ドキュメントについては、AutoComplPopも日本語ドキュメントがあるので大体同等だと思います。
ドキュメントについては、AutoComplPopも日本語ドキュメントがあるので大体同等だと思います。
presentationファイルなどを含めると、情報量的にneocomplcacheのほうが詳しいかもしれません。
presentationファイルなどを含めると、情報量的にneocomplcacheのほうが詳しいかもしれません。
カスタマイズ性やプラグインによる拡張はneocomplcacheを選択する積極的な理由となるでしょう。
カスタマイズ性やプラグインによる拡張はneocomplcacheを選択する積極的な理由となるでしょう。
snipMate補完は最新のAutoComplPopでも可能です。ただパッチを当てる必要があったり、
snipMate補完は最新のAutoComplPopでも可能です。ただパッチを当てる必要があったり、
入力が大文字の時だけだったりと、neocomplcacheの統合された補完と比較すると、ちょっと使いにくいですね。
入力が大文字の時だけだったりと、neocomplcacheの統合された補完と比較すると、ちょっと使いにくいですね。
>" neocomplcache
>let g:neocomplcache_enableatstartup = 1
>let g:neocomplcache_smartcase = 1
>let g:neocomplcache_enablecamelcasecompletion = 1
>let g:neocomplcache_enableunderbarcompletion = 1
>let g:neocomplcache_minsyntaxlength = 3
>let g:neocomplcache_manualcompletionstartlength = 0
>let g:neocomplcache_keywordpatterns['default'] = '\v\h\w*'
>let g:neocomplcache_plugincompletionlength = {
>" neocomplcache
>let g:neocomplcache_enableatstartup = 1
>let g:neocomplcache_smartcase = 1
>let g:neocomplcache_enablecamelcasecompletion = 1
>let g:neocomplcache_enableunderbarcompletion = 1
>let g:neocomplcache_minsyntaxlength = 3
>let g:neocomplcache_manualcompletionstartlength = 0
>let g:neocomplcache_keywordpatterns['default'] = '\v\h\w*'
>let g:neocomplcache_plugincompletionlength = {
しかし、その後AutoComplPopが名称変更と共に変数名を変更してしまい、結局互換性がありません。
しかし、その後AutoComplPopが名称変更と共に変数名を変更してしまい、結局互換性がありません。
のような変数名にしたかったのですが、neocomplcacheがここまで広まってしまったのでどうしようもないです。
のような変数名にしたかったのですが、neocomplcacheがここまで広まってしまったのでどうしようもないです。
>ただ、TextMateのようにプレースホルダの中にプレースホルダを定義出来ないことが残念です。
>将来のリリースに期待です。
>ただ、TextMateのようにプレースホルダの中にプレースホルダを定義出来ないことが残念です。
>将来のリリースに期待です。
snippet div
<div ${1:id="${2:someid\}"}>${3}</div>${4}
プレースホルダの中にプレースホルダを書くことができます。ただし、}はエスケープしてください。
\がエスケープ文字になっているので、\を初期値に入れるときは\\とする必要があります。
snippet div
<div ${1:id="${2:someid\}"}>${3}</div>${4}
プレースホルダの中にプレースホルダを書くことができます。ただし、}はエスケープしてください。
\がエスケープ文字になっているので、\を初期値に入れるときは\\とする必要があります。
> これだけでも「おぉ!」と思いましたが、同じような機能はautocomplpopでもできるんですよね。
> これだけでも「おぉ!」と思いましたが、同じような機能はautocomplpopでもできるんですよね。
ちなみにここなんですけど、neocomplcacheで一番重要なところはVimの補完を再実装しているところです。
ちなみにここなんですけど、neocomplcacheで一番重要なところはVimの補完を再実装しているところです。
AutoComplPopは組み込み補完を呼び出すだけなので実装が楽なんですが、ちょっと凝ったことをしようと思っても、Vimのせいで出来ないことが多くなってしまいますね。
AutoComplPopは組み込み補完を呼び出すだけなので実装が楽なんですが、ちょっと凝ったことをしようと思っても、Vimのせいで出来ないことが多くなってしまいますね。
シンタックス補完にしても、Vim標準のsyntaxcomplete.vimとは比べものにならないほど拡張されています。
シンタックス補完にしても、Vim標準のsyntaxcomplete.vimとは比べものにならないほど拡張されています。
>Ruby経由の人たちが発表している(ように見える)Emacs 拡張ファイルの凄いトコは、根本的な「Emacsインターフェースの改善」を目論んでいるように見える辺り、なんです。
>これは凄い、んです。まさに革命的で。
>Ruby経由の人たちが発表している(ように見える)Emacs 拡張ファイルの凄いトコは、根本的な「Emacsインターフェースの改善」を目論んでいるように見える辺り、なんです。
>これは凄い、んです。まさに革命的で。
m2ymさんのauto-complete.el、rubikitchさんがメンテナンスしているanything.elはそのとおりですよね。
m2ymさんのauto-complete.el、rubikitchさんがメンテナンスしているanything.elはそのとおりですよね。
実はneocomplcache, vimshell, vimfiler, vimprocは「Vimインタフェースの改善」を目的に作られています。
実はneocomplcache, vimshell, vimfiler, vimprocは「Vimインタフェースの改善」を目的に作られています。
>1.Emacsの「カスタマイズ神話」は8割方ウソである。
>2.誰も本当はEmacs Lispなんて触りたがらない。
>3.CLerなんか特にEmacs Lispなんて触らない。
>4.実はEmacsを「進歩させている」最大勢力は、現時点ではRubyist達である。
>1.Emacsの「カスタマイズ神話」は8割方ウソである。
>2.誰も本当はEmacs Lispなんて触りたがらない。
>3.CLerなんか特にEmacs Lispなんて触らない。
>4.実はEmacsを「進歩させている」最大勢力は、現時点ではRubyist達である。
>結果、「極めてLispに近く」「しかもマクロ無しで」「イテレータは使うけど再帰はそんなに必要無くって」「
自分の使ってる言語の"一種変種に見える"」言語のユーザーにしかウケが良くないんですよ、Emacs Lispって。
>この4つの条件鑑みても、導き出される言語は今んとこ一つしかないでしょ(笑)?
>Rubyですよね(笑)。
>結果、「極めてLispに近く」「しかもマクロ無しで」「イテレータは使うけど再帰はそんなに必要無くって」「
自分の使ってる言語の"一種変種に見える"」言語のユーザーにしかウケが良くないんですよ、Emacs Lispって。
>この4つの条件鑑みても、導き出される言語は今んとこ一つしかないでしょ(笑)?
>Rubyですよね(笑)。
「実はEmacsを「進歩させている」最大勢力は、現時点ではRubyist達である。」のところは現状どうなのかはよく見えていないので保留として
「実はEmacsを「進歩させている」最大勢力は、現時点ではRubyist達である。」のところは現状どうなのかはよく見えていないので保留として
90年代初頭は確かにPCではemacsは無理でしたが、その頃emacsを主に使ってたのはWS上ですので。
90年代初頭は確かにPCではemacsは無理でしたが、その頃emacsを主に使ってたのはWS上ですので。
> 4.実はVimを「進歩させている」最大勢力は、現時点ではkanaを筆頭とする新興勢力達である。
> 4.実はVimを「進歩させている」最大勢力は、現時点ではkanaを筆頭とする新興勢力達である。
ちなみに、もし気づいてたら余計なお世話ですが、ujihisaさんの次のVim Hackの締め切りまで24時間を切りました。
ちなみに、もし気づいてたら余計なお世話ですが、ujihisaさんの次のVim Hackの締め切りまで24時間を切りました。
あと、vim-users.jpに頻繁にポストしていたので、vim hacksの記事を予約投稿したのか他の記事をポストしたのか記憶がごちゃまぜになるのがあぶないですね
あと、vim-users.jpに頻繁にポストしていたので、vim hacksの記事を予約投稿したのか他の記事をポストしたのか記憶がごちゃまぜになるのがあぶないですね
既存のskk.vimの紹介 -> インストール方法や使い方の説明 -> skk7.vimを計画中だと少し告知
既存のskk.vimの紹介 -> インストール方法や使い方の説明 -> skk7.vimを計画中だと少し告知
http://ujihisa.blogspot.com/2010/02/right-way-of-running-external-commands.html




