Должны правильно подсвечиваться все конструкции языка, кроме идентификаторов типов: сейчас лексер просто угадывает вид идентификатора.
В следующих сериях : навигация, перекрестные ссылки, ссылки на данные из System.Reflection — то есть фичи, для которых код нужно не только парсить, но и типизировать.
Здравствуйте, 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>Это да. В студии она работает (с ошибками, пока). Но в студии не грузится проект компилятора. Надо посидеть над этим делом.
С самим проектом компилятора нельзя работать из студии?