2016-04-28 2 views
4

Я вижу, что buffer-has-markers-at, по крайней мере, скажет, есть ли маркеры, указывающие на позицию, но не только она была отмечена как устаревшая с 24.3, она не предоставляет одного средства для фактического получения объекта-маркера.Есть ли функции Elisp, которые перечисляют маркеры в заданном буфере?

Глядя на the C source, я вижу, что этот буфер для struct_ buffer_text указывает на односвязный список структур Lisp_marker, но я не могу найти какие-либо функции Elisp для их доступа. Также есть a related thread from 1999.

+0

Как и в дискуссии 1999 года: «Я уверен, что вы не можете этого сделать», в настоящее время. Есть ли у вас вариант использования, отличный от того, который я упомянул в этом потоке 1999 года? – Stefan

+0

@Stefan Я думаю, я пытался понять yasnippet. Я надеялся, что смогу перебрать все маркеры в области буфера и посмотреть их типы вставки. В более общем плане я хочу иметь возможность «видеть» все скрытые объекты в каком-то регионе буфера вместо того, чтобы знать, какие переменные запрашивать среди применимых режимов. –

ответ

0

Чтобы развернуть мой комментарий: действительно нет функции, которая дает вам набор маркеров, присутствующих в буфере.

Отчасти это связано с тем, что на уровне реализации каждый буфер хранит список своих маркеров, на концептуальном уровне маркеры указывают на буферы, но не наоборот: если маркер не упоминается по любым данным, он будет собираться с мусором.

Таким образом, список маркеров, которые вы можете найти в источнике C, содержит «настоящие маркеры», а также «маркеры зомби», то есть маркеры, которые стали недоступными и будут устранены на следующем GC.

Предоставление этого Elisp означает, что некоторые из этих маркеров зомби могут быть «реанимированы». Возможно, это можно сделать без каких-либо технических проблем, но это означает, что семантика такой функции будет немного уродливой.

Поэтому я думаю, что это может быть ОК, чтобы предоставить это как помощь для отладки (и заставить функцию сначала вызвать GC, чтобы отбросить зомби), но не ясно, было бы очень полезно: некоторые из этих маркеры являются чисто внутренними предметами, введенными временно подобными save-excursion.

Возможно, лучший вариант состоит в том, чтобы накладывать на ваш код (0-length) наложения вместо маркеров, поэтому вы можете использовать overlays-in, и поэтому вы можете установить свойства на этих оверлеях, что значительно упрощает определение того, что каждый из эти оверлеи для.

+0

Спасибо за расширение. Хотя я ценю ваше предложение о лучшем варианте, код, как правило, не под моим контролем (и обычно занимает много времени, чтобы понять). Мое желание состоит в том, чтобы увидеть модель буфера, которая обеспечивает четко определенные сопоставления между ним и его содержимым. Надежда, являющаяся событием, может быть понята, если смотреть на состояния до/после, а не понимать код и взаимодействие между несколькими режимами. –

Смежные вопросы