|
in reply to Perl Programming Tools - (who, what, where, when, and why)
I love vi, mainly because I'm logged onto an AIX box via PuTTY for 25 hours each day. I tend to do a lot of my programming with vi, because it's a lot easier to work on the AIX box than to develop and upload. At times, I want to do some development offline, and then I'd either use notepad.exe, or CodeGenie. CodeGenie's main feature for me is it's syntax highlighting, and best of all, it's free. |
Re: Re: Perl Programming Tools - (who, what, where, when, and why)
by zigdon (Deacon) on Oct 11, 2002 at 13:32 UTC
|
Just use vim for windows - it's free, does syntax highligting, and you get the full power of vi (and more!). AND, you use the same editor in all enviroments, which leads to more proficiency.
-- Dan | [reply] |
Re: Re: Perl Programming Tools - (who, what, where, when, and why)
by stefp (Vicar) on Oct 12, 2002 at 13:10 UTC
|
I don't know any tool that does syntactical hilighting.
What they do is lexical hilighting when this is possible, that
is when tokenization is orthogonal with parsing.
A real tool will have to hook to the Perl parsing engine
to do a decent job in all cases. More generally I don't
know of any litterate development environment in the Open
Source world. We still use age old tool like emacs and vi
which is a sure sign how backward we are.
BTW:I am told that MS-Visual tool are far mode advanced.
This is very odd because litterate tools would fit more naturally
in Open Source world than in a closed one.
--
stefp --
check out Nemo
| [reply] |
|
|
Source Insight does more than "just" lexical parsing to highlight keywords. However, it doesn't hook the Perl parsing engine. Admittedly, the concept is much more useful in a strongly-typed language like C++, where I can see a list of available members and word-completion after typing an expression thus-far, because it knows the type of that expression result and can look up the class definition.
For Perl, limited typing of lexicals are available, and simply scanning the Package lexically to find potential member names is not going to work in "fancy" frameworks.
Using Perl's parsing engine is not enough. It would need to execute the script to some point to determine what gets set up on-the-fly in the package's symbol table, and even then, you can't truely know the set of all X where $p->X is legal, because of AUTOLOAD tricks for lazy loading, generation of members on first-use from a declared template, etc.
| [reply] |
|
|
| [reply] |
|
|
|
|
