Board.KolibriOS.org

А разве нельзя для разных типов разную подсветку задавать?

Если имеется ввиду выделение файлов в разных форматах то это можно.
А если в вопросе имеется ввиду самостоятельное определение программой подключаемого файла синтаксиса в зависимости от расширения открываемого файла, то такого нет. Пользователь сам выбирает подключаемый файл подсветки из списка файлов, сидящих в папке info. При запуске программы подключается файл с именем default.syn.

Описанная ситуация возникла потому что в файле html.syn было задано выделение строк в одинарных кавычках. Если в тексте встречался апостроф то все остальные теги идущие после него воспринимались как строковый параметр, конец такого параметра это тот же самый апостроф. При создании файлов синтаксиса я мог копировать строки из других файлов синтаксиса и в html.syn видимо попала строка в одинарных кавычках из asm-вского синтаксиса.

---

Ситуация когда программа ищет завершающий символ игнорируя при этом все остальные не всегда бывает правильна. По идее программа должна поддерживать выделения по более хитрым шаблонам (регулярным выражениям и т. п.), но я сделал анализ синтаксиса по простому. Есть 2 варианта:
1) [полное совпадение слова]
2) [полное совпадение слова] + [любой набор символов, кроме завершающего символа] + [завершающий символ]
Еще есть параметры, проверяющие символы на краях, чтобы не было ложных выделений.

Сюда ещё надо небольшое расширение: возможность считать удвоенный символ за один. Например, в Паскале строки заключаются в апострофы, но двойной апостроф внутри строки -- апостроф. Возможно, трактовка двойного символа как самого себя есть не во всех синтаксисах, -- нужен флаг.

Да такая недоработка есть, но для паскаля проблемы особой не будет, т. к. в разметке получится что одна строка с точки зрения программы будет выглядеть как 2 строки стоящие рядом. А с точки зрения пользователя все будет выглядеть одним цветом. Но вот в таких языках как C++ строка с кавычкой внутри приведет к неправильному отображению синтаксиса. Например такая строка, вызовет ошибку при отображении текста стоящего после него:

char str[]="111\"222";

В общем для решения подобных проблем нужно изменить файлы синтаксиса и функции из файла t_edit.mac:
1) ted_text_colored - цветовая разметка всего документа
2) ted_text_find_sel_color - выделение найденного ключевого слова
3) ted_iterat_next_pos_char - поиск завершающего символа (при выделении по 2-му варианту)
По идее 1-ю функцию править вообще не прийдется, а 2-ю и 3-ю нужно перестраивать для подобных случаев. Может сделаю если будет возможность.

Для этого надо предусмотреть возможность задать экранирующий символ (escape character). В C++ это будет \.

А учитывается ли случай, когда строка в языке программирования может состоять из нескольких строк, с переводом строки внутри? Такое возможно, например, в SQL.

Я тоже так думал, вот попробовал изменить функцию ted_iterat_next_pos_char с учетом экранирующего символа. Вроде работает нормально, но это не конечный вариант, потому что этот символ должен передаваться в функцию снаружи, а не быть внутри функции:

;input:
; bl = symbol end of select
; edx = pointer to symbol struct
; edi = pointer to tedit struct
;description:
; найти следующую позицию указанного символа
align 4
ted_iterat_next_pos_char:
   push ax
   mov ah,'\' ;экранирующий символ (или 0 если нет проверки на них)
   mov al,1 ;первоначальное значение (любой знак кроме 0 и видимого символа)
   @@:
      cmp bl,byte[edx]
      je .found
      .no_found:
      cmp edx,ted_tex_1
      jle @f
         mov al,byte[edx]
         call ted_iterat_next
         jmp @b
   .found:
      cmp ah,al
      je .no_found
   @@:
   call ted_iterat_next
   pop ax
   ret

Приведи пример такой строки, я не совсем понял о чем идет речь. Подозреваю что скорее всего такого нет.

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

ревизия 2102
В элементе t_edit новый формат файлов синтаксиса. Добавлена возможность задавать подавляющий символ, для более правильного отображения строк. Например в синтаксисе C++ теперь правильно будет выделяться цветом такой текст:

char t1[]="aaa\"bbb";
char t2[]="ccc";

В связи с чем сделаны изменения в библиотеке box_lib.
ревизия 2125
1) исправил глюк с мышей когда окно не активно
2) небольшая оптимизация кода

Обнаружил ошибку, которая при возникает при редактировании открытых файлов, возникает так:
1) открываем файл
2) добавляем текст (минимум 1 символ)
3) отменяем редактирование
4) добавляем текст
В итоге весь текст после добавленого в п. 4 исчезает. Странно также то что на файлах меньших 29 байт это не проявляется. Найти ее в коде и исправить пока не удалось.

В ревизии 2348 поправил ошибку. Пришлось немного изменить 2 функции, которые вызывали глюк. Хотя изменения даже в одной из функций решали проблему.

Я считаю пора этой программе прописаться в ночной сборке. А то всякого игро-демо говна навалом, а полезные программы где то на обочине.

Поддерживаю.

Аналогично, тем более такая функциональность!..

За.

Игорь, а насколько сложно будет вставить более крупный шрифт в основное поле редактора?
- я имею в виду системные шрифты №2 (8х12, уже на подходе), и №4 (10х16, еще за горами)
Или, еще лучше, - предоставить пользователю возможность выбора шрифта.

А то зрение садится - приходится использовать тупой KFARовский редактор.