最近、KDevelop を試しています。semantic-complete-self-insertorよりもはるかに高速に (瞬時に) シンボル (変数、関数名、クラス、構造体...) を検索しますM-Ret。を使用するM-Ret方が高速ですが、他の IDE のような適切な形式ではなく、代わりに のような意味のないものです From nil >。emacs では、多くの場合、CEDET が含まれているすべての関連ソース ファイルを検索するのを待つため、少なくとも 1 秒ほど待つ必要があります。これには非常に時間がかかります。
を使用auto complete clangしましたが、速度の向上はないようです。それはなぜですか :( ? 私は Emacs とすべてが大好きで、KDevelop を発見するまでのほぼ 1 年間、C/C++ で Emacs を使用していましたが、Emacs を使用するということは、コード補完は簡単でオプションである必要があるということですか?
この最も単純な答えは、KDevelopのDUChainとパーサーが（おそらく）C ++で記述されており、トークン管理も同様に構築されている可能性があります。CEDETのパーサーはすべてEmacsLispにあり、データベースとルックアップもEmacsLispにあります。一部のテーブルは、Emacsの完了エンジンへの呼び出しの間に構築およびキャッシュされますが、コードが変更されると（入力のため）、頻繁に再構築されます。すべてのテーブルが作成されると、CEDET完了エンジンは非常に高速になります。
処理を高速化するために、コードの完了に対して多くのプロファイル実行を実行しました。duchainについて少し読んだ後、KDevelopにはプロジェクト全体のマスターシンボルテーブルがあるようです。すべてのファイルがプロジェクトに含まれているわけではないため、CEDETはこれを実行できません。したがって、各ファイルにはアドホックテーブルを作成する必要があります。私はそれについてかなり前から知っていましたが、CEDETのシンボルデータベースを外部化して、そのようなテーブルを別のスレッド（プロセス）で構築および維持できるようにすることはできませんでした。