Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > SynUniHighlighter и SynEdit > Дальнейшая судьба CustomData (произв. параметры)

Автор: Vitalik 2.8.2006, 13:07

Добрый день, дорогие пользователи компонента UniHighlighter! Как часто бывает при длительной разработке каких-то программ или компонентов, сложилась неоднозначная ситуация по поводу новой возможности, добавленной в http://forum.vingrad.ru/index.php?showtopic=105717. Это возможность хранения в компоненте подсветки UniHighlighter дополнительной произвольной информации (подробнее можно прочитать в теме "http://forum.vingrad.ru/index.php?showtopic=104244"). А проблема, касающая этой возможности заключается в следующем: одним пользователям эта возможность просто необходима, а другим очень мешает  Для выхода из положения весь код, который касается этой возможности (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, 13:52

Собственно, хотелось бы отметить, что использование этой возможности (CustomData) имеет очень большое поле для фантазии. Приведу несколько характерных примеров: Как писалось в теме "http://forum.vingrad.ru/index.php?showtopic=104244" можно хранить в подсветке символы комментариев, характерные для языка подсветки, можно хранить регулярные выражения для доставания переменных и функций из текста. Можно хранить какие-то дополнительные шрифтовые или настроечные данные, характерные для подсвечиваемого языка, например, в log-файлах можно было бы задать размер шрифта помельче, а в файлах C# включить умную клавишу Home  Можно также хранить такие данные, как например, цвет текста и фона при подсветке парных скобок, или какие-нибудь другие дополнительные цвета, которые можно использовать в СВОЕЙ программе, но которые не являются стандартными для всех случаев жизни (например, цвет выделения строки, содержащей закладку, цвет выделения при потере фокуса у приложения и т.п., и т.д.) Изменение: Поправил ссылку, а то форум, почему-то их портит..

Автор: jasny 2.8.2006, 14:45

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

Автор: Vitalik 2.8.2006, 14:59

Цитата(jasny @  2.8.2006,  13:45 ) Я не поддерживаю смесь ужа и ежа и если челу хочется потренироваться в программировании, то путь не пытается пришить свое (безусловно гениальное) творение к листеру коммандера, у которого одно единственное предназначение - просмотр. И, повторяясь, ежели чел хочет на что-то посмотреть в тотале, то пусть нажмет F3, а если хочет поредактировать , то пальцы так и тянуться к F4. Только это по идее касается не столько компонента, сколько программ, которые его используют, а если конкретнее то Lister-плагинов к Total Commander'у: Syn и SynPlus

Автор: Sep. 2.8.2006, 15:11

Если она не сильно мешает, лучше ее по умолчанию включить. А то если выключена, то это ведь равносильно написанию прог которые бы затирали CodeFolding правила в подсветке. CustomData надеюсь перерастет когда нибудь также в стандартизированную структуру, и не будет выглядеть как будто это левые данные чужой программы которые мне совершенно не нужны. =) Цитата Я не поддерживаю смесь ужа и ежа и если челу хочется потренироваться в программировании, то путь не пытается пришить свое (безусловно гениальное) творение к листеру коммандера, у которого одно единственное предназначение - просмотр.  И, повторяясь, ежели чел хочет на что-то посмотреть в тотале, то пусть нажмет F3, а если хочет поредактировать , то пальцы так и тянуться к F4. На кого это такие грязные намеки? =) После пары лет пользования SynPlus быстро отучаешься нажимать F4. А для тех кто любит просто смотреть уже ведь есть SciLister и т.д.  Цитата Итак у нас есть файл, хранящий конфигурационную информацию по подсветке, а надо еще чего настроечного хранить. Надо подумать над единым конфигурационным файлом, который может хранить разнородную конфигурационную информацию, в том числе и информацию по подсветкам. Так идея то не нова. Это ж просто сделали как у SciTE было уже давно. Там для каждого языка есть файл в котором лежат и цвета и параметры связанные с языком. И люди не жалуются. А ты хочешь все эти параметры вынуть и в другой файл положить, отдельный?

Автор: Vitalik 2.8.2006, 15:14

Чтобы внести небольшую ясность по поводу мнения jasny, процитирую некоторые наши сообщения из аськи  JASNY: не понял примеров, зачем они нужны  Vitalik: Подсветка теперь сможет хранить в себе не только собственно правила для подсветки, но что-то еще. При чем это "что-то еще" будет трактовать уже сам разработчик (пользователь компонента)  JASNY: я почитатель пронципа бритвы оккама и соответсвенно думаю, что не надо ничего лишнего пихать в подсветку ты же , как я понимаю собираешься написать движок какой-то - от этого пострадает скорость и ошибкоемкость (о! какое слово ), но зато будет универсально я правильно тебя понимаю? Vitalik: Движка как такового нету.. Все это уже работает, скорость (на сколько мне известно) не страдает совершенно  Но можешь об этом спросить на форуме и я тебе там отвечу, чтобы другие пользователи так тоже не подумали  JASNY: позволь мне немного примеров зачем тебе хранить еще какие-то произвольные данные? и кстати для произвольных данных надо хранить их обработку? Vitalik: Обработка уже будет ВНЕ компонента  В компоненте - только просто банальное хранение  Просто это нужно было для SynPlus и для нового плагина Syn  В Syn используется первый пример, в SynPlus когда-то очень давно хотелось использовать второй  JASNY: так просто тебя просячт, чтобы ты в файлах подсветки хранил дополнительные данные для других надобностей, типа сделать из файла подстветки своеобразный инишник? дабы не плодить конфигурационные файлы? тада я за Vitalik: Ага, ты все правильно понял  JASNY: гы, счас проголосую Vitalik: Просто есть много таких настроек, которые относятся к определенным типам файлов. А если уже есть механизм работы по типам файлов с подсветками, то почему бы с помощью такого же механизма не хранить и другие настройки, а не дублировать этот механизм.. Ага, спасибо )

Автор: jasny 2.8.2006, 15:31

Цитата(Sep. @  2.8.2006,  15:11 ) Так идея то не нова. Это ж просто сделали как у SciTE было уже давно. Там для каждого языка есть файл в котором лежат и цвета и параметры связанные с языком. И люди не жалуются. А ты хочешь все эти параметры вынуть и в другой файл положить, отдельный?  я как раз выступил за CustomData - стандартизированная структура, где каждый может хранить то, что ему заблагорассудиться (например пикантные картинки  ). а насчет грязных намеков....  я давным-давно на заре SynPlus-a (или тогда еще был SynEdit) общался с Сергем Черных, тестируя его компонент (кстати мой ник есть даже в ебауте  ) и убеждая не превращать свою dll-ку в редактор. он меня не послушал - ну как бы его право он писатель. а чисто редакторскиъх возможностей synplus мне не хватает, я им как редактором не пользовался и не собираюсь.

Автор: Sagara 2.8.2006, 16:08

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

Автор: Seldon 4.8.2006, 10:13

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)