<p>Дисплей вызова замораживания Mudlet () на регулируемом контейнере</p>

Такое поведение похоже на бесконечную рекурсию, происходящую в коде Lua каким-то образом ...

Названный таким высоким из-за плохого поведения, мы ожидаем, что Mudlet здесь преуспеет.

Было бы справедливо отметить, что это проблема, связанная только с

Такое поведение похоже на бесконечную рекурсию, происходящую в коде _Lua_ каким-то образом ...

Да, это причина. Поскольку Гейзер всегда хранит ссылку на родителя в контейнере (myGeyserElement.container).
Это известная проблема с дисплеем, а также причина того, что создатель Geyser создал функцию Geyser.display (11 лет назад: eyes:).
https://github.com/Mudlet/Mudlet/blob/d84f0b5b171370feb96db2f1950a3fd6dac1709f/src/mudlet-lua/lua/geyser/GeyserUtil.lua#L35
Таким образом, вместо использования отображения можно было бы использовать Geyser.display.

Можем ли мы идентифицировать объект Гейзер, если он дан? Может заставить display() вызвать эту функцию в этом случае автоматически.

Может быть, мы сможем помочь дисплею никогда больше не сталкиваться с этими бесконечными циклами?
Например, сохранить список всех отображаемых таблиц и не отображать полную вторую версию одной из них снова.

Немного покопавшись, я обнаружил, что у prettywrite есть отказоустойчивость против бесконечных циклов в нем, но в некоторых случаях он не работает для Гейзера (я не уверен, почему)
Например:

test = {}
test[1] = test
display(test)

Не вызовет бесконечного цикла.

Я попытался прокомментировать https://github.com/Mudlet/Mudlet/blob/4042ac7600db8196b219b3ae43a977045d591fdd/src/mudlet-lua/lua/DebugTools.lua#L185, и это, похоже, сработает, но я не уверен, может ли это вызвать другие вопросы и почему это вообще было.

Это причина: https://github.com/lunarmodules/Penlight/pull/38

Вне связи, похоже, что есть улучшение для согласованного порядка ключей, которым мы могли бы воспользоваться: https://github.com/lunarmodules/Penlight/pull/293

После дальнейшего раскопок я заметил, что проблема в основном возникает, если используются вложенные метки (в меню правой кнопки мыши регулируемого контейнера используется вложенная метка)
Лично я все еще считаю, что комментирование https://github.com/Mudlet/Mudlet/blob/4042ac7600db8196b219b3ae43a977045d591fdd/src/mudlet-lua/lua/DebugTools.lua#L185 - жизнеспособное решение проблемы.

Я тестировал https://github.com/kikito/inspect.lua, который делает более или менее то же самое, что и prettywrite, и они решают эту проблему таким же образом (как и было бы, если бы часть table [t] была закомментирована), но с той разницей, что каждая дублированная таблица получает идентификатор вместо общего <cycle>

Я также обнаружил аналогичную проблему, используя второй пример вложенных меток из Geyser Wiki (тот, у которого есть 'mainlabel') https://wiki.mudlet.org/index.php?title=Manual:Geyser#Demo -> наведите указатель мыши на 'Наведите туда часть', а затем используйте lua display(Geyser) прежнему вызывает ошибку переполнения стека (не происходит при использовании inspect)

Может быть, стоит подумать о переходе с prettywrite на inspect.

У нас нет особой причины придерживаться одного - если другой лучше, давайте сделаем это. Как они соотносятся, не могли бы вы опубликовать до / после?

Что касается согласованного порядка ключей, можно просто изменить использование пар на пары, и он должен справиться со всем этим. По сути, это все, что делает связанный фрагмент кода, мы просто абстрагировали его для использования где угодно как spairs.

У нас нет особой причины придерживаться одного - если другой лучше, давайте сделаем это. Как они соотносятся, не могли бы вы опубликовать до / после?

Он в значительной степени делает то же самое, но я не знаю, «лучше» ли он, по крайней мере, он не вылетает в Гейзере (что, на мой взгляд, делает его лучше);)
Я открою пиар