Hello, all.
I would like to know which LISP editor is /choice/ amongst the group.
I'm fascinated by all I've read about LISP and have been learning with
it on my own just for fun. I am, however, having a difficult time
*loving* emacs. Is that heresy?
~)ason
--
Jason Chesshir
·····@kioken.com
Jason Chesshir <·····@kioken.com> writes:
> I would like to know which LISP editor is /choice/ amongst the group.
> I'm fascinated by all I've read about LISP and have been learning with
> it on my own just for fun. I am, however, having a difficult time
> *loving* emacs. Is that heresy?
The key thing about Emacs, and editors like it, is that they support
various important operations for managing lisp expressions. Balanced
paren flashing, for example, and the ability to do single-keystroke
motion commands like forward-expression, backward-expression,
delete-expression-forward, delete-expression-backward, up-expression,
and so on. If you find another editor that can do these, you might also
be happy.
But Emacs is always reprogrammable, too. [Side bit of history about
Emacs: Once for a Lisp class at MIT I was helping Sussman with, I made
a little teeny editor called Minemacs that contained a useful subset
of Emacs but was missing commands that I thought would confuse people
and make it hard to teach. Stallman just about flipped out. He said
I shouldn't use the name "emacs" in the name because the defining
characteristic of Emacs is not its command set but its
reprogrammability. He said it was fine if I'd offered some other
editor's command set and called it Emacs as long as it was
reprogrammable. It was out of this event that the Emacs "novice"
library got created (I think we were still using old Teco-based Emacs
then, so it may not still exist); I think the modern incarnation of
the novice library is the feature of Emacs where when you do certain
commands like c-x c-n or c-x c-l it will stop you and ask you if you
know what you're doing.]
What exactly is it you don't like about Emacs, btw?
Kent M Pitman <······@world.std.com> wrote:
>Jason Chesshir <·····@kioken.com> writes:
+---------------
| The key thing about Emacs, and editors like it, is that they support
| various important operations for managing lisp expressions. Balanced
| paren flashing, for example, and the ability to do single-keystroke
| motion commands like forward-expression, backward-expression,
| delete-expression-forward, delete-expression-backward, up-expression,
| and so on. If you find another editor that can do these, you might also
| be happy.
+---------------
Note that most "vi" variants/clones include most of this set of features.
Balanced paren-flashing, of course. Single-keystroke forward/backward
expression: If you're on the left or right paren of an s-expr, the "%"
key will move the cursor to the matching paren. Likewise, if you're on
the left or right paren of an s-expr, "d%" will delete the s-expr. If by
"up-expression" you mean go out one level, well, that's not always *one*
keystroke, but usually a short sequence of "%" + space will get you to
the end fast enough, or "f)%" to step backwards to the beginning. And
the autoindent makes it easy enough to format Lisp properly, even if it
doesn't *enforce* proper indenting or do form-dependent indenting for you.
And FWIW, the latest version of "nvi" has hooks for extensibility with
Perl or Tcl (or your favorite scripting interpreter).
So while "vi" will never be as perfectly tuned to Lisp as Emacs is,
for me it's good enough... [Which is fortunate for me since, sadly,
my fingers just don't seem to work correctly with typing control keys
all the time.]
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> >Jason Chesshir <·····@kioken.com> writes:
> +---------------
> | The key thing about Emacs, and editors like it, is that they support
> | various important operations for managing lisp expressions. Balanced
> | paren flashing, for example, and the ability to do single-keystroke
> | motion commands like forward-expression, backward-expression,
> | delete-expression-forward, delete-expression-backward, up-expression,
> | and so on. If you find another editor that can do these, you might also
> | be happy.
> +---------------
>
> Note that most "vi" variants/clones include most of this set of features.
> Balanced paren-flashing, of course. Single-keystroke forward/backward
> expression: If you're on the left or right paren of an s-expr, the "%"
> key will move the cursor to the matching paren. Likewise, if you're on
> the left or right paren of an s-expr, "d%" will delete the s-expr. If by
> "up-expression" you mean go out one level, well, that's not always *one*
> keystroke, but usually a short sequence of "%" + space will get you to
> the end fast enough, or "f)%" to step backwards to the beginning. And
> the autoindent makes it easy enough to format Lisp properly, even if it
> doesn't *enforce* proper indenting or do form-dependent indenting
> for you.
Exactly one of the reasons (beyond ILISP, IMH and bieased opinion) why
you loose if you go the '*vi*' way.
> And FWIW, the latest version of "nvi" has hooks for extensibility with
> Perl or Tcl (or your favorite scripting interpreter).
Thank you for some new and even stronger arguments why it is evil to
use this kind of stuff :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> wrote:
+---------------
| Exactly one of the reasons (beyond ILISP, IMH and bieased opinion) why
| you loose if you go the '*vi*' way.
+---------------
Look, I am *NOT* "advocating" Vi over Emacs. I would *love* to use
Emacs... if I could. But I've tried several times, failing each time.
I've never even made it all the way through the introductory on-line
tutorial. My fingers and/or head just don't "get it". Call it a defect
in my character, or some obscure form of brain damage, whatever.
All I was trying to do is point out that for others in the same or
similar situations, you *can* still do Lisp programming fairly
conveniently (e.g., paren-matching, whole s-expr cut&paste, etc.)
with some editors. (Losing, of course, the other benefits of Emacs such
as ILISP, Gnus, infinite configurability in "a Lisp", etc., but still...)
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
>
> Look, I am *NOT* "advocating" Vi over Emacs. I would *love* to use
> Emacs... if I could. [SNIP]
> My fingers and/or head just don't "get it".
One thing which *definitely* helps, IMO, is, if you're using
one of those modern (read: trashy) keyboards, DO swap the
location of control with Caps lock, so that your left pinky
can use Control, and your left thumb can use Meta.
This makes the C-M-* expressions much easier.
Also, when you get that, if C-f is forward-char, and M-f
is forward-word, then C-M-f will be forward-sentence
(and so on for all other movement keystrokes), you'll
latch onto it quickly enough.
Don't give up on emacs: the time you invest now will be
repaid 100fold over the next 20 years...
--ap
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
> One thing which *definitely* helps, IMO, is, if you're using
> one of those modern (read: trashy) keyboards, DO swap the
> location of control with Caps lock, so that your left pinky
> can use Control, and your left thumb can use Meta.
The control keys are to the left and right of the space bar
on the Symbolics space-cadet keyboard.
--
Le Hibou
"The reasonable man adapts himself to the world; the unreasonable
one persists in trying to adapt the world to himself. Therefore
all progress depends on the unreasonable man." -- G.B. Shaw
Donald Fisk <················@enterprise.net> writes:
> Alain Picard wrote:
>
> > One thing which *definitely* helps, IMO, is, if you're using
> > one of those modern (read: trashy) keyboards, DO swap the
> > location of control with Caps lock, so that your left pinky
> > can use Control, and your left thumb can use Meta.
>
> The control keys are to the left and right of the space bar
> on the Symbolics space-cadet keyboard.
Hum... so?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
>
> Donald Fisk <················@enterprise.net> writes:
>
> > Alain Picard wrote:
> >
> > > One thing which *definitely* helps, IMO, is, if you're using
> > > one of those modern (read: trashy) keyboards, DO swap the
> > > location of control with Caps lock, so that your left pinky
> > > can use Control, and your left thumb can use Meta.
> >
> > The control keys are to the left and right of the space bar
> > on the Symbolics space-cadet keyboard.
>
> Hum... so?
Presumably Lisp machine keyboard designers put some thought into
where the control and meta keys ought to be for optimal use of
Zmacs, and decided that they should be on the same line as the
space bar. (Though why they put the rubout key immediately left
of A bothers me. I suppose you get used to it after a while.)
--
Le Hibou
"The reasonable man adapts himself to the world; the unreasonable
one persists in trying to adapt the world to himself. Therefore
all progress depends on the unreasonable man." -- G.B. Shaw
Donald Fisk <················@enterprise.net> writes:
(Though why they put the rubout key immediately left
> of A bothers me. I suppose you get used to it after a while.)
An easy to reach rubout key doesn't punish you for making mistakes!
>>>>> On Wed, 06 Jun 2001 22:22:14 +0100, Donald Fisk ("Donald") writes:
Donald> Alain Picard wrote:
>>
>> Donald Fisk <················@enterprise.net> writes:
>>
>> > Alain Picard wrote:
>> >
>> > > One thing which *definitely* helps, IMO, is, if you're using
>> > > one of those modern (read: trashy) keyboards, DO swap the
>> > > location of control with Caps lock, so that your left pinky
>> > > can use Control, and your left thumb can use Meta.
>> >
>> > The control keys are to the left and right of the space bar
>> > on the Symbolics space-cadet keyboard.
>>
>> Hum... so?
Donald> Presumably Lisp machine keyboard designers put some thought into
Donald> where the control and meta keys ought to be for optimal use of
Donald> Zmacs, and decided that they should be on the same line as the
Donald> space bar. (Though why they put the rubout key immediately left
Donald> of A bothers me. I suppose you get used to it after a while.)
Yes: they copied the layout of the keyboards from the MIT PDP-10 system
(the Knight TV's on ITS) which was optimized for Emacs (which was invented there).
Rob> If you're on the left or right paren of an s-expr, the "%"
Rob> key will move the cursor to the matching paren.
(Not to be nitpicking, but this requires pressing the shift key on most
keyboards. Granted, this is less than Control-Meta)
Philip
--
If you have a procedure with 10 parameters, you probably missed some. (Kraulis)
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
In article <··············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>Kent M Pitman <······@world.std.com> wrote:
>+---------------
>| The key thing about Emacs, and editors like it, is that they support
>| various important operations for managing lisp expressions. Balanced
>| paren flashing, for example, and the ability to do single-keystroke
>| motion commands like forward-expression, backward-expression,
>| delete-expression-forward, delete-expression-backward, up-expression,
>| and so on. If you find another editor that can do these, you might also
>| be happy.
>+---------------
>
>Note that most "vi" variants/clones include most of this set of features.
>Balanced paren-flashing, of course. Single-keystroke forward/backward
>expression: If you're on the left or right paren of an s-expr, the "%"
>key will move the cursor to the matching paren. Likewise, if you're on
>the left or right paren of an s-expr, "d%" will delete the s-expr. If by
>"up-expression" you mean go out one level, well, that's not always *one*
>keystroke, but usually a short sequence of "%" + space will get you to
>the end fast enough, or "f)%" to step backwards to the beginning. And
>the autoindent makes it easy enough to format Lisp properly, even if it
>doesn't *enforce* proper indenting or do form-dependent indenting for you.
>
>And FWIW, the latest version of "nvi" has hooks for extensibility with
>Perl or Tcl (or your favorite scripting interpreter).
>
>So while "vi" will never be as perfectly tuned to Lisp as Emacs is,
>for me it's good enough... [Which is fortunate for me since, sadly,
>my fingers just don't seem to work correctly with typing control keys
>all the time.]
Many Lispers are put off by vi's default indents
for Lisp code. An option is to use an external
!filter, but that doesn't help in autoindenting.
Luckily, vim is open-source, so I could change the
defaults (the table in function lisp_match in
file misc1.c) quite easily. It would be nice if vim
had an .exrc option to which one could +/- Lisp
keywords without having to change the source. Perhaps
Bram Moolenaar can be persuaded to allow this
capability eventually.
It's heartening to note there is a non-zero population
that doesn't consider a preference for vi as an editor
and a preference for (non-Emacs) Lisps as
proglangs to be mutually exclusive!
--d
Dorai Sitaram <····@goldshoe.gte.com> wrote:
+---------------
| Rob Warnock <····@rigden.engr.sgi.com> wrote:
| >So while "vi" will never be as perfectly tuned to Lisp as Emacs is,
| >for me it's good enough...
|
| Many Lispers are put off by vi's default indents for Lisp code.
| An option is to use an external !filter...
+---------------
Such as your very own "scmindent", eh? ;-} ;-}
<URL:http://www.cs.rice.edu/~dorai/scmindent/scmindent.html>
+---------------
| but that doesn't help in autoindenting.
+---------------
Yeah, well, I guess autoindenting just isn't very high on my wish-list.
I guess I just don't find indenting consistently to be all that difficult.
[Especially since Vi's ">%" and "<%" commands do a fine job of reindenting
multi-line s-exprs, particularly if you ":set shiftwidth=1" first, and
then use the "." to repeat as needed.]
+---------------
| It's heartening to note there is a non-zero population that doesn't
| consider a preference for vi as an editor and a preference for
| (non-Emacs) Lisps as proglangs to be mutually exclusive!
+---------------
Indeed!
And again, I am *NOT* trying to make any kind of "Emacs *versus* Vi"
statements here! Only saying that *if* (for whatever reason) someone
doesn't feel comfortable using Emacs (as I don't, despite multiple tries),
there are other editors (such as Vi &c) that *might* work "well enough"
for you when doing Lisp programming.
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> >Jason Chesshir <·····@kioken.com> writes:
> +---------------
> | The key thing about Emacs, and editors like it, is that they support
> | various important operations for managing lisp expressions. Balanced
> | paren flashing, for example, and the ability to do single-keystroke
> | motion commands like forward-expression, backward-expression,
> | delete-expression-forward, delete-expression-backward, up-expression,
> | and so on. If you find another editor that can do these, you might also
> | be happy.
> +---------------
>
> Note that most "vi" variants/clones include most of this set of features.
> Balanced paren-flashing, of course. Single-keystroke forward/backward
> expression: If you're on the left or right paren of an s-expr, the "%"
> key will move the cursor to the matching paren. Likewise, if you're on
> the left or right paren of an s-expr, "d%" will delete the s-expr. If by
> "up-expression" you mean go out one level, well, that's not always *one*
> keystroke, but usually a short sequence of "%" + space will get you to
> the end fast enough, or "f)%" to step backwards to the beginning. And
> the autoindent makes it easy enough to format Lisp properly, even if it
> doesn't *enforce* proper indenting or do form-dependent indenting
> for you.
imho the lack of form-dependent indenting is a *huge* loss. i do not
want to count parens. i just hit M-q and look how the indent shakes
itself out (letting emacs count parens for me). i can better see the
structure by the indentation.
> And FWIW, the latest version of "nvi" has hooks for extensibility with
> Perl or Tcl (or your favorite scripting interpreter).
>
> So while "vi" will never be as perfectly tuned to Lisp as Emacs is,
> for me it's good enough... [Which is fortunate for me since, sadly,
> my fingers just don't seem to work correctly with typing control keys
> all the time.]
you could try emacs' viper mode.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Jason Chesshir <·····@kioken.com> writes:
> Hello, all.
>
> I would like to know which LISP editor is /choice/ amongst the group.
> I'm fascinated by all I've read about LISP and have been learning with
> it on my own just for fun. I am, however, having a difficult time
> *loving* emacs. Is that heresy?
No. It is a serious sign that you need therapy. Pretty much like all
the serious Emacs lovers :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
It isn't that I don't like Emacs. I am new to it, and am not loving it the
way I've known others to. I can get used to the C-x method of controls - it
reminds me of older Lotus 1-2-3 when you fired user defined macros with M-x
style commands. Perhaps I just need time to adjust. I am still unclear why
C-n, C-p, C-b, C-f are necessary.
~)ason
--
Jason Chesshir
·····@kioken.com
Jason Chesshir <·····@kioken.com> writes:
> It isn't that I don't like Emacs. I am new to it, and am not loving it the
> way I've known others to. I can get used to the C-x method of controls - it
> reminds me of older Lotus 1-2-3 when you fired user defined macros with M-x
> style commands. Perhaps I just need time to adjust. I am still unclear why
> C-n, C-p, C-b, C-f are necessary.
They aren't necessary until you have to telnet into your machine and
get stuck with some brain dead terminal settings. Fortunately, I only
do this every blue moon, the rest of the time the little arrow keys
work just fine.
-Eric
>>>>> "Jason" == Jason Chesshir <·····@kioken.com> writes:
Jason> I am still unclear why C-n, C-p, C-b, C-f are necessary.
For the same reason why one has hjkl in VI: one need not move far from
the home position to move the cursor. Moving completely off the
keyboard to the arrow keys or mouse in order to move the cursor can
become very annoying in heavy-duty editing sessions.
--
"His power lies apparently in his ability to choose incompetent
enemies." - Crow T. Robot, MST3K, "Prince of Space"
> Jason> I am still unclear why C-n, C-p, C-b, C-f are necessary.
>
> For the same reason why one has hjkl in VI: one need not move far from
> the home position to move the cursor. Moving completely off the
> keyboard to the arrow keys or mouse in order to move the cursor can
> become very annoying in heavy-duty editing sessions.
Yeah, but in VI, you always have to hit the ESC key to drop out of
insert mode, and if you look at the ESC key's position on the keyboard,
it's located way the f_ck away from the "home position". I find this
extremely disruptive.
However, emacs has some disadvantages in comparision to VI as well.
Some of the key combinations are pretty insane. And VI's ability to
delete-fwd to char with a simple "df <CHAR>" rocks.
Quite frankly, neither editor is "ideal". MS-Word has some really nice
key combinations that I miss from my Windows days. Maybe I'll map them
into emacs...
--
··········@att.net
>>>>> On Fri, 01 Jun 2001 02:15:57 GMT, Ted Sandler ("Ted") writes:
Ted> However, emacs has some disadvantages in comparision to VI as well.
Ted> Some of the key combinations are pretty insane. And VI's ability to
Ted> delete-fwd to char with a simple "df <CHAR>" rocks.
You can change the Emacs key combinations to whatever you like.
Here is a function that does what I think you're asking for,
and following it is the form to bind it to the F6 key.
(You can put it on some other key, if you prefer.)
(defun delete-forward-to-char (char)
"Delete forward to specified character."
(interactive "cChar: ")
(let* ((str (char-to-string char))
(end (save-excursion (if (search-forward str nil t) (point)))))
(if end
(delete-region (point) end)
(signal 'search-failed (list str)))))
(global-set-key '[f6] 'delete-forward-to-char)
>>>>> On Fri, 01 Jun 2001 00:28:35 -0500, Thore B Karlsen ("Thore") writes:
Thore> Some of these "Emacs can do it too!"-solutions are pretty hilarious.
Thore> No offense, but this is just too inconvenient to be practical.
I don't understand why you think the program that I wrote to your
specifications is "hilarious" or "inconvenient". You said that Emacs
was missing some random favorite command from some other editor.
I added exactly that command to Emacs for you, and I think the fact
that it took me about 5 minutes to do so is evidence that Emacs is
a system that provides good solutions.
Thore> And mapping editing commands to function keys? Ouch. My fingers hurt
Thore> just thinking about it. Even the cursor keys are a stretch. :)
Apparently I was not clear in my explanation. You can change all the
key bindings for any Emacs command around to whatever you like.
They do not have to be function keys; they can be any keys.
You can put that command on the "d" key, for example, if you like.
Oh, and I forgot -- you're welcome.
>>>>> On Fri, 01 Jun 2001 00:28:35 -0500, Thore B Karlsen ("Thore") writes:
Thore> Even if you defined functions for all the neat Vim editing shortcuts
Thore> (a task in itself) you still wouldn't wouldn't have the power of modality.
People have implemented modality for Emacs, for people who prefer "vi".
This could, with about ten mintues work, probably be adapted to whatever
it is that "Vim" does. I bet implementing all of Vim would take only
a few hours. But people who prefer to use Vim might as well just use Vim
in the first place -- why should they use Emacs? But please don't make
ignorant suggestions that Emacs could not do what Vim does on the basis
that most Emacs users would not want to do that.
I'm signing off from this weird discussion, since your positions are
clearly religous and not technical: you aren't looking for information
or constuctive help, and I certainly have no interest in your opinions.
Thore B. Karlsen wrote:
> So please, please tell me where my positions have been clearly
> religious. It seems your statement about implementing all of Vim in a
> couple of hours is clearly a more religious and derogatory remark than
> anything I have ever posted in this thread.
Many may feel uncomfortable with the fact that you insist that someone has
to say a "You're right" until you stop talking. Every individual can have
every opinion he/she want's - but there is a difference in tolerating other
opinions and being forced to explicitely say that someone is right.
Regards,
Jochen
Thore B. Karlsen wrote:
> On Fri, 1 Jun 2001 12:08:22 +0200, Jochen Schmidt <···@dataheaven.de>
> wrote:
>
>>> So please, please tell me where my positions have been clearly
>>> religious. It seems your statement about implementing all of Vim in a
>>> couple of hours is clearly a more religious and derogatory remark than
>>> anything I have ever posted in this thread.
>
>>Many may feel uncomfortable with the fact that you insist that someone has
>>to say a "You're right" until you stop talking. Every individual can have
>>every opinion he/she want's - but there is a difference in tolerating
>>other opinions and being forced to explicitely say that someone is right.
>
> Please don't tell me you took those remarks seriously. How on Earth
> could you not see that I was joking?
A curious way to explain your unability to transmit your intention.
You seem to assume that I'am too dumb for your jokes...
Jochen Schmidt
Thore B. Karlsen wrote:
> On Fri, 1 Jun 2001 16:43:26 +0200, Jochen Schmidt <···@dataheaven.de>
> wrote:
>>A curious way to explain your unability to transmit your intention.
>>You seem to assume that I'am too dumb for your jokes...
>
> No, but perhaps you just didn't notice the smileys.
>
> http://www.pfccheatsheet.com/fnemot98.htm
>
> :-) user is smiling or joking
> ;-) user is being mischievous or sarcastic
Thanks for teaching me the fundamtental basics of network-jargon - I'm so
happy now that I finally understand it!!!!!!!!!! I cannot even imagine how
I could have lived further without your valuable help....
_You_ seem to misunderstand _my_ critique - I have not replied on message
Message-ID: <··································@4ax.com>
but on your statement in
Message-ID: <··································@4ax.com>
where you stated that you don't understand why others got the impression
that you're a bit religious in your opinions to the topic "Emacs vs. Vi".
I got the impression that most people here have some favorite editor and
all have good reasons for using it - but only few are trying to _defend_
their choose against others or forcing others to agree with them.
I assume that most readers here have read so many incarnations of this
"Emacs vs. Vi" topic that they simply can't stand it any more. Please try
to understand that this is a discussion that will _never_ really lead to a
"solution" - so let's better stop it here and let every hacker use it's
chosen tools...
Jochen Schmidt
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On Fri, 1 Jun 2001 04:29:51 GMT, Christopher Stacy
> <······@spacy.Boston.MA.US> wrote:
>
> > Ted> However, emacs has some disadvantages in comparision to VI as well.
> > Ted> Some of the key combinations are pretty insane. And VI's ability to
> > Ted> delete-fwd to char with a simple "df <CHAR>" rocks.
>
> >You can change the Emacs key combinations to whatever you like.
> >Here is a function that does what I think you're asking for,
> >and following it is the form to bind it to the F6 key.
> >(You can put it on some other key, if you prefer.)
> >
> >(defun delete-forward-to-char (char)
> > "Delete forward to specified character."
> > (interactive "cChar: ")
> > (let* ((str (char-to-string char))
> > (end (save-excursion (if (search-forward str nil t) (point)))))
> > (if end
> > (delete-region (point) end)
> > (signal 'search-failed (list str)))))
> >
> >
> >(global-set-key '[f6] 'delete-forward-to-char)
>
> Some of these "Emacs can do it too!"-solutions are pretty hilarious. No
> offense, but this is just too inconvenient to be practical. Vim has tons
> and tons of these change and motion commands, and all possible
> combinations of them. I use most of them extensively, and there just
> aren't enough sensible keys to map them to in a non-modal editor. You
> could probably map some of the more common ones, but you'd end up with
> RSI like Stallman if you were to use them as often as their use would be
> convenient. Even if you defined functions for all the neat Vim editing
> shortcuts (a task in itself) you still wouldn't wouldn't have the power
> of modality.
>
> And mapping editing commands to function keys? Ouch. My fingers hurt
> just thinking about it. Even the cursor keys are a stretch. :)
Will it help if I tell you that this is a standard function in
Emacs? It's called zap-to-char, and it's bound to M-z.
There's absolutely no doubt in me that, for editing and
programming, the various Emacsen have *much* more useful functionality
than Vim will ever have. I've been using Emacs for about 12 years now,
and I'm still discovering functionality that makes my work easier (and
some of that has been part of Emacs for all the time I've used it, at
least.)
--
Raymond Wiker
·············@fast.no
GNU Emacs already has zap-to-char, bound to M-z.
It differs from your delete-forward-to-char by saving the zapped
text in the kill ring and parsing a prefix argument.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On Fri, 1 Jun 2001 04:29:51 GMT, Christopher Stacy
> <······@spacy.Boston.MA.US> wrote:
>
> > Ted> However, emacs has some disadvantages in comparision to VI as well.
> > Ted> Some of the key combinations are pretty insane. And VI's ability to
> > Ted> delete-fwd to char with a simple "df <CHAR>" rocks.
>
> >You can change the Emacs key combinations to whatever you like.
> >Here is a function that does what I think you're asking for,
> >and following it is the form to bind it to the F6 key.
> >(You can put it on some other key, if you prefer.)
> >
> >(defun delete-forward-to-char (char)
> > "Delete forward to specified character."
> > (interactive "cChar: ")
> > (let* ((str (char-to-string char))
> > (end (save-excursion (if (search-forward str nil t) (point)))))
> > (if end
> > (delete-region (point) end)
> > (signal 'search-failed (list str)))))
> >
> >
> >(global-set-key '[f6] 'delete-forward-to-char)
>
> Some of these "Emacs can do it too!"-solutions are pretty hilarious. No
> offense, but this is just too inconvenient to be practical. Vim has tons
> and tons of these change and motion commands, and all possible
> combinations of them.
I must admit it has been a while I used vi-style editors. Suppose I
am editing some C++ code and decide I want to delete everything within
a nested {..} pair. How do I do that in a modern vi?
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On 01 Jun 2001 10:04:03 -0400, Marco Antoniotti <·······@cs.nyu.edu>
> wrote:
>
> >> >You can change the Emacs key combinations to whatever you like.
> >> >Here is a function that does what I think you're asking for,
> >> >and following it is the form to bind it to the F6 key.
> >> >(You can put it on some other key, if you prefer.)
> >> >
> >> >(defun delete-forward-to-char (char)
> >> > "Delete forward to specified character."
> >> > (interactive "cChar: ")
> >> > (let* ((str (char-to-string char))
> >> > (end (save-excursion (if (search-forward str nil t) (point)))))
> >> > (if end
> >> > (delete-region (point) end)
> >> > (signal 'search-failed (list str)))))
> >> >
> >> >
> >> >(global-set-key '[f6] 'delete-forward-to-char)
>
> >> Some of these "Emacs can do it too!"-solutions are pretty hilarious. No
> >> offense, but this is just too inconvenient to be practical. Vim has tons
> >> and tons of these change and motion commands, and all possible
> >> combinations of them.
>
> >I must admit it has been a while I used vi-style editors. Suppose I
> >am editing some C++ code and decide I want to delete everything within
> >a nested {..} pair. How do I do that in a modern vi?
>
> di} - delete inner {} block
>
> Same for other types of blocks:
>
> di) - delete inner () block
> di> - delete inner <> block
> di] - delete inner [] block
>
> And if you want to delete the whole block, use this:
>
> da} - delete a {} block
>
> etc.
>
> This will also delete the outer {}.
>
> Or you could yi}/ya}, yank inner/a block. And do the same with other
> objects, like paragraphs, sentences, words containing predefined
> characters, words separated by spaces, etc. And you can
> change/substitute/delete/yank from where you are to the nth occurance of
> a char, inclusive or exclusive, backwards or forwards, and all kinds of
> nifty combinations, all in two-three keystrokes. Once you start getting
> used to doing this it's really incredibly handy.
That is cool.
But
M-C-k
still beats
ESC di} ESC
:)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>Thore B. Karlsen <········@cs.utexas.edu> writes:
>
>> On 01 Jun 2001 10:04:03 -0400, Marco Antoniotti <·······@cs.nyu.edu>
>> wrote:
>>
>> >I must admit it has been a while I used vi-style editors. Suppose I
>> >am editing some C++ code and decide I want to delete everything within
>> >a nested {..} pair. How do I do that in a modern vi?
>>
>> di} - delete inner {} block
>>
>> Same for other types of blocks:
>>
>> di) - delete inner () block
>> di> - delete inner <> block
>> di] - delete inner [] block
>>
>> And if you want to delete the whole block, use this:
>>
>> da} - delete a {} block
>>
>> etc.
>>
>> This will also delete the outer {}.
>
>
> M-C-k
>
>still beats
>
> ESC di} ESC
I think there is a natlang misunderstanding here. I
would have answered as Thore has, but it seems the
questioner wants something else.
Emacs's M-C-k is not the correct equivalent for
Vim's di}, or even di). Vim's di) deletes everything
in the nearest enclosing list. Emacs's M-C-k deletes
the following list (or atom), which is d% (or dw) in
Vim. The equivalent of di) in Emacs is probably
whatever it is to go up one list, followed by M-C-k.
There may even be a single keychord for this, but I am
reaching the edge of my working knowledge of Emacs at
this point.
--d
>>>>> "TS" == Ted Sandler <··········@worldnet.att.net> writes:
TS> And VI's ability to delete-fwd to char with a simple "df
TS> <CHAR>" rocks.
Like zap-to-char in Emacs, bound to M-z by default.
--
//////////////// | | The spark of a pin
<·······@zork.net> | left blank. | dropping, falling feather-like.
\\\\\\\\\\\\\\\\ | | There is too much noise.
In article <·················@worldnet.att.net>,
Ted Sandler <··········@worldnet.att.net> wrote:
>> Jason> I am still unclear why C-n, C-p, C-b, C-f are necessary.
>>
>> For the same reason why one has hjkl in VI: one need not move far from
>> the home position to move the cursor. Moving completely off the
>> keyboard to the arrow keys or mouse in order to move the cursor can
>> become very annoying in heavy-duty editing sessions.
>
>Yeah, but in VI, you always have to hit the ESC key to drop out of
>insert mode, and if you look at the ESC key's position on the keyboard,
>it's located way the f_ck away from the "home position". I find this
>extremely disruptive.
Many people do. I surmise the use of C-[ for ESC is
therefore pretty widespread, in both the Emacs
and Vi universes.
I probably shouldn't be admitting this in public, but I
have an insert-mode map (in Vi) for jj to ESC. In the
rare case when I need to insert two successive j's (as
above), j followed by C-v (or long pause) followed by j
works fine. (You may note that for a right-dominant
person using qwerty, j is probably the first or
second easiest character to type.)
I guess if the user is heavily into languages
like Fortran or Arabic or somesuch where jj's
presumably abound, a different diliteral could be
pressed into service.
--d
Ted Sandler <··········@worldnet.att.net> writes:
> Some of the key combinations are pretty insane. And VI's ability to
> delete-fwd to char with a simple "df <CHAR>" rocks.
M-z <CHAR>
Does the same thing in emacs.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
> Yeah, but in VI, you always have to hit the ESC key to drop out of
> insert mode, and if you look at the ESC key's position on the keyboard,
> it's located way the f_ck away from the "home position". I find this
> extremely disruptive.
Try C-[ instead.
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> > Yeah, but in VI, you always have to hit the ESC key to drop out of
> > insert mode, and if you look at the ESC key's position on the keyboard,
> > it's located way the f_ck away from the "home position". I find this
> > extremely disruptive.
>
> Try C-[ instead.
You say that control key is not so bad at all?
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
>>> Yeah, but in VI, you always have to hit the ESC key to drop out of
>>> insert mode, and if you look at the ESC key's position on the keyboard,
>>> it's located way the f_ck away from the "home position". I find this
>>> extremely disruptive.
>> Try C-[ instead.
> You say that control key is not so bad at all?
Of course I do; I'm an Emacs user. :-)
I can reach the control key without having to move my hands much.
Using C-[, I can very quickly move into a position to press them, and
then return to the home position. With Esc, it takes a few seconds to
find the home position.
This is doubly true on my Maltron, where the control key is easily
reachable by the thumb. Of course, if I'm using my Maltron, I'm
normally on my computer and rarely have need for Esc, since I have
Emacs running.
But on those instances where I find myself needing vi (on a foreign
system, terminal without a meta, or some such) I find C-[ much more
convenient than reaching for Esc.
Those who remap keys to put control to the One True Control Position
(to the left of A on a QWERTY keyboard) will have even less problems.
I can't find it right now, but I used to have a fortune, which I'll
misquote here: "The caps lock key should be placed somewhere
out of the way... preferably Zaire."
joelh
Jason Chesshir <·····@kioken.com> writes:
> It isn't that I don't like Emacs. I am new to it, and am not loving it the
> way I've known others to. I can get used to the C-x method of controls - it
> reminds me of older Lotus 1-2-3 when you fired user defined macros with M-x
> style commands. Perhaps I just need time to adjust. I am still unclear why
> C-n, C-p, C-b, C-f are necessary.
>
You can do most of the small movements with the mouse on recent
emacsen. Control keys are useful for people who don't want take their
hands off the keyboard.
--tim
Tim Bradshaw wrote:
> You can do most of the small movements with the mouse on recent
> emacsen. Control keys are useful for people who don't want take their
> hands off the keyboard.
>
> --tim
I appreciate that, because when I code I don't like to interrupt my flow with
mousing either. Arrow keys anyone?
~)ason
--
Jason Chesshir
·····@kioken.com
>>>>> "Jason" == Jason Chesshir <·····@kioken.com> writes:
Jason> Tim Bradshaw wrote:
>> You can do most of the small movements with the mouse on recent
>> emacsen. Control keys are useful for people who don't want take their
>> hands off the keyboard.
>>
>> --tim
Jason> I appreciate that, because when I code I don't like to interrupt my flow with
Jason> mousing either. Arrow keys anyone?
Too far away. What are they for? :-)
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
>
> Too far away. What are they for? :-)
They are part of the conspiracy by keyboard makers to occupy all
available desk space with huge expanses of obscure & useless keys.
--tim
Jason Chesshir <·····@kioken.com> writes:
>
> I appreciate that, because when I code I don't like to interrupt my flow with
> mousing either. Arrow keys anyone?
Those should generally work I think. They do on my keyboard anyway
(even though I'm currently reading news on a machine I'm telnetted to
from an xterm running on a Unix box displaying on a PC X server...)
--tim
>>>>> "Jason" == Jason Chesshir <·····@kioken.com> writes:
Jason> It isn't that I don't like Emacs. I am new to it, and am not
Jason> loving it the way I've known others to.
Emacs certainly is a big beast, I have been using Emacs heavily for a
decade now and still discover new and exiciting things almost every
day, but luckily it is easy to get a lot out of emacs without being an
expert on all the gory details.
My own favourite argument for emacs goes like this: I spend all my
day typing at the keyboard. No matter whether I program, do shell
commands, read mails or respond to news articles like I am doing now,
I am typing. Emacs is a powerfull typing environment, why should I
preclude my self from this power just because I am not programming? I
want the full editing power also for shell commands or news articles,
ie. whenever I type.
Just to give some examples.
I often use emacs when doing various shell stuff. For instance, I will
list a bunch of files and use emacs commands to sort, filter and
rearrange the files into the relevant target shell command.
I could of course achieve the same with pipes and sort and find and
sed and awk and xargs on a normal command line, but doing it
interactively (and using stuff like keyboard macros) just feels easier
and safer to me, in part because I can see the effects of the
different steps as I go along.
But then I am working with routers, and the router and I am working
with right now does have a shell, but it has neither bash or sed or
grep, so here emacs is a *real* lifesaver, because I can apply the
full power of the emacs environment to the very limited shell on the
router.
Even more so, on the older model I used to work on, the terminal
interface was limited to 9600 baud (I think, it certainly was below
modern serial performance) meaning that even though you could connect
to the router via a xterm, you could not paste in a shell command to
the window, since it would invariably drop some of the characters.
With emacs, I could solve the problem by modifying the shell mode to
send the input with small delays between the characters, and of course
still retain the full editing power of emacs.
It seems that VIM has much of the emacs editing facilities, but how
does VIM users interact with the lisp system? The emacs user would run
the lisp system from within emacs and have the full range of lisp code
editing commands available. If the VIM anti-bloat argument has any
value, this should not be possible from within VIM.
I know of two emacs->lisp interfaces, ILISP and ELI. ILISP is a
generic interface covering many different lisp systems whereas ELI is
something developed by Franz Inc. for their Allegro system. Both has
the feature that you can ask emacs to send a defun from you source
code file to the lisp process for execution, and the interface will
notice if the file specifies another package than the default and take
that into account.
In fact, the ELI interface is *the* user interface to modern versions
of the Allegro system. There used to be a motif application with stuff
like profiler control etc. but now there is only the emacs interface
(and REPL commands of course).
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·················@ted.ericsson.dk> writes:
> In fact, the ELI interface is *the* user interface to modern versions
> of the Allegro system. There used to be a motif application with stuff
> like profiler control etc. but now there is only the emacs interface
> (and REPL commands of course).
Well -- the Composer is still there (also driven from emacs :).
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
>>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:
Janis> Well -- the Composer is still there (also driven from emacs :).
Sure, but there once was a separate motif application with menus and
stuff for the composer, such that you for instance could start and
stop the profiler from that. It was basically just a menubar with a
number of menus.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·················@ted.ericsson.dk> writes:
> >>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:
>
> Janis> Well -- the Composer is still there (also driven from emacs :).
>
> Sure, but there once was a separate motif application with menus and
> stuff for the composer, such that you for instance could start and
> stop the profiler from that. It was basically just a menubar with a
> number of menus.
Ok. And now it's in emacs. Top level menu looks like this:
Composer
+------------------------------+
| Start Composer |
+------------------------------+
| Inspect |
| CLOS > |
| Xref > |
| Profiler > |
| Options |
| Other > |
| Help > |
+------------------------------+
| Exit Composer/Common Windows |
+------------------------------+
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> writes:
> Christian Lynbech <·················@ted.ericsson.dk> writes:
>
> > >>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:
> >
> > Janis> Well -- the Composer is still there (also driven from emacs :).
> >
> > Sure, but there once was a separate motif application with menus and
> > stuff for the composer, such that you for instance could start and
> > stop the profiler from that. It was basically just a menubar with a
> > number of menus.
>
> Ok. And now it's in emacs. Top level menu looks like this:
>
> Composer
> +------------------------------+
> | Start Composer |
> +------------------------------+
> | Inspect |
> | CLOS > |
> | Xref > |
> | Profiler > |
> | Options |
> | Other > |
> | Help > |
> +------------------------------+
> | Exit Composer/Common Windows |
> +------------------------------+
Christian is remembering (from a _long_ time ago!) when Allegro Composer
would start from what we called the "Podium" window, and you would get
similar menus to the one above. However, once we started integrating
Composer with Emacsen and started taking advantage of things emacs could
offer (like presenting listeners, a common and programmable key interface,
completions, etc ...) it started getting to the point that if you tried
to start Composer without the emacs-lisp-interface, close to half of the
features of Composer wouldn't work. So we removed that interface,
eventually.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On Wed, 30 May 2001 20:34:20 -0400, Jason Chesshir <·····@kioken.com>
> wrote:
>
> >Hello, all.
> >
> >I would like to know which LISP editor is /choice/ amongst the group.
> >I'm fascinated by all I've read about LISP and have been learning with
> >it on my own just for fun. I am, however, having a difficult time
> >*loving* emacs. Is that heresy?
>
> Of course not. :) I used Emacs before, but I came to a point where I
> couldn't stand it anymore and I switched to Vim. I haven't missed one
> single thing about Emacs, and Vim doesn't have any of the annoyances
> that stopped me from enjoying Emacs. If you don't really like Emacs you
> might give it a try, although it's not for everyone. It's very different
> from most editors.
You will NEVER get ILISP for Vim. You can have my word for that.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On 31 May 2001 08:02:23 -0400, Marco Antoniotti <·······@cs.nyu.edu>
> wrote:
>
> >You will NEVER get ILISP for Vim. You can have my word for that.
>
> Good, because I don't want Vim to be bloated with something I never use.
Well, Vim is bloating right now under your fingers. It's even getting
"scripting". :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On 31 May 2001 12:03:03 -0400, Marco Antoniotti <·······@cs.nyu.edu>
> wrote:
>
> >> >You will NEVER get ILISP for Vim. You can have my word for that.
>
> >> Good, because I don't want Vim to be bloated with something I never use.
>
> >Well, Vim is bloating right now under your fingers. It's even getting
> >"scripting". :)
>
> Yep, but features like these aren't compiled in by default, so I have a
> choice without it being crammed down my throat. And both the sources and
> the editor are still small enough to fit on a floppy. :)
ILISP is not compiled within Emacs. Hence your bloat is reduced. You
cannot fit Vim and Tcl on a floppy.
You can be as happy to use Vim as you want. It's your choice.
But the bloat argument is nowadays moot.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
>>>>> "TBK" == Thore B Karlsen <········@cs.utexas.edu> writes:
[...]
TBK> No it's not. Bloat causes programs to start up slowly, among
TBK> other things. I hate programs with slow startup
TBK> times. *cough* Emacs *cough* [...]
Hmm. It (FSF emacs) seems to start up in about a second on my machines
(P-II, P-III). I start it maybe once every 40 days or so, though so I'd
still be happy if it took several seconds more. I don't see the big issue
there unless you are starting up multiple copies (why? try gnuclient to talk
to your live emacs).
cheers,
B<OT>M
Thore B. Karlsen <········@cs.utexas.edu> writes:
>
> But to answer your question, I do start up several copies of my editors,
> because it's convenient to do so, IMHO. I often browse through several
> files in succession, using Vim as my default file viewer in Windows
> Commander just so I'll get proper syntax highlighting and searching.
> Works great with Vim, but it's very painful with Emacs because it starts
> up a lot slower than Vim. Loading the correct mode, redrawing the
> window, etc. Vim just pops up in an instant.
I use xemacs to browse files - my default viewer is gnuclient. With
xemacs already running, gnuclient brings up a window as near instantly as
makes no difference. Just put (gnuserv-start) in your .emacs.
Barry.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> No it's not. Bloat causes programs to start up slowly, among other
> things. I hate programs with slow startup times. *cough* Emacs *cough*
>
> But Emacs isn't the worst. At least it doesn't have a splash screen yet.
> Splash screens are inexcusable. A program shouldn't be so bloated that
> it needs a splash screen to let the user know that something is
> happening (just in case he's playing music really loud and can't hear
> the hard drive thrashing to load all the bloat).
>
You won't get away with this on a Lisp newsgroup:
$ time xemacs -f kill-emacs
real 0.2
user 0.1
sys 0.0
Not instant but hardly a slug. This is over a pretty slow terminal
connection too - most of the time is probablyt clearing the screen
(indeed if I add a -batch in there I get 0.1 sec reliably). This is
on a dual pentium pro 200 machine running Solaris 2.6. A modern fast
machine should be able to get maybe 0.05 sec?
(Can we stop this now).
>>>>> On Thu, 31 May 2001 13:37:35 -0500, Thore B Karlsen ("Thore") writes:
Thore> No it's not. Bloat causes programs to start up slowly, among other
Thore> things. I hate programs with slow startup times. *cough* Emacs *cough*
On my original Pentium at 133 Mhz, Emacs 20.7 takes 2 seconds to start.
(Internet Explorer takes 14 seconds, and MS word takes 6 seconds.)
In article <··································@4ax.com>,
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On Thu, 31 May 2001 21:42:14 GMT, Christopher Stacy
> <······@spacy.Boston.MA.US> wrote:
>
>> Thore> No it's not. Bloat causes programs to start up slowly, among other
>> Thore> things. I hate programs with slow startup times. *cough* Emacs *cough*
>
>>On my original Pentium at 133 Mhz, Emacs 20.7 takes 2 seconds to start.
>>(Internet Explorer takes 14 seconds, and MS word takes 6 seconds.)
>
> Which proves my point. Bloat is bad.
I don't think it does. It takes 3.0 seconds to load Xemacs 19.16 on my 233
x86. Sounds pretty bad, doesn't it? Except 2.88 seconds of that time is for
loading my init files. I don't believe Xemacs itsself is bloated. Any bloat is
due to the junk I've added. Not that it really matters to me as my copy has
been up for 56 days now.
Mike McDonald
·······@mikemac.com
Thore B. Karlsen wrote:
> Vim alone fits on a floppy. If I wanted to compile it with support for a
> scripting language, I'd use Python or Perl, both of which are already
> installed on my machines for different reasons. I haven't found any
> reasons to do so yet, because I rarely need to do heavy scripting in
> Vim. Vim's built-in scripting language is enough for my needs, because
> it does pretty much everything I want right out of the box.
Strange - I read this "...but it fits on a floppy..." argument more and
more often this days. As if so many people still use 1.44 MB floppy-disc.
I cannot even remember when I last used a floppy-disc...
Besides that I do not choose my editor because I could put it on a floppy
disc - but more on features like "editing text" (which is following the
rumours I more and more often hear the thing they are meant to do...)
Both Emacs _and_ Vi are very sophisticated editors that take some time to
get used to - But I don't think that someone can say something like "Yes
Emacs/Vi is bad using Vi/Emacs will solve all your problems...
Regards,
Jochen
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I use them all the time. I get the newest sources for Vim, copy them
> over to my laptop on a floppy, and compile them. It's just a matter of
> convenience, it's not a major issue. But it beats spending $xxx on USB
> links or two extra network cards, so "fits on a floppy" is still
> important to me.
*looking under my desk* Geez, my Sun workstation has something
looking awfully like a floppy drive, I wonder if it really is one?
--
(espen)
Thore B. Karlsen <········@cs.utexas.edu> wrote:
: Maybe it's one of these?
: http://www.fu-fme.com/
BTW: I know this guy personally. In normal life he's doing music with
text-to-speech vocoders.
--
Reini Urban
To add to this useless off-topic thread...
Thore B. Karlsen <········@cs.utexas.edu> writes:
> I'm not saying Emacs is a bad editor, it's just not right for me. On
> the other hand, many Emacs users say Vim is a bad editor off hand
> without even having tried it, or having tried an ancient version of
> Vi. That's probably true for Vi users as well, although my
> impression is that Emacs users seem a lot more arrogant and like to
> look down their noses at those who use "inferior" editors such as Vi
> clones.
It was a long time ago (about 3 or 4 years) when I first installed
Linux at home. XEmacs was the editor. (CMUCL was the Lisp to be less
off-topic.)
Then, about a one and a half year ago at work (doing C programming)
and using CVS and committing changes the default editor -- VI -- came
up and that was it. How do people use this program? How to type a
letter? How to quit? (That was easy -- C-z, kill %1 :)
But then I decided to learn it just so I can later tell everybody I
know how to use vi. And I started to like it. Really. I programmed in
it (C stuff) for about half a year. I forgot what emacs even was
like. Wherever typing something the first letter always was 'i'.
Then I tried emacs again (for C programming). Man, was I
enlightened... Now every time I see Vi (or its likes) it makes me feel
sick. My $EDITOR is set to emacsclient so it does not happen
accidentally :)
And I am happy I like emacs more than vi.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> On 01 Jun 2001 13:25:08 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>
> >> I'm not saying Emacs is a bad editor, it's just not right for me. On
> >> the other hand, many Emacs users say Vim is a bad editor off hand
> >> without even having tried it, or having tried an ancient version of
> >> Vi. That's probably true for Vi users as well, although my
> >> impression is that Emacs users seem a lot more arrogant and like to
> >> look down their noses at those who use "inferior" editors such as Vi
> >> clones.
>
> >It was a long time ago (about 3 or 4 years) when I first installed
> >Linux at home. XEmacs was the editor. (CMUCL was the Lisp to be less
> >off-topic.)
> >
> >Then, about a one and a half year ago at work (doing C programming)
> >and using CVS and committing changes the default editor -- VI -- came
> >up and that was it. How do people use this program? How to type a
> >letter? How to quit? (That was easy -- C-z, kill %1 :)
> >
> >But then I decided to learn it just so I can later tell everybody I
> >know how to use vi. And I started to like it. Really. I programmed in
> >it (C stuff) for about half a year. I forgot what emacs even was
> >like. Wherever typing something the first letter always was 'i'.
> >
> >Then I tried emacs again (for C programming). Man, was I
> >enlightened... Now every time I see Vi (or its likes) it makes me feel
> >sick. My $EDITOR is set to emacsclient so it does not happen
> >accidentally :)
> >
> >And I am happy I like emacs more than vi.
>
> Great! Emacs is the right choice for many, many people.
>
> And to be honest, I'm sure I would feel the same way if I had only used
> vanilla Vi, like you.
Sorry to disappoint you but what I used *was* actually Vim. I just
don't know any other vi :)
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Thore B. Karlsen <········@cs.utexas.edu> writes:
> But it's included with Emacs, and you can't download Emacs without all
> the stuff you don't need. And that would be nice, because Emacs is
> huge.
Note that you can do that with XEmacs, which has been (for better or
worse) broken up in constitutive "packages". So you can download
"base XEmacs", add to it the stuff you use, say C mode and ILISP, and
never have to look at anything else.
On Thu, 31 May 2001 13:37:35 -0500, Thore B. Karlsen
<········@cs.utexas.edu> wrote:
> On 31 May 2001 13:52:14 -0400, Marco Antoniotti <·······@cs.nyu.edu>
[...]
> >ILISP is not compiled within Emacs. Hence your bloat is reduced.
>
> But it's included with Emacs, and you can't download Emacs without all
> the stuff you don't need. And that would be nice, because Emacs is huge.
ILISP is not included in the Emacs distribution. You have to download it
separately.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>You will NEVER get ILISP for Vim. You can have my word for that.
Promises, promises.
--d
Jason Chesshir <·····@kioken.com> writes:
> I would like to know which LISP editor is /choice/ amongst the group.
> I'm fascinated by all I've read about LISP and have been learning with
> it on my own just for fun. I am, however, having a difficult time
> *loving* emacs. Is that heresy?
>
yes. You will be burned at the stake tomorrow morning.
Seriously, what don't you like about emacs? If you prefer some other
editor we probably have an emulation for you somewhere...
--tim
Tim Bradshaw <···@tfeb.org> wrote:
+---------------
| Seriously, what don't you like about emacs?
+---------------
Holding down the control or meta key all the time. Call me ancient,
but I *like* "moded" editors such as Teco or Vi that let me use
un-shifted un-modified keys for most editing operations (including
entering and exiting "insert mode").
+---------------
| If you prefer some other editor we probably have an emulation
| for you somewhere...
+---------------
Yes, I know about Vi mode, and the like. The problem is that only
the basic editor respects those bindings, and once you try to use
anything *else* (any of the neato things you can load into Emacs,
a large part of the attraction to me in the first place), you're
suddenly back into control-meta-shift-hyper-bucky-bucky land... :-{
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
>
> Holding down the control or meta key all the time. Call me ancient,
> but I *like* "moded" editors such as Teco or Vi that let me use
> un-shifted un-modified keys for most editing operations (including
> entering and exiting "insert mode").
I certainly don't like that either (though I think my fingers are
sufficiently used to it by now that I couldn't easily change). it's
made especially toxic because keyboard designers keep moving keys
around (for instance putting the control key an inconvenient distance
from the other keys, and the caps lock key where you hit it by
mistake, which seems to be completely normal now).
>
> Yes, I know about Vi mode, and the like. The problem is that only
> the basic editor respects those bindings, and once you try to use
> anything *else* (any of the neato things you can load into Emacs,
> a large part of the attraction to me in the first place), you're
> suddenly back into control-meta-shift-hyper-bucky-bucky land... :-{
>
This argument seems dubious to me. All those `neato things' typically
aren't available at *all* for other editors, so you're comparing not
having it vs having it on inconvenient keys. I guess maybe some vis
are highly programmable, but they must have the same issues unless
they make everything available via colon commands (and esc-x command
doesn't require a shift key whike :command does!)
Anyway...
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>····@rigden.engr.sgi.com (Rob Warnock) writes:
>
>> Yes, I know about Vi mode, and the like. The problem is that only
>> the basic editor respects those bindings, and once you try to use
>> anything *else* (any of the neato things you can load into Emacs,
>> a large part of the attraction to me in the first place), you're
>> suddenly back into control-meta-shift-hyper-bucky-bucky land... :-{
>>
>
>This argument seems dubious to me. All those `neato things' typically
>aren't available at *all* for other editors, so you're comparing not
>having it vs having it on inconvenient keys. I guess maybe some vis
>are highly programmable, but they must have the same issues unless
>they make everything available via colon commands (and esc-x command
>doesn't require a shift key whike :command does!)
>
>Anyway...
Yesterday I read in a contrarian bicycle catalog (the
Rivendell, BTW) that the advantage of downtube shifters
isn't just that they are simple (in construction and
cost, and to maintain) but that they are inconvenient
to use. For a moment I thought it was a typo for I
always thought my downtube shifters were plenty
convenient. What they meant was that deliberately
super-convenient shifting, as in the more high-tech,
more expensive and higher-maintenance STI, almost
guarantees, given human nature, that one will be sucked
into pointless shifting, when one could be pedaling and
covering ground. That's how I feel about Emacs's
(_and_ Vim's) programmability and "neato things".
Luckily for me qua Lisper, Vim's scripting language is
both forbiddingly ugly (it isn't a Lisp, after all) and
easily removable at compile. I get to actually
cover ground, shifting only when it's absolutely
necessary.
--d
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Yesterday I read in a contrarian bicycle catalog (the
> Rivendell, BTW) that the advantage of downtube shifters
> isn't just that they are simple (in construction and
> cost, and to maintain) but that they are inconvenient
> to use. For a moment I thought it was a typo for I
> always thought my downtube shifters were plenty
> convenient. What they meant was that deliberately
> super-convenient shifting, as in the more high-tech,
> more expensive and higher-maintenance STI, almost
> guarantees, given human nature, that one will be sucked
> into pointless shifting, when one could be pedaling and
> covering ground. That's how I feel about Emacs's
> (_and_ Vim's) programmability and "neato things".
I used to have that problem with STI. But I think that once you can
control your urge to shift all the time it's a win. The reason, I
think, is that you can do things which are incredibly difficult
without it. For instance on a route I used to ride a lot there was a
long flat stretch and then a sharp turn directly onto something which
was 1 in 10 or worse. Coming out of the turn you needed to be in the
little ring and probably several sprockets lower as well, or the bike
would just stop. Doing this with STI is easy - you hurtle along the
flat, brake hard *and shift down*, then turn and head off up the hill.
Doing it with downtube shifters is really hard because you can't
(well, *I* can't) brake hard and shift at the same time without
standing a significant danger of falling off.
Syncromesh is like this too. If you've driven a car without
syncromesh there are some maneuvers it's really hard to do - braking
and shifting down for instance really needs three feet. Doing this in
a car where you have to make hand signals is even more exciting. I'm
told that racing drivers do something called `heel-and-toeing' which I
don't want to think about too hard. (I guess this will be an even more
alien example to USans who aren't really used to the idea of manual
transmissions let alone ones without synchromesh!)
Anyway, that's enough off-topic stuff. I think that the analogy with
Emacs is quite good though: *if* you have self-control it's not bad
for you. In the case of emacs I seem to have developed self-control:
although I have a huge amount of code I've written that I load into it
I don't change it very often at all now and haven't for several years.
I have problems when they release new versions though.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Syncromesh is like this too. If you've driven a car without
> syncromesh there are some maneuvers it's really hard to do - braking
> and shifting down for instance really needs three feet. Doing this in
> a car where you have to make hand signals is even more exciting. I'm
> told that racing drivers do something called `heel-and-toeing' which I
> don't want to think about too hard. (I guess this will be an even more
> alien example to USans who aren't really used to the idea of manual
> transmissions let alone ones without synchromesh!)
i had an old saab 96 which had a coasting feature. if the wheels
moved faster than the engine/gears, then the car would coast forward.
is this is what you mean by syncromesh?
later on in its life, it didn't run too well and tended to stall when
idling. i would turn my right foot kind of sideways with the heel
planted on the brake. then i could press the gas with my toe. left
foot was busy with clutch. shift was 4 on the column, which i felt
was pretty convenient since my hands were usually on the wheel
anyhow.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
* Johan Kullstam wrote:
> i had an old saab 96 which had a coasting feature. if the wheels
> moved faster than the engine/gears, then the car would coast forward.
> is this is what you mean by syncromesh?
No, synchromesh is a feature of modern gearboxes such that they
synchronise the two sides of the gearbox before engaging the gears.
In a non-synchromesh gearbos you have to arrange that they are running
at compatible speeds or you get amazing grinding and/or the car just
won't go into gear.
Synchromesh is kind of like garbage collection - if you really care
about maximum performance at any cost you might not want it, but you
definitely do want it for everything else. And like GC, synchromesh
gearboxes have become so good that the occasions when youdon't want it
are now seriously rare (racing cars may still not have synchromesh).
--tim
Tim Bradshaw wrote:
> Synchromesh is kind of like garbage collection - if you really care
> about maximum performance at any cost you might not want it, but you
> definitely do want it for everything else. And like GC, synchromesh
> gearboxes have become so good that the occasions when youdon't want it
> are now seriously rare (racing cars may still not have synchromesh).
I think you've been duped by anti-synchromesh FUD. If I'm not mistaken,
really modern high-tech racing cars use two buttons on the steering
wheel to switch gears.
-thant
Thant Tessman <·····@acm.org> writes:
> Tim Bradshaw wrote:
>
> > Synchromesh is kind of like garbage collection - if you really care
> > about maximum performance at any cost you might not want it, but you
> > definitely do want it for everything else. And like GC, synchromesh
> > gearboxes have become so good that the occasions when youdon't want it
> > are now seriously rare (racing cars may still not have synchromesh).
>
> I think you've been duped by anti-synchromesh FUD. If I'm not mistaken,
> really modern high-tech racing cars use two buttons on the steering
> wheel to switch gears.
Yes, but they still don't have a synchromesh. You have fancy
electronics to get all the timing right instead.
Cheers,
M.
--
The "of course, while I have no problem with this at all, it's
surely too much for a lesser being" flavor of argument always
rings hollow to me. -- Tim Peters, 29 Apr 1998
Michael Hudson <···@python.net> wrote:
+---------------
| Thant Tessman <·····@acm.org> writes:
| > I think you've been duped by anti-synchromesh FUD. If I'm not mistaken,
| > really modern high-tech racing cars use two buttons on the steering
| > wheel to switch gears.
|
| Yes, but they still don't have a synchromesh. You have fancy
| electronics to get all the timing right instead.
+---------------
Sounds like just "electronic synchromesh", to me. The point
of synchromesh isn't *how* it's done, but *that* it's done...
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Michael Hudson <···@python.net> wrote:
> +---------------
> | Thant Tessman <·····@acm.org> writes:
> | > I think you've been duped by anti-synchromesh FUD. If I'm not mistaken,
> | > really modern high-tech racing cars use two buttons on the steering
> | > wheel to switch gears.
> |
> | Yes, but they still don't have a synchromesh. You have fancy
> | electronics to get all the timing right instead.
> +---------------
>
> Sounds like just "electronic synchromesh", to me. The point
> of synchromesh isn't *how* it's done, but *that* it's done...
Oh, I thought syncromesh was a specific mechanism. Certainly what a
formula 1 car does for gear shifting is vastly different to what your
average Mondeo does.
I'll stop now, not being a car-head...
Cheers,
M.
--
That's why the smartest companies use Common Lisp, but lie about it
so all their competitors think Lisp is slow and C++ is fast. (This
rumor has, however, gotten a little out of hand. :)
-- Erik Naggum, comp.lang.lisp
Michael Hudson <···@python.net> writes:
>
> Oh, I thought syncromesh was a specific mechanism. Certainly what a
> formula 1 car does for gear shifting is vastly different to what your
> average Mondeo does.
>
I think it is a specific mechansim, but I think Rob's redefinition of
it is a good one - the point is that you don't have to equalise the
speeds of the two halves of the gearbox, not how it's done, as he
says.
I'll stop here too, or perhaps this should move to
alt.cars.obscure-programming-language-metaphors (or comp.lang.lisp.car
I guess, a newsgroup which should probably exist, though I'm sure some
people think it should be called comp.lang.list.first.)
--tim
There was a thread recently in c.l.l. about some of the
infelicities of autoindenting Scheme and Lisp
code with the Vim editor. I have described in
http://www.cs.rice.edu/~dorai/vistuff/scmvim a small
patch to the Vim source that will enable a Vim user to
customize Scheme indentation via his .vimrc file.
Tokens listed in the new 'schemedeftokens' option
will cause their subexpressions (on a following line)
to be indented tightly under the head token. E.g., define,
let, defun.
Tokens not listed in 'schemedeftokens' will cause their
subexpressions to be indented completely to the right
of the head token. E.g., procedure names.
--d
[followup to c.l.l only]
* Dorai Sitaram wrote:
> Tokens not listed in 'schemedeftokens' will cause their
> subexpressions to be indented completely to the right
> of the head token. E.g., procedure names.
As you describe this, this is not the correct way to indent.:
(foo x
y)
But
(foo
x
y)
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Dorai Sitaram wrote:
>
>> Tokens not listed in 'schemedeftokens' will cause their
>> subexpressions to be indented completely to the right
>> of the head token. E.g., procedure names.
>
>As you describe this, this is not the correct way to indent.:
>
>(foo x
> y)
>
>But
>
>(foo
> x
> y)
I am assuming you are saying that
(foo
x
y)
would be wrong (but it isn't clear). If so, yes, while
I papered over that detail, something like your
second choice is indeed chosen by Vim. I was only
comparing, out of laziness, the one case where the two
types of tokens will differ in Vim.
In the expression (foo x y), depending on where
you linebreak, Vim will do
(foo x
y)
or
(foo
x
y)
assuming foo isn't in 'schemedeftokens'.
If you are looking for an exact match against what
Emacs does, my patch very likely doesn't do it.
--d
For the wider community, T-shirt purchases can now be used as one proxy
for the general popularity amongst the programmer hordes in general:
http://www.thinkgeek.com/stuff/vi-emacs.html
This really doesn't answer the question w.r.t. Lisp, but if you are
oppressed by an unfriendly editor-bigot majority, now there's a T-shirt
for you.
Jason Chesshir wrote:
>
> Hello, all.
>
> I would like to know which LISP editor is /choice/ amongst the group.
> I'm fascinated by all I've read about LISP and have been learning with
> it on my own just for fun. I am, however, having a difficult time
> *loving* emacs. Is that heresy?
>
> ~)ason
>
> --
> Jason Chesshir
> ·····@kioken.com
--
- Mike Smith
·············@home.com
What better incentive to conservation than high prices?