Well c.l.l. probably holds the second largest active group of emacs
users...hi xah
When resting from the many Lisp vs `The Other Language wars, some of us
like to chew on a vi fanatic. Now it seems that a final battleground
has been created to solve the editor wars once and forall time.
http://wordwarvi.sourceforge.net/
--
Lisp : a multi-fetish language
<·······@eurogaran.com> wrote:
+---------------
| Perhaps vi-emacs wars are outdated.
+---------------
I think so. Most people use Emacs/Slime and love it, while a
few of us(!) use Vi (for various personal reasons) and love it.
Some may even prefer a vendor's IDE (or other way of editing).
Doesn't matter. All that matters here is whether you're successfully
coding Lisp or not. [I am; how 'bout you...?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Thu, 29 Jan 2009 14:57:36 +0100, <···@incubus.de> wrote:
>
> GP lisper wrote:
>
>> http://wordwarvi.sourceforge.net/
>
> ".swp"-files are a vim speciality, though.. How lame.
Well, the CP/M version of Emacs, known as Perfect Writer, had .swp
files. It was packaged with Kaypro II computers in their first years.
In order to have more buffer space, you needed to expand the swapfile
(disk hex edit a value in the first record). PW was dropped in later
deliveries for WordStar, a vi-like clone. I cannot remember if
microEMACS had them too, but I do remember making sure an 'emacs'
existed before getting an MS-DOS system.
--
Lisp : 'My God, it's full of cars!'
GP lisper wrote:
> Well c.l.l. probably holds the second largest active group of emacs
> users...hi xah
>
> When resting from the many Lisp vs `The Other Language wars, some of us
> like to chew on a vi fanatic. Now it seems that a final battleground
> has been created to solve the editor wars once and forall time.
>
> http://wordwarvi.sourceforge.net/
IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
to console the losers.
;)
- Daniel
On Thu, 29 Jan 2009 20:54:22 -0500, <········@at.tentpost.dot.com> wrote:
>
> GP lisper wrote:
>> Well c.l.l. probably holds the second largest active group of emacs
>> users...hi xah
>>
>> When resting from the many Lisp vs `The Other Language wars, some of us
>> like to chew on a vi fanatic. Now it seems that a final battleground
>> has been created to solve the editor wars once and forall time.
>>
>> http://wordwarvi.sourceforge.net/
>
> IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
> to console the losers.
> ;)
Games[1] never deliver on time.
[1] and microsoft OS
--
Lisp : 'My God, it's full of cars!'
D Herring <········@at.tentpost.dot.com> wrote:
+---------------
| IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
| to console the losers.
+---------------
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?
Lacking that, I'll stick with "nvi-1.79" for my Lisp hacking...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jan 30, 3:10 pm, ····@rpw3.org (Rob Warnock) wrote:
> D Herring <········@at.tentpost.dot.com> wrote:
>
> +---------------
> | IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
> | to console the losers.
> +---------------
>
> 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?
>
> Lacking that, I'll stick with "nvi-1.79" for my Lisp hacking...
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, giving you different levels of
benefit from the underlying . The Cadence VCAD environment for Skill,
Vier, which gives Slime-like integration with the Skill dialect of
Lisp, works quite well with Viper at level 2 or higher. I don't know
if Slime works correctly with Viper -- and I remember that I had to
make a few changes to Vier so it would work conveniently with Viper --
but it's probably worth checking out. I bet it wouldn't be too hard to
adapt Slime to Viper, if it needs it.
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.
On Jan 30, 5:16 pm, "Thomas F. Burdick" <········@gmail.com> wrote:
> On Jan 30, 3:10 pm, ····@rpw3.org (Rob Warnock) wrote:
>
>
>
> > D Herring <········@at.tentpost.dot.com> wrote:
>
> > +---------------
> > | IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
> > | to console the losers.
> > +---------------
>
> > 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?
>
> > Lacking that, I'll stick with "nvi-1.79" for my Lisp hacking...
>
> 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, giving you different levels of
> benefit from the underlying .
... "the underlying major mode".
Thomas F. Burdick <········@gmail.com> wrote:
+---------------
| On Jan 30, 3:10�pm, ····@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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Pascal J. Bourguignon
Subject: Re: Emacs vs VI, the final solution
Date:
Message-ID: <87pri3trxn.fsf@galatea.local>
····@rpw3.org (Rob Warnock) writes:
> 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.
It is definitely more in the unix spirit.
For me, I find it worse because each program (vi, browser, repl) have
its own user interface, its own key bindings.
The integrated user interface proposed by emacs as the advantage of
uniformity.
> 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.
Indeed (and then, waiting for C++ to compile, when you're unlucky).
--
__Pascal Bourguignon__
From: Tobias C. Rittweiler
Subject: Re: Emacs vs VI, the final solution
Date:
Message-ID: <87fxize89g.fsf@freebits.de>
····@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. :-)
> - 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.
-T.
In article <··············@freebits.de>,
"Tobias C. Rittweiler" <···@freebits.de.invalid> wrote:
> ····@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. :-)
>
>
> > - 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.
>
> -T.
LispWorks IDE: Type :ed in the textual LispWorks debugger. Double click
on a stack frame in the LispWorks window debugger. Both will locate the source
in an editor window and highlight the subexpression.
--
http://lispm.dyndns.org/
Tobias C. Rittweiler <···@freebits.de.invalid> wrote:
+---------------
| ····@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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2009-01-31, Rob Warnock <····@rpw3.org> wrote:
> Thomas F. Burdick <········@gmail.com> wrote:
> +---------------
>| On Jan 30, 3:10 pm, ····@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.
My regular job is kernel programming (among other things).
Right now, I hosed my target machine. I can't get into the shelf manager of
the chassis to reset the card, and I'm working over a VPN from home.
So today the ``edit compile run'' cycle is actually `edit, compile, run, drive
10 miles to hit a reset button, edit, compile, run ...''.
I can get the job debugged with nothing more than a dump of register values, a
piece of the stack, and some bytes around the instruction pointer in hex.
This skill is as relevant in 2009 as it has ever been.
> - Grep does find-definition, though perhaps not as conveniently as Emacs.
Grep finds occurences, not definitions, and it's horribly inefficient
for anything but small projects.
The integration into vim is nice; i.e. how the :grep command calls
the grep utility and parses its output as a quicklist that you can navigate.
But you can replace the underlying grep utility with another one that
produces compatible output.
I use the mkid utilities which provide a query program called lid,
which can be told to look like grep. This program works with an index file
built by running mkid.
See: http://www.math.utah.edu/docs/info/mkid_toc.html
With lid, I can grep the entire Linux source tree for occurences of
an arbitrary identifier virtually instantly.
I remapped the K key so that it does :grep on the identifier on the
cursor, and :grep uses lid. K normally does a man page lookup; if
given a numeric prefix it looks in that section. I set it up so that
K still does the man page lookup if given the prefix.
Now for finding definitions, of course, you want tags. Exuberant ctags supports
Lisp.
I don't think mkid supports Lisp, though, but hacking it shouldn't be
difficult. It supports plain text documents, so that alone might be good
enough.
> - I'm not sure what you mean by "source-integrated debugging"; can you
> unpack that a bit more?
It's that feature that lets you single step through running code while source
code is shown on the screen, along with an indication of where you are in the
source in relation to the executing code.
Never heard of it?
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Rob Warnock <····@rpw3.org> wrote:
| > - I'm not sure what you mean by "source-integrated debugging"; can you
| > unpack that a bit more?
|
| It's that feature that lets you single step through running code
| while source code is shown on the screen, along with an indication
| of where you are in the source in relation to the executing code.
|
| Never heard of it?
+---------------
Not until Tobias mentioned it [see parallel replies]. His example
seemed kind of weak, given that the CMUCL debugger [and presumably
others] will print both the current form and the file the current
function is in. You've probably already got
Anyway, I've never been much of one for single-stepping, myself.
Always seemed like a waste of time, to me. [And, yes, I am aware
that liking single-stepping is another one of those near-binary
preferences that some have, and some don't. I'm one of the "don't"s.]
I'm more the sort that instruments with lots of debug printouts, and
then when an assert or breakpoint is hit look at what's happened so far,
then read the source code *very* closely and try to figure out how
the hell we got here. As Kenny pointed out with his two blog posts
on "Solve the First Problem/Failure First", it's often something
that was overlooked *way* earlier than the point where the actual
assert or breakpoint was hit, so single-stepping does you no good at
that point [and is too expensive to do all the way from the beginning].
To say it another way, I'm a great believer/practitioner of "debug
by binary partition" (loosely defined). It looks like it's working
at the beginning; it's definitely off the rails at the assert/breakpoint;
so look for a point roughly halfway (40-60%) between those two and
see if it had already gone sour there, too. Wash, rinse, & repeat
until "start" == "end".
Sprinkling "N" debug printouts between the current "start" and "end"
(rather than just one) lets you find the problem a little faster,
but not much. It's the difference between (log (length program) 2)
and (log (length program) N).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Tobias C. Rittweiler
Subject: Re: Emacs vs VI, the final solution
Date:
Message-ID: <87ljsq8ew1.fsf@freebits.de>
····@rpw3.org (Rob Warnock) writes:
> Not until Tobias mentioned it [see parallel replies]. His example
> seemed kind of weak, given that the CMUCL debugger [and presumably
> others] will print both the current form and the file the current
> function is in. You've probably already got
Of course, the information is there in the compiler; it's where Slime
gets it from after all. It's a question of convenience and integration;
and the latter makes the whole be greater than the sum of its parts.
That said, I don't doubt that your personal setup suits you after years
of tweaking. Still, if you get the chance, ask someone to demo you
Slime, or a similiar environment, in real life.
-T.
On 31 jan, 16:07, ····@rpw3.org (Rob Warnock) wrote:
> Thomas F. Burdick <········@gmail.com> wrote:
> +---------------
> | On Jan 30, 3:10 pm, ····@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.
Fair enough. I've used a classic vi-based Unix environment to do C
programming in the past, as well as Emacs as just an editor for Lisp
(SBCL and CMUCL pre-Slime, Skill pre-Vier) so I think I have a pretty
good appreciation for the potential power of the setup, and I assume
you have little utilities and helpers where it matters.
> 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.
I agree for the most part. But good integration between the editor and
the environment makes some of the repetative tasks a little easier,
which means you need to spend less thought on them, freeing up brain
cycles to think about the task at hand. Put another way, going the
other direction doesn't feel like death by paper cuts, but it's enough
of a slowdown that I notice. One thing I forgot to mention in my
previous list -- and besides showing lambda-lists on space, it's the
most important feature to me in a Lisp editor -- is good
autocompletion based on the Lisp image.
Taking what you said point by point ...
> - 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].
This is a thousand paper-cuts situation. Yes, you can find defuns with
grep, and it works reasonably well. DESCRIBE is very nice in CMUCL.
But getting instantly transported to the function definition site is a
real luxury. Zipping there, looking for a second or two, then zipping
back can help keep your head in what you're doing in a way that you
tend to lose (or I tend to) with the other method. Getting a list of
method signatures to choose from is also nice.
One point here that relates to debugging, and I don't remember if you
can do this easily with just the debugger in CMUCL. The functionality
is there, obviously, but it may not be easy. When you ask to see the
source of a stack frame, you get brought to the source site, even if
it's an anonymous function or a local function, even obscured by
macros and not within the dynamic scope of the outer function. So in a
situation like this:
(defun frob (x)
(setf (callback x)
(lambda () ...)))
You can easily find your way back to the lambda inside of FROB if an
error occurs within the callback.
> - I'm not sure what you mean by "source-integrated debugging"; can you
> unpack that a bit more?
Good, tight editor integration with the debugger. So, on the one hand,
the "view source" command. The CMUCL source-path syntax is great. In
the face of large functions or ugly macros, you can have the system
take care of interpreting it, and bring you right the the sexpr you're
interested in. Again a case of keeping out of your way that I
personally find to be a big productivity gain.
There's also visually setting breakpoints, which is a little nice
thing. The rest of Slime is just sugar (usually good, not always) on
top of the basic features of the CMUCL debugger.
> - Indentation takes so little time for me it's a total non-issue.
> [Hint: ":set ai sw=1", then ">%" or "<%" then "..." as needed.]
Oh ho ho, you missed my point! This is a key editor-connected-to-
running-lisp feature. If you have a macro:
(defmacro with-complex ( (var object &body init-forms) cleanup &body
forms)
...)
And some text:
(with-complex (stylus (make-stylus) (setf (color stylus) :blue)
(enable stylus)) (flush-ouput stylus) (draw-something stylus 1) (draw-
something stylus 2) ...)
Having it be automatically indented as:
(with-complex (stylus (make-stylus)
(setf (color stylus) :blue)
(enable stylus))
(flush-ouput stylus)
(draw-something stylus 1)
(draw-something stylus 2)
...)
Is really nice. That's the most involved syntax I could think of that
would be realistic, but my point is that it's nice to have the editor
correctly find &body and indent accordingly.
And for me, here's the kicker: when the automatic indentation is
correct and doesn't screw up things like &body, you are more likely to
use it, and for larger regions. This means you always know that your
indentation isn't lying to you, and you never ever get errors due to
braindead editing.
> - 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).
Yep, but you have to invoke DESCRIBE. My editor always shows me the
lambda-list for the form I'm editing. It's just always there, so I
never have to wonder if it's :some-key-word or :some-keyword, it's
shown at the bottom of the window at all times. This is huge. Moreso
if you use large libraries of which you're not the author (or the only
author).
> - 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.]
True, but it's faster from the editor. And maybe more interestingly,
compilation notes are integrated with the editor. If you tell the
editor to compile a form, you get a tree-shaped summary of the errors,
warnings, and compilation-notes. No need to look through them all, you
can see that you have 0, 0, and 13. Also, if the error, warning or
note indicates part of the source, it will be shown in the editor by
underlining the indicated form. Something ou weren't expecting to be
underlined? That draws your attention really fast.
And auto-completion: boy does this save typing and typing mistakes.
When it's connected to the running Lisp it's far better than when
performed staticly on files.
m-v-b => multiple-value-bind
some-r-l: => some-rexp-library:
some-rexp-library:c-ex => some-rexp-library:compile-expr
Joy oh joy, no more typos!
And all that said ... there are a lot of flashy whiz-bang features in
Slime that people get excited about that are either annoying, useless,
or just don't give you something from the classic CMUCL environment.
Those in the latter category are useful in the sense that they have a
portable interface and are easier for newbies to learn, so that's a
good thing, but not relevant to you. As for the annoying and stupid
things that don't help and sometimes get in the way, for a long time I
hacked my local copy to get rid of them, but it seems that Slime is
now well factored into a basic, correctly behaving core and various
additional features. So you don't have to suffer badly implemented
features you never asked for in the first place.
Anyway, hope that's some food for thought...
-Thomas
* "Thomas F. Burdick" <····································@p2g2000prf.googlegroups.com> :
Wrote on Sun, 1 Feb 2009 12:24:36 -0800 (PST):
|
|> - 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].
|
| This is a thousand paper-cuts situation. Yes, you can find defuns with
| grep, and it works reasonably well. DESCRIBE is very nice in CMUCL.
| But getting instantly transported to the function definition site is a
| real luxury. Zipping there, looking for a second or two, then zipping
| back can help keep your head in what you're doing in a way that you
| tend to lose (or I tend to) with the other method.
Except with EMACS/SLIME window management getting in the way --- and you
end up 6 extra keystrokes to get to the point where you were before the
excursion started
| Getting a list of method signatures to choose from is also nice.
This does not work when you have (literally) 100s of methods with the
same signature. Hunting the signature down each time starting from the
same screen using the UI provided by SLIME interferes more with
development than it helps.
The same sad situation exists for the debugger and inspector --- when
you are have huge amounts of data. If SLIME cannot show you the
information you want in a few screenfuls, you have to repeat the entire
10-20 keystrokes each time around. Just getting back to your context
you were deterministically with Emacs is more painful than using the
command line.
These things will not bother the new user.
Of course since it is Emacs you can fix these things --- but that gets
in the way, and you have to end up fixing it the next time SLIME gets
rewritten. But it gets rewritten every few months with the new user
Don't get me wrong, I've been using SLIME day in and day out since 2004
and EMACS since maybe 93, and will bet my last shirt that I have clocked
up more time and knowledged of its internals than you.
It is convenient in some ways but when I have serious issues with
complex software to debug, SLIME gets in the way (more often than not)
and is liable to crash because of its threading/event model) I have to
start up a regular deterministic debugger sesssion in CMUCL without
SLIME.
--
Madhu
D Herring escreveu:
> IIRC, the editor wars are over. Emacs won. Viper-mode was introduced
> to console the losers.
I thought that beast of an OS finally got itself a decent editor. ;)