Emacs GitリポジトリですべてのEmacs Lispファイルを検索しました(goto-char (point-min))が、3621回(goto-char 1)発生し、31回発生しました。個人的に、私はたくさん見(point-min)たがどれもが1、でも、多くの場合、それは領域が狭くされていないことは100％間違いないだろう。だからここに私の質問があります：狭められていないバッファ内(point-min)より1もまだ好まれていますか？

関数呼び出しである間、定数であるため、それ1よりも高速です。さらに、は、1文字対11文字よりもはるかに短いです。(point-min)1(point-min)1(point-min)

バッファが狭められていないことをどうやって知るのですか？

関数を呼び出す直前に拡張していなければ、確実ではありません。さらに、「優れたソフトウェア」は、「作成者が想像したことのない方法で使用される」と定義されることが多いため、コードの異常な使用に常に備える必要があります。

コードの可読性は王様です

あなたが書くとき(goto-char 1)、コードを読んでいる人（あなたを含む6ヶ月後）は貴重な頭脳力の思考を費やします

• 「バッファが狭められていないことをどうやって知るのですか？」そして
• 「最初の文字は0または1ですか？」

基本的に、(widen)直前にない限り、バッファが狭められないと確信している理由を説明するコメントが必要です。

コストは簡単です

コードをプロファイリングして別の方法で見つけた場合を除き、ここでのコストは些細なものであるという安全な仮定があります。ELispが行う他のすべての機能（ネットワーク、ディスクアクセス、文字列照合など）に比べ(point-min)て、意味のあるコストはかかりません（さらに安くなる可能性があります、ステファンの答えを参照）。

sdsの答え（私も完全に同意します）を補完することは、見た目にもかかわらず、(point-min)より効率的です1。実行速度の観点では、私のテストでは測定可能な違いは見られませんが、サイズの点では異なります。

ELISP> (byte-compile '(lambda () (goto-char (point-min))))
#[nil "eb\207" [] 1]

ELISP> (byte-compile '(lambda () (goto-char 1)))
#[nil "\300b\207" [1] 1]

ELISP> 

これpoint-minは、独自のバイトコードを持っているため、他の関数呼び出しと比較して非常に効率的にエンコードおよび実行されるためです。

もちろん、私が使用するもう1つの理由point-minは、歴史的な選択が1間違いであると考えていることです（バッファは0から始まっているはずです）。