Thursday, November 07, 2013

Acme editor for Haskell development?

 A post on reddit made me discover the Oberon system and the Acme editor, that drew inspiration from it. There is a cool video on YouTube of the Acme editor in action. The concept that "everything is Text" and "every bit of text can be an executable action" looks really powerful, even if it looks like it would take a bit of practice to get used to the mouse chording and the intensive usage of the three mouse buttons.

Working with an IDE that's quite heavy (understatement of the year), I'm certainly drawn to that simplicity and power much more than to other editors like Emacs and Vi, where it seems you have to remember an near-infinite list of arcane key combinations to be productive.

So I'm wondering, are there people out there using Acme or Oberon or Plan 9 for Haskell development? How do you find it? What good ideas could be applicable to other environments? I'm always looking out for ways to improve EclipseFP and Haskell development tools in general, is this a path worth exploring?
I've seen that blog entry, from somebody apparently using Erlang, and I noticed the following: Other sacrifices are syntax highlighting, automatic indentation, specific language support. Is that true? Isn't there a way to add syntax highlighting in Acme? And I suppose the specific language support you get by exposing your tool via the Acme system for text commands...

Happy Haskell Hacking, on Acme or not!

4 comments:

Warbo said...

The Yi editor is probably closest to what you describe http://www.haskell.org/haskellwiki/Yi

Yi seems to have gone through a period of rapid development, a period of abandonment, then some more development. I'm not sure of its current status.

Leksah is also a Haskell IDE written in Haskell http://leksah.org

BTW, Emacs and Vi don't require learning loads of shortcuts; their users just end up learning shortcuts over time because, well, they're shortcuts ;) Plus keystrokes are much easier to automate than mouse events, so Googling for a couple of keystrokes to record as a macro may get a repetitive task done in 30 seconds that might otherwise require writing an IDE plugin.

Personally I use an Emacs 'starter kit' called Emacs Prelude ( http://batsov.com/prelude/ ) which I've customised over time ( https://gitorious.org/warbo-dotfiles/warbo-dotfiles/source/79ea69c4ce2940f33a2fb0ddb10cfe5580ea79eb:emacs.d/init.el ) but there are other starter kits out there too ( http://ergoemacs.org/misc/list_of_emacs_starter_kits.html ). I recommend you give Emacs and/or Vi a chance!

Daniel Santa Cruz said...

Acme's use of the mouse is what turned me off, even though some of the other issues (i.e. highlighting, tabbing/indenting) support were also troublesome.

I wonder if it would be sensible to make an Acme that didn't necessitate the mouse (yes, memorize a few CTRL+xyz commands), and if the other issues could also be resolved.

Evan Laforge said...

Mouse is the whole reason to use acme! If you don't like the mouse there's really not much left for you.

I used to use acme for python and haskell, and I still miss the quick mouse chording and proportional fonts. Especially the ability to easily transfer code between the REPL and the module. I don't like syntax coloring or autoindent, so I didn't miss those.

All that said, I longed for fancier edits and cursor moves than the "pipe to external program" model could provide, so here I am back on vim again. But vim is really antiquated and overgrown and badly needs replacing (I say that as someone who's been using it since Amiga days), and at one point I hoped yi would be that replacement. Maybe it still could be.

But even being antiquated buggy and overgrown, vim still looks like a shining model of reliability speed and simplicity compared to the IDEs I've used.

Christopher Lord said...

I think acme really has the right idea in embracing text and the full multi-dimensional qualities of the mouse. The thing I wish it had was a full-blown parser like Parsec. I certainly think there is room for an editor like acme that is configured with a haskell DSL (like xmonad) and that runs on native ui widgets.

But... there are things about acme that transcend mere language choice, like the /mnt/acme filesystem.