[nem-en] Re: [nem-feedback] Visual Studio 2005 VSIP package
NoiseEHC
NoiseEHC at freemail.hu
Wed Feb 22 16:29:21 CET 2006
Inlined...
> However, F5 didn't work. Maybe this is saved on a per-user basis?
>
Dunno, maybe.
> Sure. Where should I post my wishes? ;-)
>
> I've just started it, but these would really be nice:
> - I can't specify indention (spaces instead of tabs, smart block
> indention...)
> - Syntax highlighting for #region/#endregion would be nice
> - A "Class Library"-Project template would be useful, I think
> - for some reason, when I double-click on a keyword, the space/tab character
> before it is selected, too.
> - are you planning to implement debugger support? Outlining? Windows Forms
> editors?
>
>
So the main problem is that the fast lexer which the VS colorizer
depends on,
parses the source differently from the Nemerle lexer which the compiler
depends on.
That is the reason why it messes up the bounds of syntax elements
(selection, braces etc).
It also misses some things (for example #region and namespace handling).
Namespace handling means that a Nemerle source depends on the macros it
is using so
that the lexer somehow should track what using directives you used at
the top of the source
so it could highlight macros as user defined keywords. It could also
insert the macro
signature if you specified it with "syntax" (dream category...)
So I had the feeling that we should get rid off of this fast lexer and
tune the compiler's
lexer to handle fast/restartable parsing but compiling Nemerle with an
msbuild task does
not work currently (because of assembly loading errors). What I am
absolutely sure is
that I will not touch the Nemerle source without it because I am a lazy
windows coder.
By the way that is the reason (laziness) of developing this VS plugin...
> Do you have some kind of "roadmap" of what will be implemented when?
> Personally, I'd say correct indention support (so you can type fluidly)
> would be most important, followed by debugging support. After that,
> intellisense and then maybe WinForms and stuff.
>
>
Road map:
1. fix assembly loading
2. fix msbuild
3. replace LexerColorizer with a modified LexerBase
4. implement full source coloring
5. implement full source parsing (braces, indentation, outlining,
breakpoint selection)
6. implement auto completion/autos window
Note that full source coloring scratches the limits of the capabilities
of the VS editor but
depending on the C++ documentation it can be done.
> Just curious: Why did you write the plugin in C#, not in Nemerle?
>
>
>
Simply it is a modification of the Python plugin sample. Since that
sample will be the one
which will be maintained by MS in the next VSIP releases, it seems sane
to develop in C#
to be able to integrate the modifications they will make into our code.
Later, when it will
surpass the Python sample we could convert it to .n if that makes sense
at all...
More information about the devel-en
mailing list