Thomas F. Burdick <tburdick@gmail.com> wrote:
+---------------
| On Jan 30, 3:10�pm, rpw3@rpw3.org (Rob Warnock) wrote:
| > Last time I looked, all of the Vi-like modes (including Viper)
| > were *major* modes, which means you can't use them from within
| > another major mode... such as Lisp!
| >
| > I would be interested in trying a Vi-like *minor* mode that
| > would work inside any major mode (such as Lisp mode). Do you
| > know of any?
| 
| You might want to look at Viper again. It's not a major mode, it's
| some sort of global minor mode, and it supports 5 different levels of
| Vi emulation vs Emacs integration...
+---------------

Thanks, I'll give it a look.

+---------------
| It pains me a bit to think that Lisp hackers are missing out on the
| joys of find-definition, source-integrated debugging, automatic
| indentation that takes macro lambda lists into account, auto display
| of function arguments and eval/compile from within a source file ...
| just because of a preference for a vi-like editor. If Skill can give
| you the best of both worlds, I don't see why CL shouldn't be able to.
+---------------

Well, I don't feel like I'm "missing out" on anything I really need.

- Grep does find-definition, though perhaps not as conveniently as Emacs.
  Besides, in the CL I use (CMUCL), DESCRIBE tells me the source file a
  variable or function was defined in [granted, only for compiled files].

- I'm not sure what you mean by "source-integrated debugging"; can you
  unpack that a bit more?

- Indentation takes so little time for me it's a total non-issue.
  [Hint: ":set ai sw=1", then ">%" or "<%" then "..." as needed.]

- DESCRIBE does a wonderful job of displaying function arguments.
  If I need more info, a web browser with a tab open to a local copy
  of the CLHS is always there (plus a small CGI script I wrote in
  another tab that does symbol/glossary/issue search).

- I always keep a REPL window open, so EVAL is one copy/paste away;
  and a recompile is one REDO away. [REDO is a small utility function
  I define on a per-project basis to "do the right thing", usually runs
  LOAD* (which recompiles compiled things as needed) or ASDF and then
  sometimes a regression test.]

Does this mean I have an XTerm and a Vi open for each file being edited?
And another XTerm for the REPL? Plus a web browser window? Yes. I fail
to see why this is so much worse than an Emacs buffer per file plus an
interaction buffer.

Anyway, as I've said before, *for me* (YMMV) the fraction of time I
spend doing all these whizzy tasks for which people wax so eloquent 
about their IDEs is such a *tiny* part of the total job of application
development that halving or even quartering the time spent on them
[and I doubt even the best IDE could do that!] would hardly make a
noticeable dent in the overall schedule. The hard part is extracting
the *real* requirements from the customer, and then *thinking* about
what you really want the code to do, and then thinking about how to
get the code to do that.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607