Юникод в LuaFAR

Здесь обсуждается всё, что касается макросов.
Shmuel
Posts: 7244
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 48 times
Been thanked: 636 times

Юникод в LuaFAR

Post by Shmuel »

Latest post of the previous page:

John Doe wrote: Sat 16 Jan, 2021 10:59 Ещё одно изменение вызывает вопрос: неясно нужно ли это только для фара, или полезно и для библиотеки в целом не помешает:
Это изменение создаёт глобальную переменную utf8. Для Фара было решено её создавать.
Полезно ли это для библиотеки? На взгляд создателей Lua - не полезно и, начиная с версии 5.2, этого синтаксиса уже нет.
Если пользователю библиотеки нужно, он создаст глобальную переменную прямо в строке вызова require().
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Shmuel wrote: Sat 16 Jan, 2021 19:36 Если пользователю библиотеки нужно, он создаст глобальную переменную прямо в строке вызова require().
Ну что ж, автор (не глядя?) уже применил и это наше изменение.
Подозреваю, что лучше бы создание переменной переместить в LuaFAR, но..
https://t.me/FarManager — Telegram чат
User avatar
buniak_a_h
Posts: 4565
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 242 times
Been thanked: 674 times
Contact:

Юникод в LuaFAR

Post by buniak_a_h »

John Doe wrote: Sat 16 Jan, 2021 19:32
buniak_a_h wrote: Sat 16 Jan, 2021 19:25 А в "парной" функции utf8.rep - нет.
А если utf8.rep = string.rep?
А я не понял. Это надо в _macroinit добавить (там, где я свой пресловутый «враппер» записал)? Причём для всех трёх функций? Это, наверно, правильно удобно будет. Или это был вопрос типа что будет если…?
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

buniak_a_h wrote: Sat 16 Jan, 2021 19:59 Или это был вопрос типа что будет если…?
Да, это вопрос. С одной стороны не вижу почему бы этому не работать. А с другой - почему-то же Shmuel поступил не так:

Code: Select all

   - A few missing functions are copied to utf8 from unicode.utf8: dump, format, rep, utf8valid.
(т.е. сейчас эти функции скопированы из нашей прошлой библиотеки - Selene Unicode)
https://t.me/FarManager — Telegram чат
User avatar
buniak_a_h
Posts: 4565
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 242 times
Been thanked: 674 times
Contact:

Юникод в LuaFAR

Post by buniak_a_h »

John Doe wrote: Sat 16 Jan, 2021 20:38
buniak_a_h wrote: Sat 16 Jan, 2021 19:59 Или это был вопрос типа что будет если…?
Да, это вопрос. С одной стороны не вижу почему бы этому не работать. А с другой - почему-то же Shmuel поступил не так:

Code: Select all

   - A few missing functions are copied to utf8 from unicode.utf8: dump, format, rep, utf8valid.
(т.е. сейчас эти функции скопированы из нашей прошлой библиотеки - Selene Unicode)
1. Конкретно rep из string прекрасно работает. Можно в _macroinit добавить замену и не париться.
2. Я думал (точнее, я даже проверил):
lua:=_G.utf8 == _G. unicode.utf8.
Т.е. не "некоторые функции скопированы", а скопирована вся таблица. Думаю, приведённая цитата, возможно, устарела.
Last edited by buniak_a_h on Sat 16 Jan, 2021 21:14, edited 2 times in total.
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Недокументированный факт: utf8.len может вернуть nil если строка не является корректным utf-8, вторым значением она при этом вернёт смещение, на котором споткнулась.

Факт примечателен тем, что большинство других utf8 функций в этом случае бросают исключение.

Edit: https://www.lua.org/manual/5.3/manual.html#pdf-utf8.len
https://t.me/FarManager — Telegram чат
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Предлагаю обсудить здесь поддержку юникодных путей/имён файлов в lua(far).

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

Недостатки этого подхода:
  • сторонние C-модули не получают реализованных в LuaFAR преимуществ
  • если сторонний C-модуль передаёт зависящие от CRT объекты (в данном случае FILE*) через границы dll, то это чревато падением всего приложения.
    Обсуждение: viewtopic.php?p=182178#p182178
https://t.me/FarManager — Telegram чат
Shmuel
Posts: 7244
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 48 times
Been thanked: 636 times

Юникод в LuaFAR

Post by Shmuel »

А что обсуждать-то? Есть идеи - выкладывайте.
Один из вариантов - патчить LuaJIT.
Создайте файл с именем, содержащим последовательность русских и греческих букв. Ни Lua, ни LuaJIT его на Windows не откроют.
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Самым чистым решением могло бы быть указание activeCodePage в манифесте far.exe: https://learn.microsoft.com/windows/app ... -code-page
В этом случае все -A функции начинают работать с utf-8.

Преимущество: начинает автоматически поддерживаться Unicode в путях, и даже например старые билды lfs.dll заработают сходу.

Недостатки:
  • Только Window 10+. Но это уже неплохо, для старых ОС можно было бы оставить нынешний подход.
  • BOM наверно(?) не будет прозрачно пропускаться.
  • Если строки с путями как-то преобразуются (например усекаются по длине), то результат может быть неожиданным (например несоответствие фактической длине и разрыв посредине codepoint).
  • К ANSI-плагинам это тоже относится, т.к. ACP действует глобально на всё приложение.
Полагаю, недостатки пока перевешивают, и использовать этот подход для фара мы не сможем, по крайней мере без глобальных изменений (типа отдельного хоста для анси-плагинов).
https://t.me/FarManager — Telegram чат
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Shmuel wrote: Fri 20 Feb, 2026 20:49 Один из вариантов - патчить LuaJIT.
Если LuaJIT будет собран с MSVCRT, то это решит проблему с падением фара.
Учитывая что бинарники luajit всё равно скачиваются с отдельного репозитория уже собранными, это видится самым простым решением.

Недостаток: luafar не будет юникодным с другим lua*.dll.
Но можно наверно не трогая сам luajit, реализовать патченые функции в отдельном C-модуле...
Впрочем, без этого достаточно и точечного патча, а все связанные функции (popen, dofile etc) получили бы всё автоматически.

Разве что применить IAT-хук на fopen, что было бы видно и сторонним C-модулям (иначе наши улучшения для них бесполезны).** Edit:** на сторонние модули это не может повлиять.

Есть ли какие-нибудь препятствия (помимо трудозатрат)?
Last edited by John Doe on Sun 22 Feb, 2026 13:32, edited 1 time in total.
https://t.me/FarManager — Telegram чат
Shmuel
Posts: 7244
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 48 times
Been thanked: 636 times

Юникод в LuaFAR

Post by Shmuel »

John Doe wrote: Fri 20 Feb, 2026 21:28 Если LuaJIT будет собран с MSVCRT, то это решит проблему с падением фара.
Он собран именно с MSVCRT.
John Doe wrote: Fri 20 Feb, 2026 21:28 Учитывая что бинарники luajit всё равно скачиваются с отдельного репозитория уже собранными
(На случай, если не в курсе) - собираю его я с помощью GCC 8.1 и кладу в этот репозиторий.
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

В копилку.
Ещё один интересный приём: LuaJIT io.open monkeypatch in Windows to load UTF-8 filenames



Весь патч через FFI, т.е. никакая поддержка в LuaFAR вообще не требуется.
Используется _wfreopen с исходным файловым дескриптором.

Недостаток: производные функции (popen, dofile, ...) так не починить.
https://t.me/FarManager — Telegram чат
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Здесь патчи для lua https://github.com/Lekensteyn/lua-unicode
Я не сравнивал с теми что применяются в LuaFAR, привожу на случай если они вдруг более полные.
И для LuaJIT набор необходимых патчей может отличаться.

Edit Сравнил.
Lua-unicode патчит исходники Lua на более низком уровне, а значит не приходится реимплементировать всё с нуля: т. е. достаточно лишь нескольких локальных изменений.
При этом патч оформлен независимо, и при выходе обновлённой версии luajit достаточно будет просто перезапустить сборку, не внося никаких изменений, что огромный плюс.

Нюансы: luafar вносит ещё пару изменений, надо их перенести в патч. И можно взять за основу существующую адаптация патча для luajit: https://github.com/pragtical/luajit-unicode
Last edited by John Doe on Sun 22 Feb, 2026 13:54, edited 1 time in total.
https://t.me/FarManager — Telegram чат
Shmuel
Posts: 7244
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 48 times
Been thanked: 636 times

Юникод в LuaFAR

Post by Shmuel »

John Doe, можете заняться реализацией какого-либо из приведенных выше решений.
У меня нет для этого ни мотивации, ни потребности.
Пример с падением при использовании lfs - на мой взгляд вина самой lfs, которая залезла в детали имплементации вместо использования официального API.
Не надо пользоваться сторонними функциями, которые делают вид, что знают, как устроен file handle в Lua и преобразуют его в FILE*.
User avatar
John Doe
Бюрократ
Posts: 14582
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Юникод в LuaFAR

Post by John Doe »

Shmuel wrote: Fri 20 Feb, 2026 22:38 У меня нет для этого ни мотивации, ни потребности.
Это можно понять.
Тему я начал для того чтобы разобраться (прежде всего самому), а вопрос реализации уже второй.
Shmuel wrote: Fri 20 Feb, 2026 22:38 Пример с падением при использовании lfs - на мой взгляд вина самой lfs, которая залезла в детали имплементации вместо использования официального API.
Падение происходит в момент когда FILE* полученный от одной CRT передаётся в setmode другой CRT.
Я не знаю какой официальный API тут можно было задействовать вместо этого.

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

Впрочем, можно рассматривать это и как детали реализации lua, но в этом случае просто невозможно сделать ничего за пределами стандартной библиотеки.

Last edited by John Doe on Fri 20 Feb, 2026 23:39, edited 1 time in total.
https://t.me/FarManager — Telegram чат
Shmuel
Posts: 7244
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 48 times
Been thanked: 636 times

Юникод в LuaFAR

Post by Shmuel »

John Doe wrote: Fri 20 Feb, 2026 23:30 Падение происходит в момент когда FILE* полученный от одной CRT передаётся в setmode другой CRT.
Я не знаю какой официальный API тут можно было задействовать вместо этого.
Я смотрел соответствующие части кода lfs. Там даже разная обработка для луа 5.1 и более новых версий. Но Lua - это язык, а не его реализация. Завтра я напишу другую реализацию file handle (полностью поддерживая официальный API), и тогда lfs уже будет валить аппликацию при любых рантаймах.

Официального API вместо этого нет. Но lfs могла бы сделать свой io (назвав его lfs), а не цепляться к implementation details.
Post Reply

Return to “Обсуждение макросов”