パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

IBMからEclipseベースの新しいクライアント・フレームワーク」記事へのコメント

  • by Anonymous Coward on 2004年05月13日 9時50分 (#546916)
    何でも Eclipse でやろうという発想は emacs にも通ずるところがありますな。
    • 先を越された(笑

      Java開発環境では、結構Eclipse vs JDEE(Java Development
      Environment for Emacs)の使い勝手対決があったりするわけですが、
      もしデスクトップ環境としてのEclipseが盛隆になってきたらば、
      生活環境対決まで起こるわけですね。
      CUI系のemacsとGUI系のEclipseという住み分けになっていくのかも
      知れませんが。

      # Domino Userから若しかするとEclipseの扱い方を質問される日が
      # くるかもしれないなんて、考えもしなかったなぁ
      親コメント
    • Emacs plugin for Eclipse というのはないんでしょうか?
      親コメント
      • by SaySet (18192) on 2004年05月13日 10時41分 (#546950) 日記
        EE2E [ruru.ne.jp]とか?
        親コメント
        • それ微妙。所詮本物のemacsの機能が揃ってる訳ではないし。
          #Eclipse エディタ部分は使いにくいよ
          # アルバイト先でEclipse 使用を要求されてるのでAC
          • >Eclipse エディタ部分は使いにくいよ

            まだEclipseは本格的に使ったことが無い
            (てゆーか仕事の主戦場はEclipseが無い言語だし、趣味じゃ統合環境なんて要らないLightweightLanguageだし)
            んですが、使いにくいであろうことは容易に想像できます。

            だって、自分が好きなエディタ(の機能)が100%用意されてる、という保証が全然ないのは、
            ある意味で原理的に当然だもん(^^;

            そのへんのごちゃごちゃを考えると、
            結局理想をいえば、自分の好みのエディタが、「そのまま」Eclipseで動けばいいんですよね。
            #これがほんとの統合環境。つまり全ての機能を自分が用意するんじゃなく、全ての「既存」機能を統合する能力があるソフト(^^;

            で、そうすると、IDEとエディタの間で、どんな命令をどうやりとりすればいいのか?っていう部分を
            たぶん予めそれなりに決めておかないとならない、んじゃないかと思います。

            そういやGDBには最近、UnixPipeベースじゃなく独特なプロトコル(?)でもって
            クライアントのエディタと情報をやりとりする枠組み、ってのがあるんでしたよね。名称失念したけど。

            あれと似たようなこと(?)を、IDEがエディタに対して行なえば、いいのじゃないか?と夢想します。

            なお、もっと広範に言えば、そういう話は
            OSがそういう枠組みを用意しててくれたらいいのにな、という話に行き着くと思います。
            それも、デバッガとかIDEに限らず、出来るだけ広いかたちで。

            で、MSがそれをやる動機があるかってーと微妙でしょうね。
            接続性がよくなればなるほど、囲いこみはやりにくくなるんだから。

            ん?ってことは逆にいえば、接続性の確保は、我らがOpenSourceの仕事なのかも(^^;
            我らの立場だと逆に、特定の環境へ囲い込むことは、デメリットは有ってもメリットは無いわけだから、
            接続性については我々のほうが真剣に考え易い位置にいるんじゃないかな?

            #それの行き着く先が OLE/COM/.NET/Mono なのかどうかは、ノーコメントなのでG7
            #もちょっと素朴なレベルで、そういうこと[*]をやりたいなあ。

            #[*]ぶっちゃけ言えば、プログラム間の実行時の対話。
            #なお素朴なPipeは、Pipeの接続と子の起動終了とを独立させられないので、ここでは不適格です。
            親コメント
    • そして、NetscapeのようにOSがいらなくなるとか騒がれて、
      M$に潰されるわけですよ。

      あーでも、元々無料か
    • TeX vs ワープロの、ワープロの考え方でもありますね。

      TeX のソースはテキストファイルだから、必要に応じて様々なツールを援用できるけど、ワープロは (基本的に) 独自ファイルだから、ワープロソフトに機能をつめこんでおく必要がありますね。

      • >ワープロは (基本的に) 独自ファイルだから、ワープロソフトに機能をつめこんでおく必要がありますね。

        今回の話と関係あるかどうかは微妙ですが、一応。

        「ファイル(形式)が」独自だからといって、「1つの」アプリ(ワープロ)に機能を詰め込む必要は、
        あるとは限りません。
        だって、複数のアプリ(やライブラリやプラグイン)が同一のファイル形式をサポートしてれば済むんだもん。

        しょせんはUnixのテキスト文化も、「プレーンテキスト」という特定の(^^;フォーマットに
        全てのプログラムが特化してる、というだけのことなんだよね。

        まあ、他のフォーマットの更に基盤となるという「メタフォーマット」的な機能が
        期待しやすいという意味では、テキストファイルは便利だけど。
        #テキストの背中にXMLを乗せてーー、XMLの背中にSVGを乗せてーー、の3階層とか。

        閑話休題。ファイル形式の「サポート」ってのは、結局は、
        ある機能(アプリとかライブラリとか)が使ってる「ファイル解釈器」が
        その形式のための解釈器であれば、それでいいんですよね。
        解釈器は、テキストファイルならばgets()だし(藁)、XMLならDOMだかSAXだか(の実装)だろうし、と。

        で、解釈器だと考えると、フォーマットは個々の機能(アプリとか)に専用化するよりも、
        むしろ階層を細かくわけて、個々の階層は出来るだけ難しくない解釈だけを行なうようにして、
        そして多くの機能が1つの解釈器(や解釈器グループ)を共有し使いまわす、というかたちにするほうが
        便利そうです。少なくともプログラムの生産性という意味では。

        #XML解釈器とS式解釈器は手元に置いておいたほうがいい…のかな…なのでG7

        ----
        余談:

        WindowsのExplorerで、「ファイル内文字列の検索」機能を、上記の発想で実装しててくれたらよかったのにな。

        解釈器は個々のアプリ(?)が持ってる、と捉えて、
        各種のデータフォーマットの中身にご所望の文字列があるかどうかを、そのアプリに探索「させる」、ってこと。

        PNGを見るツールが、PNGの中の文字列をOCR(?)で拾い上げて検索する、という機能を提供してくれるとかさ。
        遅いだろうけど、速度はここでは問題ではないです。

        拡張子連動設定に「Run」とかだけじゃなく「FindString」っていうアクションも存在してくれれば
        よかったのかも。
        親コメント

人生unstable -- あるハッカー

処理中...