Related
Apple introduced Xcode source editor extensions with Xcode 8.
Will Xcode 8 still support plugins served via Alcatraz?
Xcode 8 prohibits code injection (the way plugins used to load) for security reasons. You can circumvent this by removing the code signing on Xcode. Both of these tools are capable of simplifying that:
https://github.com/inket/update_xcode_plugins
https://github.com/fpg1503/MakeXcodeGr8Again
To work on Xcode 8+ without removing the code signing, plugins will have to be rewritten as Xcode Source Editor Extensions. Unfortunately, the APIs for these extensions only allow for text replacement at the moment, so they are not an adequate replacement.
I've filed a report on rdar, do not hesitate to express your mind as well:
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party
plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being
narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic
source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First
shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
https://github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day
without:
AxeMode – Xcode issues patching Backlight – active line highlighting
ClangFormat – code formatter DerivedData Exterminator – daily need
getting rid or bad stuff FuzzyAutocomplete – name says it all, still
more powerful than Xcode completion HighlightSelectedString MCLog –
console log filtering, including regexes OMColorSense Polychromatic –
variables colouring, cute stuff RSImageOptimPlugin – processing PNG
files before committing SCXcodeMinimap – love this SublimeText-thingy!
XCFixin_FindFix – fixing Find features XcodeRefactoringPlus – patching
Refactor functionality, still buggy, but less than Xcode without
plugin XToDo – TODOs collection ZLGotoSandbox – 'cause dealing with
your folders would be a hell without it
Most of them are not source code-related, thus deserve having a way to
be loaded and working like a charm again.
You can certainly load all your plugins by recode signing Xcode 8.0. All credits to the XVim team. They seemed to solve this problem.
https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md
The Most Important Step From The Solution
There is no support and we can't expect any. Apple decides to shut down the ecosystem around the Alcatraz package manager before they have an api ready (extensions) that is able to do what the plugins were doing before. The extensions are currently limited to the text frame which does not allow to do much.
The main reason announced by apple is security and we can now disable code signing with effort to get back the most important features that were missing in Xcode.
Bad day for the community, bad decision from apple.
I also recommend the discussion on Alcatraz here: https://github.com/alcatraz/Alcatraz/issues/475
Most importantly if you want to support Alcatraz file a bug at http://bugreport.apple.com to make them aware that many people are suffering with this change
I did the same (openradar.appspot.com/28423208):
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day without:
AutoHighlightSymbol - Add highlights to the currently selected token
ClangFormat – code formatter
DerivedData Exterminator – daily need getting rid or bad stuff
FuzzyAutocomplete – name says it all, still more powerful than Xcode completion
KZLinkedConsole - be able to click on a link in the console to open the relevant file and be faster to debug
PreciseCoverage - nicer gui than xcode provides to view the coverage
XcodeColors - shows colors in the console depending on log level (how else should a console be used?)
Most of them are not source code-related, thus deserve having a way to be loaded and working like a charm again.
If you do not make a fast step to support your community i'm sure we
will find another platform to work with.
Seems like this should work. Found some answers here:
https://github.com/alcatraz/Alcatraz/issues/475
The key seems to be to removing code signing in order to get existing plugins to work.
Apparently not :'(
https://github.com/alcatraz/Alcatraz/issues/475
We have to wait until someone convert the plugins into the new Xcode Extensions
What are the differences between the different Rebol 3 branches, especially with the new REN branch?
Is it the platforms they'll run on, the feature set, code organization, the C standard compliance?
This is an answer destined to become outdated, hence set to Community Wiki. This information is as of Sep-2015. So if updating this answer after some time has passed, please modify the date as well.
Binary download of Rebol3 from rebol.com
Last build was 5-Mar-2011 and pre-dates the open source release.
No GUI support, no HTTPS support, no serial port support, no UDP support, no smart console...
No 64-bit builds. Binaries are for Windows x86, OS/X (PPC or x86), Linux (x86 or PPC), FreeBSD x86.
While Rebol2 binaries are archived for many "esoteric" systems (BeOS, AIX, Windows DEC Alpha, QNX, Solaris...) similar binaries were not provided for Rebol3. The only "weird" build is for Amiga, and only an OS4 PowerPC Amiga. No successful builds of Rebol3 for Amiga emulators have been reported.
Open source release of Rebol3 on Github rebol/rebol
Open-sourcing was on 12-Dec-2012.
The rebol.com binary downloads were not rebuilt as part of this release. However, a community member (#earl here on SO) created a build farm at rebolsource.net that follows this GitHub master whenever it updates. Given that GitHub's rebol/rebol master hasn't been updated since March 2014, this dynamism is currently underused.
Building the source at time of release got an executable not distinguishable (?) in functionality from the builds on 5-Mar-2011. This suggests few changes to the source were made besides some cleanup and Apache-licensing edits to prepare for publication.
Minor patches and bugfixes were integrated sporadically, with most PRs sitting idle. Last PR accepted at time of writing was Mar 3, 2014, which is over a year ago.
The most noticeable "breaking" PR that did get approved was to repurpose the FUNCTION name. It was considered to be worth breaking the old arity 3 form to let the word be taken for the much more useful implementation as locals-gathering FUNCT. (This also brought Rebol in alignment with Red, whose FUNCTION is arity 2 and acts similarly.) FUNCT was kept around as-is for legacy code.
The most major non-breaking PR that was taken is probably not requiring blocks around IF, UNLESS, or EITHER bodies. This has been received well among those who know it's there, as fitting the freeform and non-boilerplate philosophy of the language. It allows some code constructs to get "prettier" and gives programmers more choice, while it doesn't seem to cause any more problems than anything else. It's certainly less of a speedbump than if [condition] [...], in fact it seems almost no one knows this feature got added, so it must not be biting anyone. (If anyone can bend ears over at Red to make sure it gets IF and IF/ONLY then that would be ideal.)
RETURN/REDO was removed. Rationale was that it permitted functions to effectively behave with variable arity, and that this was unnecessary and took terra firma away by no longer being able to predict a function's arity from its spec. Perhaps this stance warrants a second look...as Lisp users who are pressuring for the addition of Lisp-style macros seeming aren't worried about that very much. (Here in the StackExchange universe, this provoked a Programmers.SE question Would Rebol (or Red) benefit from Lisp-style Macros?, which hasn't gotten much in the way of answers yet.)
The fork by Saphirion: "Saphir"
Prior to the open-sourcing of Rebol, Saphirion AG had a special relationship with Rebol technologies. They had access to the source and were taking responsibility for most of the development work for Rebol3 GUI features. They also added several other things like HTTPS.
Saphir is available as a binary download from their website, but only provided for 32-bit Windows. There was at one time an experimental .APK for Android from Saphirion.
Some (but not all) of Saphir's source was released after the open-sourcing. Notable omissions were the android build and some Rebol3 code for encapping...a way of injecting compressed scripts and resources into binaries of the interpreter without needing to recompile it.
(Note: Under Apache2 license there is no requirement to release source code for one's derived work.)
"Community" Integration at Rebolsource on GitHub
With the GitHub rebol/rebol being held up on integrations, a fork at rebolsource/r3 was established to be a "community build" where work could be staged.
Rebolsource changes were conservative, seemingly aimed toward showing process for how GitHub's rebol/rebol might adopt changes "in the spirit in which Rebol was conceived" should that repository be delegated to the community. (For that spirit, see this.) Hence it integrated non-controversial bugfixes and tweaks, instead of large third-party cryptography libraries for implementing HTTPS. Also: no allowance for adding build dependencies besides a C compiler (no GNU autotools, for instance).
Binaries for the community build were produced on an as-needed basis for those requesting them who could not build it themselves.
Atronix Engineering's Rebol "3.0" at Github zsx/r3
Atronix is an industrial automation solutions provider that uses Rebol. How they do so is described in a video here by David den Haring, director of Engineering, and their ZOE software is built on their version of Rebol.
After the open sourcing, Atronix partnered with Saphirion to port the GUI to Linux. Atronix publishes their source publicly as it is developed, and David den Haring notes in the video above that they have only one proprietary component they developed (an industrial control driver). Other than that they are happy to share the source for all Rebol development they do.
Atronix integrated the 64-bit patches from Rebolsource, created a Windows 64-bit target, and offer up-to-date binaries of their development branch for Windows and Linux x86/x64, as well as Linux ARMv7.
Besides having the features of Saphir, the Atronix build added support for CALL with /INPUT, /OUTPUT, /ERROR. It also added a Foreign Function Interface, implementing LIBRARY!, ROUTINE! and STRUCT! for communicating with non-Rebol dynamic libraries. It brings in encapping support as well on Windows and Linux.
Rebol's "religion" was at times at odds with expedience, so the Rebol-based build process was replaced when needed by hand-edited makefiles and Visual Studio projects. The FFI library introduced a dependency on GNU autotools to build.
All Atronix builds include the GUI, so there is no "Core" build. And again, only Linux and Windows.
Ren-C
(Bias Note: This fork is the initiative #HostileFork started, knows the most about, and will speak most enthusiastically about.)
Ren-C started as an an extraction of a Core build out of Atronix's codebase. That gave it features like HTTPS, the enhanced CALL, and Foreign Function Interface to essentially all the platforms that Rebolsource was able to build for. Updates Jul/Sep-2015 Ren/C supports line continuations in the console, user infix functions, several bugfixes...
Ren-C makes large-scale changes and fixes fundamental issues in R3-Alpha, which are tracked on a Trello that provides more information. There is a new FAQ as a GitHub wiki. Critical issues like definitionally-scoped returns have been solved, with continuous work on other outstanding problems.
Though Atronix's R3/View required some additional dependencies, Ren/C pushed back to being able to be built with nothing besides a C compiler, and eliminated all handmade makefiles/projects.
Beyond Windows, Linux and Mac in both 32-bit and 64-bit variants, Ren/C has also been built for smaller players like HaikuOS and yes, even Syllable. This is interesting more for the demonstration of how broadly turnkey builds of the C89 code work (simply as make -f makefile.boot) as opposed to there being a particularly large userbase of those particular OSes!
From the point of view of language rigor, Ren/C is pushing on modern techniques. Although it can still build as C89, it can be built as C99 and C11 as well. It has also been verified to build as C++98 through C++14, and with some strategic modifications under #ifdef __cplusplus it can take advantage of modern C++ as a kind of static analysis tool over the C code. Warnings are raised, type errors all fixed up, and it's "const correct". The necessary changes were carefully considered to make Rebol's baseline C code not just more correct but cleaner and clearer source across the board.
From a point of view of C developers, Ren/C should be stable, organized, and commented enough for anyone who knows C to "modify with confidence" and try new features. That means being able to implement definitionally scoped returns (actually written, but not pushed), or try developing features like NewPath.
From a point of view of architecture, Ren/C is intended to not have an executable at all...but to be a library for embedding a Rebol interpreter into other programs. It is now the basis for Ren/C++, which was designed to anticipate working with Red as well.
From a point of view of testing, Ren/C intends to whip everything into shape for engineering rigor and zero bug tolerance. This means avoiding practices like zero-filling memory to obscure uninitialized memory accesses, using Address Sanitizer, Valgrind, and a test suite that can pass the highest settings on both.
While enabling all the extra functionality has made Ren/C's executable nearly twice the size of Rebolsource's, there's not yet been any audit to see how this can be brought down. It has been confirmed that there are duplicate copies of Zlib and PNG encoding/decoding--for instance (Saphirion included LodePNG, likely to work around a bug in the existing PNG because it was easier than fixing it...yet did not mothball the previous code). Also, being able to do a build which selectively integrates only the codecs you want to use is on the agenda.
Ren/C currently has the stakeholders from Atronix and Rebolsource participating in its development and direction, which strengthens the likelihood that it may evolve into "the" Rebol Core. It is now being linked in as the code backing Ren Garden, and using a similar approach it may be set up as the library used by Atronix's R3/View...then Rebolsource...and perhaps ultimately rebol/rebol itself.
The fork by Oldes
(Bias Note: this edit is added 28-Feb-2019 by Oldes himself)
Forked from the community branch. Main focus on keeping the code close to the original Carl's release without blindly taking everything from Atronix/Saphirion but still trying to pick-up the good things from these branches slowly.
Not like Ren-C, this version is not trying to introduce new syntax, but rather be closer to the original Rebol2 and new Red language
I'm a developer in ActionScript and while I'm watching Haxe as a language to be used by me, since besides the resemblance ActionScript, still be possible to make applications with output to flash yet.
However I have a question about building AIR packages. When I search about building AIR applications with Haxe, the search does not bring satisfactory results.
I ask, after the codification and development of the code (in Haxe), how is it possible to transform what was built into an AIR package?
Thank you!
It isn't a very popular topic it seems. Anyhow, as far as I remember my experience building it some years ago, what you need would be:
If you need some air-specific APIs then you should write externs for them. There is this existing project, but it would need a bit of update as it was written for flash9, however, I believe it is doable in like 1 hour of work.
Compile to flash.
Write all the manifests you need for Air. (Sorry, don't remember what exactly it needs.)
Use this guides to package(also test and sign) your apps.
Note: If you want to go the same way you did before, you could compile haxe to as3 and be happy. However, I wouldn't recommend this method due to loosing speed and probable implications which may arrive.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am just starting at a job in which I will be using a lot of ColdFusion. What is the best IDE/Editor to use?
I'd like to provide my personal reasoning behind why you might choose any of these editors (at least the ones I'm familiar with). Just saying "use this, use that" is not at all helpful. To large degree, the question is wrong. There's rarely a "best IDE" for a language; rather, there are multiple environments, each suiting particular needs. Here goes:
1) Dreamweaver
Why you would use it: its history as a designer tool makes it much easier for "non-coder" types to start cranking out websites. If you're a solo developer building a lot of "Tom's Corner Store" type of sites, even if they require some CF Coding (mailing list, subscribers, current specials, light content management, etc), its design tools, "template" features, and ease-of-deployment (ftp) make it an attractive choice. It has good-enough code coloring and code completion for the built-in CF tags and functions. It can interrogate user-defined functions in the same page. It has excellent CSS support. You can find a wealth of extensions, too. It's pretty stable and, in my experience, hasn't been very "crashy". It will do a fair amount of code generation for you as well (whether that code is "good" is debatable). All in all Dreamweaver is incredible software for web site designers.
Why you wouldn't use it: It is not free, and it is certainly not a "coder's editor". While it provides for extensions, they're typically interface-focused (javascript validation, etc), unlike say Eclipse plugins, which can run the gamut. For large projects, it simply does not have the code navigation features that many coders come to expect. It's web-focused. So if you're a polyglot, or even just like to dabble in compiled languages (java, etc), then you'll need to keep another editor on hand for those tasks.... you won't be able to do it all in one place. ColdFusion unit testing support is nonexistent in Dreamweaver. There is no step debugging for ColdFusion.
2) CFEclipse plugged into Eclipse.
Why you'd use it: CFEclipse is going on 6 years old now and has matured significantly. It's been quite stable for the last few years and most crashiness has been due to Eclipse itself and not CFEclipse (which was not true in the early days). Recently CFEclipse has seen an infusion of fresh blood and features are being added to make coding in it even more productive. It contains a wealth of keyboard shortcuts, many of the toolbar features people love from ColdFusion Studio days, and Eclipse's in-built code navigation features (namely, Ctrl-Shift-R for finding files quickly).
It has content assist for native CF Tags and functions, and some support for in-page variables, though that's never worked all that well. It does not support in-page functions, nor does it provide native true component insight (i.e. insight into components that you write and use in other code). It will support component insight to some extent with Dictionaries, but even then, it requires a lot of work on the part of the dictionary creator. Most people find dictionaries too much work to maintain, in my experience.
The lastest version of CFEclipse contains the best CFML formatting you'll find.
For me, "method explorer" and "Snip Tree View" -- particularly keyboard shortcuts for inserting snippets -- have been big productivity boosters.
If you work with ColdSpring, ModelGlue, Mach-II, ColdBox, and other frameworks with xml configuration files, CFEclipse's Framework Explorer is brilliant.
Because it's a plugin to Eclipse, you can do everything else you'd want to do in Eclipse. You wanna code java? You can. You want webservice support? you got that. You want to do step debugging, you can do so with the free Adobe-provided extensions for Eclipse.
The large plugin ecosystem is one of the most attractive features of Eclipse, and you shouldn't discount this when deciding on an editor. For example, I would not want to work without Mylyn, which integrates with issue tracking and in my experience has transformed the way I work, much for the better.
Eclipse's version control system support is excellent as well. Subversion is well supported; there's a VSS plugin; and recently a git plugin (if not two) has been accepted into the Eclipse foundation so we'll see native git support very soon (you can get it now with a plugin).
Eclipse's ANT support is excellent.
You can easily plug the MXUnit Eclipse plugin into Eclipse for unit testing your CFML (full disclosure: I contribute to MXUnit).
Finally, I have full confidence that the folks working on CFEclipse -- Denny, Mark, Jim, Peter, et al. -- will continue to work toward keeping CFEclipse as the best open source CFML IDE available. These are some of the brightest minds in the ColdFusion community and are passionate about their mission. If you choose to use CFEclipse, you are not choosing to use an IDE that will be supplanted by ColdFusion Builder. This project is in good hands.
Why you wouldn't use it: it's a code IDE, not a design tool like Dreamweaver. It's not perfect... code assist can be too aggressive in its suggestions. Eclipse itself, especially when you pile it up with all kinds of plugins, can get unstable on lesser machines. Finally, people who don't like the "Project" view of the world often have complaints about it because they're used to working directly with the file system view of the world. Its deployment support is nowhere near as simple as Dreamweaver, though you can find plugins that get close.
3) ColdFusion Builder
Why you'd use it: all of what I said previously about Eclipse itself applies to CFBuilder when used as a plugin to Eclipse. I cannot speak to the Standalone version because as of this writing, it still doesn't support plugins very well. This will most surely be fixed by the time it is released, but I don't want to speculate on what the Standalone may or may not do.
One of CFBuilder's big draws is "Extensions". These are a way to plug in CFML code into your editor. It's hard to describe, so I'd suggest googling for "ColdFusion Builder Extensions", and you'll most likely be amazed. Adobe's Terry Ryan has created "Apptacular" for scaffolding applications from a database, and Brian Rinaldi has a series of posts on building CFBuilder extensions. These are huge and will prove themselves to be a developer's best friend after CFBuilder is released.
CFBuilder's deployment support is, in my opinion, on par with if not superior to Dreamweaver's.
CFBuilder does not require an additional plugin to do step debugging. Just hit the debug button and off you go.
CFBuilder contains true component insight, meaning that it can introspect components you write and provide ctrl-space content assist. It can be wonky, however, and does require some configuration. But please remember that as of now, CFBuilder is still in beta. My best guess is that it'll be at least a few versions until all the kinks are worked out of this feature. Still, it's a big productivity and learning booster to get content assist on your own components.
CFBuilder provides a "Servers" view for stopping/starting your CF Server. It's built on Aptana and so contains the Aptana "tail log" view, which is great for watching log files. Just like CFEclipse, it has a Snip Tree View.
The CFBuilder "vision" is led by Adobe's Adam Lehman. He's passionate about CF and is a force of nature. I have great hopes for CFBuilder because of Adam's leadership.
Why you wouldn't use it:
For one, it won't be free. Noone outside Adobe knows yet how much it will cost, however. "Extensions" and the deployment features alone may be worth the price. Time will tell.
Because it's an Adobe product, I think it's reasonable to assume that releases will come as frequently as most Adobe products, which means... not very often. While CFEclipse deploys rather frequently lately -- and makes available a "nightly" site for the brave -- CFBuilder will most likely not do such daring-do. CFEclipse can afford to make potentially unstable builds available to the public, while it is perhaps not in Adobe's best interests to do so with CFBuilder.
Finally, it's still in Beta and might not be released for some time. If you get it now and start using it, remember that. In my experience, debugging is wonky, content assist sometimes works, sometimes doesn't, and a lot of people have experience crashiness. It's free beta software... you're getting what you pay for. But know that the more you work with this beta release, and particularly if you provide feedback via the public bug database, the better off all of us will be if it provides a best of breed editor for CFML.
Personally:
At home, when I do "designer" work, I use Dreamweaver when I feel that its Templates will help me build a site as quickly as possible. For existing side projects which require maintenance coding and easy deployments, I use ColdFusion builder.
At work, where I do almost no design work, CFEclipse has been my IDE since 2006. I've begun using ColdFusion builder a lot, though currently I split my time between CFBuilder and CFEclipse. One reason is that as of this writing, CFEclipse is more stable (i.e. it doesn't crash and I don't lose work). I fully expect stability problems to be mitigated by the time CFBuilder costs money.
Both CFBuilder and CFEclipse have public bug databases. CFEclipse has a well-attended public mailing list, and if you have questions, you'll get answers quickly. I cannot yet speak to the speed with which CFBuilder questions are answered.
Finally, for "coders", it's my experience that once you invest the time in learning the tools and shortcuts, Eclipse provides superior productivity compared with designer tools like Dreamweaver. For cranking out a designed site, a designer tool like Dreamweaver confers significant advantages.
The answer to the best ColdFusion IDE isn't an answer, but a question: "What are you trying to do with ColdFusion?" The answer to that question will lead you to an IDE that suits your needs for a particular project. Different circumstances or projects may lead you to a different tool which better suits your needs.
Notepad++ with CF syntax highlighting.
For free: Eclipse with CFEclipes plugin
For cost: If you're a developer, use Coldfusion Builder, if you're a front end designer Dreamweaver edits Coldfusion pretty well. I use it quite often.
I have heavily used Dreamweaver, CFeclipse with eclipse and now Coldfusion Builder. What I found is this:
1) Dreamweaver is only good for the few times you have to do some wysiwyg wizardry. The newer versions do have SVN integration so you might be able to get away with using it. I did use it for a few years on windows.
2) CFEclipse + Eclipse - Generally the standard of what' sbeen used for a while. Runs well, once you add in the Adobe dictionary files and subclipse, you have a good environment
3) Coldfusion Builder - This is Adobe's version of CFeclipse. It's still pretty new and getting to later beta. I switched to it about 6 months ago and haven't looked back. It's got a lot of wizards, including the ability to write your own plugins in CFML that will run right inside CFbuilder. It's free right now on beta but will likely be pretty cheap like the first flex builder that came out.
My Choice: Coldfusion Builder. It doesn't mean the others aren't capable, but you'll spend the least amoutn of time getting setup and maintaining your plugins, etc.
Since I had paid for and used Dreamweaver for a lot of years (Eclipse was generally sluggish sometimes on PCs' a while back until the excess of ram + cpu today), spending to have an adobe maintained copy of eclipse is okay with me. The wizards available in CFbuilder, especially for flex are excellent.
Hope that helps, good luck and share what you ended up picking and why!
For anyone who might stumble here from Google, you should also take a look at Sublime Text coupled with the ColdFusion package.
If you are familiar with Eclipse I would recommend Eclipse with coldfusion plugin.
http://www.cfeclipse.org/
Some use Eclipse, some use ColdFusion Builder, some use emacs or TextMate or vim. I use vim.
It doesn't take much time to try out an IDE or editor. Give them all a shot and stick with the one you like most.
The best IDE is ColdFusion Builder. It allows RDS, In Line Debugging, Extensions (written in ColdFusion!), Code Generation, Refactoring, supports JavaScript, CSS and HTML and so much more. It is currently in beta and should be released in production sometime this year.
CFEclipse is a great IDE for CFML and is the right choice if you are writing CFML for the open source engines. It is free and like most open-source free products it can do almost anything Builder can do if you invest the time to install the additional plugins (like Aptana) and tweak your setup just right.
I use both. At work, we use Builder. At home, I use CFEclipse.
Welcome to the CFML community!
Notepad++. Light and easy to use.
I'll vote for jEdit. While it doesn't offer great ColdFusion support beyond syntax highlighting, and therefore probably isn't great for learning ColdFusion, its flexibility in working with other languages (which seems to happen fairly often while working on the web), powerful macros, plug-in support, proper text wrapping, and loads of other features, make it the editor to which I always end up returning after trying out the "next best thing".
CFEclipse appears to be the most popular. Adobe has a beta of ColdFusion Builder (also based on Eclipse) but when I tried it a few months ago it was still buggy.
Personally I use TextMate (OS X) a pretty bare bones text editor.
I have used textpad, for 6 years, still a solid app, provides syntax coloring/highlighting, regular expressions support. Can easily search inside any file, through tons of folders/subfolders.
Just a fast loading, easy to use, tool.
Also has macros, and macro programming...
http://www.texptad.com
I'd like to throw E TextEditor for the Windows users in here as well. Its similar to sublime but it does have its advantages. E is more or less Textmate for windows and will allow you to run the cftextmate bundles. In addition to being lightweight and extremely fast you get the huge Textmate community developing bundles, color schemes, and other community driven content.
Some of the highlights of E is that it will allow you to open a directory and treat it directory as a project. Hitting Shift-Ctrl T will allow you to browse all the files in your project in a flattened hierarchy which allows you to find files extremely fast.