最近気づいたけど、実は
Emacsが凄いんじゃなくて、lispが凄いんだと。

コーディング、コンパイル、コンパイルエラー修正

までの作業はVimもEmacsもそれほど変わらんのじゃない？
今のVim以上の機能ってどんなんだろ。

デバッグ作業はエディタよりも、IDEで視覚的にやったほうが
はるかに効率いいし。

タグ補完、タグジャンプ(定義先に飛んだり、また戻ったり)、includeファイル
からの補完、行補完、コメント行を指定幅で自動整形、makeからエラーが
起きた箇所への自動ジャンプ、インクリメンタル検索、検索語ハイライト、
アンドゥ履歴

ぱっと思いつくだけで、Vimには上の機能はある。Emacsにもあると思うが。

俺はコーディングの際の非モーダルエディタのめんどくささが嫌いだから
Vim派だが。

もちろん複数ウィンドウ表示もある。最近では、GUIタブやdiff機能なんてのも
あるな(使ってないが)。

Vimに実装して欲しい機能のアンケート結果が下記ページにあるが、この中に
EmacsにあってVimにないものが含まれてるかもしれないな（すでにVim7に
入ってるのもあるが。GUIタブとか、vimgrepとか）。
http://www.vim.org/sponsor/vote_results.php

個人的にはこれがほしい
make it possible to use Vim as a plugin in Eclipse

vimに追加してほしい機能。
elispの様に自分で自由に機能拡張できるようなスクリプト言語の導入。
Vimにもスクリプトあるみたいだけど、
elispほど自由度は高くないし、使いやすいとはいい難いと思う。
独自言語とか扱う場合、どうしても自分でメジャーモードとか
lispでつくる必要がでてくる。
はじめVim使ってたけど、これだけのためにemacsを使い始めた。
Vimの方が動作が軽快なのは好きだけど。

>>554
違う。自由に機能拡張できるようなスクリプト言語の導入では
決してEmacsのようにはならない。
そのスクリプト言語で全てを実装しないとEmacsのような高い
拡張性は得られないのだ。

Emacs は殆ど C で書かれていたと思ったけど

VimもほとんどCで書かれているからいっしょだね。

emacsはlispインタプリタといくつかの基本関数だけCで
それ以外はlispで書かれてる。

どうも理解出来ないのが、Emacs使いのLispみたいな拡張スクリプトが
ないといや、っていう主張なんだよな。

スクリプトなんかじゃなくて、Cソースそのものを変更すればいいじゃない。
んで、自分でいいと思うならそれを本家に反映するように努力すれば
いい。

過剰要求・思考偏重・視野狭窄もまたEmacs使いの特徴なのです。

それだと、手間かかりすぎでしょ。
emacsを開発することが目的ではなくて、
emacsを使用して仕事をするのが目的。

>>561
仕事する目的なら、別にEmacs Lispのようにフルカスタマイズできない
といや！っていう主張は矛盾してないか？

elispを書いて楽しむこともEmacsを使う目的に入っている
に決まってるじゃないか。

>>563
Elispを書いて楽しむことと、仕事は直接は関係ないわな。

仕事が目的であれば、それを達成する手段はElispであっても
Vimのスクリプトであってもどっちでもいいわけで。

そうそう、Vimで足りるような仕事しかしないのなら
Vimでいいんじゃないですかねぇ？

>>565
意味がわからん・・・Emacsでないとできない仕事ってなんだ？

というかエディタだけでやらないといけない仕事ってなんだ？

ま、Emacsでないとできないという仕事はないかもね。
結局はテキスト編集だから。確かにviでもgeditでもできますよ。
インデントはC-tとC-dを駆使して、サスペンドしてmakeして
ジョブ制御を駆使して行番号を見てエラー行にジャンプしても
Emacsを使ったのと同じプログラムが書けますね。
それで満足ならviでいいんじゃないですかね。

>>554 の様に、独自言語を使わないといけない場合とかに、
elispだとメジャーモードとかが比較的楽にできる。
この、メジャーモードとかを作ったりするのになるべく時間をかけたくない。
vimのスクリプトではきつくない？

>>567
Vimのことまったく知らないのはよくわかったが、せめて>>552で書いたVimの機能
にくらいは目を通してくれ。

自動インデント機能ももちろんあるし、範囲選択して'='コマンドおせばインデント
されていないものでも自動でインデントしてくれる。インデント用の言語も
C,Perl,Java,Ruby,...数え切れないくらいだ。それから、構文ハイライトで
言語の構文を色付けしてくれるし、括弧が足りなかったりするのも一目瞭然。

makeからエラーが起きた場所に自動で飛ぶ機能もある。Vimで':make'コマンド
実行するだけ。

elispのメジャーモードって何のことかわからないのが、独自言語のインデントだっ
たり構文ハイライトだったら、設定ファイル書くだけ。

> elispのメジャーモードって何のことかわからないのが、独自言語のインデントだっ
> たり構文ハイライトだったら、設定ファイル書くだけ。
あんたも、ぜんぜん emacs のことまったく知らないじゃん。

Vimに自分を合わせる気がないならVim使わないことだね


カナ入力と同じで慣れればローマ字入力より効率良いけども
慣れる気がないなら全く魅力を感じないみたいな

>>569
Vimの機能についてはよく知ってるよ。
Vimとvi、ちゃんと区別して書いてるんだからちゃんと読んでくれ。
じゃあVimで:makeしたとしよう。
次にある単語を検索しようと思い、:grepしたとしよう。
さて、:makeしたときのエラーリストはどこへいってしまったのだろう。
Vim7でlocation listというのが追加されたけど、ウィンドウごとに
1つというまったく意味不明な仕様だよね。
ウィンドウごとに:grepと:makeのどちらか片方しかするなというのだろうか。

>>570
まぁ、Emacsのことはあまりしらないが、「elispのメジャーモードうんぬん」
っていうEmacsの専門用語使わずに「Vimでこんなことできる？」って聞いて
くれたほうがありがたい。

>>572
> Vimとvi、ちゃんと区別して書いてるんだからちゃんと読んでくれ。

Vimとviの違いをわかった上で、「Vim vs Emacs」というスレで「vi vs Emacs」
の構造に仕立て上げようとしてるのはさらにタチが悪い。

> じゃあVimで:makeしたとしよう。
> 次にある単語を検索しようと思い、:grepしたとしよう。
> さて、:makeしたときのエラーリストはどこへいってしまったのだろう。

これには若干不満を感じることもなくはない。それほど大きな不満ではないが。
Emacsでは区別されてるの？

>>559
>スクリプトなんかじゃなくて、Cソースそのものを変更すればいいじゃない。

俺もそう思う。何が悲しくて劇遅のスクリプト言語で手足縛られながら
機能追加せにゃならんのかと。

全然遅く感じないけどな。

おまえら:colder

一つのエディタをあまりに使いこなしすぎると離れがたくならんか
未だにVZを越える環境が見つからんとか言ってる元MS-DOSユーザを見てると
哀れになるよ

Vim使いだけど、一時期Emacs使ってて思うこと。
俺はCはできてて、Emacs使い始めてElispをちっとかじってみた。
わざわざElisp覚えるよりも、今できるCで何か作ったほうが早いなと。

だから、別に何かを否定しなくても自分が好きならそれでいいじゃん

>>578
VZを越える環境というか、今はWindows用にWZエディタがあるんじゃ
ない。別にWZ使いを否定するわけじゃない。事実うちの会社には
WZ使いで素晴らしい生産性をあげるプログラマいるしな（デバッグ
能力は高いとはいえないが）。

まぁエディタは開発のごく一部の生産性をあげるものにしかすぎない
わけで。別に一つのエディタから離れられなくなっても、その
エディタが使えない状況というのは、工夫すればそんなにない。

いまやLinux版WZエディタもあるんだぜ。別にネーティブにこだわら
なくてもすきなプラットフォームで編集して、その後にアップロード
なりなんなりすればいい。

>>559 >>575 >>579
お前らVimに対してトリビアルでない変更をしたことがないのが
バレバレですよ。

>>581
kwsk

Emacsを批判するのにモードも知らんなんて始めから勝負あったな。ｗ
いや、それじゃ余りに馬鹿すぎるから釣りかもしれないが。
しかし理由lispが面倒だからCで書くとか馬鹿すぎるｗ
お前らだってワンライナーをPerlで書いたりするだろ。
くだらん操作とか極めて特殊な操作をCで書いて
しかもエディタに組み込んだりしたら悲惨な事になるのは目に見えてる。

>>583
Vimにもマクロはあるし、スクリプトもあるし、ちょっとした面倒な
作業ならいとも簡単に自動化できるわけで。Elispみたいにフルカスタマイズ
したいとこまでいくなら、じゃぁCソース直せばいいやん、ってことに
なるって話。

Emacsのメジャーモードちとぐぐってみたが、別にVimでも
簡単にやれそうだ。

つまんない対抗意識で素人発言連発は恥ずかしいよ。

>>586
何の情報も出していないレスを書くほうが、俺にはよっぽど
恥ずかしいと思えるが。

以前ちょっとだけvimを使ってたけど今はemacs使ってる。
vimのCのソースコードを直すとかいってる人って、
vim本体のコードのこと言ってるの？
それとも、本体とは別にCでマクロ動作をかけるってこと？
本体のコードを修正するっていう意味だったら、実用的じゃないと思うけど。
ちょっとした動作修正のためにそんなこといちいちやってられない。
それに、Cで動作書くのってあらかじめ関数が用意されてないと、かなり大変だと思うよ。

lisp嫌ってる人も多いけど、できるようになると括弧も苦じゃなくなる。
境界を越える: Lisp の美しさ
http://www-06.ibm.com/jp/developerworks/java/library/j-cb02067.shtml

>>588
いやいや、ちょっとしたことをさせたいなら、Vimのマクロもあるし
スクリプトもあるって話・・・。Perlインタフェイスや、Rubyインタフェイス、
Pythonインタフェイスなどなどもある。なんでもかんでもソースなおせ！
といってるわけじゃないってことは、理解して欲しい。

んで、ちょっとしたことなら、Elispのようにフルカスタマイズできなくても
別にできるよ、というお話。でも、Emacs使いはElisp並にカスタマイズ
できないといや！と主張してるわけ。

ちょっとしたことじゃなく、根本を変えたいというならCソースその
ものを修正したらいいじゃない、というのがVim使いの俺の主張な
わけだが、理解してもらえるだろうか。

実にどうでもいいが、カスタマイズ範囲は広いに越したことは無いだろ。
性能を追求したい場合も、モノリシックな設計よりは、モジュール化されていた
ほうが良いに決まっている。(エディタではないが)apacheのように、
あるいはeclipseのプラグインのようにね。
無論モジュールはスクリプトでも書けて、Cのモジュールの動作が気に食わない
場合は、スクリプトで置換えられるようになっているのが望ましい。

Vimがあまりにモノリシックなのは問題じゃないのかな。
winampに対するfoobar2000のような、より良い後継者が現れることを望む。

スクリプト言語インターフェイスって、コンパイル時に有効にしないと
使えないじゃん。
だからそれを使って書かれているVimスクリプトも少ないだろ。
それに何種類もあることに意味あるの？
結局1種類の言語だけを標準で内蔵したほうがいいだろ。
つまりemacs lispみたいに。

> 実にどうでもいいが、カスタマイズ範囲は広いに越したことは無いだろ。
C言語でいいじゃん

yzisに期待・・・してももうダメなのかな？

>>589
フルカスタマイズだからこそ、ちょっとした拡張で結構な事ができるんじゃないか。
労力がチョットなのと、できる事がちょっとなのは違う。
vimはチョットした事を出来るマクロ。
Emacsはちょっとした事でできるlisp。


>>591
むしろ、複数あるより一つの方がelispみたいに
膨大な遺産が蓄積されて便利だと思うね。
全部自分で作るなら種類があった方が良いけど。

>>592
馬鹿ほどこういうことを言うんだよな。
いっぺんGCライブラリなどを使わずに、長さを特に限定しない文字列処理を
Cで書いてみろよ。面倒くさいから。

>>594
インタフェースがwell-definedで、どの言語で書かれたモジュールからも
他の言語で書かれたモジュールが使用できるのなら、言語は問題ではないし、
全てが「資産」になるよ。

Vim.NETで。

>>596
それをチョット改造するのも違う言語で出来るなら別に良いけどな。

emacsの拡張性が生きる場面ってあるの？
っていうか拡張性あるの？

エディタは効率的に編集するためにあるんだからさ、
Cでやれといってる馬鹿は自分で入力する予定のテキストまで
Cでハードコーディングするといいよ。