The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

app scripting IDEs, or: foisting emacs on less technical users

I'm thinking of replacing our existing (nasty) game script compiler/editor with a combination of command-line compiler, and emacs.

The current system is a GUI tool with integrated compiler, with the GUI part being basically the windows edit control and a tree view, and some additional muck to start the game with the scripts you just compiled.

The new system I'm thinking of would be emacs, with new keyboard shortcuts for compiling, a ctags-style browser for our scripting language, and something along the lines of C-x C-e (to compile the current script snippet and send the result to the game in real time). This would, I think, be a big improvement.

There's just one issue: none of our game designers are particularly interested in learning some crazy new unixish editor. They just want (and rightly so) some easy way of making the game do what they want. So I'm wondering whether anybody else has tried forcing emacs on their less technically-savvy users, and, if so, what problems they had.

emacs's CUA keys mode looks to solve the obvious problem of the unfamiliar keyboard shortcuts, but since I'm still at the planning stage, I'd rather have the idea stillborn due to problems I've not foreseen, than go through with it only to discover them later. I'd also be interested in any suggestions for alternative editors, that can be made to talk to other processes in a similar manner.

I picked emacs to start with, on account of its scriptability, its lack of cost, and its overall familiarity (compared to my preferred vim, anyway ;) but I don't feel tied to it. The only thing I don't want to do is have an integrated editor that I have to write myself, because these things always turn out rubbish: they crash, they don't have auto indent, they don't have M-/, they don't have syntax highlighting, and they just suck up programming time.

I'm sure others will have encountered the problem of providing a pleasant environment for writing domain-specific scripts for some in-house system; I'd be interested in anybody's experience. The fact it's a computer game in my case is hopefully mostly irrevelant :)
Tuesday, June 20, 2006
What about using ANT scripting instead of some homegrown scripting system with emacs? Have you exhausted your research into integrating with the current IDE? It will probably be a much easier sell if you don't have to ween them off of their current IDE.

Also, I'm hoping that you only talk about them like that in anonymous internet posts and not to their faces. ;) I personally don't see the correlation between how technically savy someone is and their potential desire to use some sort of command line compilation scripts with arcane keyboard shortcuts. Even technically savy users can appreciate the benefits of simply clicking a "build" button over having to remember some keyboard shortcut.
Tuesday, June 20, 2006
Take a look at the editor component here:

It's highly adaptable and works very well.  It's been wrapped for most popular programming languages.  I'm using the Delphi binding for my own report creation tool and I love it.  I also recently found a C++ IDE that uses it, and it's now my preferred IDE.
Clay Dowling Send private email
Wednesday, June 21, 2006
Thanks for the replies.

Scintilla is on my list of things to try out.

After playing around with emacs, I've found it pretty cool. In general use, I don't like it as much as vim (my poor wrists!), but it's clearly much better-designed. And it's fairly easy to extend too: I now have a major mode sending scripts to the app over TCP, and it was (mostly) a snap, thanks to the awesomeness of C-x C-e and C-j. And it's all in a proper text editor! (I might have been able to do something similar with scintilla, but it would have taken an hour or two just to get a test app basically working, which is about the time it took to get this stuff up and running. And this way, I don't need 2 x Visual Studio...)

Unfortunately, after getting trapped once too often in the minibuffer modes that don't do C-], and experienced various other annoyances that I missed before, I think I've answered my original question. I'm used to spending the time getting familiar with text editors, because I personally find it a benefit in the long run, but the sheer non-win32ness of emacs makes me think it would be a hard sell convincing others.

So my current thoughts are an MFC app with a scintilla widget, with some of that C-j stuff (if you're in an interactive-type buffer), and some socket magic inside. And another possibility, that occurred to me only today, and appeals a bit more, is scripting up jEdit via Beanshell, to the same end.
Thursday, June 22, 2006
Oh, and just briefly, regarding my "less technically-savvy" comment: this was a sort of shorthand for the issue I mentioned here:

"There's just one issue: none of our game designers are particularly interested in learning some crazy new unixish editor."

But you're quite right, the two do not necessarily go together, and indeed I reckon it would be tricky to get even some of the programmers to use emacs, for the same reason. Anyway, it was not intended to be perjorative.
Thursday, June 22, 2006
> I picked emacs to start with, on account of its
> scriptability, its lack of cost, and its overall
> familiarity (compared to my preferred vim,
> anyway ;) but I don't feel tied to it.

You could try something like the Zeus IDE:
  Note: Zeus is shareware (45 day trial).

It has the stock standard set features found in most IDE's and it can also emulate several keyboard mappings, including Brief, EMACS, Epsilon, WordStar etc.
Jussi Jumppanen
Thursday, June 22, 2006
Emacs sux. Requiring it's use would be almost criminal. Specify a syntax and let people use any editor or provide a GUI.
son of parnas
Saturday, June 24, 2006
That is exactly my intention. You'll be able to use notepad, if you really want.

The intention behind using emacs was to provide a fancy major mode, with a realtime feedback buffer, including 2-way comms over TCP with the app. Ever tried emacs and M-x run-python? Experienced the joy of C-j in the *scratch* buffer?

That's the kind of thing I'm thinking of. Add in some elisp to run the build system automatically, and navigate through errors, and browse the script constructs, and you're set.

But, as I've said, if you don't want to do this, well... that's your prerogative. notepad and cmd await.

(The more I use emacs, though, the less I'm convinced it'll be suitable for general use. Too many rough edges. If you're a programmer, though, it's cool! I'm even considering switching from vi -- but I don't think my wrists will thank me for it.)
Monday, June 26, 2006
"They just want (and rightly so) some easy way of making the game do what they want."

Adopting Emacs isn't going to solve this problem per se. As others have pointed out, every IDE has a learning curve, although some have steeper curves than others. More to the point, that curve is time spent away from developing the game itself, and if you have a deadline and a budget, that time is excruciatingly valuable.

Ergo, +1 to the Notepad and Ant suggestion. Rather than focus on finding a proper IDE, I think you should be spending your time looking for or building a set of utility tools that can be run independently of any IDE.

Granted, Emacs' strength is the ability to write and execute macros, but guess what - so does Excel. In fact, if the majority of my developers were proficient in Visual Basic for Excel, I'd focus on writing some sort of export tool than requiring them to learn Emacs.

Moral of the story: find out what your developers' strengths are, and augment those strengths instead of handing them yet another tool they need to master from scratch.
Tuesday, June 27, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz