Должны правильно подсвечиваться все конструкции языка, кроме идентификаторов типов: сейчас лексер просто угадывает вид идентификатора.
В следующих сериях : навигация, перекрестные ссылки, ссылки на данные из System.Reflection — то есть фичи, для которых код нужно не только парсить, но и типизировать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну для первого нужно иметь студию, для второго — офис. Офис нахяву вообще никак, студия практически тоже. Да и не все под виндой сидят.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>А нельзя подсвечивать квази-цитаты так же как в интеграции, добавление серого фона?
C>Уже. Одной строчкой в CSS. Я экспериментировал с прозрачностью, чтобы было видно цитаты в цитатах.
Совсем чуть-чуть не хватает.
def x = <[
decl:
1
]>;
def x = <[
parameter:
1
]>;
Такой префикс называется «типом цитирования». Вот полный список типов цитирования:
* decl – декларация верхнего уровня. Тип или член типа.
* fundecl – декларация локальной функции.
* case – вхождение оператора match.
* parameter – описание параметра функции.
* ttype – «типизированная» ссылка на тип. При его использовании цитата должна содержать ссылку на тип. Допустима частичная квалификация (с учетом открытых в месте объявления пространств имен).
Здравствуйте, catbert, Вы писали:
C>Бледно выглядит код, помещенный в квазицитату. В вашем примере несбалансированная скобка помещает в квазицитату весь код дальше её самой.
А нельзя подсвечивать квази-цитаты так же как в интеграции, добавление серого фона?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>Ну, это же демка, оптимизировать её нету смысла.
Как сказать. Если добавить кнопочку "Скопировать HTML" для сгенерированного кода, то и в таком виде весьма полезно. Например, если надо в какой-нибудь блог вставить раскрашенный код на Немерле.
Здравствуйте, VladD2, Вы писали:
VD>Для этого можно воспользоваться: VD>1. Интеграцией и студией. VD>2. Авторинш-паком. В нем тоже есть подсветка для Немерла.
Ну для первого нужно иметь студию, для второго — офис. Офис нахяву вообще никак, студия практически тоже. Да и не все под виндой сидят.
Здравствуйте, catbert, Вы писали:
C>Демонстрация по ссылке (хостится прямо на моем компьютере, потому время от времени может быть офлайн):
C>www.catbert.co.cc/code
Видимо таки сейчас офлайн.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>Демонстрация по ссылке (хостится прямо на моем компьютере, потому время от времени может быть офлайн): C>www.catbert.co.cc/code
Здравствуйте, Воронков Василий, Вы писали:
C>>Демонстрация по ссылке (хостится прямо на моем компьютере, потому время от времени может быть офлайн): C>>www.catbert.co.cc/code
ВВ>По ходу оффлайн прямо сейчас.
Опубликовал и скрылся
Правда сейчас ответ появился, но он "Bad Request (Invalid Hostname)".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>К тому же без проекта типы правильно не подсветить. Плюс строки не подсвечиваются.
Проект уже есть, вот только от проекта до подсветки типов неблизко.
Строки подсвечиваются, и обычные, и рекурсивные, но вот заметить коричневый цвет на синем фоне сложно
VD>Что до клюков, то попытка залить туда код приведенный ниже привела к "Server Error in '/code' Application.".
Глюк я уже поправил: ASP очень уж заботился о защите кода от XSS
Здравствуйте, catbert, Вы писали:
C>Проект уже есть, вот только от проекта до подсветки типов неблизко.
Мне кажется самым правильным подходом для такого как у тебя решения было бы сделать плагин к компилятору, который после завершения компиляции прошелся бы по конечному АСТ и собрал бы всю необходимую информацию для подсветки типов и генерации перекрестных ссылок.
Интеграции нужно работать быстро, по этому она делает множество "приседаний". В твоем же случае можно спокойно дождаться окончания компиляции и пройтись по готовым структрам.
Кстати, интеграция пока что не может работать с проектом компилятора. Если бы твой код смог сгенерировать перекрестные ссылки для кода компилятора, то это очень помогло бы развитию самого компилятора, так как навигация по коду компилятора сильно упростилась бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Кстати, интеграция пока что не может работать с проектом компилятора. Если бы твой код смог сгенерировать перекрестные ссылки для кода компилятора, то это очень помогло бы развитию самого компилятора, так как навигация по коду компилятора сильно упростилась бы.
В SharpDevelop точно работает Class View, правда без наследований, никак не соберусь их прикрутить.
Здравствуйте, hardcase, Вы писали:
VD>>Кстати, интеграция пока что не может работать с проектом компилятора. Если бы твой код смог сгенерировать перекрестные ссылки для кода компилятора, то это очень помогло бы развитию самого компилятора, так как навигация по коду компилятора сильно упростилась бы. H>В SharpDevelop точно работает Class View, правда без наследований, никак не соберусь их прикрутить.
А как это связано с Class View? AFAIR Class View и навигация начинают работать в #D, когда ты реализуешь их интерфейсик (что-то типа IParser), который конвертит AST в CodeDom. Но там не совсем та навигация, о которой речь. Для Class View, собственно, и типизация-то не нужна. Навигации же хотелось бы такой же, как в том же Рефлекторе — т.е. внутри тел методов по коду.
Здравствуйте, VladD2, Вы писали:
VD>Понял. Не подсвечиваются $-строки. Например: VD>
VD> Message.Error(tok.Location, $"expected keyword $keywordName but found '$tok'");
VD>
Пофиксил, в связи с чем вопрос. Есть какая-то вменяемая причина, почему LooseGroup не сохраняет список своих токенов в list[Token], а лишь первый из них?
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется самым правильным подходом для такого как у тебя решения было бы сделать плагин к компилятору, который после завершения компиляции прошелся бы по конечному АСТ и собрал бы всю необходимую информацию для подсветки типов и генерации перекрестных ссылок.
Приблизительно в этом направлении я работаю. Но мне кажется, можно сделать универсальную "карту" символов для любого языка, чтобы браузер кода работал не только в Nemerle (ну, в стиле PDB).
VD>Кстати, интеграция пока что не может работать с проектом компилятора. Если бы твой код смог сгенерировать перекрестные ссылки для кода компилятора, то это очень помогло бы развитию самого компилятора, так как навигация по коду компилятора сильно упростилась бы.
Ну, учитывая то, что:
VD>Интеграции нужно работать быстро, по этому она делает множество "приседаний". В твоем же случае можно спокойно дождаться окончания компиляции и пройтись по готовым структрам.
не знаю, будет ли мое «спокойное» решение полезно для «быстрой» интеграции.
Здравствуйте, catbert, Вы писали:
C>Пофиксил, в связи с чем вопрос. Есть какая-то вменяемая причина, почему LooseGroup не сохраняет список своих токенов в list[Token], а лишь первый из них?
Нет. Можешь поправить, если нужно. Только тесты все прогони перед комитом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как это связано с Class View? AFAIR Class View и навигация начинают работать в #D, когда ты реализуешь их интерфейсик (что-то типа IParser), который конвертит AST в CodeDom.
Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению).
ВВ>Но там не совсем та навигация, о которой речь. Для Class View, собственно, и типизация-то не нужна. Навигации же хотелось бы такой же, как в том же Рефлекторе — т.е. внутри тел методов по коду.
Это да. В студии она работает (с ошибками, пока). Но в студии не грузится проект компилятора. Надо посидеть над этим делом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это да. В студии она работает (с ошибками, пока). Но в студии не грузится проект компилятора. Надо посидеть над этим делом.
А я-то сперва думал что запрос на тултип в исходниках компилятора сносил бошку SharpDevelop по моей вине.
Здравствуйте, VladD2, Вы писали:
VD>Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению).
Насколько я помню, там IParser использовался для фолдинга и Класс-вью. Собственно, и все. А для Класс-Вью зачем типизация?
ВВ>>Но там не совсем та навигация, о которой речь. Для Class View, собственно, и типизация-то не нужна. Навигации же хотелось бы такой же, как в том же Рефлекторе — т.е. внутри тел методов по коду. VD>Это да. В студии она работает (с ошибками, пока). Но в студии не грузится проект компилятора. Надо посидеть над этим делом.
С самим проектом компилятора нельзя работать из студии?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению).
ВВ>Насколько я помню, там IParser использовался для фолдинга и Класс-вью. Собственно, и все. А для Класс-Вью зачем типизация?
Да, именно для этого, а типизация потребуется для установления связей в шарпдевелоповском AST.
Здравствуйте, hardcase, Вы писали:
VD>>>Я тебе уже говорил, что IParser и вся их идеология гнилая. Она только на языки типа шарпа подходит. Как я понял, hardcase разными изворотами прикрутил туда полноценную интеграцию. Так что IParser он попросту обходит (использует не совсем по назначению). ВВ>>Насколько я помню, там IParser использовался для фолдинга и Класс-вью. Собственно, и все. А для Класс-Вью зачем типизация? H>Да, именно для этого, а типизация потребуется для установления связей в шарпдевелоповском AST.
Здравствуйте, catbert, Вы писали:
C>Демонстрация по ссылке (хостится прямо на моем компьютере, потому время от времени может быть офлайн):
C>www.catbert.co.cc/code
C>Должны правильно подсвечиваться все конструкции языка, кроме идентификаторов типов: сейчас лексер просто угадывает вид идентификатора.
C>В следующих сериях : навигация, перекрестные ссылки, ссылки на данные из System.Reflection — то есть фичи, для которых код нужно не только парсить, но и типизировать.
Здравствуйте, catbert, Вы писали:
C>Приблизительно в этом направлении я работаю. Но мне кажется, можно сделать универсальную "карту" символов для любого языка, чтобы браузер кода работал не только в Nemerle (ну, в стиле PDB).
Универсально можно сделать все. Только есть две проблемы:
1. Чем универсальнее делаешь, тем больше работы.
2. Чем универсальнее, тем менее функционально.
В АСТ немерла есть вся нужная информация. А вот как ты сделаешь тоже самое универсально, я представить себе не могу.
C>Ну, учитывая то, что:
VD>>Интеграции нужно работать быстро, по этому она делает множество "приседаний". В твоем же случае можно спокойно дождаться окончания компиляции и пройтись по готовым структрам.
C>не знаю, будет ли мое «спокойное» решение полезно для «быстрой» интеграции.
Оно было бы полезно для развития самого компилятора. Особенно если интеграцию так и не подружат с компилятором.
Твой вариант может быть проще реализован, а значит более надежен, более точен и доступен прямо в вебе.
Минус — скорость получения результата. Но для многих применений — это не такой уж и минус.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
VD>>Вот этот файл приводит к некислым тормозам.
C>Да не должен бы в теории... там же только Lexer+PreParser.
Lexer+PreParser конечно к таким тормозам привести не могут (в той же интеграции они работают молниеносно).
А вот то как формируется текст или даже то какой канал у твоего сервера — может.
Вот ты строки чем формирвешь? StringBuilder-ом?
C>Да и на практике не могу заметить тормозов. Возможно, в этот же момент мой комп занимался чем-то процессоро-интенсивным.
Возможно проблемы в канале или еще чем-то. Но вот я копипэстю содержимое указанного файла, нажимаю кнопку и... ожидаю 6-8 секунд получения результата.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот ты строки чем формирвешь? StringBuilder-ом?
Даже если складывать строки "+", то объем здесь не настолько велик, чтобы приводить к таким задержкам. Подумаешь, несколько десятков миллионов мелких объектов в куче.
Судя по поведению, дело именно в канале. Запрос-то отрабатывает почти мгновенно, т.е. видно, что страница быстро перезагружается, а потом браузер начинает досасывать сам файл, не шибко маленький.
Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Даже если складывать строки "+", то объем здесь не настолько велик, чтобы приводить к таким задержкам. Подумаешь, несколько десятков миллионов мелких объектов в куче.
Тут ты не прав. При определенных (легко достигаемых) условиях сложение строк может привести к экспоненциальному алгоритму. А это кирдык уже на тысячах объектов.
ВВ>Судя по поведению, дело именно в канале. Запрос-то отрабатывает почти мгновенно, т.е. видно, что страница быстро перезагружается, а потом браузер начинает досасывать сам файл, не шибко маленький.
Возможно, но не уверен. Лучше бы автору самому проверить все.
ВВ>Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен.
Ну, у меня канал широкий...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Тут ты не прав. При определенных (легко достигаемых) условиях сложение строк может привести к экспоненциальному алгоритму. А это кирдык уже на тысячах объектов.
А что в данном случае можно такое сотворить со строками, чтобы получить такие тормоза? Считай, минимум 5 секунд лишнего времени. Если сконкатенировать результирующий ХТМЛ через плюсик, то разница по сравнению со стринг-билдером и на глаз заметна не будет.
ВВ>>Кстати, размер HTML можно вполне ужать. К примеру, там нефиговый вью-стейт — причем непонятно, откуда он взялся и на фига он там нужен. VD>Ну, у меня канал широкий...
Здравствуйте, VladD2, Вы писали:
VD>К сожалению, нет. С Интеграцией, можно, а с компилятором нет. VD>Раньше у меня мозгов не хватало, чтобы решить там все проблемы. Сейчас вроде я до этого дорос, но туго со временем. VD>Возможно в ближайшее время попробую разобраться.
А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А что в данном случае можно такое сотворить со строками, чтобы получить такие тормоза? Считай, минимум 5 секунд лишнего времени. Если сконкатенировать результирующий ХТМЛ через плюсик, то разница по сравнению со стринг-билдером и на глаз заметна не будет.
Попробуй, вот такой вот безобидный с виду примерчик:
using System.Console;
using Nemerle.Diagnostics;
module Program
{
Main() : void
{
def source = "test ";
mutable str = "";
time
repeat(40_000)
str += source;
WriteLine($"Size: $(str.Length)");
}
}
ВВ>Однако это не поможет, если у него — узкий.
+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии
Без интеграции. В студии, но проект студия понимает как шарповский. При этом подсветка делается путем ассоциации .n-файлов с С++ и добавлением файла с ключевыми словами для С++.
При этом работает только дерево проектов, редактор кода и отладка. Хреновенько конечно, но лучше чем ничего.
Вообще, тут конечно моя лень играет плохую шутку. Давно надо было заставить интеграцию работать с проектом компилятора. Это должно было сильно ускорить работу над ним.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как вы сами-то компилятор правите? Без студии? Честно, даже как-то сложно представить — Влад и без студии
Я в SharpDevelop-е. Отлаживаю как получится, но как правило методом пристального взгляда.
Такое можно только специально написать На строку в 200 килобайт (хотя там генерится максимум 100) 40 тыс. перевыделений — это несколько крутовато.
Короче, в порядке борьбы за истину, запустил я хттп дебуггер — тот показывает, что практически все время ожидания идет ответ, т.е. "байты капают". А тут два варианта — или там ручками делается флаш или таки канал.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, hardcase, Вы писали:
H>>Я в SharpDevelop-е. Отлаживаю как получится, но как правило методом пристального взгляда.
ВВ>А там дебагер-то штатный должен был завестись. Или он глючит?
Он работает, но SD себя в системе не прописывает, и потому аттачусь к процессу (компилятор предлагает запустить отладку при флаге -debugger) студией. Но это случается если я совсем не понимаю что происходит.
Здравствуйте, _nn_, Вы писали:
__>Все три строки подсвечиваются одинаково. __>Мне кажется просто строковой литерал должен подсвечиваться как здесь на rsdn.
У меня все генерируется мгновенно, так что проблема в канале.
Да, гигантский ненужный viewstate есть, он отвечает за текст в текстбоксе, куда код писать.
Web-приложение неоптимизированное, написанное под чистые Web Forms, откуда и часть проблем. Если выход сжимать gzip-ом, ответ сервера будет соовсем маленьким.
__>def q = <#
__>my string
__>#>;
__>def p = linq <# from i in a select i #>;
__>def u = "string";
__>
__>Все три строки подсвечиваются одинаково.
В общем случае, подсветку строки в зависимости от того, какой макрос её использует, невозможно реализовать на уровне лексера.
То есть подсветка $-подвыражений внутри $-строк и linq внутри linq-строк будет реализована уже в "следующей версии", когда будут анализироваться PExpr-ы.
Хотя именно для $-строк и linq-строк наверное стоит добавить отдельную поддержку, потому что они часто используются в маленьких сниппетах, где using-и не прописуются.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, _nn_, Вы писали:
__>>Вначале текст выглядит четко, а к концу очень бледно.
C>Бледно выглядит код, помещенный в квазицитату. В вашем примере несбалансированная скобка помещает в квазицитату весь код дальше её самой.
Она закрывается после foreach, или я что-то проглядел?
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, _nn_, Вы писали:
__>>Вначале текст выглядит четко, а к концу очень бледно.
C>Бледно выглядит код, помещенный в квазицитату. В вашем примере несбалансированная скобка помещает в квазицитату весь код дальше её самой.
Поместите весь файл core.n , на каком-то моменте вы увидите , что текст бледнеет.
C>Собственно, "бледность" — один из вариантов Внешний вид кода задается CSS.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, _nn_, Вы писали:
__>>Поместите весь файл core.n , на каком-то моменте вы увидите , что текст бледнеет.
C>Долго втыкал на подсветку, так и не смог найти места, где она неправильная. Не исключено, что проблема связана с этой — http://rsdn.ru/forum/nemerle/3835775.1.aspx
ViewState у текст-бокса можно отключить, он там не нужен. Просто явно записывай текст туда, а можно даже не показывать исходный текст пока в целях экономии траффика. А в идеале бы тут прикрутить сжатие и с сервером общаться через аякс, чтобы он возвращал только собственно сгенерированный код.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Такое можно только специально написать На строку в 200 килобайт (хотя там генерится максимум 100) 40 тыс. перевыделений — это несколько крутовато.
Такое элементарно получается когда некоторые не очень опытные товарищи начинают формировать строки из мелких фрагментов.
ВВ>Короче, в порядке борьбы за истину, запустил я хттп дебуггер — тот показывает, что практически все время ожидания идет ответ, т.е. "байты капают". А тут два варианта — или там ручками делается флаш или таки канал.
Ну, тады ой. Надо переносить на более шустрй хостинг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>То есть подсветка $-подвыражений внутри $-строк и linq внутри linq-строк будет реализована уже в "следующей версии", когда будут анализироваться PExpr-ы.
Ага. И вообще типы нужно подсвечивать только на основании информации из TExpr-шенов.
C>Хотя именно для $-строк и linq-строк наверное стоит добавить отдельную поддержку, потому что они часто используются в маленьких сниппетах, где using-и не прописуются.
Не стоит. Лексер интеграции изгаляется по этому поводу, потому что анализировать TExpr дороговато для реалтайма. У тебя проблемы времени нет, так что ты можешь подкрасить код "честно".
Так что спеуиальных решений делать не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ViewState у текст-бокса можно отключить, он там не нужен. Просто явно записывай текст туда, а можно даже не показывать исходный текст пока в целях экономии траффика. А в идеале бы тут прикрутить сжатие и с сервером общаться через аякс, чтобы он возвращал только собственно сгенерированный код.
Здравствуйте, VladD2, Вы писали:
VD>Такое элементарно получается когда некоторые не очень опытные товарищи начинают формировать строки из мелких фрагментов.
HTML формируется StringBuilder’ом.
VD>Ну, тады ой. Надо переносить на более шустрй хостинг.
Nemerle.Compiler использует рефлексию, так что еще не всякий хостинг подойдет. Нужен Full Trust.
Здравствуйте, VladD2, Вы писали:
VD>Ага. И вообще типы нужно подсвечивать только на основании информации из TExpr-шенов.
Это так, но надо ещё учитывать, что не всегда дело доходит до TExpr-ов, ведь подсвечиваемый код необязательно должен вообще компилироваться без ошибок.
Кроме того, я боюсь, что в некоторых TExpr'ах может быть напутано с локейшнами (в том же $""-макросе), в результате собьется подсветка.
Имея "карту" пространств имен и типов, можно все идентификаторы правильно подсвечивать на основе PExpr где-то на 90%. Но для некоторых фич (например тултип для переменных) анализ TExpr-ов все равно обязателен.
VD>Не стоит. Лексер интеграции изгаляется по этому поводу, потому что анализировать TExpr дороговато для реалтайма. У тебя проблемы времени нет, так что ты можешь подкрасить код "честно".
VD>Так что спеуиальных решений делать не надо.
Есть проблема контекста. Если подсвечивается целый файл в контексте проекта, тогда можно (и следует) пользоватся TExpr-ами. Если подсвечивается сниппет:
Здравствуйте, catbert, Вы писали:
C>Это так, но надо ещё учитывать, что не всегда дело доходит до TExpr-ов, ведь подсвечиваемый код необязательно должен вообще компилироваться без ошибок.
Это критично для IDE, но не для подсветки закомиченых исходниках. В них наличие ошибок компиляции — это не штатная ситуация. К тому же компилятор немерла пытается до последнего типизироват даже код с ошибками, так что что-то да будет.
C>Кроме того, я боюсь, что в некоторых TExpr'ах может быть напутано с локейшнами (в том же $""-макросе), в результате собьется подсветка.
Такого тоже быть не должно. Иначе не будет работать хинты и комплит. Так что это тоже ошибка. Можешь закладываться на то, что все должно быть ОК даже в случае с кодом сгенерированным макросами.
C>Имея "карту" пространств имен и типов, можно все идентификаторы правильно подсвечивать на основе PExpr где-то на 90%.
Нельзя. Потом "правильно на 90%" — это означает не правильно.
Компилятор делает множество хитрых вычислений (вывод типов, разрешение перегрузки и т.п.) все они влияют на типы объектов. Чтобы вычислить правильную информацию, тебе придется повторить код компилятора, что сложно и бессмысленно.
C>Но для некоторых фич (например тултип для переменных) анализ TExpr-ов все равно обязателен.
Вот именно! Кроме того еще нужна навигация (гиперссылки как в Рефлекторе). Их тоже нельзя без типизации не выявить. А раз информация о типах все равно используется, то почему бы ее не использовать и для подсветки?
Короче, твой код должен выглядеть примерно так:
def currentPExpr = ...;
match (currentPExpr.TypedObject)
{
| TExpr.Xxx => анализиурем информацию о типах для получения подсветки, ссылок и подсказок.
...
}
C>Есть проблема контекста. Если подсвечивается целый файл в контексте проекта, тогда можно (и следует) пользоватся TExpr-ами. Если подсвечивается сниппет:
C>
Здравствуйте, VladD2, Вы писали:
VD>Универсально можно сделать все. Только есть две проблемы: VD>1. Чем универсальнее делаешь, тем больше работы. VD>2. Чем универсальнее, тем менее функционально.
VD>В АСТ немерла есть вся нужная информация. А вот как ты сделаешь тоже самое универсально, я представить себе не могу.
Ну, цель у нас конкретная:
VD>Мне кажется самым правильным подходом для такого как у тебя решения было бы сделать плагин к компилятору, который после завершения компиляции прошелся бы по конечному АСТ и собрал бы всю необходимую информацию для подсветки типов и генерации перекрестных ссылок.
Вот эта информация и нужна. По сути, описанный плагин можно представить как функцию: TExpr -> ProjectInfo, где ProjectInfo — структура данных, в которой собрана нужная информация. Универсальность лишь в том, чтобы сделать ProjectInfo не специфичным для Немерле.
Здравствуйте, catbert, Вы писали:
C>Вот эта информация и нужна. По сути, описанный плагин можно представить как функцию: TExpr -> ProjectInfo, где ProjectInfo — структура данных, в которой собрана нужная информация. Универсальность лишь в том, чтобы сделать ProjectInfo не специфичным для Немерле.
1. Лучше все же анализировать PExpr. В нем есть свойство TypedObject в которое после типизации записывается ссылка на соответствующий TExpr (или другой объект описывающий типы).
2. Кроме PExpr и TExpr еще нужно анализировать и дерево типов.
3. TExpr и есть необходимая тебе информация.
Я бы описал процесс генерации "активной подсветки" (назовем это так) следующим образом.
1. Прогоняем процесс компиляции до стадии на которой начинается типизация тел методв. Запоминаем ссылки на PExpr-оны этих методов.
2. Выполняем типизацию тел методов. После этого у свойствах TypedObject у PExpr-ешонов будут содержаться объекты описывающие типы.
3. Проходим по нетипизированному АСТ и генерируем текст со ссылками и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Как сказать. Если добавить кнопочку "Скопировать HTML" для сгенерированного кода, то и в таком виде весьма полезно. Например, если надо в какой-нибудь блог вставить раскрашенный код на Немерле.
Для этого можно воспользоваться:
1. Интеграцией и студией.
2. Авторинш-паком. В нем тоже есть подсветка для Немерла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какие проблемы со студией то? Качай себе изолэйтед-мод и ставь халявную интеграцию.
Да в вебе удобней.
ВВ>>Да и не все под виндой сидят. VD>Боюсь, что тогда проблема подсветки кода немерле будет самой меньшей из проблем этого человека.
Ну, пока нельзя ни скачать, ни собрать Немерле для mono, первой проблемой будет установка.
А решить ее просто: достаточно выложить архив бинарников в загрузки.