Универсальный текстовый редактор

[SiMM]

Ещё один (с сорцами) - <a href='http://scite.ruteam.ru/' target='_blank'>SciTE</a>
Как минус - неочевидный формат конфигурационных файлов
PS: для поддержки кириллицы раскомментируйте character.set=204 + chars.accented в SciTEGlobal.properties, для поддержки вкладок с несколькими открытыми файлами - расскомментируйте свойство buffers, ну и в source.files добавьте *.php

[Vitalik]

[alx]

Идея, конечно, очень интересная! Но ведь всё-равно где-то надо будет хранить как минимум одну настройку: каким настроечным плагином пользоваться
Или я чего-то не понимаю? :huh:

Всё правильно. Но только это весьма особая настройка. В WinXP есть реестр, а есть boot.ini - и в обоих этих местах хранятся настройки. Чтобы не ломать себе голову, для начала можно сделать ограничение: только один плагин реализовывает этот самый интерфейс (как ui.dll в foobar2000 - два юзер интерфеса быть не может). Можно имя выбранного интерфейса хранить в переменных окружения. Короче, нужно думать. Мозговой штурм, или что...

А вот ещё идея. Встроили мы текст по OLE – и с помощью какого-нибудь cfg_ole.dll сохранили какие-нибудь важные настройки.

Этот момент совсем не понял...

Ну, это редкое явление среди текстовых редакторов... Просто в качестве примера привёл. Аналогия на графическом редакторе: через ОЛЕ вставляем из Корела в Ворд векторную картинку; потом редактируем её - Корел открывается как часть Ворда (встраивает свои менюхи и тулбары в интефейс Ворда), и юзер какую-нибудь локальную настройку меняет - дефольтный цвет линии, или ещё чего; и вот эта настройка потом сохраняется вместе с документом внутри Вордовского документа. Вообще очень на cfg_inline.dll похоже. Необходимость - спорная. Это просто пример был.

Или некий cfg_inline.dll умеет читать настройки прямо из файла, который редактируется, как это делают VIM и Emacs:

Это можно, но он же не будет реализовывать интерфейс настроек. Это будет просто обыкновенный плагин, который при загрузке файла, анализирует его содержимое и соответственно меняет настройки редактора. Так ведь? [/QUOTE]
А это уже вопрос чистоты концепции. Почему бы не сделать это плагином, реализующим интерфейс cfg? Ну, он будет немного особый: скорее всего, он будет пытаться прочитать настройки из самого файла, который редактируется, а затем - если в файле конкретно вот это настройки нету - передаст вызов глобальному плагину. А редактору и другим плагинами подсовывается интерфейс cfg_inline.dll - и им даже неинтересно, откуда он берёт настройки. С сохранением могут быть трудности. Но, скорее всего, это останется на совести пользователя - пусть он сам руками нужные настройки в файл засовывает.

Может, сделать несколько типов окно, которые экспортируются плагинами? Например, DOCUMENT (что-то вроде документа по форме и отображению – то же Preview in Internet Explorer), PANEL, TOOLBAR, DIALOG, MODELESSDIALOG, и т.д. И передаётся при этом HWND, т.е. Виндузная структура, и тогда уже не важно, на чём плагин написан – он вставляется в нужное место как окно.

Совсем не понял, что ты имеешь ввиду? :blink:

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

Хм... А по какому принципу "кэшировать"? Только по типу файла, что ли?..

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

(Интересно, что это с кодами случилось?..)

[Vitalik]

<!--QuoteBegin-alx+Feb 13 2005, 19:27--><div class='quotetop'>QUOTE(alx @ Feb 13 2005, 19:27)</div><div class='quotemain'><!--QuoteEBegin-->Короче, нужно думать. Мозговой штурм, или что...<!--QuoteEnd--></div><!--QuoteEEnd-->
Да! Нужно думать! Ребята, подключайтесь! Давайте обсудим этот момент с настраиваемыми настройками!

<!--QuoteBegin-alx+Feb 13 2005, 19:27--><div class='quotetop'>QUOTE(alx @ Feb 13 2005, 19:27)</div><div class='quotemain'><!--QuoteEBegin-->Необходимость - спорная. Это просто пример был.<!--QuoteEnd--></div><!--QuoteEEnd-->
При том, что встравивать OLE врядли можно будет... <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

<!--QuoteBegin-alx+Feb 13 2005, 19:27--><div class='quotetop'>QUOTE(alx @ Feb 13 2005, 19:27)</div><div class='quotemain'><!--QuoteEBegin-->А это уже вопрос чистоты концепции. Почему бы не сделать это плагином, реализующим интерфейс cfg?<!--QuoteEnd--></div><!--QuoteEEnd-->
Как ты предлагаешь реализовать в cfg_inline этот интерфейс?..

<!--QuoteBegin-alx+Feb 13 2005, 19:27--><div class='quotetop'>QUOTE(alx @ Feb 13 2005, 19:27)</div><div class='quotemain'><!--QuoteEBegin-->Примерно следующее:
плагин говорит редактору: "хочу создать окно типа TOOLBAR"
редактор создает (и по ходу дела проверяет, а нет ли случайно каких-нибудь настроек для тулбара с таким именем - положение, видимые/скрытые кнопки) это окно и возвращает плагину хэндл
плагин наполняет окно своими контролами, а также обрабатывает все специфические события (нажатия горячих клавиш, к примеру), оставляя неспецифические события (тягание тулбара из угла в угол, закрытие) ядру редактора (или плагину, который заведует тулбарами, окнами, и т.д.)
<!--QuoteEnd--></div><!--QuoteEEnd-->
Может сделать идеологически примерно как в Far'е для диалогов? То есть сделать своё API для создания элементов на панелях редактора?

<!--QuoteBegin-alx+Feb 13 2005, 19:27--><div class='quotetop'>QUOTE(alx @ Feb 13 2005, 19:27)</div><div class='quotemain'><!--QuoteEBegin-->Когда ядро видит плагин впервые (файл с таким именем и такой датой модификации/создание), оно загружает его и через специальные вызоввы, общие для всех плагинов, спрашивает: как звать? что можешь? какие настройки предоставляешь? Потом ядро эту информацию сохраняет в кэш. При следующей загрузке редактора он из кэша всё узнает, и не будет грузить все плагины подряд, чтобы узнать, а не предоставляет ли такой-то плагин какой-нибудь тулбар важный.
<!--QuoteEnd--></div><!--QuoteEEnd-->
А каким образом (по каким свойствам) ядро будет определять нужно ли грузить плагин или нет? <!--emo&;)-->[img]style_emoticons/<#EMO_DIR#>/wink.gif[/img]<!--endemo-->

[alx]

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->Как ты предлагаешь реализовать в cfg_inline этот интерфейс?..<!--QuoteEnd--></div><!--QuoteEEnd-->
Пожалуй, это стоит оставить до того момента, как будет реализован cfg_ini или cfg_reg - тогда inline можно будет за часок-другой сделать.

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->Может сделать идеологически примерно как в Far'е для диалогов? То есть сделать своё API для создания элементов на панелях редактора?<!--QuoteEnd--></div><!--QuoteEEnd-->
Если вспомнить, что редактор задумывался простым... Или хотя бы вспомнить о сложности построения удобной иерархии контролов... То сразу эта идея перестаёт быть такой уж привлекательной. На одну только эту идею придётся потратить не одну человеконеделю. Не стоит.

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->А каким образом (по каким свойствам) ядро будет определять нужно ли грузить плагин или нет?<!--QuoteEnd--></div><!--QuoteEEnd-->
Нужно запланировать несколько первоочерёдных плагинов/фич, потом на основе этого списка набросать архитектуру, из чего уже почти само логически выльется искомое. Обычно это назвается планированием первого релиза, если не ошибаюсь. Предполагаемое состояние кода - "proof of a concept".

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

[Vitalik]

alx, спасибо за твои быстрые ответы и помощь в идеологическом проектировании этого редактора!

<!--QuoteBegin-alx+Feb 15 2005, 22:20--><div class='quotetop'>QUOTE(alx @ Feb 15 2005, 22:20)</div><div class='quotemain'><!--QuoteEBegin-->Пожалуй, это стоит оставить до того момента, как будет реализован cfg_ini или cfg_reg - тогда inline можно будет за часок-другой сделать.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Еще один момент: в reg и в xml можно сохранять древовидные структуры настроек. А вот в ini как такое сделать? Типа названия секция должны содержать "полный путь" к опции?
Кстати, если настройки делать древовидными, то тогда и интерфейс этих настроечных плагинов должен быть тогда немного другим...

<!--QuoteBegin-alx+Feb 15 2005, 22:20--><div class='quotetop'>QUOTE(alx @ Feb 15 2005, 22:20)</div><div class='quotemain'><!--QuoteEBegin-->Если вспомнить, что редактор задумывался простым... Или хотя бы вспомнить о сложности построения удобной иерархии контролов... То сразу эта идея перестаёт быть такой уж привлекательной. На одну только эту идею придётся потратить не одну человеконеделю. Не стоит.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Дело в том, что для красивой реализации панелей инструментов и "функциональных панелей" <span style='color:gray'>(наподобие в Microsoft Office XP панель слева "Область задач" или справа "Восстановление")</span> я использую дополнительные компоненты ToolBar 2000 и ToolBar XP, которые позволяют очень красиво, безглючно и многофункционально это сделать.
Поэтому допустим, для стандартизации и улучшения интерфейса панелей, и было бы не плохо написать API, которое бы создавало ряд нестандартных компонентов на таких панелях...
Или как вариант можно эти компоненты вынести в runtime-пакет BPL. Но тогда они будут доступны только для плагинов на Delphi и C++Builder...

<!--QuoteBegin-alx+Feb 15 2005, 22:20--><div class='quotetop'>QUOTE(alx @ Feb 15 2005, 22:20)</div><div class='quotemain'><!--QuoteEBegin-->Нужно запланировать несколько первоочерёдных плагинов/фич, потом на основе этого списка набросать архитектуру, из чего уже почти само логически выльется искомое.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Итак, пока что я остановился на следующей логике работы плагина.

Редактор при запуске ищет все плагины и берёт от них нужную информацию <span style='color:gray'>(название, версия, количество команд, перекрываемые команды, позже местоположение в меню и на панели инструментов)</span> вызывая у плагина экспортируемую функцию GetPluginInfo.

Затем редактор передаёт плагинам необходимую для их работы информацию <span style='color:gray'>(дескриптор формы, управляющую функцию Control - о ней напишу ниже, и т.д.)</span> вызывая у плагина экспортируемую функцию SetApplicationInfo.

У плагина есть экспортируемая функция ProcessEvent. При возникновении в редакторе какого-либо события <span style='color:gray'>(например, открытие файла, закрытие программы, ввод текста и т.д. и т.п.)</span> редактор передаёт плагину на обработку это событие вызывая у плагина экспортируемую функцию ProcessEvent с параметром - номером события.

У плагина есть экспортируемая функция ProcessCommand. На вход передаётся номер внутренней команды плагина. При выборе пункта меню, соответствующего этому плагину, вызывается эта экспортируемая функция.

Плагин имеет возможность взаимодействовать с редактором с помощью управляющей функции Control, адрес которой ему передаётся при запуске редактора. С помощью этой функции плагин может запрашивать различную информацию у редактора <span style='color:gray'>(о тексте, о настройках, ...)</span>, а также посылать какие-нибудь управляющие сигналы <span style='color:gray'>(различная модификация текста, изменение настроек, ...)</span>

<!--QuoteBegin-alx+Feb 15 2005, 22:20--><div class='quotetop'>QUOTE(alx @ Feb 15 2005, 22:20)</div><div class='quotemain'><!--QuoteEBegin-->Мне кажется, главное сейчас - нАчать
<!--QuoteEnd--></div><!--QuoteEEnd-->
Значит, давай начнём...
Пока что я составил такой очень приблизительный список событий, которые обрабатывает плагин, и команд, которые он может посылать редактору:

События:
• ET_ACTION_EVENTS - события возникающие при выборе стандартного пункта меню.
  • ET_FILENEW
  • ET_FILEOPEN
  • ET_FILESAVE
  • ET_FILESAVEAS
  • ET_FILEPRINT
  • ET_FILEPAGESETUP
  • ET_FILEEXIT
  • ET_EDITCUT
  • ET_EDITCOPY
  • ET_EDITPASTE
  • ET_EDITFIND
  • ET_EDITFINDNEXT
  • ET_EDITFINDPREV
  • ET_EDITREPLACE
  • ET_FORMATFONT

• ET_OVERRIDE_EVENTS - события, которые плагин может перекрыть
  • ET_GETHIGHLIGHTER
  • ET_LOADINGFILE
  • ET_SAVINGFILE
  • ET_SHOWOPENDIALOG
  • ET_SHOWSAVEDIALOG
  • ET_SAVEREQUEST

• ET_FACT_EVENTS - события, не входящие ни в одну из остальных групп
  • ET_START
  • ET_MODIFIED
  • ET_FILENEW_AFTER <span style='color:gray'>(суффикс _AFTER обозначает, что это событие посылается ПОСЛЕ соответствующей основной обработки события без этого суффикса)</span>
  • ET_FILEOPEN_AFTER
  • ET_FILESAVE_AFTER
  • ET_FILESAVEAS_AFTER
  • ET_FILEPRINT_AFTER
  • ET_FILEPAGESETUP_AFTER
  • ET_FILEEXIT_AFTER
  • ET_EDITCUT_AFTER
  • ET_EDITCOPY_AFTER
  • ET_EDITPASTE_AFTER
  • ET_EDITFIND_AFTER
  • ET_EDITFINDNEXT_AFTER
  • ET_EDITFINDPREV_AFTER
  • ET_EDITREPLACE_AFTER
  • ET_FORMATFONT_AFTER
  • ET_GETHIGHLIGHTER_AFTER
  • ET_LOADINGFILE_AFTER
  • ET_SAVINGFILE_AFTER
  • ET_SHOWOPENDIALOG_AFTER
  • ET_SHOWSAVEDIALOG_AFTER
  • ET_SAVEREQUEST_AFTER

• ET_APP_EVENTS - события от Application
  • ET_ACTIVATE
  • ET_DEACTIVATE
  • ET_HINT
  • ET_MINIMIZE
  • ET_RESTORE

• ET_FORM_EVENTS - события от формы
  • ET_CANRESIZE
  • ET_CLOSE
  • ET_CLOSEQUERY
  • ET_MOUSEWHEEL
  • ET_MOUSEWHEELDOWN
  • ET_MOUSEWHEELUP
  • ET_RESIZE

• ET_EDIT_EVENTS - события от компонента-редактора SynEdit
  • ET_CHANGE
  • ET_CLEARBOOKMARK
  • ET_CLICK
  • ET_CONTEXTHELP
  • ET_DOUBLECLICK
  • ET_DRAGDROP
  • ET_DRAGOVER
  • ET_DROPFILES
  • ET_ENDDRAG
  • ET_ENTER
  • ET_EXIT
  • ET_GUTTERCLICK
  • ET_GUTTERGETTEXT
  • ET_KEYDOWN
  • ET_KEYPRESS
  • ET_KEYUP
  • ET_MOUSECURSOR
  • ET_MOUSEDOWN
  • ET_MOUSEMOVE
  • ET_MOUSEUP
  • ET_PLACEBOOKMARK
  • ET_REPLACETEXT
  • ET_SCROLL
  • ET_SPECIALLINECOLORS
  • ET_STARTDRAG
  • ET_STATUSCHANGED

Ряд из этих событий возможно излишен. Некоторые возможно еще нужно добавить. Если есть вопросы по каким-либо событиям (а они безусловно есть!) задавайте - и давайте обсудим какие события будут нужны, а какие нужно выкинуть!

Команды (их пока меньше, просто еще мало думал на эту тему):
  • CT_GETFILENAME
  • CT_GETFILEEXT
  • CT_GETVALIDFILEEXT
  • CT_GETINIFILENAME
  • CT_GETEXEPATH
  • CT_GETTEXT
  • CT_SETTEXT
  • CT_GETLINE
  • CT_SETLINE
  • CT_INSERTLINE
  • CT_DELETELINE
  • CT_CLEARTEXT
  • CT_GETCARETX
  • CT_SETCARETX
  • CT_GETCARETY
  • CT_SETCARETY
  • CT_GETSELTEXT
  • CT_GETHIGHLIGHTERFILENAME
  • CT_SETSEARCHENGINE
  • CT_GETBLOCKBEGIN
  • CT_SETBLOCKBEGIN
  • CT_GETBLOCKEND
  • CT_SETBLOCKEND
  • CT_GETSELAVAILABLE
  • CT_SEARCHREPLACE
  • CT_GETCURSORSCREENCOORD
  • CT_GETCLIENTRECT
  • CT_GETLINEHEIGHT
  • CT_GETLINELENGTH

Опять же. Это всё очень и очень ориентировочно. Следует сюда добавить команды изменения многочисленных настроек компонента-редактора. Возможно нужно будет добавить возможность "динамического" создания/изменения подсветки... Добавить побольше команд для получения разнообразной информации от редактора. Добавить команды, позволяющие запускать, стандартные действия редактора, а также позволяющие генерировать события...

Из обработки событий и из управляющих действий (команд) как из кирпичков будут строиться все разнообразные плагины. Нужно только продумать до мелочей эти кирпичики... <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

[SiMM]

<!--QuoteBegin-Vitalik+Feb 20 2005, 00:17--><div class='quotetop'>QUOTE(Vitalik @ Feb 20 2005, 00:17)</div><div class='quotemain'><!--QuoteEBegin-->Еще один момент: в reg и в xml можно сохранять древовидные структуры настроек. А вот в ini как такое сделать? Типа названия секция должны содержать "полный путь" к опции?<!--QuoteEnd--></div><!--QuoteEEnd-->Да. На примере одной секции

Код: выделить все

[PHP]
zlib.output_compression = Off

PS: не назвал бы объект, откуда взят пример, удачным - просто то, что под руку подвернулось.

[Vitalik]

<!--QuoteBegin-SiMM+Feb 19 2005, 23:41--><div class='quotetop'>QUOTE(SiMM @ Feb 19 2005, 23:41)</div><div class='quotemain'><!--QuoteEBegin-->Да. На примере одной секции

Код: выделить все

[PHP]
zlib.output_compression = Off


<!--QuoteEnd--></div><!--QuoteEEnd-->Либо так:

Код: выделить все

[PHP.zlib]
output_compression = Off


<!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

Так что по поводу настроечных плагинов? ИМХО, ведь идея всё-таки действительно очень интересная! Где бы так лучше и универсальнее хранить настройку: "каким настроечным плагином пользоваться"? <!--emo&:blink:-->[img]style_emoticons/<#EMO_DIR#>/blink.gif[/img]<!--endemo-->

Кстати, я так подумал, что можно сделать также отдельные плагины для считывания "файлов", содержащих структуру меню и панели(ей) инструментов.

А также в будущем возможно и для "файла" перевода... <!--emo&:rolleyes:-->[img]style_emoticons/<#EMO_DIR#>/rolleyes.gif[/img]<!--endemo-->

А возможно окажется более логичным все эти настройки (обычные, меню, перевод) читать ТОЛЬКО посредством единственного настроечного плагина.... <!--emo&B)-->[img]style_emoticons/<#EMO_DIR#>/cool.gif[/img]<!--endemo-->

Теперь по поводу системы плагинового API. Тот список событий и команд, который я написал выше, это просто то, что временно реализованно на данный момент.
Что вы думаете по поводу самой "идеи"? Давайте продумаем логичный и правильный набор команд и событий для плагинов? <!--emo&;)-->[img]style_emoticons/<#EMO_DIR#>/wink.gif[/img]<!--endemo-->

[Vitalik]

Есть ли желающие помочь в написании плагинов для редактора?

Дело в том, что я немного зациклился на том, как бы лучше сделать плагиновую систему, и поэтому процесс разработки несколько затормозился...

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

Очень надеюсь на вашу помощь!

[Vitalik]

Всем привет!

Я всё-таки решил выложить сейчас хоть что-то сколько-нибудь работающее.

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

Вот ссылки для скачивания:
• <span style='color:blue'><a href='http://www.unihighlighter.com/files/SynNotepad/SynNotepad.rar' target='_blank'>www.unihighlighter.com/files/SynNotepad/SynNotepad.rar</a></span> (258k) - собственно сам редактор, который я временно назвал SynNotepad. Помогите подобрать более подходящее название! <!--emo&:unsure:-->[img]style_emoticons/<#EMO_DIR#>/unsure.gif[/img]<!--endemo-->

• <span style='color:blue'><a href='http://www.unihighlighter.com/files/SynNotepad/vcl70.rar' target='_blank'>www.unihighlighter.com/files/SynNotepad/vcl70.rar</a></span> (397k) - это собственно та самая пресловутая библиотечка VCL, входящая в состав Delphi. Её нужно скопировать в папку Windows\System32. Если у вас стоит Delphi 7, то можете не качать эту библиотеку.

• <span style='color:blue'><a href='http://www.unihighlighter.com/files/SynNotepad/Plugins.rar' target='_blank'>www.unihighlighter.com/files/SynNotepad/Plugins.rar</a></span> (198k) - небольшой набор полезных (и не очень) плагинов:
• Brackets - плагин, производящий подсветку парных скобок при подходе к ним текстового курсора. Работает в случае использования подсветки.
• FindReplace - плагин, заменяющий стандартный механизм поиска/замены на более продвинутый.
• HighlightChooser - плагин, выбирающий в зависимости от открываемого файла нужную подсветку для него
• HighlightDesigner - плагин, позволяющий редактировать текущую подсветку.
• SampleBold - простой пример плагина, вставляющего теги <B> и </B>
• Template - просто пример-пустышка для начала написания плагинов на Delphi и C++Builder

Буду очень рад, если будут желающие помочь в написании плагинов для редактора. Плагиновое API еще не достаточно продумано, поэтому если плагины будут писаться активнее, можно будет быстрее развить необходимое плагиновое API.

Напишите здесь ваше мнение о еще довольно сыром редакторе (версия 0.4.1.0)! (<!--emo&:ph34r:-->[img]style_emoticons/<#EMO_DIR#>/ph34r.gif[/img]<!--endemo-->)

Спасибо за внимание! <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

[Миша Спларов]

2Vitalik
Он хочет ещё rtl70 для работы.

[Миша Спларов]

Нашёл на фтп местном. Кинул в system32 всё заработало.
Замечания: не получается выделить всю строку несколькими щелчками мыши. Выделяется только одно слово. Затем. На панель инструментов вынести отключение/включение подсветки. Затем туда же вынести wordwrap (перенос по словам). Затем нужно сделать историю файлов которые я открывал. Затем какие-то неавтоматические (по запросу пользователя) встраиватели в винду (ассоциация с типами файлов, реассоциация (обратно вернуть), встраивание в контексное меню пункта "открыть в SynNotepad" (также обратная функция для убирания пункта)). Затем опционально: делать отступ или нет, пробелы/табы (а также количество). Что у нас с кодировками?.. Вроде всё. Извинияюсь что в одной строке - читать неудобно...

[maxovt]

<a href='http://jenprog.narod.ru/files/rtl70.zip' target='_blank'>Скачать rtl70.bpl</a> (311 KB).

[Vitalik]

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:34--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:34)</div><div class='quotemain'><!--QuoteEBegin-->Он хочет ещё rtl70 для работы.<!--QuoteEnd--></div><!--QuoteEEnd-->
Странно... <!--emo&:(-->[img]style_emoticons/<#EMO_DIR#>/sad.gif[/img]<!--endemo--> В качестве пакетов времени выполнения я использовал только vcl70... Ну что ж? Тогда будем выкладывать и rtl70 вместе с vcl70 <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo--> Спасибо!

Архив содержащий и vcl70.bpl и rtl70.bpl можно скачать здесь: <a href='http://www.unihighlighter.com/files/SynNotepad/vclrtl70.rar' target='_blank'>www.unihighlighter.com/files/SynNotepad/vclrtl70.rar</a> (630k)

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->не получается выделить всю строку несколькими щелчками мыши. Выделяется только одно слово.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Для этого я думаю стоит написать отдельный плагин. Он будет отлавливать двойное нажатие, и если с каким-то интервалом был еще один щелчёк мыши - то тогда будет выделять всю строку. Угу?

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->На панель инструментов вынести отключение/включение подсветки.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Да, вещь полезная. Нужно в редакторе отдельно реализовать такую возможность. И потом добавить эту кнопку как плагин?

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Затем туда же вынести wordwrap (перенос по словам).
<!--QuoteEnd--></div><!--QuoteEEnd-->
Хм... Может просто потом сделать возможность опциональной настройки панели инструментов?
Не знаю стандартного значка для кнопки переноса слов...

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Затем нужно сделать историю файлов которые я открывал.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Это со временем можно будет сделать ввиде плагина... Надо лишь будет дать ему возможность создавать своё меню с подпунктами либо просто несколько пунктов в нужном месте...

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Затем какие-то неавтоматические (по запросу пользователя) встраиватели в винду (ассоциация с типами файлов, реассоциация (обратно вернуть), встраивание в контексное меню пункта "открыть в SynNotepad" (также обратная функция для убирания пункта))
<!--QuoteEnd--></div><!--QuoteEEnd-->
Это, я думаю, по-любому нужно доверить плагинам. Худо-бедно реализовать и встроить можно даже сейчас - отдельными пунктами в меню Плагины. Но я планирую со временем сделать настраиваемым местоположение плагинов в главном меню (а потом и на панели инструментов, а потом и на разных панелях инструментов)

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Затем опционально: делать отступ или нет, пробелы/табы (а также количество).
<!--QuoteEnd--></div><!--QuoteEEnd-->
Будет реализовано в редакторе с возможностью использования из плагинов...

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Что у нас с кодировками?..
<!--QuoteEnd--></div><!--QuoteEEnd-->
Пока что ничего. Я думаю перекодирование можно банально сделать "матрицами преобразования", то есть просто поставить в сответствие каждому символу одной кодировки соответствующий символ другой кодировки?
Со временем можно даже сделать плагин, заменяющий стандартное открытие файла на открытие в нужной кодировке <!--emo&:)-->[img]style_emoticons/<#EMO_DIR#>/smile.gif[/img]<!--endemo-->

<!--QuoteBegin-Миша Спларов+Mar 28 2005, 21:52--><div class='quotetop'>QUOTE(Миша Спларов @ Mar 28 2005, 21:52)</div><div class='quotemain'><!--QuoteEBegin-->Вроде всё. Извинияюсь что в одной строке - читать неудобно...
<!--QuoteEnd--></div><!--QuoteEEnd-->
Спасибо за пожелания! Они будут направлять дальнейшую разработку редактора.

[Arvur]

2Vitalik
я конешшно дико извиняюсь... но, не есть ли это изобретение велосипеда?
сейчас буду объясняцца <!--emo&B)-->[img]style_emoticons/<#EMO_DIR#>/cool.gif[/img]<!--endemo-->

1. момент номер раз - с использованием Delphi да еще и Toolbar2000 - легкий и шустрый редактор врядли возможен вобще. Писать такие вещи нужно как минимум на FreePascal или Delphi + KOL. И никаких VCL <!--emo&:lol:-->[img]style_emoticons/<#EMO_DIR#>/laugh.gif[/img]<!--endemo-->
2. момент номер два - как уже правильно было замечено, попыток таких крайне много и может быть проще довести до ума что-нить уже существующее?
2a. Более того, неудачно опущеный здесь кем-то SciTE является всего лишь демкой одного из лучших и имхо самого гибкого движка для редактора (Scintilla). На нем, кстати, сделано очень много приличных редакторов. Существуют и интерфейсы для паскаля.
3. Я много лет просидел на Aditor'е и отказался от него из-за отсутствия поддержки юникода. Перед "отказом" просмотрел очень много редакторов и был достаточно придирчив <!--emo&;)-->[img]style_emoticons/<#EMO_DIR#>/wink.gif[/img]<!--endemo--> Сейчас попробую поделиться итогами.
3a. Основные критерии - я привык в Адиторе к MDI, подсветке и нормальной работе с кодировками. Далее - на сегодняшний день редактор без поддержки юникода нежизнеспособен. Поддержка плагинов приветствуется.
3b. Уточню про юникод - подавляющее большинство редакторов - фальшивки. Нормальная поддержка юникода предполагает отображение текстов c 3-мя и более языками. При этом реально такую возможность (не считая notepad) я увидел только у двух(!) движков - один из них как раз Scintilla. о втором чуть ниже. Все остальные преобразуют юникод в обычный текст и отображают его шрифтом с двумя наборами символов (напр. кирилица).
3c. Файл с примером текста на трех языках готов предоставить
4. Выбирал редактор я уже давно, многое забылось. Что вспомню - напишу. Итак, в процессе отбора встретились весьма приличные, но малоизвестные, вещи
- <a href='http://www.mibprogs.nm.ru/mibeditor/index.dhtml' target='_blank'>MiBEditor</a> симпатичный, но уж больно тяжеловат. C юникодом беда
- <a href='http://www.flos-freeware.ch/notepad2.html' target='_blank'>Notepad2</a> Наоборот слишком простенький, но легкий и шустрый. Нет MDI. Движок от scintilla = юникод в норме.
- <a href='http://www.rulnote.udmlink.ru/' target='_blank'>RulNote</a> Позабавил интерфейс. Кто пишет на Delphi - поймет Как редактор приятен, но звезд с неба не хватал
- <a href='http://www.textpad.com' target='_blank'>TextPad</a> Громоздкий, но умеет почти все. Вроде даже и юникод был.
- UniRed и SciTE здесь уже вроде бы упоминались...
5. А теперь имхо бесспорный лидер - <a href='http://emeditor.com/' target='_blank'>EmEditor!</a>
Рекламой заниматься не буду, про все фичи можно почитать на сайте. Поддерживает плагины, есть MDI, правильно работает с юникодом(!), что не маловажно - не смотря на платность, легко доступен Я остановился именно на нем и пока ни разу не пожалел. Как минус можно засчитать - много настроек, один раз под себя придется возиться и настраивать. Вобщем предлагаю всем качнуть и посмотреть, оно того стоит имхо.

З.Ы. Приаттачил файл с тремя языками
[attachmentid=617]