Subject: Re: Emacs vs VI, the final solution
From: rpw3@rpw3.org (Rob Warnock)
Date: Sat, 31 Jan 2009 19:16:13 -0600
Newsgroups: comp.lang.lisp
Message-ID: <uqCdnc3z2rNAahnUnZ2dnUVZ_uydnZ2d@speakeasy.net>
Tobias C. Rittweiler <tcr@freebits.de.invalid> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > Well, I don't feel like I'm "missing out" on anything I really need.
| 
| I bet a C++ programmer does not feel like missing something out,
| language-wise. :-)
+---------------

Perhaps, but we're not talking pure Blub here, since I *am* at least
coding in CL, not C++.  ;-}  ;-}

+---------------
| > - I'm not sure what you mean by "source-integrated debugging"; can you
| >   unpack that a bit more?
| 
| http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/source-oriented-debugging.html
| 
| In case of Slime, you can press `v' on a backtrace frame in the Slime
| debugger, and it'll bring you to the source expression corresponding to
| that frame.
+---------------

Your preferences clearly differ, but for my tastes, that example
makes a very weak case to me. Consider how much you already get
from the standard CMUCL debugger:

    $ cat test.lisp
    (defun test (x)
      (let ((y (/ x 9)))
	(print y)
	(print (/ 8 y))))
    $ cmu
    cmu> (compile-file "test")
    ...[chatter]...
    ; test.x86f written.
    ; Compilation finished in 0:00:00.

    #P"/u/rpw3/test.x86f"
    NIL
    NIL
    cmu> (load *)

    ; Loading #P"/u/rpw3/test.x86f".
    T
    cmu> (test 0)

    Arithmetic error DIVISION-BY-ZERO signalled.
    Operation was KERNEL::DIVISION, operands (8 0).
       [Condition of type DIVISION-BY-ZERO]

    Restarts:
      0: [ABORT] Return to Top-Level.

    Debug  (type H for help)

    (KERNEL::INTEGER-/-INTEGER 8 0)
    Source: Error finding source: 
    Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
      target:code/numbers.lisp.
    0]  back

    0: (KERNEL::INTEGER-/-INTEGER 8 0)
    1: (TEST 0)
    2: (INTERACTIVE-EVAL (TEST 0))
    3: (LISP::%TOP-LEVEL)
    4: ((LABELS LISP::RESTART-LISP SAVE-LISP))

    0] l   
    KERNEL::X  =  8
    KERNEL::Y  =  0

    0] down
    (TEST 0)
    1] l
    X  =  0

    1] (describe 'test)

    TEST is an internal symbol in the COMMON-LISP-USER package.
    Function: #<Function TEST {48A7C869}>
    Function arguments:
      (x)
    Its defined argument types are:
      (T)
    Its result type is:
      NUMBER
    On Saturday, 1/31/09 04:43:33 pm PST it was compiled from:
    /u/rpw3/test.lisp
      Created: Saturday, 1/31/09 04:41:57 pm PST

    1] (ed "/u/rpw3/test.lisp")
    ;;; And a fresh XTerm pops up with "vi /u/rpw3/test.lisp" in it
    ;;; [At least, that's what I have ED set to do. You could also
    ;;; have it run Hemlock, if you prefer.]

    1] ;;; And now we can continue debugging in this window
       ;;; while editing in the other.
    1] source

    (/ 8 Y)
    1] ;;; So that's where we need to look...

You have two windows; I have two windows. We're both coding/debugging
Common Lisp. We both know which source form in which file produced the
error. That's the important thing, to me. Can we can simply agree to
disagree about the exact editor that each of us finds more comfortable?


-Rob

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