'Best' defined as an environment most like one that an experienced
programmer would be familiar with. This would include Eclipse, Visual
Studio, and (perhaps most commonly) a plain text editor combined with
gcc, g++, javac, etc.
I have given SLIME a good try, but it's too unlike the tools I use
most often for me to feel comfortable with it. I have tried LispWorks
and CLISP in a command interpreter (shell), but these still feel
awkward. I'm not particularly looking for a GUI based environment,
e.g. VS, but I'm finding that fighting with the environment is getting
in the way of using Lisp.
Thanks, CC.
On Jun 29, 9:58 am, ccc31807 <········@gmail.com> wrote:
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
If you have LispWorks already, why not try the IDE it comes with?
Allegro CL also comes with an IDE on Windows, and has a gratis trial
edition like LispWorks.
Cheers,
Pillsy
ccc31807 <········@gmail.com> writes:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it.
I think most folks would suggest that you use SLIME. Yes, emacs is very
unlike Visual Studio or Eclipse, but there are good reasons for most of
the differences and historical reasons for most the the rest.
As an example, the keys for manipulating text are not the common Ctrl-C,
Ctrl-V that you may be used to; this seems annoying. There's an
historical reason: emacs was developed before the Ctrl-C/Ctrl-V
convention existed. But there's a good reason to learn the emacs way:
it affords a much more convenient way to manipulate text. E.g. there's
C-a, which goes the the beginning of the current line (I think the
mnemonic is 'a is the beginning of the alphabet'); C-e goes to the end
of the current line; in SLIME mode C-b goes back one sexp and C-f goes
forward one sexp. The emacs equivalent to copy/paste is kill/yank, but
it's more flexible than copy/paste in that there is a killring which
saves previous selections.
Or as another example, Ctrl-S is commonly used to save; in emacs C-s is
instead used to search and saving is C-x C-s. This seems annoying, but
C-s is instead bound to an interactive forward-search, while C-r is
bound to an interactive reverse-search, and C-M-s is bound to an
interactive forward regexp search and C-M-r is bound to an interactive
reverse regexp search.
What I'm getting at is this: yes, emacs is different. But once you
learn it, it's _better_. You'll want to read your email and newsgroups
in emacs; you'll want to browse the web in emacs; you'll want to manage
your time in emacs. It really is that nice.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I admit that X is the second worst windowing system in the world,
but all the others I've used are tied for first. --Paul Tomblin
On Jun 29, 11:13 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> I think most folks would suggest that you use SLIME. Yes, emacs is very
> unlike Visual Studio or Eclipse, but there are good reasons for most of
> the differences and historical reasons for most the the rest.
I'm in the IT department of a large public university, working as a
database manager. I frequently write little scripts that munge data. I
have written in Java, C, C++, but mostly I use Perl -- in fact I find
myself writing Perl perhaps two hours a day on a light day and eight
hours on a heavy day. As an editor, I use vi, and over the years have
become quite proficient in vi.
I have made several attempts to learn EMACS, without too much success.
I'm now working through the 3rd edition of Winston and Horn using
SLIME, and continue to be frustrated by the environment. Maybe it will
take a lot of time getting used to it, and maybe in time I'll become
proficient with it, but I still resent the fact that learning my LOTY
(CL) means fighting with the implementation.
> What I'm getting at is this: yes, emacs is different. But once you
> learn it, it's _better_. You'll want to read your email and newsgroups
> in emacs; you'll want to browse the web in emacs; you'll want to manage
> your time in emacs. It really is that nice.
I'm an older guy, and like the older technologies. I still drop into
the DOS prompt, much to the dismay of my younger colleagues who can't
understand that giving a command is a lot quicker and simpler than
pointing and clicking through multiple layers of UI -- or writing,
compiling, and running a Java program using vi, javac, and java.
emacs certainly qualifies as a retrograde technology, but for me it's
brand new. I'll continue to soldier onward with SLIME, but I'll
continue to yearn for Mr. Right, speaking environmentally.
CC
ccc31807 <········@gmail.com> writes:
> On Jun 29, 11:13 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> I think most folks would suggest that you use SLIME. Yes, emacs is very
>> unlike Visual Studio or Eclipse, but there are good reasons for most of
>> the differences and historical reasons for most the the rest.
>
> I'm in the IT department of a large public university, working as a
> database manager. I frequently write little scripts that munge data. I
> have written in Java, C, C++, but mostly I use Perl -- in fact I find
> myself writing Perl perhaps two hours a day on a light day and eight
> hours on a heavy day. As an editor, I use vi, and over the years have
> become quite proficient in vi.
Ah, I misunderstood where you're coming from--I thought that you must be
someone who's used to the IDE model.
> I have made several attempts to learn EMACS, without too much success.
I was there once too. Part of the problem is that the tutorial really
wasn't useful to me, e.g. it covered C-p/C-n which I never used but
didn't mention the arrow keys which I use all the time.
How did I finally switch? Too long ago now to remember exactly; I think
I just forced myself too and then discovered that it was working pretty
well for me.
> Maybe it will take a lot of time getting used to it, and maybe in time
> I'll become proficient with it, but I still resent the fact that
> learning my LOTY (CL) means fighting with the implementation.
Not too different from learning Java and having to fight with Eclipse,
though--right?
> emacs certainly qualifies as a retrograde technology, but for me it's
> brand new. I'll continue to soldier onward with SLIME, but I'll
> continue to yearn for Mr. Right, speaking environmentally.
An approach that might work for you is to try to learn one new feature
or keystroke per day, and use it as much as you can. E.g. if you're not
used to C-b/C-f or C-M-a/C-M-e, use them constantly today.
Or install emacs-w3m and hyperspec.el and use C-c C-d h to look up Lisp
documentation within emacs...that's awfully handy.
Also, for learning Lisp you might wish to check out Practical Common
Lisp--it's excellent.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...I've seen Sun monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these things will be
lost in time, like the root partition last week. Time to die... --Peter Gutmann
ccc31807 wrote:
>
> I have made several attempts to learn EMACS, without too much success.
> I'm now working through the 3rd edition of Winston and Horn using
> SLIME,
Well, that may be part of the problem, that book is 20 years old. It's
still a pretty good book, but you may want to try something more modern
like this:
http://www.gigamonkeys.com/book/
that also includes an introduction to Slime (see Chapter 2).
> and continue to be frustrated by the environment.
What exactly is it that frustrates you?
> Maybe it will
> take a lot of time getting used to it, and maybe in time I'll become
> proficient with it, but I still resent the fact that learning my LOTY
> (CL) means fighting with the implementation.
You should be careful to distinguish the 'implementation' from the
'environment'. By implementation we usually mean a realization of the CL
standard, and there are several to choose from, both free and commercial
(CLISP, CMUCL, SBCL, Allegro, Lispworks... which one are you using,
BTW?). The development environment is the set of tools provided by your
implementation (or by an independent package like Slime) to facilitate
writing programs. Each implementation provides one, ranging from a basic
REPL to Emacs-based interfaces to complete graphical IDEs. Every CL
implementation gives you a REPL, most of them are supported by Slime,
and then there are the proprietary solutions. So you have a lot to
choose from... but it seems that your problem is simply to get used to
the Emacs way of doing things (that is only incidentally related with CL).
> I'm an older guy, and like the older technologies. I still drop into
> the DOS prompt, much to the dismay of my younger colleagues who can't
> understand that giving a command is a lot quicker and simpler than
> pointing and clicking through multiple layers of UI -- or writing,
> compiling, and running a Java program using vi, javac, and java.
Which is exactly the same thing you do when you use Emacs+Slime+CL,
except that the editor, compiler, runtime environment, debugger,
profiler, etc are all integrated...
> emacs certainly qualifies as a retrograde technology
Would you care to explain this statement?
Alberto
On 2009-06-29 16:43:50 +0100, ccc31807 <········@gmail.com> said:
> I'm in the IT department of a large public university, working as a
> database manager. I frequently write little scripts that munge data. I
> have written in Java, C, C++, but mostly I use Perl -- in fact I find
> myself writing Perl perhaps two hours a day on a light day and eight
> hours on a heavy day. As an editor, I use vi, and over the years have
> become quite proficient in vi.
I suspect (but am not sure) that one of the emacs vi-modes should work
OK with SLIME. I don't know which of them is preferred, really (I use
vi a lot at work but I've managed to avoid learning it properly, which
is a dumb decision, I know).
--tim
Tim Bradshaw <···@tfeb.org> writes:
> On 2009-06-29 16:43:50 +0100, ccc31807 <········@gmail.com> said:
>
>> I'm in the IT department of a large public university, working as a
>> database manager. I frequently write little scripts that munge data. I
>> have written in Java, C, C++, but mostly I use Perl -- in fact I find
>> myself writing Perl perhaps two hours a day on a light day and eight
>> hours on a heavy day. As an editor, I use vi, and over the years have
>> become quite proficient in vi.
>
> I suspect (but am not sure) that one of the emacs vi-modes should work
> OK with SLIME. I don't know which of them is preferred, really (I use
> vi a lot at work but I've managed to avoid learning it properly, which
> is a dumb decision, I know).
Viper-mode seems solid to me.
Paul Donnelly <·············@sbcglobal.net> wrote:
+---------------
| Tim Bradshaw <···@tfeb.org> writes:
| > I suspect (but am not sure) that one of the emacs vi-modes should work
| > OK with SLIME. ...
|
| Viper-mode seems solid to me.
+---------------
The last time I tried to learn Emacs, Vi mode was a *major* mode
[not a minor mode], and thus cannot be used while in Lisp mode.
Has that changed?!?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article
<····································@k8g2000yqn.googlegroups.com>,
ccc31807 <········@gmail.com> wrote:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
>
> Thanks, CC.
If you have access to a Macintosh I'd recommend looking at Clozure
Common Lisp. It's free, and it has an IDE. (You can also run it on
Linux and Windows but without the IDE.) It's pretty new and still has a
few rough edges, but a lot of those have been smoothed out recently.
rg
On 2009-06-29 20:01:53 +0100, Ron Garret <·········@flownet.com> said:
> If you have access to a Macintosh I'd recommend looking at Clozure
> Common Lisp. It's free, and it has an IDE. (You can also run it on
> Linux and Windows but without the IDE.) It's pretty new and still has a
> few rough edges, but a lot of those have been smoothed out recently.
I second that. When Ron says "pretty new" he actually means "pretty
old" in some ways - it's fairly directly descended from Macintosh
Common Lisp which I think is of some considerable vintage. I think the
IDE may be much newer though.
--tim
In article <·······················@tfeborg>,
Tim Bradshaw <···@tfeb.org> wrote:
> On 2009-06-29 20:01:53 +0100, Ron Garret <·········@flownet.com> said:
>
> > If you have access to a Macintosh I'd recommend looking at Clozure
> > Common Lisp. It's free, and it has an IDE. (You can also run it on
> > Linux and Windows but without the IDE.) It's pretty new and still has a
> > few rough edges, but a lot of those have been smoothed out recently.
>
> I second that. When Ron says "pretty new" he actually means "pretty
> old" in some ways - it's fairly directly descended from Macintosh
> Common Lisp which I think is of some considerable vintage. I think the
> IDE may be much newer though.
Here's the full history (and I know this because I've personally used
every product in the chain):
What is now Clozure Common Lisp started in 1986 as Coral Common Lisp
(not coincidentally also CCL). CCL 1.0 was released in 1987. It ran on
a Macintosh Plus with 1 MB of RAM. I wrote the code for my master's
thesis on this system. (NB: The power of that system relative to the
hardware it ran on has IMO never been surpassed. It was a full Common
Lisp IDE running on hardware that had a tiny fraction of the computing
power of an iPhone.)
CCL was briefly renamed Macintosh Allegro Common Lisp in a short-lived
joint venture with Franz, Inc. It was then acquired by Apple and
renamed Macintosh Common Lisp (MCL) in 1989. MCL was spun off to an
independent company called Digitool in 1994.
In 1997 or so, I hired Gary Byers, author of the MCL compiler among
other things, to work for me at JPL to port MCL to run under the vxWorks
operating system as part of an effort to get Lisp to run on a
spacecraft. (That effort was ultimately successful, but the Lisp that
flew was Harlequin, not MCL. To this day I believe that decision was a
mistake. But that's another story.) Along the way he also ported MCL
to run under Linux and Solaris. Gary is truly one of the great unsung
heros of the Lisp world.
Gary left JPL around 1999, and shortly thereafter managed to convince
Digitool to open-source his ports. Those ports included the core Lisp,
but not the IDE, which depended heavily on the peculiar architecture of
Mac OS (classic/carbon, not OS X). That fork was named OpenMCL, despite
the fact that it ran on just about everything *except* a Macintosh.
The current Clozure Common Lisp is the result of extensive develoment on
the OpenMCL fork. It has come full-circle by running under OS X, with a
new Cocoa-based IDE based on the Hemlock editor. I've been noodling
around with it for several months, and it kicks major ass. It has a
solid FFI, including an objective-C bridge that give you direct access
to Cocoa. It also has native threads. The base Lisp runs on Linux and
Windows, so you can use it to write server code. CCL has prompted me to
switch my primary development back to Lisp after wandering for many
years in the Python wilderness.
FWIW, I've spent more time programming in Lisp than any other language.
But I've never used Slime. So it can be done, and done productively.
(I do use emacs, but I'm far from what you'd call a power user.)
rg
P.S. The latest MCL was recently open-sourced and ported to run under
Rosetta, so the original MCL environment is now universally accessible
on OS X as well. (Before, you needed a PPC Mac to run it. CCL has a
native Intel compiler for both 32 and 64 bit environments, but that
compiler has never been back-ported to MCL. Because MCL is based on the
now-obsolete carbon environment its useful days are numbered.)
ccc31807 wrote:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with.
I feel a naggum coming on.
> This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
If those are what you call best, we need to work on your idea of best.
Let's lose that troublemaker of a word and change the subject to "Lisp
environment most like what us MS-possessed drones are used to"... oh,
look!...
AllegroCL IDE, available on Windows and I think Linux. Not sure of the
actual nature of the second, I use the first. Linux has a sub-par but
powerful IDE that runs cross-platform.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it.
Do I tell you my problems? If the Lisp experience makes you
uncomfortable Lisp either sucks or really is as different as you have
heard. Suggest you stop whining and start memorizing those keychords.
> I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
We do that to keep out the riff-raff. Suck it up for a week and you'll
be fine.
hth, kt
ps. Yes, Emacs+Slime is a joke of an IDE. kt
On Jun 29, 3:58 pm, ccc31807 <········@gmail.com> wrote:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
In lisp world that would be emacs probably with slime on top of it.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
You'll have to get used to it. Lisp doesn't have a multi billion $
corporation to develop the IDE and in days like today after 14
restarts of the Visual Studio I think that's an advantage rather then
a deficit..
BTW lispworks has an windows mode if you're used to win shortcuts
rather then emacs ones but you're doing yourself a bad favor. I never
liked emacs but I've learned to tolerate it. If you don't plan to buy
lw or acl I suggest to spent some time learning basic emacs and or
even better use the slime.
Slobodan
>
> Thanks, CC.
ccc31807 <········@gmail.com> writes:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
What would be the best way to go to the moon with the environment an
experienced carpenter would be familiar with. This would include
wood, scisors, saws, planes, and (perhaps most commonly) a plain
hammers combined with nails, glue, etc.
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
I have tried iron works, but it's too unlike the tools I use most
often for me to feel comforntable with it. I have tried tools to deal
with aluminium and tungstein, but these still feel awkward. I'm not
particularly looking for a woodworking shop based environment, but I'm
finding that fighting with the environent is getting in the way of
going to the Moon.
ccc31807, perhaps you could try this:
http://pagesperso-orange.fr/macareux-oiseaux/Icare/icareB.jpg
Just add wings to the legs, and of course, take of during the night:
you have to learn from the errors of your elders!
--
__Pascal Bourguignon__
ccc31807 schrieb:
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
You were speaking in general about Lisp, so I don't know if you wish to
learn Scheme, Common Lisp or Dylan, or one of the newer dialects, such
as Clojure.
If that is the case then you could use NetBeans + Enclojure. That would
be a modern IDE and sounds like what you are looking for (GUI based
environment).
http://www.enclojure.org/
If an editor is enough then you can use Lisp also via SLIME and also
via vimclojure: http://kotka.de/projects/clojure/vimclojure.html
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Tue, 30 Jun 2009 05:20:51 -0700, Thomas F. Burdick wrote:
> I don't see why it Viper wouldn't fit what you're looking for. As a vi
> replacement for programmers, it should be fine, and I disagree
> completely with Robert Uhl. For sysadmins, it would suffer from the
> usual Emacs issue of being big and slow to start up.
Lies, nothing but lies ! With the new daemon mode(emacs --daemon) and
emacsclient -t(tty mode), emacs spawns a new (terminal) frame faster than
vim(haven't tried vi).
Furthermore, to ease typing I have in .bashrc alias ed="emacsclient -t".
Vi(m) can eat my shorts :P
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
On Jun 30, 9:34 pm, Stelian Ionescu <····················@poste.it>
wrote:
> On Tue, 30 Jun 2009 05:20:51 -0700, Thomas F. Burdick wrote:
> > I don't see why it Viper wouldn't fit what you're looking for. As a vi
> > replacement for programmers, it should be fine, and I disagree
> > completely with Robert Uhl. For sysadmins, it would suffer from the
> > usual Emacs issue of being big and slow to start up.
>
> Lies, nothing but lies ! With the new daemon mode(emacs --daemon) and
> emacsclient -t(tty mode), emacs spawns a new (terminal) frame faster than
> vim(haven't tried vi).
> Furthermore, to ease typing I have in .bashrc alias ed="emacsclient -t".
> Vi(m) can eat my shorts :P
Two things: first, unless I'm terribly mistaken, none of the server/
client setups for emacs preserve the properties of the shell that
invoked the editor (uid, gid, umask, etc). That makes them nonstarters
for sysadmin work. Second, vim is not vi. Vi and nvi are small, simple
tools for unix sysadmins. Vim wishes it was emacs (and has the startup
time to match).
"Thomas F. Burdick" <········@gmail.com> writes:
>
> Two things: first, unless I'm terribly mistaken, none of the server/
> client setups for emacs preserve the properties of the shell that
> invoked the editor (uid, gid, umask, etc).
I believe that you are correct.
> That makes them nonstarters for sysadmin work.
That's actually immaterial; as with so many other things, using emacs as
a sysadmin requires a different mode of work than does vi.
With vi, one lives in a shell, navigating around--sometimes becoming
other users (normally root)--annd one fires up vi frequently. Fast
startup time is really important here.
With emacs, one lives in emacs, probably with at least one shell session
opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
access files as other users, and to run shells as those other users.
Fast startup time is not so important here, because the emacs session is
persistent.
As a matter of fact, I use both very often. They each have their strong
points. Vi is great for simple line-oriented text editing; it's
particularly good when performing the same actual a limited number of
times (I often wish that emacs had an equivalent to vi's . command).
Emacs is great for structured text editing; it's particularly good at
doing new things, or automating large tedious tasks. Now that more and
more Unix vendors are doing IMHO silly things like using XML instead of
line-oriented formats for config files I anticipate that my usage of
emacs will increase yet more.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Power corrupts. Touching the wrong capacitor corrupts absolutely.
--Anthony de Boer
On Jul 1, 4:24 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> "Thomas F. Burdick" <········@gmail.com> writes:
>
>
>
> > Two things: first, unless I'm terribly mistaken, none of the server/
> > client setups for emacs preserve the properties of the shell that
> > invoked the editor (uid, gid, umask, etc).
>
> I believe that you are correct.
>
> > That makes them nonstarters for sysadmin work.
>
> That's actually immaterial; as with so many other things, using emacs as
> a sysadmin requires a different mode of work than does vi.
Context, Robert :-)
That makes them nonstarters for sysadmin work *as vi replacements*. Of
course you can invert things and try to do all your permission
changing from within Emacs ... although honestly, I'd rather just wait
for Emacs to start up than to mess with TRAMP. And besides ... did I
mention umask? Emacs is a great programming editor, but I've never
found a happy use model for sysadmin work with it.
> With vi, one lives in a shell, navigating around--sometimes becoming
> other users (normally root)--annd one fires up vi frequently. Fast
> startup time is really important here.
Also changing gid, umask, and all number of other fiddly little
things.
> With emacs, one lives in emacs, probably with at least one shell session
> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
> access files as other users, and to run shells as those other users.
> Fast startup time is not so important here, because the emacs session is
> persistent.
This I never found especially usable. I end out with one Emacs session
for a given host/user/permission set. If I have a number of things to
do in that state, this is fine. If I just want to edit a config
file ... well, this is why I still know how to use vi.
> As a matter of fact, I use both very often. They each have their strong
> points. Vi is great for simple line-oriented text editing; it's
> particularly good when performing the same actual a limited number of
> times (I often wish that emacs had an equivalent to vi's . command).
I used to have a vi-dot command in my Emacs. I should track down that
package again.
> Emacs is great for structured text editing; it's particularly good at
> doing new things, or automating large tedious tasks. Now that more and
> more Unix vendors are doing IMHO silly things like using XML instead of
> line-oriented formats for config files I anticipate that my usage of
> emacs will increase yet more.
Not that Emacs is especially great with XML, but yeah, I'd rather use
it than vi for that purpose.
"Thomas F. Burdick" <········@gmail.com> writes:
>
>> > Two things: first, unless I'm terribly mistaken, none of the
>> > server/ client setups for emacs preserve the properties of the
>> > shell that invoked the editor (uid, gid, umask, etc).
>>
>> I believe that you are correct.
>>
>> > That makes them nonstarters for sysadmin work.
>>
>> That's actually immaterial; as with so many other things, using emacs as
>> a sysadmin requires a different mode of work than does vi.
>
> Context, Robert :-)
>
> That makes them nonstarters for sysadmin work *as vi replacements*. Of
> course you can invert things and try to do all your permission
> changing from within Emacs ... although honestly, I'd rather just wait
> for Emacs to start up than to mess with TRAMP.
C-x C-f /sudo::/etc/passwd
Or as a user other than root:
C-x C-f ··········@:/home/user/foo
TRAMP really is that easy.
> And besides ... did I mention umask?
You get it for free with sudo.
> Emacs is a great programming editor, but I've never found a happy use
> model for sysadmin work with it.
I use emacs and vi both for sysadminry.
>> With vi, one lives in a shell, navigating around--sometimes becoming
>> other users (normally root)--annd one fires up vi frequently. Fast
>> startup time is really important here.
>
> Also changing gid, umask, and all number of other fiddly little
> things.
By 'changing,' do you mean chown? Because M-! works pretty well for
that. If you mean 'edit a file as another user' then TRAMP handles
that.
>> With emacs, one lives in emacs, probably with at least one shell session
>> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
>> access files as other users, and to run shells as those other users.
>> Fast startup time is not so important here, because the emacs session is
>> persistent.
>
> This I never found especially usable. I end out with one Emacs session
> for a given host/user/permission set.
C-x C-f ···············@···················@:/home/otheruser/
It even works with tab completion!
> I used to have a vi-dot command in my Emacs. I should track down that
> package again.
I would _love_ to have that.
>> Emacs is great for structured text editing; it's particularly good at
>> doing new things, or automating large tedious tasks. Now that more and
>> more Unix vendors are doing IMHO silly things like using XML instead of
>> line-oriented formats for config files I anticipate that my usage of
>> emacs will increase yet more.
>
> Not that Emacs is especially great with XML, but yeah, I'd rather use
> it than vi for that purpose.
At least emacs can be made better at editing XML...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Curmudgeon: Someone so down on the world that he won't donate old
clothes because one day he might be mugged by someone wearing one of his
old shirts. --Unknown
From: Marc Tfardy
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <h2jeu7$i0q$1@news.onet.pl>
Robert Uhl schrieb:
>> I used to have a vi-dot command in my Emacs. I should track down that
>> package again.
>
> I would _love_ to have that.
,----[ C-h k C-x z ]
| C-x z runs the command repeat
| which is an interactive compiled Lisp function in `repeat.el'.
| It is bound to C-x z.
| (repeat repeat-arg)
|
| Repeat most recently executed command.
| With prefix arg, apply new prefix arg to that command; otherwise,
| use the prefix arg that was used before (if any).
| This command is like the `.' command in the vi editor.
|
| If this command is invoked by a multi-character key sequence, it
| can then be repeated by repeating the final character of that
| sequence. This behavior can be modified by the global variable
| `repeat-on-final-keystroke'.
|
| `repeat' ignores commands bound to input events. Hence the term
| "most recently executed command" shall be read as "most
| recently executed command not bound to an input event".
|
`----
or: http://www.eskimo.com/~seldon/vi-dot.el
from http://www.eskimo.com/~seldon/
regards
Marc
Marc Tfardy <···@cyk.cyk> writes:
>
>>> I used to have a vi-dot command in my Emacs. I should track down that
>>> package again.
>>
>> I would _love_ to have that.
>
> | C-x z runs the command repeat
You, sir, are my hero.
Emacs...is there anything it can't do?
--
Robert Uhl <http://public.xdi.org/=ruhl>
I'm proud to be an old-fashioned bigoted unixoid. They'll take my
keyboard away from me when they pry it from the shattered skulls of my
enemies. --Mark Hughes
On Wed, 01 Jul 2009 08:24:46 -0600, Robert Uhl wrote:
> With vi, one lives in a shell, navigating around--sometimes becoming
> other users (normally root)--annd one fires up vi frequently. Fast
> startup time is really important here.
>
> With emacs, one lives in emacs, probably with at least one shell session
> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
> access files as other users, and to run shells as those other users.
> Fast startup time is not so important here, because the emacs session is
> persistent.
Again, wrong! I use a daemonized emacs and pop up frames with emacsclient
whenever I need. I can be done, people
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
Stelian Ionescu <····················@poste.it> writes:
> On Wed, 01 Jul 2009 08:24:46 -0600, Robert Uhl wrote:
>> With vi, one lives in a shell, navigating around--sometimes becoming
>> other users (normally root)--annd one fires up vi frequently. Fast
>> startup time is really important here.
>>
>> With emacs, one lives in emacs, probably with at least one shell session
>> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
>> access files as other users, and to run shells as those other users.
>> Fast startup time is not so important here, because the emacs session is
>> persistent.
>
> Again, wrong! I use a daemonized emacs and pop up frames with
> emacsclient whenever I need. I can be done, people
Not if you need your uid, gid & umask to be those of another user,
e.g. if one is a sysadmin...which is what Mr. Burdick referred to.
--
Every time I read up about the next XML "solution" it feels like someone just
missed the point of the Lisp syntax, S expressions, and tried to achieve the
same results by sticking a salad fork in their brain, swirling for a while,
then recording the results. --Daniel Pittman
"Thomas F. Burdick" <········@gmail.com> writes:
> I don't see why it Viper wouldn't fit what you're looking for. As a vi
> replacement for programmers, it should be fine, and I disagree
> completely with Robert Uhl. For sysadmins, it would suffer from the
> usual Emacs issue of being big and slow to start up.
and since the usual Vi these days is actually Vim, the above usual issue
is not actually an issue any more.
Michael Livshin <······@cmm.kakpryg.net> writes:
>
>> I don't see why it Viper wouldn't fit what you're looking for. As a
>> vi replacement for programmers, it should be fine, and I disagree
>> completely with Robert Uhl. For sysadmins, it would suffer from the
>> usual Emacs issue of being big and slow to start up.
>
> and since the usual Vi these days is actually Vim, the above usual
> issue is not actually an issue any more.
Wow--you're right. On my machine, I can run emacs --no-init then C-x
C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
Of course, emacs with my normal .emacs takes 2.853 seconds...
--
Robert Uhl <http://public.xdi.org/=ruhl>
If something's expensive to develop, and somebody's not going to get
paid, it won't get developed. So you decide: Do you want software to be
written, or not? --Bill Gates doesn't foresee the FSF or Linux, 1980
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| Michael Livshin <······@cmm.kakpryg.net> writes:
| >> For sysadmins, it would suffer from the
| >> usual Emacs issue of being big and slow to start up.
| >
| > and since the usual Vi these days is actually Vim, the above usual
| > issue is not actually an issue any more.
|
| Wow--you're right. On my machine, I can run emacs --no-init then C-x
| C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
| Of course, emacs with my normal .emacs takes 2.853 seconds...
+---------------
Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
On my laptop, Vi (nvi-1.79) takes 0.83 s to
start up & exit the first time; only 7 ms thereafter!!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, 30 Jun 2009 18:32:47 -0500, ····@rpw3.org (Rob Warnock) said:
> ...
> On my laptop, Vi (nvi-1.79) takes 0.83 s to
> start up & exit the first time; only 7 ms thereafter!!
Is that faster than `ed'?
---Vassil,
who couldn't resist...
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Vassil Nikolov <········@pobox.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) said:
| > On my laptop, Vi (nvi-1.79) takes 0.83 s to
| > start up & exit the first time; only 7 ms thereafter!!
|
| Is that faster than `ed'?
+---------------
Not even close! The "ed" program takes only ~1 ms to start up & exit
[mode of 500 runs]. Though note that when I run Vi [as "ex"] 500 times
in a row, it takes only ~5 ms, so "ed" is really "only" 5x faster at
startup.
But seriously, any startup time less than ~100ms is negligible to
a human, so who cares? ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jul 1, 1:32 am, ····@rpw3.org (Rob Warnock) wrote:
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
> +---------------
> | Michael Livshin <······@cmm.kakpryg.net> writes:
> | >> For sysadmins, it would suffer from the
> | >> usual Emacs issue of being big and slow to start up.
> | >
> | > and since the usual Vi these days is actually Vim, the above usual
> | > issue is not actually an issue any more.
> |
> | Wow--you're right. On my machine, I can run emacs --no-init then C-x
> | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
> | Of course, emacs with my normal .emacs takes 2.853 seconds...
> +---------------
>
> Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
> On my laptop, Vi (nvi-1.79) takes 0.83 s to
> start up & exit the first time; only 7 ms thereafter!!
Not to argue against the venerable usenet tradition of discussions
that go flying off on a random tangent ... but weren't we talking
about whether Emacs+Slime+Viper could serve as a modal IDE? For this
purpose, you would *not* want to be constantly starting and shutting
down your editor: you want it to stay connected to the Lisp :-)
Thomas F. Burdick <········@gmail.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > Robert Uhl �<·········@NOSPAMgmail.com> wrote:
...
| > | Wow--you're right. �On my machine, I can run emacs --no-init then C-x
| > | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
| > | Of course, emacs with my normal .emacs takes 2.853 seconds...
| > +---------------
| >
| > Which is why I use real Vi, and *NOT* Vim!! �;-} �;-}
| > On my laptop, Vi (nvi-1.79) takes 0.83 s to
| > start up & exit the first time; only 7 ms thereafter!!
|
| Not to argue against the venerable usenet tradition of discussions
| that go flying off on a random tangent ... but weren't we talking
| about whether Emacs+Slime+Viper could serve as a modal IDE? For this
| purpose, you would *not* want to be constantly starting and shutting
| down your editor: you want it to stay connected to the Lisp :-)
+---------------
Yes, of course, thanks for dragging us back on-topic. [I'm afraid
I let myself get dragged down the "startup time" rathole... (*sigh*)]
And it wasn't quite "whether Emacs+Slime+Viper could serve as a
modal IDE", but "whether Emacs+Slime+Viper could serve as a Lisp IDE
with a modal editor even when editing Lisp". I know the difference
may sound subtle, but it's important. I have no problems using Emacs
chords -- or, better, M-x long-commands -- for the IDE functions.
I just want navigation/insertion/editing to work like Vi (modal editing).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jul 1, 1:03 pm, ····@rpw3.org (Rob Warnock) wrote:
> Thomas F. Burdick <········@gmail.com> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) wrote:
> | > Robert Uhl <·········@NOSPAMgmail.com> wrote:
> ...
> | > | Wow--you're right. On my machine, I can run emacs --no-init then C-x
> | > | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
> | > | Of course, emacs with my normal .emacs takes 2.853 seconds...
> | > +---------------
> | >
> | > Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
> | > On my laptop, Vi (nvi-1.79) takes 0.83 s to
> | > start up & exit the first time; only 7 ms thereafter!!
> |
> | Not to argue against the venerable usenet tradition of discussions
> | that go flying off on a random tangent ... but weren't we talking
> | about whether Emacs+Slime+Viper could serve as a modal IDE? For this
> | purpose, you would *not* want to be constantly starting and shutting
> | down your editor: you want it to stay connected to the Lisp :-)
> +---------------
>
> Yes, of course, thanks for dragging us back on-topic. [I'm afraid
> I let myself get dragged down the "startup time" rathole... (*sigh*)]
>
> And it wasn't quite "whether Emacs+Slime+Viper could serve as a
> modal IDE", but "whether Emacs+Slime+Viper could serve as a Lisp IDE
> with a modal editor even when editing Lisp". I know the difference
> may sound subtle, but it's important.
Yeah, actually that's what I meant. I didn't mean to imply that you'd
have a navigation mode, editing mode, evaluation mode, debugging mode,
etc.
> I have no problems using Emacs
> chords -- or, better, M-x long-commands -- for the IDE functions.
> I just want navigation/insertion/editing to work like Vi (modal editing).
That's not a problem. My group at work has an Emacs-based IDE for the
(Cadence proprietary) Skill dialect of Lisp, and I make a point of
ensuring that it works with Viper as well. The few issues that have
come up over time weren't due to Lisp-Mode, and were nothing more than
minor annoyances.
On 2009-06-30, Rob Warnock <····@rpw3.org> wrote:
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
> +---------------
>| Michael Livshin <······@cmm.kakpryg.net> writes:
>| >> For sysadmins, it would suffer from the
>| >> usual Emacs issue of being big and slow to start up.
>| >
>| > and since the usual Vi these days is actually Vim, the above usual
>| > issue is not actually an issue any more.
>|
>| Wow--you're right. On my machine, I can run emacs --no-init then C-x
>| C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
>| Of course, emacs with my normal .emacs takes 2.853 seconds...
> +---------------
>
> Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
Good thing you put in those smileys.
nvi real?
nvi is an offshoot of Steve Kirkendall's Elvis, which was first released in
1990. The 1.79 version that is still in wide use, and shipping in OpenBSD and
others dates back to 1997.
This program has nothing to do with any code written by Bill Joy,
which would be the prime requirement for calling anything ``real vi''.
Moolenaar's Vim existed in an unreleased 1.0 form in 1988; but its first public
release was in 1991. It wasn't from scratch, but rather some bugfixes and
enhancements to Stevie, a vi-like editor by Tim Thompson, which was
posted to Usenet in 1987.
So Vim has a more ancient lineage than nvi.
nvi's saving grace is a high degree of compatibility with Unix (TM) vi,
thanks to hacking by Keith Bostic. As far as actual features and ueseability
are concerned, nvi badly sucks compared to later versions of Elvis, and
compared to 1997 vintage Vim.
On Jun 29, 2:58 pm, ccc31807 <········@gmail.com> wrote:
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
You could try ABLE (http://phil.nullable.eu/). I also have a newer
version with the things people have been asking for (e.g. menus and
tabbed editing) in testing which I can send you if you're
interested...
-- phil