LINUX.ORG.RU

История изменений

Исправление bormant, (текущая версия) :

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...
С другой стороны, utf32 не избавляет от ситуации «несколько кодпоинтов -> одно знакоместо», и тперь минусы уже перевешивают плюсы...

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Плюс, нужно иметь в виду, что TV изначально был ориентирован на дешёвый вывод на экран больших областей в формате {символ, цвет} — пиши себе в видеопамять напрямую и горя не знай, после CGA даже обратного хода луча не надо ждать. А вот *nix терминалы в тупом варианте такого счастья лишены напрочь, под удалённую работу имело смысл минимизировать передачу, для вывода областей отдельные команды, вывода цвета отдельно нет и т.п.
Вот над этой разницей при порте FV тоже стоит немного подумать.

Исправление bormant, :

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...
С другой стороны, utf32 не избавляет от ситуации «несколько кодпоинтов -> одно знакоместо», и вот минусы уже перевешивают плюсы...

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Плюс, нужно иметь в виду, что TV изначально был ориентирован на дешёвый вывод на экран больших областей в формате {символ, цвет} — пиши себе в видеопамять напрямую и горя не знай, после CGA даже обратного хода луча не надо ждать. А вот *nix терминалы в тупом варианте такого счастья лишены напрочь, под удалённую работу имело смысл минимизировать передачу, для вывода областей отдельные команды, вывода цвета отдельно нет и т.п.
Вот над этой разницей при порте FV тоже стоит немного подумать.

Исправление bormant, :

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Плюс, нужно иметь в виду, что TV изначально был ориентирован на дешёвый вывод на экран больших областей в формате {символ, цвет} — пиши себе в видеопамять напрямую и горя не знай, после CGA даже обратного хода луча не надо ждать. А вот *nix терминалы в тупом варианте такого счастья лишены напрочь, под удалённую работу имело смысл минимизировать передачу, для вывода областей отдельные команды, вывода цвета отдельно нет и т.п.
Вот над этой разницей при порте FV тоже стоит немного подумать.

Исправление bormant, :

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Исходная версия bormant, :

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...