Здравствуйте, MasterZiv, Вы писали:

MZ>Что значит система проектов?
MZ>Билд-система -- я сказал, а система проектов, -- это что ?
MZ>Набор файлов, который IDE считает "своими" ?
MZ>Если так, то тоже далеко не везде она есть, система прокетов.
MZ>Например, тот же самый Eclipse -- нету там системы проектов.
MZ>Есть только билд-система.

В Эклипсе как раз полноценная система проектов, как и пологается мегамонстру. Там есть воркспейсы. В них проекты. А папки в проектах могут быть ещё как реальные, так и виртуальные. В общем полная коллекция всего.

Да, и кстати проект — это обычно не что считает "своим". А когда какая-то часть настроек системы делается специфичной под группу файлов. И уж у мегамонстра типа Эклипса настроек под проект естественно миллион. Причём из коробки прямо. А если ещё модулей надобавлять, то....

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, MasterZiv, Вы писали:

MZ>>Что значит система проектов?
MZ>>Билд-система -- я сказал, а система проектов, -- это что ?
MZ>>Набор файлов, который IDE считает "своими" ?
MZ>>Если так, то тоже далеко не везде она есть, система прокетов.
MZ>>Например, тот же самый Eclipse -- нету там системы проектов.
MZ>>Есть только билд-система.

_>В Эклипсе как раз полноценная система проектов, как и пологается мегамонстру. Там есть воркспейсы. В них проекты. А папки в проектах могут быть ещё как реальные, так и виртуальные. В общем полная коллекция всего.

_>Да, и кстати проект — это обычно не что считает "своим". А когда какая-то часть настроек системы делается специфичной под группу файлов. И уж у мегамонстра типа Эклипса настроек под проект естественно миллион. Причём из коробки прямо. А если ещё модулей надобавлять, то....


Кромен настроек билда — какие из этих "миллиона" настроек вы считаете важными?
вот к примеру я пользую на данный момент Netbeans для java проектов и MSVC2010 для С++... Все что я настраиваю в проекте относится к билду.
А в случае с java — там вообще папка с pom.xml считается "своим" проектом — все что нетбинс своего создает это файлы с с моими кастомными правилами запуска. Аля такие то аргументы коммандной строки, такая то директория текущая и тд... Это я даже в свн не добавляю естественно. Проекта как такого нет — полет нормальный. Боюсь что пользователям qmake, cmake, scons вы тоже не объясните зачем нужны эти проекты. Как правило они только мешают своей ограниченностью. делаете к примеру svn mv для файла — и все — проект накрылся — почему? Если я к примеру всего лишь поменял .h на .hpp — и это самый простой и безобидный пример

> В Эклипсе как раз полноценная система проектов, как и пологается мегамонстру.

Ага. Фиг там !
Нет там проектов.
Там проект -- это поддерево каталогов в файловой системе.

> Да, и кстати проект — это обычно не что считает "своим". А когда какая-то часть
> настроек системы делается специфичной под группу файлов. И уж у мегамонстра типа
> Эклипса настроек под проект естественно миллион. Причём из коробки прямо. А если
> ещё модулей надобавлять, то....

Да уж, чего-чего, а настроек в эклипсе -- как у дурака фантиков.

Здравствуйте, Kefir, Вы писали:

PSV>>Это всё понятно. Воспринимаю как крик души...
PSV>>(а я тут новый "недостаток" заметил: в настройках "Caret Shapes" до полноты картины не хватает "рамочки", как в JEdit. Даже боюсь теперь и предлагать ).
K>Ну ты то все равно не будешь пользоваться, так что твой реквест не считается Я посмотрел, мне чтобы добавить рамочку, придется кое что менять (использую CreateSolidCared? надо будет переходить на CreateCaret). Так что пока — фиг с ней .

Я подам жалобу на официальный форум .

K>Вот сделал скриншот — надеюсь теперь будет понятней. Просто для стиля Outlining (Highlighted) надо поставить цвет поярче.

Спасибо, дошло, куда ещё надо смотреть.

K>Удаление я пока не показываю. Я не делаю diff а запоминаю как атрибут строки была ли она модифицирована/сохранена и манипулирую этими данными после undo/redo.

Имхо, этот diff не шибко и нужен. С одной стороны, может быть и приятно, когда там слева всё показывается (кстати, такими же цветами, как в diff-сравнивалке), но с другой, какое-то "попугайство" даже излишне.

PSV>>А что это за фишка такая в NTFS: Alt. File Stream, чё-то раньше не обращал внимание. Куда копнуть? (скорее, я опять туплю в чём-то, от усталости)
K>File Streams и еще тут кое что. Там ничего сложного, тоже чтение/запись в файл но с кое какой магией в именах.

Ага, спасибо. Я уже сам понял, что "протупил".

PSV>>Тут нужен такой эффект: вот после того, как сработал сниппет а-ля TextMate/Sublime, я чего-то поделал, а потом хотелось бы вернуться курсором в той район, где раньше был ввод через сниппет, чего-то клацнуть, и этот сниппет опять заработал, но уже на имеющихся данных, т.е., например, я могу редактировать имя функции/метода, клацнул таб — перелетел на первый параметр, его правлю и т.д. При этом все изменения автоматом корректируются и в JavaDoc для этого метода, т.е. то, что было настроено для некоего сниппета для ввода нового метода. В сниппетах и резиновые табы очень полезны будут. Как-то так. Надеюсь, что более-менее понятно, о чём говорю.
PSV>>Конечно, такой функционал — это уже для спецпарсеров с семантикой, удел настоящих IDE, с рефакторингом и пр. Но можно попробовать оценить, реально или нет для универсального парсера, с настройками для всяких синтаксических сниппетов, добиться похожего функционала.
K>Понятно, типа работа по форме/шаблону. Думается мне — тут работы будет дофига, а будет ли что то юзабельное в конце концов — не ясно.
K>Можно будет глянуть, когда я добавлю множественное выделение/редактирование. Может быть надо будет просто не сбрасывать/запоминать шаблоны после вставки... Хотя их все надо будет пересчитывать, плюс что делать если пользователь кликнет где нибудь мимо шаблона. Те надо будет еще какие то защищенные области вводить.

Да, что-то по мотивам форм/шаблонов. Я как раз и обратил на это внимание, поскольку ты намекал на то, что намечается расширение шаблонов кода по мотивам TextMate.
Я тут сам подумал немного на досуге и, откровенно говоря, даже не могу сообразить, как такой эффект можно сделать. Ведь нужно как-то вычислять эту нужную область, причём могут быть несколько кандидатов-шаблонов на срабатывание, и пользователь, после первичной работы с шаблоном, может изменить контекст (текст внутри нужной области), а затем попытаться снова работать с шаблоном. Под несколькими кандидатами я подразумеваю следующее: в идеале нужно, чтобы я стал курсором куда-то, где раньше работал шаблон, затем клацнул, например, "Ctrl+E Tab" — редактор сам "прокачал", какой здесь нужно запустить шаблон, и я поехал жать tab куда мне нужно, редактировать и т.д. Тут важно ещё корректно разрулить ситуацию, когда редактор может ошибиться, выбрать не тот шаблон для работы, или шаблон может заработать, но поверх ранее видоизмененного для него контекста, т.е. гораздо хуже, если редактор начнёт править данные не так, как нужно, вместо того, чтобы сказать: я не могу догнать, чего от меня нужно.
Скорее всего, для указания форматов внутри шаблона кода уже будет недостаточно одних переменных, способов форматирования или каких-то вычислений (всё это обязательно должно быть). Может потребоваться введение каких-то уже явных синтаксических инструкций, вида "тут ключевое слово такое-то", "здесь начало такой-то синтаксической области", "а тут такая-то Label" и т.д. Это может усложнить написание шаблонов, т.е. они будут не для каждой кухарки.

Короче говоря, маловероятны такие фантазии. Но всё-таки есть смысл, что-то покумекать над этим.

А так, тут, как для обычных Sublime-подобных сниппетов, можно добавить эти резиновые табы, на которые ты обращал внимание. Кстати, в том же JEdit эти "Elastic Tabstop" как-то слабо развиты пока, хотелось бы получше, как минимум, работа не только с явными таб-ами (т.е. и поддержка soft-tab через пробелы, сейчас там этого нет).
Также можно добавить что-то вроде указания для переменных какой использовать автокомплит: где-то из файла, это из такого-то XML, тут из jar-файла, здесь из таблиц в СУБД, и т.д. Как я понимаю, у тебя намечается создание каких-то провайдеров для автокомплита и др. Т.е. создается некий набор API (если его ещё нет), где можно будет ваять разные источники данных и т.п. На основе этого, я так понимаю, есть и идеи прикрутить ctags. Такие разные провайдеры для всяких случаев — реально очень хорошие помощники.

Кстати, так к слову, для ФАР-а есть плагин YAC, который делает хорошее автодополнение по файлам, всяким системным объектам и пр. — неплохо помогает для написания команд и bat-файлов (это кроме автокомплита в самом фаре). Это пример, где можно подсмотреть реализацию такого же провайдера для HE.

PSV>>Вот если посмотреть в Sublime, то можно заметить, что скроллбар фактически дублируется ползунком в мини-мапе.
PSV>>Одним словом, можно объединить мини-мап, Overview Bar, скроллбар в один мега-пупер контрол, который заставит облизываться даже пользователей Sublime. А кнопки вверх/вниз в скроллбаре фактически не нужны.
K>Да действительно, был не прав. Скролит по всему документу. Просто мини изображение только по части документа (попробуй реально большой документ). А overview bar — по всему документу. Те больше соответствует инфо скроллеру.
K>Скролл бар позволяет скролить постранично/построчно с помощью мыши. Если это убрать, народ работающий с мышью будет возмущаться.
K>Так что если делать, совместить не сильно получится, только для небольших документов как то можно. Но пока желания нет . По крайней мере не в 1.50

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

Я почему на это обращаю внимание, вот в JEdit все эти хрени выглядят как-то так:


Тут ещё из-за такой темы для Swing-а и жирный splitter. Конечно, даренному коню в зубы не смотрят, но как-то это "не для имиджа". Было бы лучше, если бы взять Sublime и заменить его скроллбар на что-то типа инфо-скроллера, указанного тобой ранее, где выводились бы чёрточки из overview bar. Причём в этом новом скроллбаре нужен такой же плоский и полупрозрачный индикатор, как в минимапе, что-то по мотивам всяких айфонов, чтобы это всё гармонично выглядело.
Я конечно, понимаю, что тебе в лом возиться с переделкой скроллбаров, даже на уровне OwnerDraw, в любом случае это гемор.


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


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

Здравствуйте, Denys V., Вы писали:

DV>Кромен настроек билда — какие из этих "миллиона" настроек вы считаете важными?
DV>вот к примеру я пользую на данный момент Netbeans для java проектов и MSVC2010 для С++... Все что я настраиваю в проекте относится к билду.
Ну вот касательно Netbeans'а например. У него можно заводить конфигурации различные (чем мы кстати интенсивно пользуемся). Под каждую конфигурацию можно настроить команду построения, команду очистки, команду запуска. Соответственно на тулбаре у нас выпадающий список с конфигурациями. А справа от него кнопки построить, очистить, запустить, отладить. И они действуют в соответствующие с текущим конфигом. Довольно удобно и это как раз следствие системы проектов. Хотя естественно это всё не принципиально и можно без всего этого обойтись. Но раз уж есть, то почему бы не использовать.

И ещё там можно настроить под проект каталоги для анализатора кода. Правда это мы не используем — загнали все библиотеки в общесистемные настройки.

Ну и естественно отображаемые в дереве проекта папки — их же можно настраивать как удобно, а не как отображение реальной структуру каталогов. Например папку со всяким мусором от построения нам же не надо видеть в процессе работы.

DV>А в случае с java — там вообще папка с pom.xml считается "своим" проектом — все что нетбинс своего создает это файлы с с моими кастомными правилами запуска. Аля такие то аргументы коммандной строки, такая то директория текущая и тд... Это я даже в свн не добавляю естественно. Проекта как такого нет — полет нормальный. Боюсь что пользователям qmake, cmake, scons вы тоже не объясните зачем нужны эти проекты. Как правило они только мешают своей ограниченностью. делаете к примеру svn mv для файла — и все — проект накрылся — почему? Если я к примеру всего лишь поменял .h на .hpp — и это самый простой и безобидный пример
Хаха. ))) Мы как раз используем scons для всего. И как раз поэтому (ну точнее это одна из причин) я и ищу "просто мощный редактор" (см. первое сообщение в теме), а не IDE. Но к сожалению пока ни одного редактора поддерживающего подсветку, автокомплит и навигацию уровня монстро-IDE нет. Поэтому и приходится пользоваться ими, хотя нам нужен именно только редактор.

Здравствуйте, MasterZiv, Вы писали:

MZ>Ага. Фиг там !
MZ>Нет там проектов.
MZ>Там проект -- это поддерево каталогов в файловой системе.

Ну может проектов и нет, но зато настроек проекта море...

Здравствуйте, PSV100, Вы писали:

PSV>Здравствуйте, Kefir, Вы писали:

K>>Ну ты то все равно не будешь пользоваться, так что твой реквест не считается Я посмотрел, мне чтобы добавить рамочку, придется кое что менять (использую CreateSolidCared? надо будет переходить на CreateCaret). Так что пока — фиг с ней .
PSV>Я подам жалобу на официальный форум .
Давай У меня еще один аргумент против появился: в этом режиме у меня не будет работать/будет некрасиво Case Caret (когда высота каретки зависит от текущего регистра).

K>>Удаление я пока не показываю. Я не делаю diff а запоминаю как атрибут строки была ли она модифицирована/сохранена и манипулирую этими данными после undo/redo.
PSV>Имхо, этот diff не шибко и нужен. С одной стороны, может быть и приятно, когда там слева всё показывается (кстати, такими же цветами, как в diff-сравнивалке), но с другой, какое-то "попугайство" даже излишне.
Да, такой diff в принципе не сильно полезен. Основная его цель показывать измененные строки — это то что пользователям действительно надо. Видеть что они поменяли в текущей сессии. У меня даже навигация по этим измененным линиям есть.

PSV>Да, что-то по мотивам форм/шаблонов. Я как раз и обратил на это внимание, поскольку ты намекал на то, что намечается расширение шаблонов кода по мотивам TextMate.
PSV>Я тут сам подумал немного на досуге и, откровенно говоря, даже не могу сообразить, как такой эффект можно сделать. Ведь нужно как-то вычислять эту нужную область, причём могут быть несколько кандидатов-шаблонов на срабатывание, и пользователь, после первичной работы с шаблоном, может изменить контекст (текст внутри нужной области), а затем попытаться снова работать с шаблоном. Под несколькими кандидатами я подразумеваю следующее: в идеале нужно, чтобы я стал курсором куда-то, где раньше работал шаблон, затем клацнул, например, "Ctrl+E Tab" — редактор сам "прокачал", какой здесь нужно запустить шаблон, и я поехал жать tab куда мне нужно, редактировать и т.д. Тут важно ещё корректно разрулить ситуацию, когда редактор может ошибиться, выбрать не тот шаблон для работы, или шаблон может заработать, но поверх ранее видоизмененного для него контекста, т.е. гораздо хуже, если редактор начнёт править данные не так, как нужно, вместо того, чтобы сказать: я не могу догнать, чего от меня нужно.
PSV>Скорее всего, для указания форматов внутри шаблона кода уже будет недостаточно одних переменных, способов форматирования или каких-то вычислений (всё это обязательно должно быть). Может потребоваться введение каких-то уже явных синтаксических инструкций, вида "тут ключевое слово такое-то", "здесь начало такой-то синтаксической области", "а тут такая-то Label" и т.д. Это может усложнить написание шаблонов, т.е. они будут не для каждой кухарки.
PSV>Короче говоря, маловероятны такие фантазии. Но всё-таки есть смысл, что-то покумекать над этим.
Я видел нечто подобно для XML комментариев C# в Visual Studio (уже давно, не знаю осталось ли еще). Там область комментариев была как бы блокирована, и показывалась в одном виде а при двойном клике переключалась в другой режим (уже текстовый) и ее можно было редактировать. Область шаблона определялась по неким тегам. Можно было бы сюда копать, но очень будет там много нюансов, так что скорее всего работы будет больше чем пользы Но посмотреть, если мне уже нечего будет делать можно будет

PSV>А так, тут, как для обычных Sublime-подобных сниппетов, можно добавить эти резиновые табы, на которые ты обращал внимание. Кстати, в том же JEdit эти "Elastic Tabstop" как-то слабо развиты пока, хотелось бы получше, как минимум, работа не только с явными таб-ами (т.е. и поддержка soft-tab через пробелы, сейчас там этого нет).
У меня вроде поддержка софт табов есть (если я тебя правильно понял). Я Elastic Tabstops в jEDIT потом заметил, когда тебе написал. Но имплементацию не проверял. Референсная версия по ссылке, что я привел. В НЕ я не делал, но у меня есть кое какие наработки по автоматическим позициям в таких случаях, базируясь на информации с верхних и нижних линий. Но пока динамически не растягивается, как в Elastic Tabstops.

PSV>Также можно добавить что-то вроде указания для переменных какой использовать автокомплит: где-то из файла, это из такого-то XML, тут из jar-файла, здесь из таблиц в СУБД, и т.д. Как я понимаю, у тебя намечается создание каких-то провайдеров для автокомплита и др. Т.е. создается некий набор API (если его ещё нет), где можно будет ваять разные источники данных и т.п. На основе этого, я так понимаю, есть и идеи прикрутить ctags. Такие разные провайдеры для всяких случаев — реально очень хорошие помощники.
Да, я буду делать как плагины, соответственно через API, единственно будет вопрос как потом внутреннюю информация с информацию от плагинов смешивать (теже метки, что сейчас для определения функций используются).

PSV>Кстати, так к слову, для ФАР-а есть плагин YAC, который делает хорошее автодополнение по файлам, всяким системным объектам и пр. — неплохо помогает для написания команд и bat-файлов (это кроме автокомплита в самом фаре). Это пример, где можно подсмотреть реализацию такого же провайдера для HE.
Ага спасибо — запишу себе. У меня уже был запланирован completion для файлов (теже инклуды вставлять), но думал самому все парсить придется.

PSV>Да, ты прав, этот минимап не всегда синхронно работает со скроллбаром, как в больших, так и в малых (не на весь экран) документах. К тому же, ползунок скроллбара хочет частенько менять свою высоту в зависимости от размера текста и соответственно от размера области прокрутки.
PSV>Тут ещё из-за такой темы для Swing-а и жирный splitter. Конечно, даренному коню в зубы не смотрят, но как-то это "не для имиджа". Было бы лучше, если бы взять Sublime и заменить его скроллбар на что-то типа инфо-скроллера, указанного тобой ранее, где выводились бы чёрточки из overview bar. Причём в этом новом скроллбаре нужен такой же плоский и полупрозрачный индикатор, как в минимапе, что-то по мотивам всяких айфонов, чтобы это всё гармонично выглядело.
PSV>Я конечно, понимаю, что тебе в лом возиться с переделкой скроллбаров, даже на уровне OwnerDraw, в любом случае это гемор.

Я когда делал Overview Bar рассматривал вариант рисования на скрол баре, но потом отбросил. С одной стороны — сложнее, с другой стороны, при наложении ползунка (даже прозрачного) поверх информационных блоков — будет мешанина, в которой ничего не понять. И чаще всего, соответственно это будет для текущего "окна", что не очень хорошо (хотя с другой стороны все видно и так, на экране, если документ не большой, но а если большой или длинная строка без переноса?). Плюс к этому — сплит скин. Который добавляет свои проблемы, так как придется дублировать скроллер, он уменьшиться, на нем будет хуже все видно.


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

PSV>>>- вроде для выделений есть режимы Reset/Restore, но как-то они не так работают. Посмотрите опять же на Sublime.
K>>Ну не знаю. Режимом пользуются не часто, но нареканий не было. Я гляну.
PSV>Тут надо одновременно клацать и там и здесь. Пока заметил, что Reset в sublime не всегда сразу всё сбрасывает, как-то он удобнее.
Посмотрел кстати на версию Undo/Redo selection в Sublime. Это все же не тоже самое что и Reset/Restore selection в HE. Оно и называется Soft Undo/Redo. Sublime просто сохраняет в общую историю изменений, наряду с реальными изменениями текста, изменения позиций курсора/выделений (моде еще что). И при отмене, либо пропускает все до изменения текста (если нормальное Undo) либо идет более "мелкими" шагами, включающими и изменения выделений позиций, при Soft Undo. Функция конечно крутая, это да, но работает это только потому что к одному документу привязано только одно представление (в Sublime нет ни split screen ни еще одного вида документа в другом окне — стандартный MFC функционал). А как это забабахать если представлений много и позиции/выделения у них свои — история то общая, в документе.
У меня все эти функции реализованы отдельно (позиции курсора, выделения — правда только последнее ). Перемещения каретки тоже вообще то в документе сохраняется. Че так не помню. Баг наверное, но пока не жаловались — не нашли.

PSV>И раз тут уже вспомнили про интерфейс... Очень хорошо, когда есть возможность настраивать цвета не только для панели с текстом, но и для всего интерфейса редактора, всех панелей. При этом, чтобы одним махом можно было бы быстро переключиться с одной темы на другую, или запустить редактор с нужным ключом. Очень неприятно, когда включена тёмная тема в тексте, а вокруг есть светлые панели.
PSV>Я так понимаю, что тебя MFC сильно ограничивает в этом. Пока в лучшем случае, ты сможешь лишь добавить тему для интерфейса в стиле а-ля офис 2010, если есть обновление для соответствующей библиотеки.
Инвестировать в GUI я не хочу пока. Перееду потом на VS 2011 и перейду на новый MFC, убью свою GUI библиотеку, и от новой MFC уже буду плясать. Все равно все эти екстеншены придется таскать.

PSV>И ещё одно замечание. Я заметил, что в диалоге настроек не все элементы имеют раздел справки (по кнопке-вопросику). Я понимаю, что перед релизом ты будешь рихтовать help. Я обращаю внимание, что есть элементы, которые ссылаются не на свой раздел, ряд контролов указывают на одно и тоже (кто-то не на своё).
Та с помощью там вообще завал Это как раза та неблагодарная работа, неинтересная и за которую деньги не платят. Контекстный help буду править по месту, как будут жаловаться.

Здравствуйте, Kefir, Вы писали:

K>Я видел нечто подобно для XML комментариев C# в Visual Studio (уже давно, не знаю осталось ли еще). Там область комментариев была как бы блокирована, и показывалась в одном виде а при двойном клике переключалась в другой режим (уже текстовый) и ее можно было редактировать. Область шаблона определялась по неким тегам. Можно было бы сюда копать, но очень будет там много нюансов, так что скорее всего работы будет больше чем пользы Но посмотреть, если мне уже нечего будет делать можно будет

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

K>У меня вроде поддержка софт табов есть (если я тебя правильно понял). Я Elastic Tabstops в jEDIT потом заметил, когда тебе написал. Но имплементацию не проверял. Референсная версия по ссылке, что я привел. В НЕ я не делал, но у меня есть кое какие наработки по автоматическим позициям в таких случаях, базируясь на информации с верхних и нижних линий. Но пока динамически не растягивается, как в Elastic Tabstops.
Ну, вроде да, у тебя есть преобразование табов в пробелы, как и в JEdit. А вот эти Elastic Tabstops в JEdit сейчас работают только тогда, когда табы вводятся как есть, без преобразования в пробелы. Поэтому, лично я ими просто не могу пользоваться.
А я больше имел в виду следующее. Неплохо было бы иметь возможность для шаблонов, этих сниппетов, указывать выравнивание по столбцам, т.е. некую виртуальную таблицу, чтобы само выравнивалось, по мотивам этих резиновых табов. А если будет как в org-mode в эмаксе — там и таблицы рисуются, не только виртуальные — вообще шик.

K>Да, я буду делать как плагины, соответственно через API, единственно будет вопрос как потом внутреннюю информация с информацию от плагинов смешивать (теже метки, что сейчас для определения функций используются).

Я не совсем понял, о чём конкретно речь. Вот в JEdit наплодились исторически всякие разные плагины для кучи разных способов и источников данных в рамках автокомплита. В последнее время появилось вполне грамотное решение: можно взять небольшой жабий класс (из плагина-API), переопределить с пяток методов и получить один автокомплит, но я сам подключаю туда свои источники, используя свой код, или подключая программно другие плагины, и т.д. Причём это можно сделать из макроса, не только из бинарного плагина. И ничего сложного, для тех, кому нужно.
И в целом, в JEdit не плохо развиты такие обобщающие средства — есть относительно несложное API, можно накатать свою какую-то обработку текста, включая полноценные парсеры для разбора, и получи сразу и автокомплит, и броузер кода, и списки ошибок и прочих элементов и т.д. — наколенный Эклипс (конечно, сообщество разработчиков, хоть и мизерное, но даёт эффект, одному человеку не под силу всё).

K>Я когда делал Overview Bar рассматривал вариант рисования на скрол баре, но потом отбросил. С одной стороны — сложнее, с другой стороны, при наложении ползунка (даже прозрачного) поверх информационных блоков — будет мешанина, в которой ничего не понять. И чаще всего, соответственно это будет для текущего "окна", что не очень хорошо (хотя с другой стороны все видно и так, на экране, если документ не большой, но а если большой или длинная строка без переноса?). Плюс к этому — сплит скин. Который добавляет свои проблемы, так как придется дублировать скроллер, он уменьшиться, на нем будет хуже все видно.

Понятно. В твоём случае, имхо, если сделать минимап как в Sublime — он нормально впишется, т.к. этот Overview Bar у тебя, как бы, отдельно, не внутри текстовой панели. Скорее всего, ты сам так и планируешь.

K>Посмотрел кстати на версию Undo/Redo selection в Sublime. Это все же не тоже самое что и Reset/Restore selection в HE. Оно и называется Soft Undo/Redo. Sublime просто сохраняет в общую историю изменений, наряду с реальными изменениями текста, изменения позиций курсора/выделений (моде еще что). И при отмене, либо пропускает все до изменения текста (если нормальное Undo) либо идет более "мелкими" шагами, включающими и изменения выделений позиций, при Soft Undo. Функция конечно крутая, это да, но работает это только потому что к одному документу привязано только одно представление (в Sublime нет ни split screen ни еще одного вида документа в другом окне — стандартный MFC функционал). А как это забабахать если представлений много и позиции/выделения у них свои — история то общая, в документе.
K>У меня все эти функции реализованы отдельно (позиции курсора, выделения — правда только последнее ). Перемещения каретки тоже вообще то в документе сохраняется. Че так не помню. Баг наверное, но пока не жаловались — не нашли.
Понятно. Вот что значит, профессиональный взгляд.
Кстати, удобной работы с документами/буферами реально не хватает в том же Sublime, и в HippoEdit тоже, к сожалению. У твоих пользователей это не так востребовано, похоже.

K>Инвестировать в GUI я не хочу пока. Перееду потом на VS 2011 и перейду на новый MFC, убью свою GUI библиотеку, и от новой MFC уже буду плясать. Все равно все эти екстеншены придется таскать.
А сейчас свое расширение работает в интерфейсе, не Codejock какой-нибудь? А новая MFC уже какая-то настраиваемая, по мотивам цветовых тем как в новой студии (я сейчас этими вопросами не занимаюсь) ?

PSV>>И ещё одно замечание. Я заметил, что в диалоге настроек не все элементы имеют раздел справки (по кнопке-вопросику). Я понимаю, что перед релизом ты будешь рихтовать help. Я обращаю внимание, что есть элементы, которые ссылаются не на свой раздел, ряд контролов указывают на одно и тоже (кто-то не на своё).
K>Та с помощью там вообще завал Это как раза та неблагодарная работа, неинтересная и за которую деньги не платят. Контекстный help буду править по месту, как будут жаловаться.
Вот она халтура где

Здравствуйте, PSV100, Вы писали:

PSV>[...]

Дополню по поводу этих супер-сниппетов. Я немного поработал в HippoEdit, и заметил, что есть теоретические шансы что-то сделать в этом направлении. Вот картинка:



Я не разбирался подробно в правилах для синтаксиса, но эти Label и области синтаксиса у тебя отличные штуки. Система вызывает уважение. Вот сейчас курсор находится внутри метода generateParameterReifierCode и вверху показывается имя метода и его корректное определение, как полноценный заголовок синтаксической области (в моём понятии). Если я зайду курсором ниже во внутрь цикла "for", то система вычисляет новую вложенную область и корректно также показывает её заголовок, т.е. расписывает оператор for со всем содержимым в его скобках.
Так вот, можно дальше развить этот механизм, и реализовать правила для организации некоего режима для модификации/перехода по данным, по мотивам сниппетов. Назовём его условно "режим формы".

Например, для "for" уже как-то определено, что его "заголовочная область" находится внутри скобок. Пусть я нахожусь где-то внутри "for", клацнул "Ctrl-E Tab" — включился режим формы, я перелетел на начало цикла, на первое слово внутри скобок. Дальше я могу клацать tab/shift-tab и прыгать по словам внутри скобок, редактировать их, как в сниппетах. При этом, если есть одинаковые слова, например, переменные для цикла, при этом желательно учитывать, чтобы они находились не перед и не после точки (т.е. это не свойства/методы) — это как-то зависит от синтаксиса или как указали для синтаксической области, то сразу работает множественное изменение для этих одинаковых данных.
И таким же образом реализуется режим произвольной "формы ввода" — выделили любой блок (не при множественном выделении) и также внутри прыгаем по словам и можем их редактировать, включая одинаковые слова. Т.е. это нечто того режима, на который я давал когда-то ссылку как пример в IDE Lazarus-а (здесь). Для выше примера с циклом "for" можно сказать, что это частный случай этого универсального режима, только мы явно не выделяем область внутри скобок оператора for.

Дальше. Пусть я переехал курсором выше цикла for, здесь уже область самой функции. Нажимаю "Ctrl-E Tab" — включаю режим формы и курсор прыгает на название метода, табом я прыгаю по именам параметров, типам и т.д. — т.е. внутри заголовка функции. Но при этом одинаковые слова также подсвечиваются и в соседней синтаксической области — JavaDoc-комментарии (имена параметров, сама функция). Т.е. нужно указать в файле-синтаксисе, что эти две области повязаны друг с другом (в этом случае расположены последовательно, так их можно отличать от других областей в тексте, ведь комментариев много, к разным функциям, и возможны другие варианты, когда области могут быть однозначно определены на уровне синтаксиса, например, разделы interface и implementation).
А когда я в самой области JavaDoc-комментария, то, соответственно, одинаковые слова подсвечиваются и в области функции. Но в самой области javadoc я прыгаю не по каждому слову, а по каким-то внутренним содержательным областям (их нужно определять в синтаксисе внутри javadoc): сразу выделяется вся область основного описательного комментария до аннотаций, при этом если я, скажем удалил текст, то внешний вид этого места должен быть корректно перестроен, т.е. должны учитываться отступы, звёздочки в начале строки и прочие префиксы и суффиксы (тут должен сработать другой режим, о котором была речь раньше). Дальше я прыгаю на само слово-аннотацию (т.е. на "@param"), дальше на значение этой аннотации и т.д.

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

private ${2:Type} ${1:field};

/**
 * Getter function for the field $1
 */ 
public $2 get${1=firstUp(s)}() {
    return $1;
}

/**
 * Setter function for the field $1
 */
public void set${1=firstUp(s)}($2 $1){
    this.$1 = $1;
}

Т.е. писать код так: ${number=code}, где в параметре s содержится текст переменной, на которую ссылается эта позиция.
Также можно писать полноценные кодо-шаблоны:

<table>
<# for(i=0; i<=5; i++){ #>
  <tr>
  <# for(j=0; j<=5; j++){ #>
    <td><#= i*j #></td>
  <# } #>
  </tr>
<# } #>
</table>

Но лично мне такая PHP-лапша не нравится. Для таких случаев удобны генераторы кода через прямое программирование, как, например, делает Cog:

// This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
    cog.outl("void %s();" % fn)
]]]*/
//[[[end]]]
...

Что превращается в:

// This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
    cog.outl("void %s();" % fn)
]]]*/
void DoSomething();
void DoAnotherThing();
void DoLastThing();
//[[[end]]]
...

Т.е. лучше полностью самому печатать через out/outl, с нужным контролем всего форматирования, например, всех пробелов. Для сниппетов нужно просто указать код для выполнения, а такое форматирование через "[[...]]]" удобно для генераторов кода в самом тексте исходника. Я писал макрос — клацнул и сразу на месте обновился код (есть ещё возможность указывать контрольные суммы для проверок на предмет обнаружения ручного вмешательства в генерированный код, на сайте Cog есть примеры).

Но это не всё. Вот код:

CREATE TABLE inventory
(
   id          INT IDENTITY(1,1)   PRIMARY KEY,        -- это первичный ключ
   product     VARCHAR(50)         UNIQUE,             -- здесь уникальность
   quantity    INT,
   price       DECIMAL(18,2)                           -- ещё комментарий
);

В типовых этих сниппетах не хватает:

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

— инвариантность ввода. Вот если ввели в позиции слово PRIMARY, значит следующее будет KEY (автоматом добавили). Также нужно указание разных источников автокомплита, включая и элементарные списки (типа встроенные типы SQL);

— необязательность ввода. Пусть в полях ввода при работе сниппета светятся какие-то подсказки, например, влетел я в позицию для ввода, где может быть PRIMARY KEY, здесь может выделенным текстом светится: "PRIM UNIQ CHECK...". Как только я жму буквы — начинается ввод, не хочу — нажал tab и перелетел дальше или тут же на месте "перешли" к воду новой позиции (в зависимости от текущей ситуации с форматированием текста). Дальше, например, мне предлагают ввод комментария, но перед позицией поля ввода уже светится префикс "-- ", я ввожу текст или просто сразу enter — поехали заново подшаблон на новой строке, при этом, если я не ввел комментарий — префикс "-- " убрался;

— автовыравнивание текста. Причём нужны не только столбцы (типа этих резиновых табов), но и "объединение" виртуальных ячеек, разное выравнивание (влево, вправо, по центру, по ширине разбросать), короче говоря, виртуальные таблицы;

— и др. Имхо, направление ясно.

Здесь однозначно нужно делать простое и гибкое API для реализации "режима формы" и сниппетов, которое будет доступно и для текстовых макросов/скриптов. Тогда можно найти компромисс. Что-то дать возможность по простому задать декларативно в шаблонах (например, для виртуальных таблиц: $<tr> $<td> $</td> и т.д.), но "продвинутую" часть будет проще програмлять вручную. Тогда разработчик синтаксиса для языка сможет создать и типовой наборчик крутых сниппетов (кроме обычных), но и остальные, если захотят, тоже повозятся.
И этот же API нужен и для режима формы ввода для синтаксической области. Например, при редактировании заголовка функции, как в примере выше, можно программно корректировать сразу и область JavaDoc, скажем, вписывать там новые "@param ...". И это всё в рамках имеющегося парсера в редакторе, не на основе глобального AST для языка, которое в взрослых IDE.

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

Также, если будет такой функционал, то упростится реализация таких плагинов, как для работы с Zen Coding (имхо, очень вероятно, что тебя уже просили о нём подумать).

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

А вот тот бред, по поводу того, что такой функционал реализовать только через сниппеты — можно выбросить. Я думал так: пусть мы находимся в том цикле "for" — клацнули "включить режим формы", редактор пытается подобрать шаблон по поводу "for", на основе их содержимого, как-то его запустить, с учётом того, что теперь позиции тех же переменных могут не соответствовать тому, что указано в шаблоне, но и т.д. Когда только как бы одна универсальная форма ввода для соответствующей синтаксической области — это вполне реально. И эти формы ввода вполне гармонично должны работать с независимыми сниппетами.


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

Здравствуйте, PSV100, Вы писали:

PSV>Имхо, там, скорее всего, работают спецпарсеры. Я думаю, что ты идею правильно понял: сработал где-то сниппет, повводил я данные, закончил ввод, сниппет как бы отключился. Потом я ушёл в другое место и т.д., потом вернулся назад, что-то здесь подправил, т.е. уже изменил контекст, захотел кайфа — клацнул, а редактор сам догнал, какой нужно включить сниппет, и "пошла жара", или же он (редактор) отказался, вежливо.
PSV>На сколько это реально — мне тяжело сказать. В тех же вимах/эмаксах — сниппеты на уровне Sublime.
Если этого нет в emacs то либо это очень сложно и много языковых нюансов, либо нафиг никому не надо, либо решаеться другими путями.
Я вообще не уверен что сильное расширение движка сниплетов необходимо. Да, в HE еще многих необходимых вещей не хватает, как то tabstops или наборы значений на выбор и множественное изменение. Но встраивать зачатки программирования? Нафиг? Если все это можно сделать через скриптинг, и гораздо более еффективно. Зачем еще один велосипед с перекывающимся функционалом? Может скриптинг для кого то будет сложнее в освоении, но любым инструментом надо учиться пользоваться правильно. И мне, как разработчику меньше гемороя.

K>>У меня вроде поддержка софт табов есть (если я тебя правильно понял). Я Elastic Tabstops в jEDIT потом заметил, когда тебе написал. Но имплементацию не проверял. Референсная версия по ссылке, что я привел. В НЕ я не делал, но у меня есть кое какие наработки по автоматическим позициям в таких случаях, базируясь на информации с верхних и нижних линий. Но пока динамически не растягивается, как в Elastic Tabstops.
PSV>Ну, вроде да, у тебя есть преобразование табов в пробелы, как и в JEdit. А вот эти Elastic Tabstops в JEdit сейчас работают только тогда, когда табы вводятся как есть, без преобразования в пробелы. Поэтому, лично я ими просто не могу пользоваться.
PSV>А я больше имел в виду следующее. Неплохо было бы иметь возможность для шаблонов, этих сниппетов, указывать выравнивание по столбцам, т.е. некую виртуальную таблицу, чтобы само выравнивалось, по мотивам этих резиновых табов. А если будет как в org-mode в эмаксе — там и таблицы рисуются, не только виртуальные — вообще шик.
Было бы круто Если бы у меня на все хватало времени

K>>Да, я буду делать как плагины, соответственно через API, единственно будет вопрос как потом внутреннюю информация с информацию от плагинов смешивать (теже метки, что сейчас для определения функций используются).
PSV>Я не совсем понял, о чём конкретно речь. Вот в JEdit наплодились исторически всякие разные плагины для кучи разных способов и источников данных в рамках автокомплита. В последнее время появилось вполне грамотное решение: можно взять небольшой жабий класс (из плагина-API), переопределить с пяток методов и получить один автокомплит, но я сам подключаю туда свои источники, используя свой код, или подключая программно другие плагины, и т.д. Причём это можно сделать из макроса, не только из бинарного плагина. И ничего сложного, для тех, кому нужно.
PSV>И в целом, в JEdit не плохо развиты такие обобщающие средства — есть относительно несложное API, можно накатать свою какую-то обработку текста, включая полноценные парсеры для разбора, и получи сразу и автокомплит, и броузер кода, и списки ошибок и прочих элементов и т.д. — наколенный Эклипс (конечно, сообщество разработчиков, хоть и мизерное, но даёт эффект, одному человеку не под силу всё).
Возможно информация собираемая редактором и предоставляемая плагином будет дублироваться. Надо заводить правила как разруливать конфликты. Но конечно все решаемо. У меня тоже практически все можно сделать через скриптинг. Без бинарных плагинов. Поэтому я и упоминал "скриптовые плагины". Для AutoComplete пока еще API не добавил.

PSV>Понятно. В твоём случае, имхо, если сделать минимап как в Sublime — он нормально впишется, т.к. этот Overview Bar у тебя, как бы, отдельно, не внутри текстовой панели. Скорее всего, ты сам так и планируешь.
Как я я писал, я его пока не планирую Но да, надо будет как то расширить OverviewBar дополнительной областью.

PSV>Кстати, удобной работы с документами/буферами реально не хватает в том же Sublime, и в HippoEdit тоже, к сожалению. У твоих пользователей это не так востребовано, похоже.
Да, у меня никто не спрашивал. А какие конкретно проблемы решаються этой самой удобной работой с буферами. Пока я только от тебя видел пример с областью в которой собирается autocomplete.

K>>Инвестировать в GUI я не хочу пока. Перееду потом на VS 2011 и перейду на новый MFC, убью свою GUI библиотеку, и от новой MFC уже буду плясать. Все равно все эти екстеншены придется таскать.
PSV>А сейчас свое расширение работает в интерфейсе, не Codejock какой-нибудь? А новая MFC уже какая-то настраиваемая, по мотивам цветовых тем как в новой студии (я сейчас этими вопросами не занимаюсь) ?
Нет, это у меня надстройка над стандартным MFC, тоже на базе одной свободной имплементации с codeproject. Но правда, говно из говна. Я там где надо подточил,кое что переписал, но все равно менять там что-нибудь еще тот геморой.
Да, вроде новая MFC достаточно продвинута. MS просто купила готовое расширение своего старого MFC у BCGSoft и подрихтовала чуток. Но я думаю мне будет достаточно, либо вообще уходить с MFC и все переписывать на кросс платформ.

Здравствуйте, PSV100, Вы писали:

сказать что я все понял — будет неправдой Ну думаю основную мысль я ухватил. Себе записал, буду разбираться, когда займусь усовершенствованием code templates / они же snippets.
Основные вещи что я вынес для себя:
— да, наверное использовать вызовы скриптов из snippets для расширения не плохая идея. Уже было у меня в туду, но теперь еще определенней.
— EasyMotion можно добавить — можно найти не одно применение, и если сделать удобно, будет неплохо. Да и в принципе там работы не много, и логика понятна как мне, так скорее всего и пользователю будет.
— Synchronos edit — неплохо, я уже его давно заметил, когда еще появилось у CodeGear. Это потом его только похоже в SyncEdit перетащили. Не удивительно, и то и то дельфийцы. Тоже хотел добавить — нравится и думаю будет полезно, но опять же упирается в множественное выделение которого еще не сделал.
— неплохо бы добавить такие in-text формы... В принципе у меня можно какие угодно диалоги из скриптов создавать (модальные/немодальные), а это будет как альтернатива, твой режим формы. Раскрытый шаблон, где поля ввода это placeholders в тексте.
— навороченные сниппеты — ну их нафиг. Сделаю необходимое, остальное как скриптовые расширение пусть пользователи пишут если им надо. Работы будет до черта, куча неопределенных сценариев, написать эти сниппеты для всех синтаксисов — у меня ни времени, ни знаний по специфике синтаксиса не хватит. Идея конечно интересная, но сделать что то работающее, для одного человека — это целый релиз работы.

PSV>Я не разбирался подробно в правилах для синтаксиса, но эти Label и области синтаксиса у тебя отличные штуки. Система вызывает уважение. Вот сейчас курсор находится внутри метода generateParameterReifierCode и вверху показывается имя метода и его корректное определение, как полноценный заголовок синтаксической области (в моём понятии). Если я зайду курсором ниже во внутрь цикла "for", то система вычисляет новую вложенную область и корректно также показывает её заголовок, т.е. расписывает оператор for со всем содержимым в его скобках.
PSV>Так вот, можно дальше развить этот механизм, и реализовать правила для организации некоего режима для модификации/перехода по данным, по мотивам сниппетов. Назовём его условно "режим формы".
У меня просто есть регулярное выражение (label), которое привязывается к scope (открывающий закрывающий тег). Много пользы для режима пользы это не принесет — надо будет писать что то свое.

PSV>Например, для "for" уже как-то определено, что его "заголовочная область" находится внутри скобок. Пусть я нахожусь где-то внутри "for", клацнул "Ctrl-E Tab" — включился режим формы, я перелетел на начало цикла, на первое слово внутри скобок. Дальше я могу клацать tab/shift-tab и прыгать по словам внутри скобок, редактировать их, как в сниппетах. При этом, если есть одинаковые слова, например, переменные для цикла, при этом желательно учитывать, чтобы они находились не перед и не после точки (т.е. это не свойства/методы) — это как-то зависит от синтаксиса или как указали для синтаксической области, то сразу работает множественное изменение для этих одинаковых данных.
PSV>И таким же образом реализуется режим произвольной "формы ввода" — выделили любой блок (не при множественном выделении) и также внутри прыгаем по словам и можем их редактировать, включая одинаковые слова. Т.е. это нечто того режима, на который я давал когда-то ссылку как пример в IDE Lazarus-а (здесь). Для выше примера с циклом "for" можно сказать, что это частный случай этого универсального режима, только мы явно не выделяем область внутри скобок оператора for.
Понравилась ссылка на фичи из Lazarus (я в прошлый раз видно пропустил) — неплохо сделали демонстрацию. По поводу шаблонов — это то что я уже написал. Не представляю как можно написать общие синтакс не зависимые правила, ну или пусть частично зависимые, не зная реально грамматики языка (а у меня ее в схемах нет). Можно конечно как то извращаться с регулярками, но думаю, все равно будет убого. Единственный реальный выход — предоставить базовые функции (множественное выделение, табы и тд), и отдать это все синтакс специфичным скриптам.

PSV>Дальше. Пусть я переехал курсором выше цикла for, здесь уже область самой функции. Нажимаю "Ctrl-E Tab" — включаю режим формы и курсор прыгает на название метода, табом я прыгаю по именам параметров, типам и т.д. — т.е. внутри заголовка функции. Но при этом одинаковые слова также подсвечиваются и в соседней синтаксической области — JavaDoc-комментарии (имена параметров, сама функция). Т.е. нужно указать в файле-синтаксисе, что эти две области повязаны друг с другом (в этом случае расположены последовательно, так их можно отличать от других областей в тексте, ведь комментариев много, к разным функциям, и возможны другие варианты, когда области могут быть однозначно определены на уровне синтаксиса, например, разделы interface и implementation).
PSV>А когда я в самой области JavaDoc-комментария, то, соответственно, одинаковые слова подсвечиваются и в области функции. Но в самой области javadoc я прыгаю не по каждому слову, а по каким-то внутренним содержательным областям (их нужно определять в синтаксисе внутри javadoc): сразу выделяется вся область основного описательного комментария до аннотаций, при этом если я, скажем удалил текст, то внешний вид этого места должен быть корректно перестроен, т.е. должны учитываться отступы, звёздочки в начале строки и прочие префиксы и суффиксы (тут должен сработать другой режим, о котором была речь раньше). Дальше я прыгаю на само слово-аннотацию (т.е. на "@param"), дальше на значение этой аннотации и т.д.
Круто Согласен. Ты мне хотя бы правила опиши, чтоб можно было для разных синтаксисов использовать, а я уже запрограммирую — сложно это. В особенности для generic редактора.

PSV>А механизм сниппетов будет сам по себе, но похожий в принципах управления с режимом формы и логически с ним повязан (об этом ниже). Я тут глянул документацию по Sublime и заметил, что там эти сниппеты не очень развиты. Кроме самих переменных, которые могут быть как бы виртуальными (указывать на текущий выделенный текст, результат работы внешней программы и т.д.), слабовато развиты механизмы вычислений, есть какие-то преобразования через регэкспы. В Jedit как-то помощнее, можно писать полноценный код:
PSV>

PSV>private ${2:Type} ${1:field};

PSV>/**
PSV> * Getter function for the field $1
PSV> */ 
PSV>public $2 get${1=firstUp(s)}() {
PSV>    return $1;
PSV>}

PSV>/**
PSV> * Setter function for the field $1
PSV> */
PSV>public void set${1=firstUp(s)}($2 $1){
PSV>    this.$1 = $1;
PSV>}
PSV>

PSV>Т.е. писать код так: ${number=code}, где в параметре s содержится текст переменной, на которую ссылается эта позиция.
PSV>Также можно писать полноценные кодо-шаблоны:
PSV>

PSV><table>
PSV><# for(i=0; i<=5; i++){ #>
PSV>  <tr>
PSV>  <# for(j=0; j<=5; j++){ #>
PSV>    <td><#= i*j #></td>
PSV>  <# } #>
PSV>  </tr>
PSV><# } #>
PSV></table>
PSV>

PSV>Но лично мне такая PHP-лапша не нравится. Для таких случаев удобны генераторы кода через прямое программирование, как, например, делает Cog:
PSV>

PSV>// This is my C++ file.
PSV>...
PSV>/*[[[cog
PSV>import cog
PSV>fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
PSV>for fn in fnames:
PSV>    cog.outl("void %s();" % fn)
PSV>]]]*/
PSV>//[[[end]]]
PSV>...
PSV>

PSV>Что превращается в:
PSV>

PSV>// This is my C++ file.
PSV>...
PSV>/*[[[cog
PSV>import cog
PSV>fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
PSV>for fn in fnames:
PSV>    cog.outl("void %s();" % fn)
PSV>]]]*/
PSV>void DoSomething();
PSV>void DoAnotherThing();
PSV>void DoLastThing();
PSV>//[[[end]]]
PSV>...
PSV>

PSV>Т.е. лучше полностью самому печатать через out/outl, с нужным контролем всего форматирования, например, всех пробелов. Для сниппетов нужно просто указать код для выполнения, а такое форматирование через "[[...]]]" удобно для генераторов кода в самом тексте исходника. Я писал макрос — клацнул и сразу на месте обновился код (есть ещё возможность указывать контрольные суммы для проверок на предмет обнаружения ручного вмешательства в генерированный код, на сайте Cog есть примеры).

Зачем оно все надо, если есть полноценный скриптинг.

PSV>Но это не всё. Вот код:
PSV>

PSV>CREATE TABLE inventory
PSV>(
PSV>   id          INT IDENTITY(1,1)   PRIMARY KEY,        -- это первичный ключ
PSV>   product     VARCHAR(50)         UNIQUE,             -- здесь уникальность
PSV>   quantity    INT,
PSV>   price       DECIMAL(18,2)                           -- ещё комментарий
PSV>);
PSV>

PSV>В типовых этих сниппетах не хватает:

PSV>- повторяемость ввода. Вот здесь как-то можно задать подшаблон для ввода строки с информацией о поле таблицы. Нужен триггер, например, enter — поехали новый ввод (новая строка). Могут потребоваться и другие способы: ввели запятую при наборе параметра функции — перескочили на ввод нового параметра (повторяем подшаблон);

PSV>- инвариантность ввода. Вот если ввели в позиции слово PRIMARY, значит следующее будет KEY (автоматом добавили). Также нужно указание разных источников автокомплита, включая и элементарные списки (типа встроенные типы SQL);

PSV>- необязательность ввода. Пусть в полях ввода при работе сниппета светятся какие-то подсказки, например, влетел я в позицию для ввода, где может быть PRIMARY KEY, здесь может выделенным текстом светится: "PRIM UNIQ CHECK...". Как только я жму буквы — начинается ввод, не хочу — нажал tab и перелетел дальше или тут же на месте "перешли" к воду новой позиции (в зависимости от текущей ситуации с форматированием текста). Дальше, например, мне предлагают ввод комментария, но перед позицией поля ввода уже светится префикс "-- ", я ввожу текст или просто сразу enter — поехали заново подшаблон на новой строке, при этом, если я не ввел комментарий — префикс "-- " убрался;

PSV>- автовыравнивание текста. Причём нужны не только столбцы (типа этих резиновых табов), но и "объединение" виртуальных ячеек, разное выравнивание (влево, вправо, по центру, по ширине разбросать), короче говоря, виртуальные таблицы;

PSV>- и др. Имхо, направление ясно.

PSV>Здесь однозначно нужно делать простое и гибкое API для реализации "режима формы" и сниппетов, которое будет доступно и для текстовых макросов/скриптов. Тогда можно найти компромисс. Что-то дать возможность по простому задать декларативно в шаблонах (например, для виртуальных таблиц: $<tr> $<td> $</td> и т.д.), но "продвинутую" часть будет проще програмлять вручную. Тогда разработчик синтаксиса для языка сможет создать и типовой наборчик крутых сниппетов (кроме обычных), но и остальные, если захотят, тоже повозятся.
PSV>И этот же API нужен и для режима формы ввода для синтаксической области. Например, при редактировании заголовка функции, как в примере выше, можно программно корректировать сразу и область JavaDoc, скажем, вписывать там новые "@param ...". И это всё в рамках имеющегося парсера в редакторе, не на основе глобального AST для языка, которое в взрослых IDE.

PSV>Этот функционал можно связать с быстрыми переходами по мотивам вимператора, о котором говорили раньше. Например, при работе в форме ввода в такой синтаксической области CREATE TABLE (...) я чего-то клацнул, подсветились элементы внутри, ввёл пару букв — перелетел и сразу продолжаем форму ввода. Или при обычной работе я клацнул и включил режим быстрого перехода — перелетел в нужную синтаксическую область (можно подсвечивать только их начало) — и сразу поехал режим формы.

PSV>Также, если будет такой функционал, то упростится реализация таких плагинов, как для работы с Zen Coding (имхо, очень вероятно, что тебя уже просили о нём подумать).
Мне его нефиг делать добавить и сейчас. У меня скрипт плагины (как и бинарные) имею доступ почти ко всему. А здесь всего пару команд зарегистрировать, и читать вставлять текст.

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

PSV>А вот тот бред, по поводу того, что такой функционал реализовать только через сниппеты — можно выбросить. Я думал так: пусть мы находимся в том цикле "for" — клацнули "включить режим формы", редактор пытается подобрать шаблон по поводу "for", на основе их содержимого, как-то его запустить, с учётом того, что теперь позиции тех же переменных могут не соответствовать тому, что указано в шаблоне, но и т.д. Когда только как бы одна универсальная форма ввода для соответствующей синтаксической области — это вполне реально. И эти формы ввода вполне гармонично должны работать с независимыми сниппетами.
Да, в принципе это может быть реально.. Регуляркой выделить placeholders, по правилу определить их соответствие (или по подобию) и перейти в режим формы. Это в принципе мы уже обсуждали, о так сказать постоянных snippets.

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

Кто знает что про Netbeans, проблема запустить его, окоянного, под Unity
(видимо, проблема именно в этом).

Короче, Netbeans 7.1.1, Ubuntu 11.10, Unity -- запускаешь netbeans, --
и всё висит, нетбинс не появляется. Сначала показывается его заставочка,
потом пропадает, и -- всё.
Есть лекарства ?

Здравствуйте, Kefir, Вы писали:

K> [...]

Рад, если удалось свои сумбурные мысли как-то более-менее наконец-то донести попонятней. Да, нужен хороший API для реализаций всяких навороченных режимов редактирования. В тех же эмаксах и вимах есть немало умненьких помогалок, добавлялок, удалялок и пр., реализованных энтузиастами специально для конкретных языков через ручной скриптинг, это особенно приятно, если они соседствуют с мощными функциями полноценной IDE (правда на практике такое счастье в основном для таких языков как Лисп, Хаскель, Эрланг и др.). А универсальные сниппеты везде сделаны по мотивам TextMate, где-то есть свои нюансы, какие-то небольшие плюшки (в принципе, полезно на них глянуть, хотя бы в рамках документации/описания). В некоторых IDE, где есть мощный семантический анализ, могут предоставить дополнительные переменные вида "имя текущего класса", "тип возвращаемого значения из функции" и т.д.

Почему меня, собственно, "пробило" по поводу этих сниппетов/форм ввода. Я иногда, на досуге, обдумываю, как можно сделать удобный для себя гипотетический редактор (который, может быть, когда-то появится в реале). В том числе кумекаю и над интерфейсом в редакторе. Я оцениваю варианты, чем можно заменить, например, в Sublime его такие панели, как для режима поиска. И до меня "дошло", что как раз вместо GUI-панели можно задействовать те же текстовые буферы, где "включить" спец-режим формы ввода для задания условия для поиска. И тогда можно, фактически, реализовать концепцию, например, эмакса: везде одна и та же работа с текстом, везде можно использовать типовые функции для операций с текстом (быстрый поиск, быстрый переход как тот же EasyMotion, чего-то выделить и скопировать и т.д.). Это мощная техника, удачные принципы, очень удобно для работы.
Также по таким мотивам можно реализовать какие-то всплывающие быстрые немодальные диалоги в редакторе при наборе текста около позиции курсора, как окна для автокомплита, но где можно осуществить ввод каких-то данных перед какой-то операцией по генерации кода, какого-то рефакторинга и т.п. (в тяжёлых случаях запросить специальный ввод "yes"). И т.п.
Тогда для кроссплатформенного интерфейса для редактора останется потребность лишь в системном меню и стандартном скроллбаре (ну может какие-то ещё обязательные элементы для Мак-платформы, что-то и в линухе). Остальные элементы — тулбары с кнопками (скорее всего, их можно ликвидировать полностью или заменить "кастомными" для редактора элементами, т.е. нестандартными в системе тулбарами), разделители текстовых панелей, переключение буферов, информационный вывод — это вполне могут быть "фирменные" свои элементы, одинаковые везде, и несложные. Остальной функционал: какие-то таблицы, деревья, ссылки на элементы и картинки (типа какой-то wiki-view) и пр. — всё через стандартный текстовый буфер, со специфичным включенным mode — как в эмаксе.

PSV>>Кстати, удобной работы с документами/буферами реально не хватает в том же Sublime, и в HippoEdit тоже, к сожалению. У твоих пользователей это не так востребовано, похоже.
K>Да, у меня никто не спрашивал. А какие конкретно проблемы решаються этой самой удобной работой с буферами. Пока я только от тебя видел пример с областью в которой собирается autocomplete.
Да, это иногда удобно для автокомплита. Могу также кроме этого вспомнить из личной практики:

— классическое сравнение двух файлов (версий текста), в большинстве случаев это выполняется в режиме включенного diff-а (больше наворотов, чем в JEdit, как-то и не хочется);

— удобно рядом открыть второй буфер с этим же файлом, но в другом месте в тексте, например, подсматривать как реализована функция. Или рядом открыть другой файл и что-то также подсматривать, тут и фолдинг пригодится, если он удобен для этого документа: клацнул — сверни до 2-го уровня — получи список функций, что-то нужное раскрыл, посмотрел, можно что-то виртуально вырезать (narrow-режим) — короче говоря, броузер кода "на коленке" (часто это удобнее и приятнее, чем какое-то GUI-дерево для структуры кода, или когда нет полноценного парсера для документа). Можно макрос забабахать, который будет открывать что нужно и переходить куда надо в зависимости от курсора в тексте. Можно несколько файлов открыть рядом.

Тут рядом на форуме давали ссылку на Light Table. Фактически, его многие фишки из этого Code Bubbles можно реализовать "вручную" (кстати, идея об интерактивной отладке, когда рядом видны все значения для всех элементов прямо сразу в коде и результаты работы — очень интересна, тут кложура, конечно, молодец в этих вопросах).

В виме/эмаксе абсолютно всё открывается как полноправные буферы с текстом, включая и всякие консоли, какие-то автокомплиты для команд и пр. В JEdit чуть другая концепция — там отдельно выделены dock-панели по сторонам для специальных средств, тех же консолей и пр., которые удобно управляются и клавиатурой. Они могут быть и "плавающими", есть и альтернативы, как docking в Нетбинсе, Эклипсе, только это никому особо не нужно. Есть понятие активного текстового буфера, он специально выделяется цветом слева — удобно, например, когда я в консоли, то я сразу вижу, относительно какого буфера будут даваться команды. Теоретически нужен какой-то компромисс между эмакс и JEdit: вместо GUI-панелей в JEdit нужны специализированные текстовые буферы, о которых я говорил выше.

К сожалению, возня в MDI-интерфейсе крайне не удобна, а имеющийся сплитинг в НЕ далеко не всё покрывает (почему именно MDI и пр. в НЕ — совершенно очевидно).

K>>Инвестировать в GUI я не хочу пока. Перееду потом на VS 2011 и перейду на новый MFC, убью свою GUI библиотеку, и от новой MFC уже буду плясать. Все равно все эти екстеншены придется таскать.
PSV>А сейчас свое расширение работает в интерфейсе, не Codejock какой-нибудь? А новая MFC уже какая-то настраиваемая, по мотивам цветовых тем как в новой студии (я сейчас этими вопросами не занимаюсь) ?
K>Нет, это у меня надстройка над стандартным MFC, тоже на базе одной свободной имплементации с codeproject. Но правда, говно из говна. Я там где надо подточил,кое что переписал, но все равно менять там что-нибудь еще тот геморой.
K>Да, вроде новая MFC достаточно продвинута. MS просто купила готовое расширение своего старого MFC у BCGSoft и подрихтовала чуток. Но я думаю мне будет достаточно, либо вообще уходить с MFC и все переписывать на кросс платформ.

Тут позволю себе одну рекомендацию. Вот в Sublime сделали настраиваемый интерфейс, но через какую-то мутную возню со скинами, включая то, что нужно рисовать картинки для темы редактора. В большинстве случаев многих устраивает наличие хотя бы двух тем: светлой и тёмной (например, в серых тонах). Делать какие-то свои темы всем влом. Я в JEdit использую NimROD Look &amp; Feel — это что-то вроде темы для жабского swing-а (с сайта можно скачать его маленький jar-файл, и всякие для него темы, можно запустить этот jar — там есть специальный main-класс для тестирования настроек). Это более-менее вменяемая альтернатива многим "темам" для жабы, где указав всего несколько цветов можно раскрасить интерфейс как угодно. Я, например, задаю жёлтые тона для светлой темы (под Solarized) и синии цвета под тёмную тему (тема Atom для вима). Это пример, как можно реализовать глобальную настройку редактора, не только синтаксическую раскраску.

PSV>>И небольшое замечание. Всё-таки несколько задёрганный индикатор текущей строки в редакторе, когда он прыгает вверх-вниз при прокрутке экрана (при его крайнем положении вверху/внизу и прокрутка через клавиатуру) — как-то портит солидность. Имхо, может быть, есть смысл как-то подправить цикл обработки сообщений, что ли. Но это не страшно.
K>Я, если честно, не понял в чем дело. Вышли мне пример сценарий (или видео), тогда скорее всего поправлю. Я уже много из твоих замечаний поправил, но пока версию не обновил — кое что доделываю. Так что могу успеть поправить в ней же.

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

А пока попробую объяснить. Нужно установить курсор на последнюю строку на экране, с которой начнётся прокрутка текста. Нажимаем один раз "вниз". Экран прокручивается на одну строку, при этом индикатор текущей строки как бы прокрутится вместе с текстом (в этот момент его видно, и есть ощущение, что он как бы прыгнул вверх) и затем тут же прыгнет на строку ниже, т.е. теперь это текущая строка. А если нажать "вниз" и не отпускать, т.е. прокрутить сразу на несколько строк, то на прокрутку каждой строки этот индикатор реагирует также, в результате есть ощущение, что он постоянно прыгает вверх-вниз, в глазах какая-то задёрганность. Это не всегда ярко заметно, имхо, зависит от текста, как работают парсеры, как обновляется инфа вверху по поводу всяких label, вложенных структур и т.д. В том же JEdit этот индикатор текущей строки всегда "как вкопанный", никуда не дёргается.

Всё это мелочи, на которые многие не обратят внимание.

Здравствуйте, alex_public, Вы писали:

_>Да, а мне тут баг встретился — не хочет назначать ассоциации файлов. Ставлю галочки, нажимаю update — окно молча закрывается, но в проводнике никаких изменений... Это потому что бета или нет? )

Обновил бету — вроде все баги отписанные здесь поправил. В том числе поиск по нескольким CHM.

Здравствуйте, Kefir, Вы писали:

K>Обновил бету — вроде все баги отписанные здесь поправил. В том числе поиск по нескольким CHM.

Поставил) Остальные баги/фичи пока не смотрел, а вот про хелп глянул. Всё работает, правда какой-то баг есть. То ли у меня такой chm файл, то ли ещё что... В общем при его открытие появляется ещё одна закладка с путём вида "res://C:\WINDOWS\system32\shdoclc.dll/navcancl.htm#javascript:void(0)". И не появляется она только если нужна страница уже открыта. И при этом ещё исходный файл иногда начинает выглядеть пустым (переключение закладок это исправляет).

Здравствуйте, alex_public, Вы писали:

_>Поставил) Остальные баги/фичи пока не смотрел, а вот про хелп глянул. Всё работает, правда какой-то баг есть. То ли у меня такой chm файл, то ли ещё что... В общем при его открытие появляется ещё одна закладка с путём вида "res://C:\WINDOWS\system32\shdoclc.dll/navcancl.htm#javascript:void(0)". И не появляется она только если нужна страница уже открыта. И при этом ещё исходный файл иногда начинает выглядеть пустым (переключение закладок это исправляет).

То ли у меня такой chm файл
Я думаю страница, которую ты открываешь, содержит java script, который срабатывает на onLoad. Ну или внутри embedded IE у меня по умолчанию отключено выполнение скриптов (я этого не проверял).
То что файл выглядит пустым, это скорее всего появилось окно без тайтл, и поэтому табы не обновились, но окно перекрыло открытый документ. Это наверное баг — можно поправить.
В любом случае, отошли мне chm (на supportbox hippoedit.com) и слово что искал, я проверю. С пустым фреймом скорее всего можно поправить без проблем, а с java script пока не знаю.

Здравствуйте, PSV100, Вы писали:

с "прыганьем" курсора при скролле, я вроде понял. Это у меня скорее всего оптимизация прорисовки, что обновляет позицию каретки только на idle, чтобы уменьшить количество обновлений при скролле. Можно будет это отключить для маленьких документов но оставить для терминальной сессии или больших документов. Поправлю. Версию я уже обновил, но чувствую я, что придется скоро заново обновлять. Бывает падает при выходе.
Для скринкастов вроде инструментов полно, тот же Snagit или Camtasia. Но уже не надо.

С "буферами" я вроде понял, имелось в виду больше взаимное расположение окон документов и их привязка друг к другу (типа синхронный скрол, хотя это только для diff что есть особый случай). Типа группы или варианты расположения как в Sublime. А так mdi + новый вид в новом окне + новый вид в сплиттере у меня уже есть. Может не привычно/не удобно, но "Вам шашечки или ехать"

Light Table я смотрел — да вариант гуи мне понравился. Этакий минимализм, аля гугл или Windows 8 Metro. Но эта тенденция меня пугает — раз богатый пользовательский интерфейс придумывали, значит это было кому то нужно? А то что происходит сейчас это все дань моде. Хотя конечно все базируется на здравых идеях, но скорее всего этого минимализма для программистских задач будет мало, и он всех требований не покроет, либо все будет как в emacs на клавиатуре, и с годом на освоение. Там в комментах подобное мнение тоже есть — хорошо для мини сценария, но будет ли это так же работоспособно/удобно в большом проекте. Другой пример — серая VS2011 с минималистким дизайном — народ тоже не доволен.
В общем, ко всему надо подходить с умом Может если писать что то новое, вариант Light Table не плох и там со временем можно будет решить все проблемы, но переделать существующий проект под его стиль — неблагодарный труд.
А идеи спереть/переработать — это да

On 04/18/2012 01:59 AM, Kefir wrote:

> Обновил бету <http://forum.hippoedit.com/beta-version-test/alpha-1-50/&gt; — вроде

А это тольно Windows ? На GNU перенести нереально ?

Здравствуйте, MasterZiv, Вы писали:

MZ>А это тольно Windows ? На GNU перенести нереально ?

Да, только Windows. Перенести конечно возможно, но не реально
Работы много, и она, скорее всего не отобьется.

Здравствуйте, Kefir, Вы писали:

K>В любом случае, отошли мне chm (на supportbox hippoedit.com) и слово что искал, я проверю. С пустым фреймом скорее всего можно поправить без проблем, а с java script пока не знаю.

Собственно вот https://sourceforge.net/projects/wxwindows/files/2.9.3/wxWidgets-docs-chm-2.9.3.zip/download он. )