OberonCore

А почему вы ударяете согласные? Это баг или фича?

Научить каретку не убегать - несложно, это небольшие изменения. Правда, они, наэн, размазаны будут по трем модулям: TextViews, TextSetters, TextControllers.

В теме prosilver они ставятся правильно. А у вас наверное стоит subsilver2, в ней и правда, ударения рисуются над другими буквами. Наверное, от шрифта зависит.

Переходить к UTF-кодировкам, в итоге, не хочется (ломать удобную логику "1 элемент массива = 1 литера". Про сборные знаки - понятно, но всё же, это не совсем то же самое). И попытки их введения втаскивают BlackBox в длительную турбулентность - когда "пока не поймёшь, что где валяется и когда всё это кончится".

Проще всего логически, алгоритмически - принять CHAR 4-байтным. Это решает всё, но ведёт к двухкратному перерасходу памяти. Ну и требует анализа всех библиотек, где там вместо SIZE(CHAR) сидит просто 2.

Но можно принять размерность CHAR решением этапа компиляции. Так же, как платформу.
Тогда по-умолчанию графическая среда собрана и работает с 4-байтным CHAR, но можно собрать, например, серверное приложение с 2-байтным, если мы знаем, что нам не нужно обслуживать азиатские тексты, например.

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

Вот попалась:
https://polit.ru/article/2020/10/13/neuroeconomy/print/
Там таких й не все, но довольно много.

Прошу прощения, я внимательно прочел html-файл, но не нашел ни одной. Возможно, я не знаю, чего ищу? Или мы др др не поняли? Вы не могли бы указать точнее, в каком предложении?

Если открыть ссылку в Хроме, сделать Ctrl+A, Ctrl+C, потом пойти в Blackbox и сделать Ctrl+V в окошко Log, то первая композитная й стоит в конце первого же предложения основного текста:

Даниэль Канеман выдвинул предположение о существовании двух систем, обусловливающих принятие решений.

Если поставить курсор после между "й" и "." и нажать пробел, то "й" развалится на две литеры.

Страшно жить...

Если видишь в тексте й


Не верь глазам своим...
Вот она, правда:



Ужас... окопаться... по периметру блекбокса выставить санитарные кордоны и беспощадно выкорчевывать UTF8 СС86...

Вот интересно, откуда же она у них в их аштээмэлах берется?

Следом падёт жертвой буква Ё, я полагаю.

Видимо, придется в Text реализовывать поддержку этих псевдолитер.

Наверное, стоит в режиме показа скрытых символов считать эти литеры отдельными, а в режиме без скрытых символов - толковать эти две литеры как единое целое?

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

Но что делать с Find?

Вот ещё какая хрень бывает с юникодом:

Коллеги, я обнаружил еще одну, кмк, жемчужинку, доставшуюся ББ от Оберона.

Формат OCF вмещает множество метаданных, многие из которых представляются числами - там и сям всякие индексы. Напр, сведения о процедуре содержат: ее номер в таблице; количество параметров; имя и имена всех параметров, которые представляются индексами в массиве имен; каждое имя начинается с указания длины и т.п. (не претендую на точность).
И большинство этих чисел - небольшие. В памяти ЭВМ они занимают по 4 байта.

А вот в файл выводится количество байт, необходимое и достаточное для представления каждого числа. Т.е. напр. число 28 займет 1 байт в файле, а число 1978 - два.

Меня почему-то в восторг привела эта находка!

Какое отношение к Уникоду: даже если использовать LONGCHAR или CHAR = {0X..FFFFFFFFX}, в ODC файл можно записывать, пользуясь той же методикой: ровно столько байт, сколько необходимо и достаточно для конкретной литеры. И это сбережет файлы от распухания.

Что-то очень странно про OCF. Учитывая, что он загружается в память блоками, как есть - и просто настраиваются ссылки.

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

Грамотно организованный интерфейс пользователя вообще не должен включать понятие файла. Пользователь не должен решать вопросы идентификации файлов (по имени, в таком-то каталоге, на таком-то диске и т.п.) Как пример - гугл-документы: пользователь создает документы, таблички, презентации и т.п., как-то там их для себя называет; файлы? не, там нет файлов, и нет имен файлов.

Другой пример - модули в КП/ББ: модули - это не файлы. Это фундаментально отличает от других языков и "экосистем". (Не хватает только пары команд в меню, которые позволяли бы сохранять модули, не залезая в меню "Файл" и не открывая папочное окно; но для себя я сделал ; )

Т.е. следует развести два понятия: идентификатор файла (используется программистами); и некое название, обозначение того, что внутри него, которое используется пользователем. Названия может и не быть; название может быть реализовано как метаданные файла, если таковые поддерживает ФС, или приложения должны хранить их внутри файлов, если ФС не поддерживает метаданные.
А к идентификаторам файлов можно бы предъявить те же требования, что и к идентификаторам переменных: буквы и цифры, и никаких головняков про пробелы, запятые, и всякие уникодные чудо-литеры, которые не видны или вообще левое обозначают правым )

Надеюсь, новый вариант UTF8 переизобратать не будете?

Взгляните на DevCPM.WriteNum и .ReadNum; Kernel.RefNum. возможно, я и ошибся.

Я правильно понял вас, что описанная методика напоминает UTF8?

Я читал когда-то описание этого формата. По-моему, старший бит кодирует необходимость прочитать и добавить ещё один байт. Почти как в UTF-8.


Это как раз цикл по старшему биту при чтении. В UTF-8 отличие в том, что первый байт сразу содержит длину литеры.

Впрочем, Обероновский формат компактнее UTF-8, так что можно, наверное, хранить прямо так же, как числа. Вроде как избыточность не нужна, да и вопрос совместимости не стоит.

Оберон рулит ) даже в мелочах

А, в доп. символьной информации да.

В основных дескрипторах метаинформации - нет.