3

起動時間（= autoload）を最小限に抑え、ユーザーのemacs.elへの影響を最小限に抑えて、flymakeのパッチ適用が必要なモジュールを提供するにはどうすればよいですか？

私はflymake-for-csharpモジュールに取り組んでいます。これはflymakeで動作し、C＃コードファイルをより柔軟にする方法を教えます。たとえば、makefileを使用するだけでなく、flymake-for-csharpは.csprojファイルを使用することも、csc.exeを直接呼び出すこともできます。

モジュールは正常に動作します。現在、正しく自動ロードできるようにしようとしています。

これが課題です。

どの言語がflymakeされるかを定義するために、flymake.elには、ファイル拡張子（.java、.cs、.cなど）のリストと、それらの各言語のinitおよびcleanupルーチンが含まれています。デフォルトのflymake.elにはC＃のエントリがありますが、前述したように、デフォルトのC＃の動作は十分に柔軟ではありません。より柔軟にするには、flymakeリストのC＃エントリを置き換えて、flymake-for-csharpモジュールの新しいinit/cleanupロジックを指すようにする必要があります。私と一緒に？

実行時にアリストにパッチを適用することは問題ありません。次のようになります。

  (let (elt
        (csharp-entry nil)
        (masks flymake-allowed-file-name-masks))

    ;; Find the existing C# entry
    (while (consp masks)
      (setq elt (car masks))
      (if (string= "\\.cs\\'" (car elt))
          (setq csharp-entry elt))
      (setq masks (cdr masks)))

    ;;  remove the original entry for C# ...
    (if csharp-entry
        (setq flymake-allowed-file-name-masks
              (delete csharp-entry flymake-allowed-file-name-masks)))

    ;; Now add a new entry for C#, with the custom init and cleanup methods.
    (setq flymake-allowed-file-name-masks
          (cons
           '("\\.cs\\'" flymake-for-csharp-init flymake-for-csharp-cleanup)
           flymake-allowed-file-name-masks)))

長期的な解決策は、flymakeとemacsの作成者に、現在flymake-for-csharpにあるロジックを受け入れるように説得することです。次に、アリストはより柔軟な初期化/クリーンアップルーチンを取得し、おじさんをボブします。

しかし今のところ、flymake-for-csharpを既存の（組み込みの）flymake.elで動作させたいと思います。そこに問題があります。アリストにパッチを適用しながら、flymake-for-csharpを自動ロードするにはどうすればよいですか？

理想的には、ユーザーのemacs.elを次のように表示します。

(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

...おそらく小さな(eval-after-load ..セクションで。

ただし、C＃の新しいエントリを含めるためにflymake alistにパッチが適用された 後でのみ、関数flymake-for-csharp-initが呼び出されます。

この鶏が先か卵が先かという状況を回避する方法はありますか？

私が考えた1つのアプローチは(require 'flymake-for-csharp)、の代わりに使用することでしautoloadた。そのflymake-for-csharpモジュール内で、パッチロジックのみを実行してから、残りの関数に何らかの方法でautoloadを使用します。これは良い考えでしょうか？これには、flymake-for-csharpを2つの異なるファイルで配信する必要がありますか？

私が考えたもう1つのアプローチはeval-after-load、onflymake.elを使用することでした。その中で、パッチ機能を提供することができました。これといくつかの質問：

  • これは、flymakeが自動ロードされている場合にのみ機能しますか？（外部の）eval-after-loadが評価されたときに、すでにロードされているモジュールのeval-after-load内のロジックはどうなりますか？

  • ユーザーのemacs.elに影響を与えずにこれを行うにはどうすればよいですか？

要約すると、起動時間（= autoload）を最小限に抑え、ユーザーのemacs.elへの影響を最小限に抑えて、flymakeのパッチ適用が必要なモジュールを提供するにはどうすればよいですか？

4

1 に答える 1

1

私が正しく理解していれば、ユーザーにこれを追加して.emacsもらうと問題が解決します。

;;;###autoload
(eval-after-load "flymake" '(code-that-patches-flymake-allowed-file-name-masks))
(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

これで、パッケージを使用している人々と協力する場合、loaddefs.elトリック;;;###autoloadを使用して、パッケージの行の直前にコメントを配置することにより、ユーザーがこのコードを自動的にロードしeval-after-load、ファイルを再構築loaddefs.elできます。

ただし、インターネットでの一般的な使用法の解決策を期待している場合は、ユーザーが両方の行を持っている必要があります.emacs。

クリーンアップコードについてのコメントです。次のように簡略化できると思います。

(let ((csharpentry (assoc "\\.cs\\'" flymake-allowed-file-name-masks)))
  (when csharpentry
    (setcdr csharpentry '(flymake-for-csharp-init flymake-for-csharp-cleanup))))
于 2010-11-16T22:02:27.063 に答える