An interesting component is the DLTK project [L2 ]. This essentially brings IDE capabilities to dynamic languages. They currently feature Ruby and... TCL! This is an exciting development since it exposes to large number of developer eyeballs.
jmn 2008-05-14 I find the Tcl perspective in eclipse unusable. In the script explorer - it creates a row for every subfolder recursively. For some of my projects this results in hundreds of rows under the project folder - making navigation slow and tedious. The time to even open a project in Tcl perspective is way slower than for other languages.
Folders are hierarchical for good reason - why would you flatten the tree out like this? Even if the total number of folders was relatively small - I wouldn't want this extra clutter.
I've not seen any other eclipse plugin do this obnoxious folder expansion. Is there a cure for this misfeature?
LV Weird! First, I have to admit - I am not an eclipse user. So I don't really have an idea what is going on. What I have done, however, is visit the dltk link above, and run the wmv video demonstrating dltk. That video shows, at least in the Script explorer tab, a tree structure with folders nested as one would expect to see in a GUI application. You might explore http://dev.eclipse.org/newslists/news.eclipse.technology.dltk/maillist.html which is a newsgroup for dltk, to see if the topic has been broached within the development community working on the tool. Perhaps it is a shortcoming in the version of the tool you are using - or a symptom of a current incompatibility between the version of tcl you are using and the tool.
jmn I should have been more specific.. but that video shows how folders nest *only if they contain a .tcl file*. If like me, you happen to use a few tcl extensions, (eg .tk,.tm,.cgi) then even though these extensions are associated with the Tcl editor just like .tcl - the folders containing them are presented flat-style. I also have many folders that belong logically with a project, but don't contain Tcl source - and these are also listed in non-treelike fashion cluttering it up.
My solution for the moment is just to use the PHP perspective when working with Tcl. I'm not an experienced eclipse user myself - so I don't know what I'm missing out on by not using the Tcl perspective (aside from the annoying folder listing).
Perhaps it's early days for the DLTK plugin, but I may as well mention for the curious, that the Tcl code completion is currently pretty primitive. I guess it's a step up from no expansion at all - which I've lived with happily enough in other editors - but the DLTK plugin doesn't really seem to 'get' Tcl all that well.
e.g it doesn't understand any subcommands.. invoking code completion after typing 'info ' will give you just the usual commands and variables it knows about, not args, body, cmdcount etc.
Also - due to the simple Tcl syntax rules, you'd think it could deduce from your source what words are actually commands, and add them to code completion and the outline tree. It should theoretically be able to run your 'package require' statements somewhere and use info commands to deduce what additional commands belong to what packages.
I guess with such a dynamic language - it may not always be easy/possible for such tools to determine where a command was actually defined - but it doesn't even seem to take account of such things as 'interp alias', or 'rename'.
Now I see in the DLTK project plan, 'DLTK TCL' is described as an 'exemplary TCL IDE' - so perhaps we shouldn't expect too much of it - and it should be considered more of a 'sample' built on the features provided by DLTK. There may be room for people who are specifically passionate about Tcl to use this as a basis to create a better DLTK Tcl IDE.
RJM 2008-01-13 I have taken a look at DLTK with Tcl support, since I am using Eclipse for various other projects, too. Actually, the problem is the debugger. One can download dbgp_tcldebug.exe separately at the ActiveState website. But apparently other resources from KOMODO are necessary, too.
RLH 2008-01-14 :: Could you list what those other resources are?
To be short: I believe that ActiveState should consider to bring a debugger support package at reasonable cost. I would pay for good debugger support for projects managed with Eclipse, provided a capability is present to send procedures for update to a running script.
LV Note that for some time ActiveState had Tcl debugger support in Komodo. They spun the code off. I suspect that it will still integrate with Komodo - your best bet would be to ask on the Komodo mailing list how to go about doing that.
RJM Thanks for the hint. I was not aware of the fact that more than one resource (dbgp_tcldebug.exe) has been spun off. Meanwhile I have posted an email to the DLTK team. The defective link to the video has been reported, too. Hope that sufficient infos will enter in order to let the installation instruction not end with the header "debugger"...
JH The ActiveState Tcl debugger is not free and was never spun off. There was never any communication to this effect, so I'm not sure why that was misrepresented. It is available as a separate component purely for the purpose of allowing you to debug on a remote machine and still connect to Komodo (or another DBGP capable debugger like Eclipse+DLTK). Note that you are still required to own a license to Komodo or the Tcl Dev Kit to be legally compliant and run the Tcl debugger.
RJM 20080318 The DLTK, also with Tcl package has been updated to a V1.0 state. It is not found that easy. It is here [L8 ] but one has to select "More DLTK downloads". Then select the subpage "Integration Builds". One should download the Core Frameworks and the Tcl IDE. Once having started eclipse, and having set up a project, the project properties must be opened. In the tree, Tcl must be opened, then Debug, Engines and finally ActiveState. The dialog associated with this tree element allows for "Configure Workspace Settings...", where another dialog allows to DOWNLOAD the ActiveState Debugging engine. Alas, it is not explicitly noted which single download must be taken. One must download the Tcl Remote Debugging package for the appropriate OS, then store this and specify the path of the External Debugging Engine.
My first experience is that this works! I'm still going into getting more experiences.
JH 20080318 I am curious if that process properly notes the license requirements for the Tcl debugging component. It used to and still should. We don't mind others leveraging the Tcl debugger, but making something free that isn't ... is not appreciated. RJM Hm. OpenKomodo - as a closer investigation shows - only means the editor to be open source and for free usge. Regarding the debug resources, anyhow confusion could arise here.
EasyEclipse [L10 ] apparently does not.