Заметил странное поведение у GoldEd+:
Cначала, при открытии сообщения с русскими буквами всё отображается корректно: http://pics.rsh.ru/img/before_keyDown_wluhtg06.png
о, если проскроллировать текст стрелочками вверх/вниз, отображение ломается: http://pics.rsh.ru/img/after_keyDown_jhpndcyx.png
Если после этого нажать pageUp/pageDown - всё снова начинает
отображаться корректно. И так до следующего нажатия стрелочек.
GoldEd собирал из мастера 9 марта этого года.
Кто может подсказать, в какую сторону копать?
Проблема не страшная, но немного раздражает
Кто может подсказать, в какую сторону копать?
Проблема не страшная, но немного раздражает
Подобная фигня уже у кого-то была. Воспроизвести у себя я не смог. Похоже, зависит от каких-то локальных настроек или комбинации либ.
Какую кодировку и локаль используешь для запуска эхотага?
В виндовом дедушке повторяемость 100%.
Какую кодировку и локаль используешь для запуска эхотага?В виндовом дедушке повторяемость 100%.
Кто может подсказать, в какую сторону копать?
Проблема не страшная, но немного раздражает
Подобная фигня уже у кого-то была. Воспроизвести у себя я не
смог. Похоже, зависит от каких-то локальных настроек или
комбинации либ.
Какую кодировку и локаль используешь для запуска эхотага?
В виндовом дедушке повторяемость 100%.
В виндовом дедушке повторяемость 100%.
В линуксовом тоже. Откат пуллреквеста от 17 марта не помог.
Ищу функцию сохранения буфера экрана из ncurses, т.к. косяк
проявляется даже при выходе в "скринсейвер" и возврате из него. Вот
через вызов скринсейвера и докопаюсь до искомой строчки.
Так это новая проблема или уже была? Можешь найти конкретный коммит, который ломает это поведение? git bisect очень помогает.
Так это новая проблема или уже была? Можешь найти конкретный
коммит, который ломает это поведение? git bisect очень помогает.
Спасибо за git bisect, полезная штука, я прям далеко копнул!
И нашел, что проблема в моем способе сборки. Сборка по-умолчанию с системной ncurses-6.5 все и ломала. Собрал как надо с libncurses.5 (ncurses 6.2) собранной без WIDE и все заработало как надо. адо было
сразу ldd gedlnx посмотреть.
Тогда можешь попробовать собрать коммит c98d48ca1634b472c02c62cf2b2c2f824492689e и подтвердить, что он не
ломает ничего? Я тогда его верну.
Тогда можешь попробовать собрать коммит
c98d48ca1634b472c02c62cf2b2c2f824492689e и подтвердить, что он не
ломает ничего? Я тогда его верну.
Его и собрал во вторую очередь - все ОК.
а с wide ncurses в первую очередь упирается в inline-ы в goldlib/gvidall.h:
inline vchar vgchar (vatch chat)
{
return chat & 0xff;
}
inline vattr vgattr (vatch chat)
{
return (chat >> 8) & 0xff;
}
inline vatch vschar (vatch chat, vchar chr)
{
return (chat & 0xff00) | chr;
}
inline vatch vsattr (vatch chat, vattr atr)
{
return (chat & 0xff) | (atr << 8);
}
inline vatch vcatch (vchar chr, vattr atr)
{
return (chr & 0xff) | ((atr << 8) & 0xff00);
}
#endif
inline vchar vgetc (int row, int col)
{
return vgchar(vgetw(row, col));
}
Где б еще столько "досуга" найти, чтоб на досуге с этим
поковыряться?)))
Его и собрал во вторую очередь - все ОК.
Значит, последний роллбэк можно убрать. :)
а с wide ncurses в первую очередь упирается в inline-ы в
Где б еще столько "досуга" найти, чтоб на досуге с этим
поковыряться?)))
Там нет быстрого решения. Этот код глухо однобайтовый. Чтобы заработал wide - нужно всё переделывать под юникод. А это значит переписать
больше половины.
Его и собрал во вторую очередь - все ОК.
Значит, последний роллбэк можно убрать. :)
а с wide ncurses в первую очередь упирается в inline-ы в
Где б еще столько "досуга" найти, чтоб на досуге с этим
поковыряться?)))
Там нет быстрого решения. Этот код глухо однобайтовый. Чтобы
заработал wide - нужно всё переделывать под юникод. А это значит
переписать больше половины.
у как минимум, чтобы весь вывод перевести на wide char я уже знаю
как, потихоньку начал другие функции править для вывода все, что в gvidbase. Там больше сложность с кучей ифдефов для других типов cchar.
о это похоже единственный путь, если вывод и ввод уже будет работать
с wide, то потом можно аккуратно и остальное править, ну ословно на
std string переводить.
Там нет быстрого решения. Этот код глухо однобайтовый. Чтобы
заработал wide - нужно всё переделывать под юникод. А это значит
переписать больше половины.
у как минимум, чтобы весь вывод перевести на wide char я уже
знаю как, потихоньку начал другие функции править для вывода все,
что в gvidbase. Там больше сложность с кучей ифдефов для других
типов cchar. о это похоже единственный путь, если вывод и ввод
уже будет работать с wide, то потом можно аккуратно и остальное
править, ну ословно на std string переводить.
Вот это дело. епросто только будет сделать так, чтобы оно без wide работало. Для старых систем. А без wide юникод нормально не взлетит. В общем, палка о двух концах.
Я уже подумываю о том, чтобы сделать ветку для перевода на юникод и потихоньку пилить в том направлении.
Какие задачи я там вижу кроме собственно перевода на юникод:
1. Перевести сборку полностью на cmake и выбросить все остальные make, vcproj и подобное. 2. Поднять стандарт как минимум до C++11. 3. Забить
на поддержку старых систем, в которых нет cmake и C++11. При этом по
идее кросскомпиляция должна помочь собирать под старые системы, если
кому сильно захочется нового функционала.
Если будет хороший прогресс и народ будет использовать эту версию -
влить её в мастер, заодно подняв версию до 2.0.
Как идея?
Мне все это нравится, можно даже до C++17 апнуть,
Мне все это нравится, можно даже до C++17 апнуть, если будут какие-то фиксы можно будет их бекпортить в легаси ветку.
новошта?)Мне все это нравится, можно даже до C++17 апнуть,
Оппа, у нас новонод нарисовался.
Так то и мы бы шмогли. А ты вот попробуй, где-то уровню C++98 соответствовать. Есть Open Watcom C/C++ 1.9, или открытый V2, который
ваще нивдупаляет про стандарты, но по-факту держит C++98, и
неофициально некоторые конструкции C++03. ФСЁ. икаких C++11 там нет.
P.S. -std=c++26, я у себя дома на петпроектах пишу.
Мне все это нравится, можно даже до C++17 апнуть, если будут
какие-то фиксы можно будет их бекпортить в легаси ветку.
Как раз с бекпортами возникнет больше всего проблем из-за отсутствия наличия разработчиков, если все переметнутся в новую мажорную версию с отдельной кодовой базой. Таким макаром проще уж на КуТях сразу
рисовать редактор, ну и назвать, естественно, по-другому. А, так это
уже не форк, это другой редактор... И сколько таких утонуло уже?
Там нет быстрого решения. Этот код глухо однобайтовый. Чтобы
заработал wide - нужно всё переделывать под юникод. А это
значит переписать больше половины.
у как минимум, чтобы весь вывод перевести на wide char я уже
знаю как, потихоньку начал другие функции править для вывода
все, что в gvidbase. Там больше сложность с кучей ифдефов для
других типов cchar. о это похоже единственный путь, если вывод
и ввод уже будет работать с wide, то потом можно аккуратно и
остальное править, ну ословно на std string переводить.
Вот это дело. епросто только будет сделать так, чтобы оно без
wide работало. Для старых систем. А без wide юникод нормально не
взлетит. В общем, палка о двух концах.
Я уже подумываю о том, чтобы сделать ветку для перевода на юникод
и потихоньку пилить в том направлении.
Какие задачи я там вижу кроме собственно перевода на юникод:
1. Перевести сборку полностью на cmake и выбросить все остальные
make, vcproj и подобное. 2. Поднять стандарт как минимум до
C++11. 3. Забить на поддержку старых систем, в которых нет cmake
и C++11. При этом по идее кросскомпиляция должна помочь собирать
под старые системы, если кому сильно захочется нового
функционала.
Если будет хороший прогресс и народ будет использовать эту версию
- влить её в мастер, заодно подняв версию до 2.0.
Как идея?
Мне все это нравится, можно даже до C++17 апнуть, если будут какие-то фиксы можно будет их бекпортить в легаси ветку.
Мне все это нравится, можно даже до C++17 апнуть,
Оппа, у нас новонод нарисовался.
новошта?)
https://nodehist.bsrealm.net/?address=2:5030/3165
Четыре года - это как вчера. ;)
Да, у меня была другая нода, эх) https://nodehist.bsrealm.net/?address=2:5031/65Мне все это нравится, можно даже до C++17 апнуть,
Оппа, у нас новонод нарисовался.
новошта?)
https://nodehist.bsrealm.net/?address=2:5030/3165
Четыре года - это как вчера. ;)
| Sysop: | Angel Ripoll |
|---|---|
| Location: | Madrid, Spain |
| Users: | 13 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 302:38:09 |
| Calls: | 1,105 |
| Files: | 1,389 |
| D/L today: |
11 files (10K bytes) |
| Messages: | 71,872 |
