«Скучно», дайте баг или запилить куда-то фичу

Но странно, что не отразилось на количестве скачиваний, все же тема iptv популярна, а где тв, там и телепрограмма, одно не может быть без другого. Плюс, mpv популярен у сторонников минимализма или иначе, у тех кто не любит перегружать дистрибутив различными гуи.

Отмечу еще один нюанс, который нарисовался после многомесячного использования iptv. Когда количество каналов переваливает за сотню, не так весело и слишком долго листать такой массив в поисках чего либо интересного.

Это мы с тобой обсуждали выше и в данном моменте yuki-iptv более продвинут, позволяя просмотреть сразу же всю телепрограмму с процентами просмотра, кратким содержанием и названием фильмов. Твои доводы о невозможности такого в mpv мной были приняты, я лишь напомню о чем речь:

Это как в yuki-iptv =) Но, там свои проблемы с этим, и это уже будет тяжёлой задачей для скрипта
«Скучно», дайте баг или запилить куда-то фичу (комментарий)

Это возможно сделать, но тут уже надо нормальный полноценный GUI нахлобучивать, поиск с выпадающим списком по мере набора, вкладкой прокрутки каналов, вкладкой прокрутки телепередач канала и во время всего этого ещё отображать некие текущие данные, иконки подгружать каналов и прочее. Короче делать полноценное приложение внутри mpv, можно но у меня нет к этому интереса, это будет долго, сложно и в итоге получится ещё один yuki-iptv, но зачем, если он и так уже есть. EPGTV это же просто маленькая нашлёпка, которая, если EPG не весит пол гига, заведётся на любом тапке, оно и так тормозит уже хотя я старался сохранить что-бы всё было примитивное и просто поверх видео выводился текст разукрашенный в неком подобии как будто это интерфейс.

Не, если там что и делать то писать с нуля, и писать уже не отображалку телепередач, а телегид делать полноценный. Если нужен телегид, то надо использовать телегид типа yuki-iptv, ибо делать тоже самое, но просто более тормознутое с тонной костылей такое себе, плюс нужна поддержка будет постоянная. Даже с казалось бы простой вещью как часовой пояс одни костыли. Не получится просто вот взять и сделать как по RFC что-то, там эдак, тут так. Пусть скромно, но будет как есть сейчас. Если у кого загорит может взять за основу и зафигачить прям конкретный телегид, с меню, поиском, выпадающими списками, картинками, скроллами, списком телеканалов и их редактором, кучей графический настроек, галочками и даже уведомлениями о начале любимой телепередачи и календарём. Это всё реально можно сделать и даже будет прикольно что это просто подключается к плееру как плагин.

Кто-то это сделает, но точно не я, может какой китаец =) Там в readme ссылка на сборку mpv китайскую, челик для плеера альтернативный гуй зафигачил с анимациями и куртизантками, плейлисты в виде списка выпадающего и прочее.

А ты мог бы например написать разработчице yuki-iptv, мол нет ли у неё желания сделать yuki-lite например, и не встраивать mpv в yuki-iptv, а встроить yuki-iptv в mpv если не всё, то может подмножество. Может ей будет интересно, а может и нет.

но тут уже надо нормальный полноценныйGUI

Имхо, это должно решаться без всяких gtk/qt и подобных. Иначе консольный mpv, уже не консольный, а в этом его преимущество, для ценителей.

И думаю это возможно, тем более самолично видел кучу lua скриптов, реализующих списки и позволяющих взаимодействовать с ними.
Но это я написал ради одной лишь истины, ) твои доводы, повторюсь, я услышал.

Имхо, это должно решаться без всяких gtk/qt и подобных.

Я и не говорю про них, я имею в виду реализацию GUI на уровне скриптов, без внешних зависимостей, просто делаешь свои графические примитивы, кнопочки, списки и так далее. Уже есть почти готовые.

самолично видел кучу lua скриптов, реализующих списки и позволяющих взаимодействовать с ними

Вот и я о том. Да.

Реально сделать? Да, кто-то займётся этим? ¯\(ツ)/¯

Тут обнаружил что у человека в арче mpv 0.39.0 не отдаёт пути до скриптов, странно, если пользуешься и отвалилось, то можно обновиться. Я не нашёл решения лучше чем тупо вшить предполагаемый для линукса путь скриптов по умолчанию в конец поисковых путей lua.

• https://github.com/blogdron/EPGTV/issues/9

Человек сам закостылил решение, и закрыл проблему. Я только щас увидел.

plan9port интересует? Есть один самый бесячий баг в GUI. Сишка, сам GUI довольно простой, не какой-нибудь огромный фреймворк а-ля GTK или Qt. Ну и конкурентность во всю через CSP.

У самого нет времени копаться и дебажить, но готов погрузить настолько глубоко, насколько возможно.

Спасибо скажут буквально все пользователи.

plan9port интересует?

Фиг знает, может ничего и не пойму, ручки у меня коротенькие

но готов погрузить настолько глубоко, насколько возможно.

Я сейчас не представляю как смогу скооперироваться, ну там гарантировать что мол давай спишемся тогда-то.

Есть один самый бесячий баг в GUI. Сишка

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

А там отпишусь, я слился, лапки к верху или попрошу комментарии/консультацию по тому что не понял.

Так как баг гуёвый можно ещё фоточку, где он виден, или просто место где он бывает, иногда можно понять где проблема тупо по фотке, если сложится понимание о том какое место в коде ответственно за место на картинке =) даже без хрустального шара и карт Таро хехе

Чёнибудь тут напиши, а я чёнибудь попробую сделать ::)

есть Tron и Ethereum кошелек на луа, додедаешб?

https://dev.narayana.im/narayana/sterwa
https://dev.narayana.im/narayana/sterwa-erx

Tron и Ethereum

Йя понятия не имею как они работают в целом.

кошелек на луа

Бегло, по коду, как я понял это утилита для взаимодействия с trongrid и ещё там какой-то api сервис запроса данных из/в кубикчейна, там просто дёргать надо всё у них правильно, а сама суть в локальной работе с локальной фигулиной котрой делать подписи/кошелей так я понял.

Хрен знает, если только приспичит прост покопаться, как выше сказал понятия не имею об нюансах, а они там есть например строка

input = "0x70a08231" .. string.rep("0", 24) .. address:gsub("0x", "")

Почему 0x70a08231, почему оно дополняется 24 нулями, почему надо у адреса вырезать префикс 0x и приклеивать это в конец. Это такие нюансы, о которых специфичные для конкретной штуки, о которых надо просто знать, а если не знаешь то и суваться смысла нет, а такого там много. В целом, запросить у сервиса данные по токену, показать что там есть, сформировать запрос с транзикацией, подписать её (чем-то там) и отправить, насколько я понял тут вся суть.

Кольнёт, потыкаю, а пока нет так как тут не в код вникать надо, а в матчасть для чего он. А я от крипты далёк.
Я пока жду что kaldeon напишет.

Но, пусть висит. Как минимум может кто ещё заинтересуется, или я вернусь позже.

Для справки, стоит иметь в виду:

Эта тема протухла, я некропостнул, но по делу.
99% всего в этой теме предложенного я не осилил, только вон для krasnh плагин и всё.
Но в целом попытка не пытка в любом случае.

Plan 9 может быть непривычным, но он практически во всех аспектах проще любого современного юникса. Ядро, юзерспейс, документация — всё написано очень ясно и коротко. Концепции необычные, но зато нет enterprise-scale абстрактной фабрики абстрактных фабрик, нет десятилетних легаси и техдолга, когда качество кода приносится в жертву функциональности, и нет башни из слоновой кости, когда порог входа не ниже PhD в computer science.

Одна из основных графических программ — Acme, текстовый редактор. Это настолько мощная программа, что один из разработчиков при переходе на Linux/macOS портировал весь юзерспейс Plan 9, чтобы получить Acme. Так и появился plan9port.

Если пакет есть в репозитории (например, в Arch Linux есть), можно ставить оттуда. Если нет, можно вручную склонировать git-репозиторий в /usr/local/plan9 и выполнить ./INSTALL (он не будет ничего трогать за пределами /usr/local/plan9).

После установки нужно добавить путь к бинарникам:

export PLAN9=/usr/local/plan9
PATH="$PATH:$PLAN9/bin"

Чтобы не возникло конфликтов (/bin/grep vs /usr/local/plan9/bin/grep), путь лучше добавить в конец PATH.

Установка более подробно описана здесь, но описанных инструкций должно быть достаточно.

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

Код Acme находится в src/cmd/acme. Заходим туда и выполняем команду mk (аналог make). Потом пробуем запустить o.acme.

Acme — это мультиоконный текстовый редактор. Сегодня мультиоконность в текстовых редакторах принято реализовывать через табы. В Acme окна располагаются по-вертикали в каждой колонке. Управление полуавтоматическое: Acme пытается сам угадать наиболее выгодное расположение, но пользователь может его изменить с помощью прямоугольника в левом-верхнем углу.

Баг связан именно с автоматической механикой. Если в любом месте написать команду (условно echo hello world) и исполнить её, нажав на колесо мыши (если есть только тачпад, то нажатие на колесо мыши эмулируется нажатием на тачпад во время удержания клавиши Alt), то Acme автоматически создаст новое окно с названием +Errors, в котором будет напечатан вывод этой команды. Кроме того, курсор мыши сам встанет на место нового окна. И если мы его закроем (нажав на Del колесом мыши), то курсор мыши вернётся обратно.

Кроме тех случаев, когда он по ошибке остаётся на месте, выдёргивая пользователей из состояния нирваны. Именно в этом состоит баг. В Acme есть куча других незаметных багов, но этот самый противный, потому что напрямую ломает ожидания пользователя. Это аффектит всех пользователей.

Демо. Демо без голоса, потому что сейчас половина третьего ночи и все остальные (нормальные) люди дома спят. Если нужно, завтра запишу версию с голосом.

В демо объясняется механизм возникновения ошибки, потому что его проще объяснить на примере. Но ключевые моменты нужно вынести в текст. Основной виновник — это поведение, при котором курсор ставится на окно, чьи размеры были изменены автоматически. +Errors некуда встать, другое окно отодвигается, на него ненадолго встаёт курсор мыши, появляется +Errors и курсор мыши встаёт на окно +Errors, запоминая предыдущее невидимое расположение. Когда +Errors удаляется, курсор встаёт на место пододвинутого окна, где курсор находился долю секунды.

При этом в +Errors нет ничего особенного. Это просто самый частый случай. Новое окно может быть создано в результате любой причины, будь это необходимость показать пользователю вывод команды (этот случай мы рассмотрели), создать новое пустое окно или что-нибудь ещё. Вот ещё одна демка проблемы. В любом случае последующий Del должен вернуть курсор мыши назад.

Нет ничего плохого в том, что курсор встаёт на окно, чьи размеры были изменены. Это помощь пользователю со стороны интерфейса. Кстати, это поведение можно вызвать не только действием пользователя, последствия которого сложно отследить в коде (handleClick и дальше удачи), но и через API. Демо. Можно по коду проследить что делает Acme, когда кто-нибудь записывает строку show в файл ctl.

(echo show |9p write acme/2/ctl — это ничто иное как эмуляция того, что можно было бы выразить через echo show >/mnt/acme/2/ctl в настоящем Plan 9. Просто /mnt/acme был бы у каждого инстанса редактора свой. Это невозможно в юниксах, поэтому эмулируется через 9p write acme/2/ctl. Но в коде Acme это будет выглядеть как отслеживание записей в файл /mnt/acme/2/ctl. Это просто файл с точки зрения программы, ничего особенного.)

Как решить эту проблему? Не ставить курсор на окно с изменёнными размерами, если изменение было вызвано созданием нового окна. Даже если новое окно подвинет десять других окон выше, Acme не должен ни на одно из них ставить курсор мыши.

Как это реализовано сейчас программно? Увы, не знаю.

Источники, которые могут помочь:

• ознакомиться с тем, что вообще такое Acme, чтобы не чувствовать себя как в тёмном лесу, можно здесь.
• архитектура описана здесь, в секции Concurrency in the implementation (с тем отличием, что Acme с тех пор был переписан на язык C)
• структуры данных хранятся в src/cmd/acme/dat.h
• для конкурентности используется libthread, реализующий стиль CSP в языке C
• для рисования используется libdraw
• тонкие отличия диалекта C от ANSI подробно написаны здесь. Но, в целом, это всё тот же C в подавляющей степени.

Мощно. Три видео на всякий случай скачал. Прочитал, пока писать ничего не буду, завтра буду снова перечитывать и ещё раз видео смотреть внимательнее. Об успехах отпишусь, когда будут новости. Спасибо за подробности. Попробую нырнуть, завтра вечером тихонько начну.

А сейчас, да, пора спать.

Если будут вопросы, проблемы, нужны дополнительные пояснения или примеры, сразу задавай, можно на kaldeon@yahoo.com, можно в t.me/spektrokalter, можно в другое удобное тебе место, даже простые вопросы, в любое время. Помогу чем смогу. Это незнакомый контекст (другая ОС, другой туллинг, другой UI) и не может не вызывать проблем, недопониманий и ложных следов. Я через это прошёл и постараюсь других провести. Хотя в коде я, к сожалению, ещё не разобрался.

Тебе спасибо, что решился взяться. Неожиданно. Доброго сна.

Воспроизвести поведение бага удалось

• https://i.ibb.co/wNnDhfMz/2025-09-12-22-50-08.png

Кажется нашёл логику, как минимум её часть, оно там в двух местах, row.c col.c больше похоже на адаптированную под ситуацию копипасту кода, просто разнесённую по файлам, удалось блокировать перемещение курсора при исполнении echo hello на новое окно. Вроде более менее понятно, что куда в целом, но в частностях там это

• https://i.ibb.co/j9krZK58/2025-09-12-23-21-11.png

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

abs(a-b)>30 && x>y+30 что может приводить в пограничных ситуациях к приколам если в другом месте, подобное просто не учитывается, а должно например.

В целом то понятно куда копать, код успешно и точечно удаётся сломать, видя потом в гуе место слома ожидаемое =)) Но рано радоваться не стоит, так как поведения там много, и наивное «исправление» может исправить А сломав БВГДЕ :D

На этом пока всё, далее отпишусь либо когда будет готово, либо когда я сольюсь. Вопросов нет, в целом всё что связано и ограничено фичебагом я понял вроде.

Ещё одна демка. Подчёркивает особенность: когда меняются размеры любого окна, курсор не возвращается.

Эта демка вынуждает рассмотреть тонкий вопрос: должен ли курсор возвращаться в данном случае? Выглядит так, что это не критично и лучше предпочесть простую реализацию. Если вывод команды будет большой, а места на экране будет прилично, то пользователю не придётся увеличивать окно: оно и так будет открыто в большом размере. А если места будет мало, то изменение размеров этого окна повлечёт за собой изменение размеров других окон, что загородит предыдущую локацию.

(Если же мы попытаемся вернуть курсор при изменении размеров окна, то нужно будет следить за тем, чтобы размеры других окон не были тронуты. Иначе предыдущая локация будет загорождена. Различие. И похоже на то, что это будет сложно достичь в конкурентном контексте.)

Поэтому мне пока самым рациональным кажется делать как-то так: если изменение окна было вызвано созданием нового окна, то не трогаем курсор мыши. boolean-флаг типа. Когда новое окно создаётся, то оно отправляет условное событие change{source: newwindow}, а при других обстоятельствах (например, при echo show >/mnt/acme/2/ctl или при открытии файла) событие change{source: undefined} (хотя код написан так, будто там не события, а global state). Мне кажется, нечто вроде этого флага используется, когда пользователь увеличивает размер окна во всю, принуждая другие окна уменьшиться. Курсор же не встаёт на другие окна, хотя их размеры были изменены.

В общем, надеюсь эти мысли помогут разобраться что к чему, исключить ложные следы, совместить А с БВГД.

Если нужно будет протестировать что-то, присылай артефакты (патчи или бинарник).

Хорошо, что уже есть хоть какой-то результат 👍

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

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

Начну с того что на ты написал выше

(Если же мы попытаемся вернуть курсор при изменении размеров окна, то нужно будет следить за тем, чтобы размеры других окон не были тронуты. Иначе предыдущая локация будет загорождена. Различие. И похоже на то, что это будет сложно достичь в конкурентном контексте.

И так далее, сразу с ходу, нет :) Там просто для этого ничего нет. Положение курсора и окна ваще никак не связаны и живут сами по себе, просто предыдущее положение курсора, при создании нового окна сохраняется, а при закрытии восстанавливается на то что было, если то окно ещё существует, а если нет то остаётся на месте, всё, это буквально вся логика перемещения курсора =) Ну почти вся, я не могучий пользователь, там ещё есть принудитульный скок его, но это видимо просто я не в курсе про то что он должен быть. Ну это к текущей проблеме отнощения не имеет.

Если я прав то баг пофикшен, и если кратко то тупо убери в файле plan9port/src/cmd/acme/cols.c последнюю строчку в теле функции colgrow, а именно вызов winmousebut(w); ну или вот патч

--- a/src/cmd/acme/cols.c
+++ b/src/cmd/acme/cols.c
@@ -469,7 +469,6 @@ colgrow(Column *c, Window *w, int but)
        free(nl);
        free(ny);
        c->safe = TRUE;
-       winmousebut(w);
 }
 
 void

А теперь в чём суть, когда мы вызываем echo hello в левой колонне, в правой дёргается coladd, затем берётся последнее окно в этой колонке, если для нового окна там нет места для его размещения, то в цикле вызывается colgrow который меняет размер последнего окна в колонке до тех пор пока там не появится место для нового окна, беда в том что в конце своего вызова colgrow дёргает winmousebut(w) который меняет значение положения курсора на положение смещающегося окна, запомним этот момент, затем уже идёт создание и размещение нового окна и вызывается savemouse в который мы передаём это новое окно (то окно которое появляется справа, при клике колёсиком на echo hello слева), savemouse же просто сохраняет указатель на окно и координаты мышки, для последующего их восстановления назад при закрытии этого окна, только вот положение предыдущее мышки уже затёрто вызовом winmousebut(w) и возвращается уже курсор назад не на окно слева инициирующее создание нового окна справа, а на окно в колонке справа, которое было отодвинуто. И во время его отодвигания вызовом colgrow курсор прыгал, и эти прыжки ты и видел при замедленном воспроизведении. Итого winmousebut просто нахрен не нужен в конце вызова colgrow так как просто не надо менять позицию курсора, на автоматически сдвигаемом окошечке, а если надо это надо сделать явно после вызова colgrow, а не внутри его и всегда. И именно это и делается в coldrawin

Ну и почему бага не происходит, когда для окна есть место для его размещения без отодвигания, ну тут всё просто, когда нет вызова colgrow то просто создаётся новое окно, вызывается savemouse сохраняя положение курсора и указатель на окно, затем вызывается coldrawin который переносит курсор в новое окно и отображает его, когда мы его закрываем, берутся предыдущие координаты и если указатель на окно живой, то курсор просто перемещается назад вызовом
restoremouse ну, вернее там и идут проверки. В ином случае курсор просто остаётся на месте и всё.

Насколько я понял, изменение не сломает никакого другого поведения, кроме как бесполезного прыгания курсора при неявном изменении окна, которое просто отодвигается для нового, пользователь с ним не взаимодействовал, следовательно не надо на него кусор перемещать. Вот и всё.

Видива результата, сорян за качество, у меня компъ тормозит, записывал в шакалах на шакалах

• https://0x0.st/Kc-c.ogv

Есть вероятность что я промахнулся в своих выводах и доводах, но вроде как нет и всё так

Всё, я спать. Надеюсь проблема решена ::)

Ещё раз всё перепроверил, регрессий не вижу, хоть убей.

Оформил реквест с объяснением

• https://github.com/9fans/plan9port/pull/730

А вы уж там разберитесь что с этим делать.

Сегодня ночью буду тестировать.

Большое спасибо за то, что разобрался в том, как оно устроено. Но, к сожалению, вот с этим есть проблема:

Насколько я понял, изменение не сломает никакого другого поведения, кроме как бесполезного прыгания курсора при неявном изменении окна, которое просто отодвигается для нового, пользователь с ним не взаимодействовал, следовательно не надо на него кусор перемещать. Вот и всё.

Неявное изменение окна тоже должно захватывать курсор в некоторых случаях. Подробнее написал на гитхабе вместе с вариантом фикса.

На всякий случай демо.

Как только докатишь фикс, позовём мейнтейнеров.

В целом, это было неожиданно и круто. Ещё раз спасибо! У Plan 9 вроде сильное сообщество, а такой баг не могут пофиксить уже десятилетиями.

Ага, надеялся что регрессий не будет, но ничего, зато они понятно где лежат.

Есть одно и простое безболезненное решение в коде acme всего 9 мест, где вызывается colgrow гарантированно можно вернуть всё взад, не поломав снова починенное, просто расставив после его вызова winmousebut(w) или вообще moveto явно, кроме того места где оно уже проставлено, и того места где оно ненужно. Единственный вопрос куда невозвращать вызов winmousebut(w).

Расставлю где оно было ранее, в том смысле что, на поведение багофичи полагались, я надеялся что нет, и всё вернётся назад как было, только баг будет починен.

Ща, только кашу покушаю и отправлю.

вместе с вариантом фикса.

Тьфу, слепой, не заметил, это не вариант фикса, это и есть прямой фикс, так и надо, просто в нескольких местах сразу. Это можно сделать как в рамках исправления текущего бага, или в рамках отдельного фикса регрессий. Я хз как там приянто, но завину просто всё сразу. Как минимум это будет гарантировать исправление бага плюс гарантировать отсутствие регрессий. Я не сделал этого ранее, думая что просто баг он баг, и он не стал фундаметом, но стал =)))

А хотя нет, отложу, там есть пару мест на подумать…

Нашёл причину и этого бага, он не связан с исправлением предыдущего, но работает по той же логике, на этот раз виноват winresize он перезатирает координаты мышки до их сохранения. Он не является регрессией, а является отдельным багом.

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

Короче думаю, на деле, баг на баге багом погоняет =)))))) Ну не баги, а просто много частных случаев переплелись и друг с дружкой местами не очень жружат, вот и всё.

Буду думать, напишу про это в гите

Снова нашёл вторичную причину бага, на этот раз координаты мышки сохранены верно, но вот указатель на окно улетает, если убрать проверку укзаателя, кусор вертается нормально, буду искать где зануляется указатель на окно, до момента возврата мышки, хотя вроде нигде :( пока хз даже. Там ещё прикол, сам то указатель на окно хранится не предыдущий, а текущий, что само по себе бесполезно, и тоже баг, логический и они дружно друг на дружке сидят :)

Но они логические, просто за годы было много вкраплений.

Частично пофиксил первую часть, вторую пока сложно воспроизвести. Тут уже другая история, курсор не переходит на область. Пока не знаю.

А что за вторая часть?

Edit: можешь написать что именно в интерфейсе работает не так, как ожидается?

На всякий случай: в последнем демо ошибки только на первом окне. Во втором окне всё как должно быть.

Там где ID начал вбивать и далее. Но тут навреное я уже всё, вернее логика там уже всё, для перемещения курсора есть только 1 механизм, а именно сохранение его позиции, которое в 100500 местах может быть затёрто, неглядя на то что его нужно потом вернуть, для предотвращения прыжка курсора обратно используется указатель на это же новосозданное окно, а не на окно инициатор, если в ряде случаев, например закрытие всех окон, не нужно никуда обратно курсор возвращать вызывается clearmouse который просто затирает ранее установленный указатель, таким образом проверяется не факт того что окно существует чтобы на него вернуть, проверяется только частный случай, а указатель на окно используется как по сути булевый флаг, разрешить курсору обратно прыгнуть при restoremouse или нет. Иными словами всё состояние перемещать обратно курсор или нет хранит 1 переменная, и ещё одна, хранящая куда возвращать может быть много где просто затёрта и оно друг с другом никак не синхается и не проверяется, ну вот в этом частном случае нам надо всё затерерть, а что что оно сломает другой частный случай не важно, там такого много.

Это всё про возврат курсора, а у тебя там иногда он и на новое окно не перемещается, это уже другая история. Отдельная от текущего бага, так как чтобы что-то вернуть надо сначала сохранить и переместить, где-то этого не просиходит просто. Но пока что мой лимит времени всё. Можешь накатить изменения те что есть, это частично исправить самый бесячий баг, а остальное это уже другие баги, их надо отдельно чинить, но да у них есть общие места.

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

На этом пока всё, чем смог тем помог, по факту баг исправлен, вернул на свои места вызов winmousebut кроме того места где оно вызывало проблему и переместил сохранение положения курсора, до возможных моментов где значение могло быть затёрто до его сохранения, но это касается только того случая когда создаётся новое окно, там и другие есть, просто баг там не один, может вернусь если будет время.

Ухъ как-то так.

Откатился на твою ветку, тестирую. Заметил, что если +Errors уже существует, загорожен, то при исполнении echo hello курсор, как и ожидается, прыгает к этому окну, но при закрытии возвращается. Ты, случаем, не этот сценарий рассматриваешь?

Здесь сложно судить, не являясь автором программы. Но выглядит так, будто на это лишнее. Я думаю, можно ограничиться тем, чтобы курсор возвращался только тогда, когда удаляют новое окно. Если же окно уже до этого существовало и нам нужно выбрать, то нужно подумать, а хотим ли мы, чтобы курсор возвращался.

Выглядит так, что да. Я просто об этом раньше не задумывался. Допустим, скрипт какой-то работает в фоне и иногда пишет логи, которые нас в случайный момент дёргают в +Errors. Удаляем окно — курсор вернулся назад. Ну и аналогично с другими окнами, которые по той или иной причине вздрогнули. Но, честно говоря, это нигде не задокументировано и я не уверен в том, что это самое лучшее решение. Может быть, оно и правильно, что курсор не возвращается после удаления существующих дёрнутых окон (потому что пользователь не ожидает этого). Я не знаю.

Теперь прочту твоё сообщение.

Edit: можешь написать что именно в интерфейсе работает не так, как ожидается?

Я не очень уверен на счёт ожиданий, при первом echo hello курсор должен прыгнуть на новое окно с «hello», а вот далее при последующих вызовах echo hello там просто далее ещё выводится «hello» «hello» должен ли он снова прыгать? Если нет то всё нормально.

Да, здесь всё нормально. Если окно стоит на месте, курсор не должен на него прыгать.

Я думаю, можно ограничиться тем, чтобы курсор возвращался только тогда, когда удаляют новое окно.

А оно только это теперь и делает, прыг назад сохраняется только в случае если было создано новое окно и затем оно удалено, и всё. Починка заключалась в том чтобы убрать/изменит то что этому мешало, а именно неявном затираением позиции при попытке расширить область для нового окна до сохранения позиции и в моменте когда окно отображается и затирается указатель ранее сохранёненый если окно перемещено, но взаимодействия с ним не было.

Я это и починил. Если курсор в других случаях ещё прыгает, то там много мест где его перемещают насильно и явно через moveto. Но если раньше перемещали, то и сейчас перемещаться будет как раньше, эти вещи я не трогал.

А оно только это теперь и делает

Нет же. Если окно уже существует, дрогнуло и мы его удалили, курсор возвращается назад. Вот демо (и на нём же ещё одна проблема).

Хочешь сказать, что судя по коду оно и должно так работать, и если бы хотели, чтобы курсор не возвращался при изменении размеров любого окна, то сделали бы по-другому?

Я сейчас думаю как лучше написать мейнтейнерам, чтобы нас поняли и согласились принять патч.

Длинное сообщение ещё не успел прочесть, читаю.

Я накидал такое сообщение, проверь, пожалуйста, что оно соответствует истине. Если да, позовём мейнтейнеров, попросим смерджить.

Initially, you addressed the issue of the mouse not returning after
deleting a new window, which was caused by other windows shifting.
Now, you've also resolved the problem where the mouse doesn't return
after deleting any existing window whose dimension changes attract the
mouse.

The challenge you've faced is that fixing this issue is
straightforward for +Errors windows but more difficult for other
cases, such as when writing "show" to "ctl".

Edit: ещё надо подумать что делать с ошибкой в последнем демо (где курсор не возвращается после ручного ввода и удаления \n). Если не получится исправить, можно вообще ничего не говорить и оформить как отдельный баг.

Нет же. Если окно уже существует, дрогнуло и мы его удалили, курсор возвращается назад.

Нууу, да =) Ранее же была проблема в том что он не возращался. Ты нажал echo hello создалось окно, туда прыгнул курсор, ты закрыл окно с выводом hello курсор вернулся обратно на echo hello включая случай если справа было два окна в самом низу «блинчиками» друг к другу прибытыми. Тут я чинил возврат мышки. Всё.

Хочешь сказать, что судя по коду оно и должно так работать, и если бы хотели, чтобы курсор не возвращался при изменении размеров любого окна

Да, так как это было так и раньше, если для окна и его текста в нём есть место, то туда просто печатается hello без прыжка курсора вправо, но если окна там блинчиками, то курсор прыгнет туда. У нас проблема была в том что он не прыгал обратно. А два поведения других прыгает на вывод если окно изменилось или не прыгает если не изменилось, это так было изначально и к исправленному багу невозврата курсора назад отношения не имеет, это отдельное поведение и если его менять, то отдельно и явно в функции winresize через вызов moveto

Это просто так раньше и было. Если окно изменилось то на него явно перебрасывается курсор, но там ещё должны ifы сработать, то есть это сделано в acme явно.

Да, всё так, изменения решают проблему возвращения курсора назад, но другие оооочень похожие на эту проблему вещи, и визуально как-бы связанные, похожие, являются просто другими и более сложными частными случаями и решаться должны отдельно. Но решаться так чтобы не ломать друг друга, так как они используют общие механизмы от которых их же поведение и зависит.

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

Прежде чем мержить пусть ещё кто-то потыкает наверное. Ну, базово починилось и ладушки.

На этом пока всё, не знаю смогу ли время выделить ещё, уж взялся программу минимум сделал. А с остальным видно будет, может да, может нет. Как минимум и что более важно архитектурная проблема явно обозначена и видны её проблемы, это не значит что там надо всё передлопачивать, нет, код прозрачный и позволяет вот так на ходу чинить. Но просто стоит как-то может в комментариях логику обозначивать мол вот тут мы хотим это и пожалуйста не делайте вон то пока это не отработает ну или типа того.

А пока и так норм :) Может майнтейнеры подтянутся и ещё чуть допилят сами, у них то там лбы пошире и видели больше, нюансы знат лучше.

Досвиданья.

Примерно понял. Спасибо за терпение и старания. Напишу сначала мейнтейнерам. Если не ответят до субботы, напишу в список рассылки.

Пральна. Тебя не одного говоришь бесит, если у кого тоже горит и узнает что идёт попытки бесячее убрать то может кто присоединится, причём что важно кто-то активно пользующийся. И даже если не смержат, не страшно, локально ты у себя пропатчил уже, а тот кто захочет починить но уже возможно более капитально уже будет знать куда смотреть и в чём была изначальная проблема. Но, первичный баг исправлен. Просто его можно исправить и по другому, но это приведёт к мнодественным изменениям, мне показалось такого никто бы не хотел, и те кто код уже понимает, сохранили его понимание.

Кроме plan9port есть 9front.org — ОС, работающая на современном железе (хоть и без финансирования). В случае чего они могут быть заинтересованы.

Пока что призвал мейнтейнеров на гитхабе.