From: "Hal E. Fulton" Date: 2001-12-04T11:29:14+09:00 Subject: [ruby-talk:27403] Re: Killer app for Ruby developers? ----- Original Message ----- From: John Carter To: ruby-talk ML Sent: Monday, December 03, 2001 7:10 PM Subject: [ruby-talk:27394] Re: Killer app for Ruby developers? > On Tue, 4 Dec 2001, Hal E. Fulton wrote: > > > This is an idea that is very skeletal > > yet I think there's a twist that makes > > it significant (especially for XP people). > > I have a hard earned deep scar tissue programming rule-of-thumb... > > Never write an editor, never write a sort routine. > > Why? Because it requires a huge amount of effort to get up to anything as > good as the existing system tools. [snip] This is an *excellent* point. > I'm not saying, "Don't do that". > > I'm saying, "Make sure what you do will be compelling better than Emacs > and a few lines of Elisp." > > Probably should join forces with somebody working on a refactoring > browser for Ruby. Is someone doing that? > Parting shot... > > The first place to look for how to design such an editor is emacs. Emacs > is basically an Elisp interpretor providing the basic infrastructure and > then a largish pile of Elisp macros doing the actual work... > > ie. Work out what basic primitives elisp has to work on buffers and the > like, implement those in Ruby or in C primitives. > > Either that or simply provide ruby bindings to the same primitives that > Elisp uses... My tentative choice of these two would be the latter -- Ruby bindings to the primitives. How do-able is this? Is there an emacs library that is independent of the rest of the editor? I assume the interface is independent also? Actually, if I *were* going to write an editor from scratch (and this is really hypothetical, since I've never written an editor of significant size), this is what I'd do: 1. Make it Ruby-scriptable and Ruby-friendly (obviously) 2. Add emacs and vi(m) compatibility modes for (at least) the most common commands Hal