What a strange idea you say, do we need yet another text editor?
Well… maybe…
I’m adding a text editor to ee-xml and I’d rather say it’s not for the sake of it – the application framework behind ee-xml (or lack thereof, given ee-xml is based on an F* derivative) is doing jolly good and I’m quickly heading towards an IDE that will bridge the gap between Antegram (XML-annotated code editing) and standard IDEs (text-oriented).
I won’t claim that the following features aren’t in any other text editor, but I haven’t seen them before (with the exception of templating which is ‘kind of’ available in Eclipse and other IDEs), and I feel that they will make the difference in many situations:
- Creating many, many new files in less time. Creating a new file is rarely a one step process. Most editors I’ve seen pop a file selector for that, and file selectors don’t provide fast interaction. Say you want to create a batch of 20 to a 100 files or more in a really short time, what would you do? I decided to reuse a feature from Antegram: given a selected folder in my file browser, I have a tiny text field at the bottom of the browser and I can just type in the names of all the files I need created. This allows me to create class members quickly in Antegram and I doubt many text editors can get as fast as that.
>> As I’m currently extracting class skeletons from a spec, this is exactly what I need to do (and there’s more to it, see below…) - Renaming and moving files quickly. Renaming a file can also turn out a bit slow in many situations, the fastest ways I know still being, do it from the desktop, or use a command line. When refactoring classes, renaming is common. So instead of having a label at the top of my document views, I’ll replace it with a text field. As a geeky way to move things around, I might even include the full path.
- Templating new files. Still on my ‘file generation spree’, I surely would like to template the creation of my text files – what’s the point in just generating blank files? After considering, I’ll probably add templating rules rather than an explicit drop-down menu. Files can be templated by extension and by name – this gives a first benefit to clear naming conventions.
There’s a few other small things that will make the difference – the non-overlapping document views that I’m so fond of, a speedy ‘open file’ featurette by-passing the file selector (backed by an implicit, localised search) and… well… some surprises.
Is it worth it? Yes, yes and… yes! I’m not even bored – after all, thinking innovation on such a tiny scale is a challenge in ergonomics design.
By the way, we’re still open to suggestions, 24/7.
