Добрый день, дорогие пользователи компонента UniHighlighter!

Как часто бывает при длительной разработке каких-то программ или компонентов, сложилась неоднозначная ситуация по поводу новой возможности, добавленной в UniHighlighter 2.0 Beta4. Это возможность хранения в компоненте подсветки UniHighlighter дополнительной произвольной информации (подробнее можно прочитать в теме "Хранение произвольных параметров в подсветке").

А проблема, касающая этой возможности заключается в следующем: одним пользователям эта возможность просто необходима, а другим очень мешает 
Для выхода из положения весь код, который касается этой возможности (CustomData) был заключен в директивы {$IFDEF CUSTOMDATA}...{$ENDIF}, поэтому, чтобы установить компонент БЕЗ этой возможности нужно просто перед установкой закоментировать в файле SynUniHighlighter.inc строчку {$DEFINE CUSTOMDATA}. После этого ни единого упоминания о CustomData в UniHighlighter не останется (ни объявления, ни использования, ни сохранения/загрузки). Это уже, кстати, сделано в UniHighlighter 2.0 Beta4.

Так же в последующих версиях компонента UniHighlighter 2.0 BetaX/Stable эта возможность по умолчанию будет в отключенном состоянии. Так как следующие бета-версии 2.0 нужны в основном для стабилизации компонента и решения проблем совместимости, а не для реализации новых возможностей. Последние будут со временем выложены в действительно новой версии компонента (2.1, 2.2 или может быть еще больше) 

Но что сделать с этой возможностью после стабилизации версии 2.0 компонента?

• включить в официальную сборку, то есть по умолчанию эта возможность будет включена, но ее можно будет отключить (первые два варианта голосования)
• сделать по умолчанию эту возможность отключенной, желающие ее использовать должны будут включить ее с помощью файла SynUniHighlighter.inc (последние два варианта голосования)

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

Собственно я голосую за первый вариант, а Quadr0, скорее всего, за последний 


P.S. Просьба по возможности писать хотя бы небольшие сообщения с написанием пункта, за который Вы проголосовали 
P.P.S Ну а если вы напишите даже причину или объяснение своего голоса, то это будет просто замечательно   

Изменение:
Поправил ссылки, а то форум, почему-то их портит.. 

Это сообщение отредактировал(а) Vitalik - 2.8.2006, 14:32

Собственно, хотелось бы отметить, что использование этой возможности (CustomData) имеет очень большое поле для фантазии. Приведу несколько характерных примеров:

• Как писалось в теме "Хранение произвольных параметров в подсветке" можно хранить в подсветке символы комментариев, характерные для языка подсветки, можно хранить регулярные выражения для доставания переменных и функций из текста.
• Можно хранить какие-то дополнительные шрифтовые или настроечные данные, характерные для подсвечиваемого языка, например, в log-файлах можно было бы задать размер шрифта помельче, а в файлах C# включить умную клавишу Home 
• Можно также хранить такие данные, как например, цвет текста и фона при подсветке парных скобок, или какие-нибудь другие дополнительные цвета, которые можно использовать в СВОЕЙ программе, но которые не являются стандартными для всех случаев жизни (например, цвет выделения строки, содержащей закладку, цвет выделения при потере фокуса у приложения и т.п., и т.д.)

Изменение:
Поправил ссылку, а то форум, почему-то их портит.. 

Это сообщение отредактировал(а) Vitalik - 2.8.2006, 14:34

Значить Виталик меня просил, здесь оставить свои мысли по поводу (и без оного).

Итак мысль первая и самая важная - всех редакторописатетей фтопку! 

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

И, повторяясь, ежели чел хочет на что-то посмотреть в тотале, то пусть нажмет F3, а если хочет поредактировать , то пальцы так и тянуться к F4.

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

Так как из моего велеречивого сообщения не понять как я проголосую, то поясняю, я проголосовал за пункт 1, но как всегда со своими дополнениями .

Только это по идее касается не столько компонента, сколько программ, которые его используют, а если конкретнее то Lister-плагинов к Total Commander'у: Syn и SynPlus   

Если она не сильно мешает, лучше ее по умолчанию включить. А то если выключена, то это ведь равносильно написанию прог которые бы затирали CodeFolding правила в подсветке. CustomData надеюсь перерастет когда нибудь также в стандартизированную структуру, и не будет выглядеть как будто это левые данные чужой программы которые мне совершенно не нужны. =)

На кого это такие грязные намеки? =) После пары лет пользования SynPlus быстро отучаешься нажимать F4. А для тех кто любит просто смотреть уже ведь есть SciLister и т.д. 

Так идея то не нова. Это ж просто сделали как у SciTE было уже давно. Там для каждого языка есть файл в котором лежат и цвета и параметры связанные с языком. И люди не жалуются. А ты хочешь все эти параметры вынуть и в другой файл положить, отдельный?

Чтобы внести небольшую ясность по поводу мнения jasny, процитирую некоторые наши сообщения из аськи 

JASNY: не понял примеров, зачем они нужны 

Vitalik: Подсветка теперь сможет хранить в себе не только собственно правила для подсветки, но что-то еще. При чем это "что-то еще" будет трактовать уже сам разработчик (пользователь компонента) 

JASNY: я почитатель пронципа бритвы оккама
и соответсвенно думаю, что не надо ничего лишнего пихать в подсветку
ты же , как я понимаю собираешься написать движок какой-то - от этого пострадает скорость и ошибкоемкость (о! какое слово ), но зато будет универсально
я правильно тебя понимаю?

Vitalik: Движка как такового нету.. Все это уже работает, скорость (на сколько мне известно) не страдает совершенно 
Но можешь об этом спросить на форуме и я тебе там отвечу, чтобы другие пользователи так тоже не подумали 

JASNY: позволь мне немного примеров зачем тебе хранить еще какие-то произвольные данные?
и кстати для произвольных данных надо хранить их обработку?

Vitalik: Обработка уже будет ВНЕ компонента 
В компоненте - только просто банальное хранение 
Просто это нужно было для SynPlus и для нового плагина Syn 
В Syn используется первый пример, в SynPlus когда-то очень давно хотелось использовать второй 

JASNY: так просто тебя просячт, чтобы ты в файлах подсветки хранил дополнительные данные для других надобностей, типа сделать из файла подстветки своеобразный инишник?
дабы не плодить конфигурационные файлы? тада я за

Vitalik: Ага, ты все правильно понял 

JASNY: гы, счас проголосую

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

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

а насчет грязных намеков.... 

я давным-давно на заре SynPlus-a (или тогда еще был SynEdit) общался с Сергем Черных, тестируя его компонент (кстати мой ник есть даже в ебауте  ) и убеждая не превращать свою dll-ку в редактор. он меня не послушал - ну как бы его право он писатель.

а чисто редакторскиъх возможностей synplus мне не хватает, я им как редактором не пользовался и не собираюсь.

IMHO такие дополнительные данные нужны для многих полезных фич по редактированию текста, например, тот же самый comment/uncomment block of code. Проголосовал за 1.

проголосовал за 1

интересно, а чем эта возможность может мешать?