新しいEmacsバージョンの調整/開発が行われる場所がありませんか?


13

最近、Emacs 25に含まれている新しい/改善されたものに感銘を受けました。それから、その背後にあるプロセス全体について考え始めました。私の考えをあなたと共有したいと思います。

最新のリクエスト、多くのバグ修正、メンテナンス、Emacs core / devの拡張など、すべてを維持することは、間違いなく大変な作業です。

Emacs 25で実装されている多くの変更と改善を確認すると、多くの開発時間を費やさなければなりません。

かなり大きな調整が必要です。Emacsをさらに推し進めるには、これらすべての変更の背後に大企業がなければならないようです。しかし、それは有益なものではなく、すべてフリーソフトウェアであり、GPLライセンスです。

だから、彼らの通常の仕事の次に、Emacsをさらに推し進めるために時間を割いて喜んでいるボランティアからです。それには何らかの調整が必要です。

のメーリングリストを確認したところ、Emacs-dev調整があまり進んでいないようで、参加している人は多くありません。

許してください、私は個人的にメーリングリストは90年代のものだと考えています。最近では、GitHubの課題トラッカーや定期的なコミュニティなど、より多くの選択肢があります。

私がWebを見回すと、通​​常のブログ(Endless Parentheses、Sacha Chua、Redux、OrEmacsなど)とEmacsコミュニティ(このEmacs Exchangeのような-おそらく最大のコミュニティ-reddit.com/r/emacs)があります。 )およびemacs.zeef.comやwikiemacsなどのコレクション。

しかし、多くの人と調整が必要なEmacsの新しいリリースを開発する場所ではありません。

このような気がしたのは、すべてアンダーグラウンドで、Emacsの新しいバージョンが密かに開発されている...面白い考えです。

これはすべて、すべての魔法が発生するウェブ上の大きなホットスポットのようなものを逃していないのだろうかと思うようになりますか?


メーリングリストはほとんどすべてだと思います。
フリークヒル

1
個人的には、それがうまく調整されているとは思いませんし、大きな機能でさえ一人の努力とは思えません。ですから、ここでは珍しいことは何もありません。
wasamasa

1
人々がなぜメーリングリストを嫌うのかはわかりません。それらはフォーラムやFacebookのようなもので、技術的にはるかに優れています;-)。冗談はさておき、これらはWebベースのものよりも明確な利点あります。多くのクライアントのいずれかを使用してseacrh / read / compose / sendメールを送信し、好みに合わせエクスペリエンスをカスタマイズできます。これは、Emacs(= 拡張可能なエディター)自体の哲学に非常によく適合しています。
mbork

メーリングリストは、パッチを送信するだけで、メールアカウント以上のものを必要としないため、素晴らしいものです。これは真に分散化されたワークフローです。Githubでこれを行うことはできません(ブラウザーで実行するには非フリーソフトウェアと、別のアカウントも必要です)。
レカド

回答:


13

相互作用と調整のために行く場所についての私はここで他のコメントを2番目にしながら、Emacs開発には別のユニークな側面があります。その規模、革新、および調整のために、それは比較的静かな努力です。それ自体についてあまりノイズはありません。メジャーリリースでは、数十件の余分なメールが送信されます。長いスレッドでも、レトルトは簡潔です。

それを非常に多くのノイズを生成するように思われる比較可能なプロジェクトと比較して、私は定期的に主要なイベントの周りのリストを購読解除します。

このコミュニケーションの経済は、アイデアの成熟度と、実装に値するアイデアを開発する自由を反映しています。不要な機能は静かに衰退し、新しいアイデアは(たとえ悪モードと呼んでも)変更ログに記録されます。

あなたが言及しているブログに関しては、彼らは単に教育するだけでなく、競合するアイデアやピギーバックのアイデアを通して働く上でも重要な役割を果たしています。たとえば、ace-jumpは、バッファの他の部分、他のバッファ、他のファイル、リモート検索などにジャンプするという多くのアイデアを復活させました。たとえば、ack、avy、ivy、anzu、counsel、swiper、swoopなどは、現在すべて洗練されており、google +で頻繁に議論されるトピックです。

planet emacs rssフィードを購読すると、ほとんどのアクティブなブログがカバーされるでしょう。rssは、誰かが同じニュース項目を時折繰り返すことを除いて、比較的簡潔です。

Emacs開発者のリストにはサブ機能に関する開発者のメールはありませんが、プロジェクト固有のメーリングリストにある可能性があります。これらのプロジェクト固有のリストの最大のものは、もちろん組織モードです。そのリストに何百もあったかもしれないものは、おそらくemacs変更ログの単一のアナウンスに削減されます。

包括的な開発者の電子メールリスト、usenetグループ、ircチャネル、ウェブサイト、gitハブの場所、ブログの場所、またはソーシャルメディアページの代わりに、単一のプラットフォームが引き継ぐことのない、真に分散した多様なやり取りがあります。emacsの開発がこれらの通信プラットフォームのどれよりもずっと長く行われているという事実に一部起因する可能性がありますが、一部には通信の単一モードに制限しないという意図的な選択に起因する可能性もあります。

全体としては、十分な調整がない場合はありません。開発者としては、必要な入力をほとんど、またはできるだけ多く取ります。Emacsの開発モデルは、比較的ノイズのない(そして摩擦のない)コラボレーションに役立ちます。それは良いことだと思います。私もあなたがそうすることを望みます。


10

いいえ、Emacsバグメーリングリスト:(bug-gnu-emacs@gnu.orgを使用debbugs.gnu.org)を除き、何も欠落していません。

そして、Emacsソースコード用のgitリポジトリがあります-それが使用されているものです。

議論がオンになっているemacs-devel@gnu.orgbug-gnu-emacs@gnu.org。いくつかのコードが公開され、そこで議論されています。

ただし、コード開発は個人(たとえば、あなた)によって行われます。個人は、必要なアクセス/特権がある場合、リポジトリに変更をコミットできます。または、メーリングリストのいずれかにパッチを送信し、他の誰かにそれを適用するように依頼できます。

使用M-x report-emacs-bugするとき、修正を提案したい場合は、バグレポートにパッチを添付できます。

「魔法」は、個々の開発とコメント/議論を通して起こります。

FWIW:巨大な言語で非常に複雑なCommon Lispは、1970年代後半から1980年代初期にかけて、電子メールを使用して完全に定義(およびプロトタイプ化)されました。これは、インターネットが幼児の頃のワールドワイドウェブの前でした。言語を定義するものは、世界中のさまざまな場所、主に研究室にありました。確かに魔法。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.