OberonCore

С формами проблема в том, что свойсва контролов, созданных в ББ 1.5, записаны в кодировке 1251.
Кажется, можно сделать перекодировщик, аналогичный тому, что для текстов.
А вот со ссылками не придумал ничего, кроме как раскрывать их, перекодировать текст, а потом пересоздавать.

Идиот! Можно было сделать перекодировщик, как и для форм.

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


Конечно, можно просто забить и перекомпилировать исходники. Но хочется совместимости, хотя бы в одну сторону: чтобы стандартные бинарники работали. Ну еще, если все имена попадают в Latin-1, то чтобы бинарники получались стандартными. Сейчас это выполняется только если имена помещаютя в ASCII/

Речь о перекомпиляции не шал, речь шла о тулзе, вроде, или о механизме типа интерфейсных модулей.

Я пытаюсь вытащить из Вашего подсознания все эти вещи:

Да, разумно требовать совместимости в одну сторону.
Но если можно предусмотреть тулзовину для совместимости в обратную сторону, то тоже неплохо.

О перекомпиляции - это я подумал. По сути сейчас ситуация аналогична той, что сложилась с русским ББ1.5.
Вроде бы несовместимость со стандартным не особенно мешает.

Не уверен, что "по сути".

Русский ББ1.5 -- это школьная такая учебная штука.
Особого хода именно как *русский* ББ она не имеет.
Во всяком случае мне об этом не известно.

У-ББ1.6 -- это совсем другая песня.
Глобальная. Потенциально встраивается в комбинации глобального масштаба.
Раcтормозите чуток воображение и помыслите ... ну, хотя бы, Samsung. Так, чисто для примера.

Призываю очень тщательно, не спеша повертеть в голове сценарии для У-ББ1.6.

Вот повертел немножко.

Сначала проблемы нынешнего Блэкбокса.
1. Ссылки. Можно создать ссылку на файл с именем "привет", но при сохранении это имя будет обрезано до "?@825B". Идеального решения, похоже, нет. Можно изменить StdLinks или создать собственную замену, но такие ссылки не будут открываться в стандартном ББ.
Подобные проблемы есть в StdFolds и StdStamps, но это менее актуально.

2. Локализация. Сейчас после установки языка через Dialog.SetLanguage подгружаются соответствующие строковые ресурсы. Кроме того, в командах OpenDoc и т.п. можно ссылаться на документы в зависимости от языка, например 'Docu/*/Views'.
Хотелось бы, чтобы это работало и для меню, сообщений об ошибках. Тем более, что меню уже обновляются при смене языка.

Теперь о возможном "консервативном" расширении.
С компилятором относительно просто: можно сделать кодировку, сохраняющую буквы из Latin-1. Тогда модули можно будет запускать и в стандартном ББ, если интерфейсная часть останется латинской.
А вот дальше - хуже.
В Meta предусмотрена установка раширений, но многие модули используют напрямую Kernel. Большая их часть локализована в Dev, котрую все равно менять. Но вот Kernel.SplitName затрагивает все.
В некоторые модули зашита проверка имен (в русском ББ1.5 там National.IsIdentChar). Тут уж точно без правки не обойтись.
В общем без аналога дельты не обойтись.

Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.

А, собственно, отчего боязнь модификаций базовых модулей каркаса? Или до сих пор уповаем на развитие со стороны OM?

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

Это, в принципе, правильный подход.
Он и в других местах приложим.

Но надо обсуждать: давать списки, что выделить, с сигнатурами etc., и обсуждать.

Но, например,StdCmds ведь все равно вызывает Kernel.SplitName.

И?..

И будет искать модули по-старому, невзирая на нашу собственную SplitName.

А какие другие зависимости остаются от модуля Kernel и в каких модулях?

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

Можно искать сегменты расширенного аски или юникодные, и туда-сюда конвертировать куски с сохранением атрибутов и вьюшек (для вьюшек deep copy).

Конвертация всегда в новое окно.

Расширенный АСКИ может сидеть внутри линков -- имена файлов и заголовки окон.
Преобразование таких скрытых фрагментов пока не предусмотрено, тоже надо как-то с интерактивным контролем это делать.

viewtopic.php?p=71322#p71322 А зачем CESU-8? На будущее, когда в текстах вместо UCS-2 будет UTF-16?

Можно во время преобразования писать в журнал ссылки вида <OpenDoc(original | result); ShowPos(link.context... .Pos())>xxx<>. И контролировать (временный) результат. Мне кажется это проще, нежели ещё тулзу для поиска городить.

http://oberoncore.ru/bbcc/subs/unicode --- тут только выдачу допилить

А что там такого сложного?

Юникод это не "инакоговорящие юзеры", а инакомыслящие.. , это целая алфавитно-цифровая инфраструктура, применений коей несть числа. См. кнопочки:

& VBDOS стиль:

А теперь приложите к этому события и дин. структуры данных.. В плане, значить, "текста как интерфейса"..☝
http://graphemica.com/scripts/common

Не помню, где обсуждался юникод. Если что, прошу перенести туда.
(модератор: прикреплено к существующей теме, 27.02.2014)

Лично я почти созрел для того, чтобы согласиться с предложением Trurl'я насчёт уникодизации Компонентного Паскаля (т.е. разрешение уникодовых идентификаторов) через UTF-8 внутри.

Ведь Java, вроде, разрешает уникод в идентификаторах, нет?

Хотелось бы ещё раз перечислить/уточнить ключевые пункты.

Самый ключевой: совместимость только в одну сторону:

Литерные цепочки, содержащие только чистый АСКИИ, в UTF-8 вида не меняют, отчего BB 1.6U будет принимать бинарники от BB 1.6, но не наоборот.

Прошу дополнить список.

**

Вопрос по длине идентификаторов.
При неизменной длине SHORT-литерных массивов эффективная длина идентификаторов из не-EASCII литер с применением UTF-8 уменьшится вдвое (?).

Насколько серьезные проблемы возникнут при изменении формата внутренних SHORT-литерных массивов?
Или это уже обсуждалось? Пож., дайте ссылку, кто помнит.

А зачем?


Почему именно UTF-8? Внутри же UCS-2.


Java Language Specification, Lexical Structure


нет