Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 35

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

фрагмент документа извлекается в буфер и хранится в виде строки

А будет ли это работать, если я ищу регуляркой что-то более длинное, чем одно слово?
Всего голосов 3: ↑3 и ↓0+3
Вы не пробовали реализовать регулярные выражения на чем-нибудь вроде списков Haskel? :)

Нет, не пробовали :)
А будет ли это работать, если я ищу регуляркой что-то более длинное, чем одно слово?

Длина возможного результата будет определятся длиной буфера и величиной смещения буфера. Но тут, конечно, нужно найти компромисс между возможной максимальной длиной результата и скоростью поиска.
Всего голосов 4: ↑4 и ↓0+4
Нужно его сделать еще и «удобным» для конечного пользователя.
… вот только удобным он должен быть не только для конечного пользователя, но и для разработчика, который на его основе будет писать приложение.

Наверное не стоит подстраиваться под абстрактного «конечного пользователя». Если вы делаете продукт в для себя — не стоит перегружать его чем-то, не нужным вам. Не факт, что такие утяжеления пойдут на пользу в том числе и его популярности. А вот у «сделанных для себя» продуктов как правило неплохие шансы. Ведь что пригодилось вам, наверняка пригодится и кому-то другому, не абстрактному.
Конечно если ваши требования и решаемые задачи не эксклюзивно-уникальные. Тогда тем более нет смысла обвешивать профессиональный инструмент паблик-функциями.
Всего голосов 1: ↑0 и ↓1-1
Специфика нашего продукта как раз такова, что мы его делаем не для внутреннего использования, а для разработчиков и стараемся максимально «облегчить им жизнь» :) Поэтому приходится ориентироваться на различные сценарии его использования.
Всего голосов 6: ↑5 и ↓1+4
А вы кто? Не разработчик? :)
Вы — один из представителей целевой аудитории, так что спрашивать себя «как и что делать» вполне разумно.
Всего голосов 2: ↑1 и ↓10
Безусловно, вы правы :) Однако, когда продукт начинают уже использовать и появляется фидбек от пользователей, приходится учитывать и их пожелания.
Всего голосов 3: ↑3 и ↓0+3
С помощью регулярных выражений нельзя разобрать исходный код и обеспечить корректную подсветку.
Всего голосов 4: ↑4 и ↓0+4
Распарсить xml, например, вполне получится.
Всего голосов 5: ↑4 и ↓1+3
не распарсить, а подсветить, конечно :)
Всего голосов 3: ↑2 и ↓1+1
С поддержкой cdata и комментариев?
Всего голосов 4: ↑4 и ↓0+4
Может я чего не понимаю, но что такого страшного в комментариях? Разве выражение типа "" их не найдет?
Комментарий пока не оценивали0
Прошу прощения, 
"<!--.*-->"
— вот это выражение
Всего голосов 4: ↑2 и ↓20
вот конкретно то что вы написали greedy выборка, и она я вас уверяю проглотит много чего лишнего (два комментария подряд сделайте и между ними текст любой). Вам стоит подучить регулярки )
Всего голосов 4: ↑4 и ↓0+4
Может быть. Я не занимался подсветкой синтаксиса, это не входило в мои задачи. Обязательно подучу)
Всего голосов 1: ↑1 и ↓0+1
Ну тогда уже 
"<!--.*?-->"
, иначе оно будет жадное и съест слишком много, вплоть до последнего -->"
Всего голосов 1: ↑1 и ↓0+1
Да, спасибо за поправку)
Всего голосов 1: ↑1 и ↓0+1
Если комментарий вложен в cdata, то логика его обработки должна измениться, и наоборот. И это только xml, а языках программирования намного больше специфики, например, в C# подсветка from, select зависит от контекста.
Всего голосов 4: ↑4 и ↓0+4
Тут я с вами полностью согласен. Подсветка синтаксиса — не основное назначение регулярных выражений. Они подойдут только для простых случаев, что-то типа «ключ=значение».
Всего голосов 1: ↑1 и ↓0+1
Я недавно гуглил «правильное» реглярное выражение для поиска С++ комментариев…
«Правильное» означает, что оно должно справляться с хитрыми ситуациями вроде:

1.

// A comment /*
Code

2.

/* A comment // */ Code

3.

// A Comment \
Still a comment
Code

4.

// A Comment \n
Code

5.

" // String " // A Comment

Ну, и т.д.

Смею Вас заверить, регулярные выражения для подобных ситуаций — это тот еще «матан».

В итоге, комментарии парсятся стейт машиной.
Всего голосов 3: ↑3 и ↓0+3
Охотно Вам верю) Просто встроенный поиск по регулярным выражениям — это единственное, что мы могли предоставить с нашей стороны пользователям, пишущим на основе нашего контрола редакторы языков.
Всего голосов 2: ↑2 и ↓0+2
Для таких случаев правильно средство использовать внешние генераторы парсеров, или языки, которые их поддерживают. Например, в Nemerle генерация парсера по грамматике реализована как библиотека макросов и находиться в такой же шаговой доступности, как и регулярные выражения.
Всего голосов 2: ↑2 и ↓0+2
Расскажите об этом авторам TextMate и бандлов для него :).
Всего голосов 1: ↑1 и ↓0+1
Думаю, они это знают. Реализовать разбор на регулярных выражениях сделать нельзя, так как языки программирования не являются регулярными=) Можно их использовать на этапе лексического анализа, но вся логика разбора будет уровнем выше. Для этих целей лучше использовать полноценные парсеры.
Всего голосов 4: ↑4 и ↓0+4
Для IDE, наверное, регулярки не подойдут, а вот для текстового редактора с подсветкой (как TextMate, например) они очень даже неплохо подходят, судя по количеству бандлов для TextMate и его умению разукрашивать текст даже в весьма непростых случаях (большинство IDE и редакторов для PHP не умели (и некоторые до сих пор не умеют) раскрашивать все части HTML, где находится помесь PHP, HTML, CSS и Javascript).
Всего голосов 2: ↑2 и ↓0+2
Реализовать разбор на регулярных выражениях сделать нельзя, так как языки программирования не являются регулярными

Теоретически — вы правы.
На практике синтаксические возможности современных регулярных выражений намного превышают класс регулярных языков. Например, с помощью backreferences можно построить выражение, которое опишет язык, не относящийся ни к регулярным, ни даже к контекстно-свободным (большинство языков программирования, тем не менее, контекстно-свободные — описываются BNF). Вообще, движок регулярок давно уже никто не реализовывает с помощью ДКА, там давно перебор. Я и не припомню сейчас движок «чистых» регулярок, с ДКА внутри. В Tcl/Tk такое осталось, кажется, но не уверен.
Всего голосов 1: ↑1 и ↓0+1
Величина буфера и смещения зависят от возможной длины результата поиска

Мне кажется, что при таком подходе не сработают просмотр вперёд и назад (positive/negative lookahead/lookbehind), так как возможные условия не будут присутствовать в рассчитанном буфере.
Комментарий пока не оценивали0
Нет, почему же, сработают. Обратите внимание на скриншот формы поиска. Там как раз используется просмотр вперёд и назад для поиска начала параграфа.
Всего голосов 3: ↑3 и ↓0+3
Слона-то я и не приметил. Спасибо
Всего голосов 3: ↑3 и ↓0+3
А что з мак-стайл с таким ужасным сглаживанием?
Комментарий пока не оценивали0
Один из возможных скинов. А что вам не понравилось?
Всего голосов 1: ↑1 и ↓0+1
Может это потому, что картинка 256 цветов? Можно, конечно, сделать цветнее, а смысл?
Всего голосов 2: ↑2 и ↓0+2
Это рабочий скриншот? Галочка выходит за пределы чек бокса, интересно как реализовано.
Всего голосов 1: ↑1 и ↓0+1
Это технология скинения WinForms приложений, используя DevExpress XtraSkins. Там есть галерея, так что если есть желание — можете ознакомиться. ) Вот тут даже более показательный вариант для чекбокса. А вообще практически все UI-элементы могут быть нарисованы, используя различные (офисные, тематические и др.) скины. Вот, например, вариант скинов для Хеллоуина.
Всего голосов 6: ↑6 и ↓0+6
имхо, дайте редактор с возможностью определять синтаксис/подсветку создавая файл в формате yacc/flex.
Комментарий пока не оценивали0
yacc только законченные (правильные) тексты разберет, а подсвечивать надо и неполные конструкции
Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr