私はbuffer-has-markers-atが少なくとも位置を指し示すマーカーがあるかどうかを知るが、24.3以来時代遅れとマークされているだけでなく、マーカーオブジェクトを実際に取得する手段も提供しない。与えられたバッファにマーカをリストするElisp関数はありますか？
the C sourceを見ると、buffer to buffer_text構造体がLisp_marker構造体の単独リンクリストを指していることがわかりますが、それらにアクセスするためのElisp関数を見つけることができません。また、a related thread from 1999もあります。
私のコメントを拡大するには：実際にはバッファに存在するマーカーのセットを与える機能はありません。
実装レベルでは、各バッファに概念レベルでマーカーのリストが保持されていますが、マーカーはバッファを指し示しますが、逆の方法ではありません。どんなデータでも、ガベージコレクションされます。
Cソースで見つかるマーカーのリストには、「実際のマーカー」と「ゾンビマーカー」、つまり到達不能になったマーカーが含まれ、次のGCで削除されます。
これをElispに公開すると、ゾンビマーカーの一部が「蘇生」される可能性があります。たぶん技術的な問題を導入することなく行うことができるかもしれませんが、そのような機能のセマンティクスは少し醜いことになります。
これをデバッグの助けとして提供することができます（そして、ゾンビを取り除くために関数をGCに呼び出すようにしてください）が、非常に便利であることは明らかではありません。マーカーは、save-excursionのような一時的に導入された純粋に内部のものです。
マーカーの代わりにコードを使用する（0-長さのオーバーレイ）ため、overlays-inを使用できます。そのため、これらのオーバーレイのプロパティを設定することができます。それらのオーバーレイはのためのものです。
ありがとうございます。私はあなたのより良い選択肢の提案に感謝しますが、コードは一般的に私のコントロール下ではありません（通常は時間を浪費します）。私の望みは、それとその内容との間の明確なマッピングを保証するバッファーモデルを見ることです。複数のモード間のコードや相互作用を理解することなく、前後の状態を見ることで、イベントの可能性を理解することができます。 –
1999年の議論と同じように：「私はあなたがそうすることができないと確信しています。あなたは、1999年のスレッドで言及したものとは異なるユースケースを持っていますか？ – Stefan
@Stefan私はヤスニッペを理解しようとしていたと思う。私は、バッファのある領域のすべてのマーカーを繰り返し処理して、その挿入タイプを調べることができると期待していました。より一般的には、適用可能なモードの中でどの変数を照会するかを知る必要はなく、バッファの一部の領域内に隠れたオブジェクトをすべて「見る」ことができるようにしたい。 –