Это похоже старания кого-то из наших или орла что переносил изменения из старых версий в нашу.
IT>Это меняется в NemerleLanguage, в самом начале есть массивчик с цветами.
Кстати, ты там не видел, нельзя ли сделать так чтобы кроме основных цветов еще можно было бы подсвечивать разые вещи разым цветом фона?
Например, хоршо бы выделять квази-цитаты други фоном. Так же у меня была идея выделять параметры функций другим фоном. И вообще мне кажется пастельные цвета чуть-отличимые от основного фона могли бы резко повысить читабельность в разных местах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, ты там не видел, нельзя ли сделать так чтобы кроме основных цветов еще можно было бы подсвечивать разые вещи разым цветом фона?
Думаю, можно. Но это ещё одна отдельная задача. Надо выкидывать тот колорайзер, который сейчас есть и переходить на стандартный лексер.
Ещё мне не понравился интерфейс с SDK. Когда запрашивается расцветка, SDK не передаёт колорайзеру номер строки, а только сами строки по одной в неопределённом порядке. Т.е. сейчас даже многострочные комментарии не работают, т.к. в контексте одной строки ничего не сделать. Но, к счастью, метод, который вызывает данный метод — виртуальный и имеет всю необходимую информацию. Вот его и надо окучивать. Этот метод вызывается студией и заполняет цветами массив int для каждого символа в строке. Так что, в принципе, разукрасить можно как хочешь.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Klapaucius, Вы писали:
IT>>Подглядывать не хорошо
K>+3 это, конечно, не потому, что я в таком дичайшем восторге от этого поста, а скоромное выражение моей благодарности за реализацию динамической подсветки ошибок.
Жаль, я уже думал, что во мне умер не только выдающийся ораклист, но ещё и выдающийся писатель-юморист
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Подглядывать не хорошо
+3 это, конечно, не потому, что я в таком дичайшем восторге от этого поста, а скоромное выражение моей благодарности за реализацию динамической подсветки ошибок.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, IT, Вы писали:
IT>Думаю, можно. Но это ещё одна отдельная задача. Надо выкидывать тот колорайзер, который сейчас есть и переходить на стандартный лексер.
Если бы вычислительные возможности компьютеров были бы беспредельны, то я бы ответил — никаких кроблем. Но к сожалению это не так.
Редактор VS сохраняет состояние лексера в каждой строке. Это стандартная оптимизация в редакторах. Это позволяет начать разбор с начала строки. Только ввод многострочных конструкций вроде строк или коментариев приводит к разбору более одной строки.
К сохранять состояние штатного лексера Немерла практически невозможно.
Насколько я понимаю редактирование Шарпа осуществляется в два этапа на первом работает такой же тупой лексер только написанный чуть более качественно. На втором производися полноценный парсинг и дальнейшее отображение осуществляется уже на основе его данных. При редактировании им приходится вообще не сладко. Тут я даже не очень представляю алгоритм.
IT>Ещё мне не понравился интерфейс с SDK. Когда запрашивается расцветка, SDK не передаёт колорайзеру номер строки, а только сами строки по одной в неопределённом порядке. Т.е. сейчас даже многострочные комментарии не работают, т.к. в контексте одной строки ничего не сделать.
В строке можно сохранять состояние которое тебе дадут при начале парсинга. Так что парсить можно без проблем. Хотя конечно парся строку можно сделать ряд оптимизаций.
А вот тем кто делает такие вещи как:
_prevToken = token;
в строке 131 файла NemerleScanner.cs надо бы линеечкой по пальчика.
Какие к черту _prevToken если в следующий раз сканирование может быть начато в другом месте?
У лексера не должно быть вообще никакого состояния кроме переданного через парамерт.
IT> Но, к счастью, метод, который вызывает данный метод — виртуальный и имеет всю необходимую информацию. Вот его и надо окучивать. Этот метод вызывается студией и заполняет цветами массив int для каждого символа в строке. Так что, в принципе, разукрасить можно как хочешь.
Это хорошо. Но боюсь полностью отказаться от легкоко колорера не выйдет.
Хотя можно попробовать опять же применить оптимизацию при редактировании метода. При редактировании метода можно тупо перепарсивать всеь метод. Если хватит скорости, то даже типизировать его. Это позволит при редактировании методов получать идиальную подсвекту и все фичи которые тольк модно предстваить в реалтайме.
Но что делать при редактировании кода вне методов?
Ну, для выражений инициализирующих поля мы сможем сделать такую же оптимизацию.
Но для остального? Можно конечно попробовать сделать отдельное редактирование для каждой конструкции языка и по окончании ее редактирования перепарсивать все файлы. Но до этого нам прийдется пользоваться вот таким вот примитивным лексером как сейчас. Так что довести его до ума видимо все равно прийдется.
Первым шагом тут будет удалешие _prevToken, так как это маразм. Можно как ты говорил переопределить функцию:
public virtual int ColorizeLine(int line, int length, IntPtr ptr, int state, uint[] attrs)
и уже в ней организовать локальную переменную prevToken если она конечно нужна. Но вообще смотреть на прошлый токен это маразм. Немерле имеет классическую LL(1)-краматику. Так что ему достаточно одного токена и возможности заглянуть вперед на один токен. Это делает стандартный лексер. Так что prevToken нужно просто грахать. Это косяк.
ЗЫ
Думаю лексером нужно заниматься только когда у нас заработают фичи первой очереди. Это позволит перейти на нее саму и тем самым поднять производительность и понизить порог вхождения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Думаю, можно. Но это ещё одна отдельная задача. Надо выкидывать тот колорайзер, который сейчас есть и переходить на стандартный лексер.
VD>Если бы вычислительные возможности компьютеров были бы беспредельны, то я бы ответил — никаких кроблем. Но к сожалению это не так.
Думаешь стандартный лексер работает медленнее? Королайзер на 90% повторяет функциональность стандартного лексера. Если уже что-то ускорять и оптимизировать, то без дубляжа кода.
VD>К сохранять состояние штатного лексера Немерла практически невозможно.
А его и не надо сохранять. Надо выкинуть дублирование кода.
VD>Насколько я понимаю редактирование Шарпа осуществляется в два этапа на первом работает такой же тупой лексер только написанный чуть более качественно. На втором производися полноценный парсинг и дальнейшее отображение осуществляется уже на основе его данных. При редактировании им приходится вообще не сладко. Тут я даже не очень представляю алгоритм.
К сожалению не всё так просто. Обсуждаемый метод используется не только для расцветки, но ешё и для триггеров. Т.е. поддержка интеллисенса "на лету" делается именно в этом методе.
VD>В строке можно сохранять состояние которое тебе дадут при начале парсинга. Так что парсить можно без проблем. Хотя конечно парся строку можно сделать ряд оптимизаций.
Ты про параметр state?
VD>А вот тем кто делает такие вещи как: VD>
VD>_prevToken = token;
VD>
VD>в строке 131 файла NemerleScanner.cs надо бы линеечкой по пальчика. VD>Какие к черту _prevToken если в следующий раз сканирование может быть начато в другом месте?
А ты посмотрел для чего это вообще?
VD>У лексера не должно быть вообще никакого состояния кроме переданного через парамерт.
Документацию для начала почитай. Или хотя бы посмотри в исходниках как это всё работает.
Call the SetSource method to set the line that is to be parsed. Then the ScanTokenAndProvideInfoAboutIt method is typically called repeatedly until all tokens are obtained.
VD>Это хорошо. Но боюсь полностью отказаться от легкоко колорера не выйдет.
Если не выйдет, то хотя бы по максимуму задействовать стандартный код.
VD>Хотя можно попробовать опять же применить оптимизацию при редактировании метода. При редактировании метода можно тупо перепарсивать всеь метод. Если хватит скорости, то даже типизировать его. Это позволит при редактировании методов получать идиальную подсвекту и все фичи которые тольк модно предстваить в реалтайме.
Можно попробовать ограничиться хотя бы Parsetree.
VD>Первым шагом тут будет удалешие _prevToken, так как это маразм.
Ну вот, блин, началось. Говно попало в вентилятор!
Ты правда смотрел зачем нужен _prevToken или просто догадался? Он вообще не нужен для колорайзера. Это временный костыль для тригеров, с которыми тоже ещё надо будет разбираться. Там одно только сравнение строк говорит само за себя. По уму лексер должен выдавать разные типы лексем, что кстати и делает стандартный лексер.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Думаешь стандартный лексер работает медленнее? Королайзер на 90% повторяет функциональность стандартного лексера. Если уже что-то ускорять и оптимизировать, то без дубляжа кода.
Речь не о медленее. Речь о том, что стандартный лексер и темболее парсер не может сохранять состояние в int и возобновлять сканирование с этого состояния.
VD>>К сохранять состояние штатного лексера Немерла практически невозможно.
IT>А его и не надо сохранять. Надо выкинуть дублирование кода.
Представь себе файл в мегабайт или более размером в котором изменяется один байт. Так вот колорайзер перепарсит ровно одну строку, а стандартный парсер весь файл.
IT>К сожалению не всё так просто. Обсуждаемый метод используется не только для расцветки, но ешё и для триггеров. Т.е. поддержка интеллисенса "на лету" делается именно в этом методе.
Ну, как мы вчера говорили, в простых случаях можно делать и так. А в сложных нужно тригерить по чем зря, а уже в обрабочиках брать полноценное АСТ и по нему разбираться что и как нужно делать.
IT>Ты про параметр state?
Да.
IT>А ты посмотрел для чего это вообще?
IT>Документацию для начала почитай. Или хотя бы посмотри в исходниках как это всё работает.
IT>
Call the SetSource method to set the line that is to be parsed. Then the ScanTokenAndProvideInfoAboutIt method is typically called repeatedly until all tokens are obtained.
ОК, если это поле используется только при парсинге строки, то проблем нет. Но это все равно дуро. Проще парсить строку и не держать полей (переменная станет локальной).
VD>>Это хорошо. Но боюсь полностью отказаться от легкоко колорера не выйдет.
IT>Если не выйдет, то хотя бы по максимуму задействовать стандартный код.
Согласен. Я думаю сделать так. При подсветке смотрим есть ли готовое дерево типов. Если оно есть, то забиваем на этот убогий лексер и живем по дереву. Для методов на лету строим PExpr, а то и TExpr. Если же только что произошло редактирование, то пользуем тупой лексер до тех пор пока не станет доступным полноценное дерево и/или PExpr/TExpr метода.
IT>Можно попробовать ограничиться хотя бы Parsetree.
Это и есть PExpr. Попробовать конечно можно, но в нем еще не разобраны типы и их подсветить не удастся. Скорее всего прийдется пользоваться TExpr (т.е. компилировать отрисовываемый метод). Но это только предположения. Надо подойти к проблеме ближе и тогда уже разбираться. Пока что у меня в планах разобраться с глюками комплейшон энжина. Там не все просто.
VD>>Первым шагом тут будет удалешие _prevToken, так как это маразм.
IT>Ну вот, блин, началось. Говно попало в вентилятор!
Спокойствие, только спокойствие (с)
IT>Ты правда смотрел зачем нужен _prevToken или просто догадался? Он вообще не нужен для колорайзера. Это временный костыль для тригеров, с которыми тоже ещё надо будет разбираться. Там одно только сравнение строк говорит само за себя. По уму лексер должен выдавать разные типы лексем, что кстати и делает стандартный лексер.
Понял. Как временный костыль пусть живет. А потом перепишем по человечески. Один фиг я хочу разными цветами одсвечивать отдельные части кода (например, квази-цитирование).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Думаешь стандартный лексер работает медленнее? Королайзер на 90% повторяет функциональность стандартного лексера. Если уже что-то ускорять и оптимизировать, то без дубляжа кода.
VD>Речь не о медленее. Речь о том, что стандартный лексер и темболее парсер не может сохранять состояние в int и возобновлять сканирование с этого состояния.
Его не сложно будет обманывать. Например, если предыдущая строка закончилась комментарием, то добавление '/*' в начало следующей строки убедит лексер в том же самом. Но писать свой вариант всё равно придётся. стандартный лексер тупо глотает некоторые вещи, которые нам могут быть интересны. В общем-то, я не против отдельного лексера, я лишь за то, что бы там где можно использовать код стандартного. Например, тот же разбор числовых значений нет смысла изобретать по новой. Можно, конечно, его скопипейстить, что видимо и было сделано в королайзере, но уже сейчас этот код там и там различаетя.
IT>>А его и не надо сохранять. Надо выкинуть дублирование кода.
VD>Представь себе файл в мегабайт или более размером в котором изменяется один байт. Так вот колорайзер перепарсит ровно одну строку, а стандартный парсер весь файл.
Ему можно скармливать и одну строчку. Но да ладно, всё равно похоже придётся заняться написанием своего.
IT>>Ты про параметр state? VD>Да.
В принципе, похоже, что оно работает. Сложных контекстных вещей на нём не сделаешь, но подавляющее большинство стандартных раскрасок сделать можно.
VD>ОК, если это поле используется только при парсинге строки, то проблем нет. Но это все равно дуро. Проще парсить строку и не держать полей (переменная станет локальной).
Всё это ещё 10 раз будет переделываться.
VD>Согласен. Я думаю сделать так. При подсветке смотрим есть ли готовое дерево типов. Если оно есть, то забиваем на этот убогий лексер и живем по дереву. Для методов на лету строим PExpr, а то и TExpr. Если же только что произошло редактирование, то пользуем тупой лексер до тех пор пока не станет доступным полноценное дерево и/или PExpr/TExpr метода.
Для этого это дерево хорошо бы упорядочить по location, иначе беготня по нему сожрёт всё возможное время. К тому же могут появиться побочные эффекты. Например, королайзер вызывается для прохода по тексту один раз взад вперёд. Потом вызывается только для текущей строки. Если в этот момент придёт событие Check и исходник будет распаршен, то эффектно прорисуется только текущая строка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Его не сложно будет обманывать. Например, если предыдущая строка закончилась комментарием, то добавление '/*' в начало следующей строки убедит лексер в том же самом.
А зачем это делать? Почему просто не иметь состояние "многострочный комментарий"?
Таких состояний нужно 3 штуки. Normal, MultilineComment и MultilineString.
В общем-то классика жанра.
IT> Но писать свой вариант всё равно придётся. стандартный лексер тупо глотает некоторые вещи, которые нам могут быть интересны.
Это исправимо. Вопрос в том надо ли это исправлять...
IT> В общем-то, я не против отдельного лексера, я лишь за то, что бы там где можно использовать код стандартного.
Я тоже за это. Тут у нас полный... эээ... какое там матерное слово Горбачев использовал? А этот косексус.
IT> Например, тот же разбор числовых значений нет смысла изобретать по новой. Можно, конечно, его скопипейстить, что видимо и было сделано в королайзере, но уже сейчас этот код там и там различаетя.
Согласен. Вообще надо покумекать нельзя ли стандартный лексер все же прикрутить.
Как идея можно сделать следующее. Любой файл изобилует местами где лексер находится в исходном состоянии. Можно ввести два состояния Default и Other. Ну, и при запросе лексера всегда начинать разбор с ближайшей (в верх) строки у которой состояние Default. Будет конечно некоторый оверхэд. Но думаю его не будет заметно. Но эту идею надо продумывать. Да и реализация не тривиальна. Так что это надо откладывать на будущее.
IT>В принципе, похоже, что оно работает. Сложных контекстных вещей на нём не сделаешь, но подавляющее большинство стандартных раскрасок сделать можно.
Теоритически на нем можно делать лексер любой сложности. Надо только понимать, что лексер не парсер. И он будет всегда уметь выделять только лексемы ничего не говоря о структуре.
IT>Для этого это дерево хорошо бы упорядочить по location, иначе беготня по нему сожрёт всё возможное время.
А что там не упорядочено? Да и вряд ли беготня по нему что-то там сожрет. Это микросекунды.
IT> К тому же могут появиться побочные эффекты. Например, королайзер вызывается для прохода по тексту один раз взад вперёд. Потом вызывается только для текущей строки. Если в этот момент придёт событие Check и исходник будет распаршен, то эффектно прорисуется только текущая строка.
На самом деле это будет видно только как недопдсвечивание на доли секунды (или секунду) при открытии файла. А это и у Шарпа есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А зачем это делать? Почему просто не иметь состояние "многострочный комментарий"? VD>Таких состояний нужно 3 штуки. Normal, MultilineComment и MultilineString.
+ multiline квази-цитирование
+ условная трансляция
+ multiline blahblahbla в $"$(blahblahbla)"
+ multiline строки в multiline квазицитировании
+ multiline комментарии в multiline квазицитировании
VD>В общем-то классика жанра.
Ну да, плюс некоторый модерн.
IT>>Для этого это дерево хорошо бы упорядочить по location, иначе беготня по нему сожрёт всё возможное время.
VD>А что там не упорядочено? Да и вряд ли беготня по нему что-то там сожрет. Это микросекунды.
Я имею ввиду, что поиск по хешу по идее должен работать быстрее обхода дерева.
IT>> К тому же могут появиться побочные эффекты. Например, королайзер вызывается для прохода по тексту один раз взад вперёд. Потом вызывается только для текущей строки. Если в этот момент придёт событие Check и исходник будет распаршен, то эффектно прорисуется только текущая строка.
VD>На самом деле это будет видно только как недопдсвечивание на доли секунды (или секунду) при открытии файла. А это и у Шарпа есть.
Вообще, интересен механизм реализации этого дела. Я пока так и не понял когда это делается, самим колорайзером или же отдельным событием.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>+ multiline квази-цитирование
+1
IT>+ условная трансляция
Тут сильно сложнее. Для этого нужен интерпретатор препроцессора и он работать на состояниях вряд ли будет.
IT>+ multiline blahblahbla в $"$(blahblahbla)"
$ не влияет на тип строки.
IT>+ multiline строки в multiline квазицитировании
Возможно. А возможно процдут как обычные строки. Даже почти наверняка.
IT>+ multiline комментарии в multiline квазицитировании
Тоже самое.
IT>Ну да, плюс некоторый модерн.
Модерн в языке. А парсинг классический.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>+ условная трансляция
VD>Тут сильно сложнее. Для этого нужен интерпретатор препроцессора и он работать на состояниях вряд ли будет.
Я только мельком глянул, но мне показалось, что лексер обрабатывает условную трансляцию.
IT>>+ multiline blahblahbla в $"$(blahblahbla)"
VD>$ не влияет на тип строки.
Вдруг захочется выделить выоажение в строке другим цветом, а эт выражение будет задано в нескольких строках.
IT>>+ multiline строки в multiline квазицитировании
VD>Возможно. А возможно процдут как обычные строки. Даже почти наверняка.
Это уже вложенное состояние получается.
VD>Модерн в языке. А парсинг классический.
Да он и так классический, только состояний больше.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>Тут сильно сложнее. Для этого нужен интерпретатор препроцессора и он работать на состояниях вряд ли будет.
IT>Я только мельком глянул, но мне показалось, что лексер обрабатывает условную трансляцию.
Тот что в компиляторе — да. Тот что используется для подсветки — нет, к сожалению.
IT>Вдруг захочется выделить выоажение в строке другим цветом, а эт выражение будет задано в нескольких строках.
Это можно сделать только по АСТ. Так что этот лексер тут не поможет.
IT>Это уже вложенное состояние получается.
Возможно. Даже наверняка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Я только мельком глянул, но мне показалось, что лексер обрабатывает условную трансляцию. VD>Тот что в компиляторе — да. Тот что используется для подсветки — нет, к сожалению.
Он много чего не умеет. Я как раз и предлагаю заменить его на свой, по максимуму использующий стандартный.
IT>>Вдруг захочется выделить выоажение в строке другим цветом, а эт выражение будет задано в нескольких строках. VD>Это можно сделать только по АСТ. Так что этот лексер тут не поможет.
А просто найти вхождения $() в строке не получится?
IT>>Это уже вложенное состояние получается. VD>Возможно. Даже наверняка.
Ещё один случай для нового состояния — подсветка кода между | и => в match. И тоже вложенное.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Он много чего не умеет. Я как раз и предлагаю заменить его на свой, по максимуму использующий стандартный.
Надо бы конечно. Но это ломает планы. И еще одна проблема. Четкой концпеции того как это лучше сделать у меня нет. Надо бы как-то использовать имеющийся лексер. Но как?
IT>А просто найти вхождения $() в строке не получится?
А что толку? Их же еще и распарсить нужно.
IT>Ещё один случай для нового состояния — подсветка кода между | и => в match. И тоже вложенное.
Вот тут как раз никаких особых сотсояний не будет. Это просто лексемы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Он много чего не умеет. Я как раз и предлагаю заменить его на свой, по максимуму использующий стандартный.
VD>Надо бы конечно. Но это ломает планы. И еще одна проблема. Четкой концпеции того как это лучше сделать у меня нет. Надо бы как-то использовать имеющийся лексер. Но как?
Так есть главный метод — GetToken, кажеться. Вот его использовать не надо. Остальное использовать по мере надобности как конструктор. Недостающие куски дописывать.
IT>>А просто найти вхождения $() в строке не получится? VD>А что толку? Их же еще и распарсить нужно.
Не надо. Для начала достаточно эти вхождения отобразить другим цветом. Например, если строка зелёная, то это будет чуть более тёмное зелёное. Для большинства вещей этого будет достаточно.
IT>>Ещё один случай для нового состояния — подсветка кода между | и => в match. И тоже вложенное. VD>Вот тут как раз никаких особых сотсояний не будет. Это просто лексемы.
Я о том, что вдруг захочется всё между | и => отделить, например, другим фоном.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не надо. Для начала достаточно эти вхождения отобразить другим цветом. Например, если строка зелёная, то это будет чуть более тёмное зелёное. Для большинства вещей этого будет достаточно.
Ой, только не надо строки зеленым. Уж лучше красненьким.
Что до "достаточно". Для этого достточно все равно надо хоть как-то парсиь строку. Вот только если парсить примитивно, то даже ключевые слова не будут покрашены.
IT>Я о том, что вдруг захочется всё между | и => отделить, например, другим фоном.
Такие вщи нельзя делать на лексере. Для этого нужно бырать АСТ и по нему красить. Иначе ты подкрасишь:
SomeFunc(a | b, a => a / 2);
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Например, хоршо бы выделять квази-цитаты други фоном.
V>Вообще, подсветка другим фоном не есть гут, ИМХО, но квазицитирование — сам бог велел.
Ну, почему? Вот я видел как в Сцентиле строки многострочные выделяли фоном. Очень удобно.
В общем, выделять фоном токены конечно не здорово. Но например, отделить код тела метода, было бы не плохо. Причем так чтобы разница между цветами была почти не заметра. Прикинь, тело метода рисуем белым, а код заголовка функции и скобки обрамляющие тело бледно-бледно зелененьким. Так что бы почти не видно было. При работе напрягать не будет, а если надо сразу можно выхватить тело метода и сам метод в классе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, выделять фоном токены конечно не здорово. Но например, отделить код тела метода, было бы не плохо. Причем так чтобы разница между цветами была почти не заметра. Прикинь, тело метода рисуем белым, а код заголовка функции и скобки обрамляющие тело бледно-бледно зелененьким. Так что бы почти не видно было. При работе напрягать не будет, а если надо сразу можно выхватить тело метода и сам метод в классе.
Мне до сих пор нравится фенечка в IDE 6-го VBA, когда можно переключать представление кода программы из плоского в пометодный. (Свертка кода нравится чуть меньше, ибо когда таких сверток много, то тоже листать приходится).
В 2005-м VB-проекте приколол TestBench. Создай проект VB.Net, и в ClassView поиграй с пунктами меню "Create Instance" и "Invoke Method". Вот бы прикрутить подобное для Nemerle Если такое сделать, тогда можно будет заявить, что IDE не уступает смолтолковским.
Здравствуйте, vdimas, Вы писали:
V>Мне до сих пор нравится фенечка в IDE 6-го VBA, когда можно переключать представление кода программы из плоского в пометодный. (Свертка кода нравится чуть меньше, ибо когда таких сверток много, то тоже листать приходится).
А чем это отличается от перехода к нужному методу по комбику вверху окна редактора файла? Это мы обеспечим. Но подсвечивать зоны функции как бы совсем другое дело. Тут именно выделяется тело метода и его сигнатура.
V>В 2005-м VB-проекте приколол TestBench. Создай проект VB.Net, и в ClassView поиграй с пунктами меню "Create Instance" и "Invoke Method". Вот бы прикрутить подобное для Nemerle Если такое сделать, тогда можно будет заявить, что IDE не уступает смолтолковским.
Собственно уже есть Немерлиш (интерператор Немелра). Не думаю, что динамическое создание кода будет давать что-то большее.
Необъодимость такой фичи вообще мне кажется очень сомнительной. А дел еще море, так что по крайней мере в первой верисси такая фича не планируется.
Что до крутости Смолтоковских сред, то это миф. Любая студия затыкает их за пояст по большинсту параметров. Причем просто потому, что есть полноценная информация о типах до стадии компиляции. Такого качества подсказок и комплита как есть в C# (да и в общем-то в Немерле) Смолтоку никогда не видать просто из-за его динамической типизации.
Ну, а гнаться за идеей СТ о том, что программа почти всегда находится в стадии исполнения и ее можно при этом править бессмысленно для статически типизированного языка. Это прераготива динамики. За то ее поклонники и платят столь высокую цену (торомза, поздняя диагностика ошибок и т.п.).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
Если такое сделать, тогда можно будет заявить, что IDE не уступает смолтолковским.