Mewソースファイルの分割について

[Naoya Yamashita]

こんにちは。このフォーラムには初めて投稿させていただきます。
山下と申します。最近Mewを使い初めたものです。

自分が使うにあたり、自分が使うソースはさらっと見たのですが、
mew-imap{, 2}.el、mew-summary{, 2, 3, 4}.elなどの名付けは一般的で
はないと思います。

中でもmew-mule{, 3}.el、やmew-vars{, 2, 3, x}.elなどはさらに問題
があると思っています。(mew-mule2.elが抜けている・mew-vars{x}.el。。)

ファイル分割をするのであれば適切なカテゴリ分けの元で分割をしたい
と思っています。この点について以前の議論などはあったのでしょうか。

[Tomoyuki Murakami]

On Tue, 18 Aug 2020 00:45:23 +0900 (JST), Naoya Yamashita <con...@gmail.com> wrote:

> mew-imap{, 2}.el、mew-summary{, 2, 3, 4}.elなどの名付けは一般的で
> はないと思います。
>
> 中でもmew-mule{, 3}.el、やmew-vars{, 2, 3, x}.elなどはさらに問題
> があると思っています。(mew-mule2.elが抜けている・mew-vars{x}.el。。)
>
> ファイル分割をするのであれば適切なカテゴリ分けの元で分割をしたい

ファイル名に数字の枝番が付いていることを問題視されているのでしょ
うか？枝番が付いている本当の理由は知りませんが、想像するに、今の
ようにちょっと位ファイルが長大になってもWindowの右端の小窓に視覚
的にファイル内の現在地が表示される(VS Codeのこと)ような時代ではな
かった時に枝番が増えていったものと思います。
枝番が付いていることを除けば当該ファイル名が何の処理に関係してい
るのかを寧ろ言い得ていて、分類としては理に叶っていませんかね？

[Hideyuki SHIRAI]

白井です。

# 久しぶりっす

もう20年以上前の話なので、なにも覚えていないのだけど、summary.el
が分割されたのはそんな感じだったような記憶があります。その後新し
い関数が増えるときは、関連が強いファイルに増やしていったような。

また、すくなくとも、mew-mule3.el は Mule3 以降に対応ってことで数
字に意味はあります。(今の Mew は Mule2 には対応していないってこ
とです)。最近の Emacs で Non Mule が組めるかどうか知らないのです
が、

vars も中身をみるとさもありなんって分類だし。

個人的には、Emacs の機能を使えばどのファイルにあっても問題ないの
で、まったく気にしていませんが。。。

## あとはなにも思い出せない。。。

--
白井秀行 (mailto:shi...@meadowy.org)

[Naoya Yamashita]

>> ファイル名に数字の枝番が付いていることを問題視されているのでしょ
>> うか？枝番が付いている本当の理由は知りませんが、想像するに、今の
>> ようにちょっと位ファイルが長大になってもWindowの右端の小窓に視覚
>> 的にファイル内の現在地が表示される(VS Codeのこと)ような時代ではな
>> かった時に枝番が増えていったものと思います。

Minimapのことでしょうか。VS Codeではなく、Sublime Textで導入され
た機能だと思います。

>> 枝番が付いていることを除けば当該ファイル名が何の処理に関係してい
>> るのかを寧ろ言い得ていて、分類としては理に叶っていませんかね？

枝番が付いていることを問題にしているので、枝番がなければ適切だと
思います。今のファイル分割が積極的に行なわれたのなら、数字のサフィッ
クスではなくきちんと名前を付けるべきだと思います。

行数を調べてみました。ファイル分割が行数で行なわれてないことが分
かります。そしてmew-summary4.elとmew-vars.elが肥大化していること
が分かります。

$ find -mindepth 1 -maxdepth 1 -type f | sort | xargs wc -l
1919 ./mew-imap.el
659 ./mew-imap2.el

170 ./mew-mule.el
426 ./mew-mule3.el

744 ./mew-nntp.el
446 ./mew-nntp2.el

428 ./mew-summary.el
819 ./mew-summary2.el
492 ./mew-summary3.el
1229 ./mew-summary4.el

3319 ./mew-vars.el
1015 ./mew-vars2.el
225 ./mew-vars3.el
270 ./mew-varsx.el

> もう20年以上前の話なので、なにも覚えていないのだけど、summary.el
> が分割されたのはそんな感じだったような記憶があります。その後新し
> い関数が増えるときは、関連が強いファイルに増やしていったような。

「関連が強いファイル」はどのように判別するのでしょうか。「関連が
強いファイル」として確立されているなら枝番ではなく適切な名前を付
けるべきではないでしょうか。

> また、すくなくとも、mew-mule3.el は Mule3 以降に対応ってことで数
> 字に意味はあります。(今の Mew は Mule2 には対応していないってこ
> とです)。最近の Emacs で Non Mule が組めるかどうか知らないのです
> が、

これは知りませんでした。現在のMuleのバージョンは6ですかね。これも
現在分けておく必要はないと思います。

mule-version
;;=> "6.0 (HANACHIRUSATO)"

Emacsのコミットログを調べるとどうやら1997年にEmacs本体のソースツ
リーにMuleが追加され、その時点でMule3だったようです。「Mule3未満」
を考慮するなら、23年前より前のソースを考慮するということになり、
それは現実的ではないと思います。Emacsのバージョンで言うと
Emacs-20.1です。現代でEmacs-19を使っている人はおられるのでしょう
か。(実際におられないことを主張するものではありません。)

> vars も中身をみるとさもありなんって分類だし。

これも先の「関連の強いファイル」に対する考えと同じです。

> 個人的には、Emacs の機能を使えばどのファイルにあっても問題ないの
> で、まったく気にしていませんが。。。

Emacsの機能とはどんな機能でしょうか。例えば1ファイルであればソー
スを開いてisearchなどの操作ができますが、複数ファイルに分かれてい
るとrgrepを叩かないといけないと思います。

[Takahiro Kambe]

こんにちは、Mewの利用者です。

In message <20200818.115427.18398...@gmail.com>
on Tue, 18 Aug 2020 11:54:27 +0900 (JST),

Naoya Yamashita <con...@gmail.com> wrote:
>> 個人的には、Emacs の機能を使えばどのファイルにあっても問題ないの
>> で、まったく気にしていませんが。。。
>
> Emacsの機能とはどんな機能でしょうか。例えば1ファイルであればソー
> スを開いてisearchなどの操作ができますが、複数ファイルに分かれてい
> るとrgrepを叩かないといけないと思います。

Mewを実際にEmacsに読み込んでいる状態であれば、describe-function,
describe-variable, apropos等で関数や変数の説明を表示し、必要であればソー
スファイルの該当部分の表示もできるので、ファイル名を気にする必要性を感
じないことは確かな気はします。

--
神戸 隆博 (かんべ たかひろ) at 仕事場

[Tomoyuki Murakami]

On Tue, 18 Aug 2020 11:54:27 +0900 (JST), Naoya Yamashita <con...@gmail.com> wrote:

> 枝番が付いていることを問題にしているので、枝番がなければ適切だと
> 思います。今のファイル分割が積極的に行なわれたのなら、数字のサフィッ
> クスではなくきちんと名前を付けるべきだと思います。

仰りたいことは何となく理解できるような気がします。つまり、Mewにお
いてソースコードのファイル名命名ルールが明確に存在して、それに
則って適切なファイル名が付与されているべき、ということでしょうか。
恐らく現状はご覧の通りです。
今後Mewのメンテナンスに積極的に関与すべく、ソースコードの可読性
を上げるためにファイル名、関数名、変数名等の規約を設けて既存コー
ドのリファクタリングを行うことは自由だと思います。（ライセンスは
確認していないので、もし問題があったらすみません）実際やるとなっ
たらファイル名を変えるのみならず、ファイルの中身も一定のルールに
従った適切な内容となるように整理する必要があるでしょうね。
ただ、これまでそういうプロジェクトの勃興や際立った行動を見ること
もなかったのは大多数のユーザ、developersがそこ(リファクタリング)
にモチベーションを維持できるような何かを見いだせていない結果だと
も考えます。
# リファクタリングを全くやってないと言う意味ではありません。過去
# 何度か大幅な書き換えがあったのを見た気がします。
私個人は普段使っている分には不自由しない派、静観派なのでなおさら
(リファクタリングに)メリットを見いだせない派です。

余談ですが、最近の技術なら既存コードを分析してコードの分類、各種
命名法の確立(支援?)など人手を介さずとも一足飛びにやっつけてしまう、
なんてこともできなくもない気がしますが....本当に余談でした。
# LispといえばAI, AIといえばLispだったような...遠い昔...