Google 网上论坛不再支持新的 Usenet 帖子或订阅项。历史内容仍可供查看。

About emacs (was: Let's do something about Microsoft)

已查看 666 次
跳至第一个未读帖子

Christian Lynbech

未读,
1995年7月11日 03:00:001995/7/11
收件人
I like to think about this everything-in-an-editor business in the
following way: editing, whether we are talking programs or emails or
commandlines, are the most abundant task any of us do. It therefore
(IMHO) makes sense to stuff as many features into your editor as
possible.

The advantage of using emacs for both programming and compiling and
emails and news are the tight and highly uniform integration you get
between those different activities. You can for instance edit a C
file, hit a key and start the compiler and if there are errors, hit
yet another key and have emacs transfer you to the point of the
error. This type of integration may not be unique for emacs, but no
application goes as long as emacs. I think SUN has something like the
above with their compiler products, but (apart from the fact that you
have to pay for it) it will only get you integration between C compiler
and debugger, and then only for SUN's compiler and debugger. With
emacs, you get a similar facility for `grep' or even LaTeX.

Furthermore, emacs not only offers one particular interface to a large
varity of activities, it is also as close to platform independent as
you get. Emacs works on machines all the way from my lowly Atari ST
and up. And it is not just the same keybindings, it's the same program,
with the same features.

Emacs is extensible, meaning that you have a fully featured
programming language at your finger-tips. This does not just mean that
elisp has both a debugger and a compiler and defun and lambda and
lists, but it is also a unique environment for `editing applications',
filled to the brim with all those things you need when writing support
for editing in any particular way. This you do not get when starting
from scratch with C, and you certainly do not get it when working with
closed applications like vi or WordPerfect.

Emacs is not just an editor, concerned with replacing characters by
other characters. Emacs is an environment for interaction: the
interaction between you and your C files, the interaction between you
and the compiler, the interaction between you and debugger, the
interaction between you and the internet. When I had the good fortune
to move to an SGI workstation, I was sorry to loose my AutoWarp
facility when switching between windows, but spending all my time
inside emacs anyway, there was (of course, we are talking about emacs)
solutions. This is the power of integration at work. Had I been using
several small indepent utilities, I would have had to find another
window manager instead.

Really learning emacs is not that easy, but the hours you put into it are
paying back many times later. Of course, you need to learn the features
to see the point. If all you ever use emacs for is replacing
characters by characters, then vi may suit you better.


------------------------------------------------------------------------------
Christian Lynbech (R0.33) | Hit the philistines three times over the
phone: +45 8942 3217 | head with the Elisp reference manual.
email: lyn...@daimi.aau.dk | - pet...@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------

Jason F. McBrayer

未读,
1995年7月11日 03:00:001995/7/11
收件人

>>>>> "MY" == Marinos Yannikos <ni...@mips.complang.tuwien.ac.at>
>>>>> writes:

MY> On my good old SPARC IPC Emacs approx. 10 seconds (and a lot of
MY> harddisk- rattling) to start up, and that's why I still prefer vi
MY> for editing, "elm" for mail and so on. I wouldn't bet that I'm not
MY> going to convert to Emacs-ism once we get those nifty 289MHz Alpha
MY> clones. :-)

Well, on my bad old 386sx-16, Emacs takes about 1 minute to start up
(in a Presentation Manager frame under OS/2), but then again, I only
run it once, at boot. All of my text file objects are associated with
emacsclient, and when I double-click on one, it starts a new emacs
frame in just a couple of seconds. Not as fast as tedit, almost as
fast as e, faster than elvis. The convenience of using emacs as my
default editor far outstrips the added boot time.

--
+---------------------------------+----------------------------------+
|Jason F. McBrayer | Southern | Then Jarf presents itself as the |
|j...@kevin.net | Center for | ultimate in worthlessness. |
| | Jarf Studies | -thin...@netcom.com |
+------------------+--------------+----------------------------------+

Ko Georges

未读,
1995年7月11日 03:00:001995/7/11
收件人
>>>>> "Christian" == Christian Lynbech <lyn...@xenon.daimi.aau.dk> writes:

Christian> Furthermore, emacs not only offers one particular interface
Christian> to a large varity of activities, it is also as close to
Christian> platform independent as you get. Emacs works on machines all
Christian> the way from my lowly Atari ST and up. And it is not just the
Christian> same keybindings, it's the same program, with the same
Christian> features.

...

Christian> Really learning emacs is not that easy, but the hours you put
Christian> into it are paying back many times later. Of course, you need
Christian> to learn the features to see the point. If all you ever use
Christian> emacs for is replacing characters by characters, then vi may
Christian> suit you better.

No matter who will win the OS battle, there will always be an
Emacs on it, so learning Emacs and elisp can't be wrong. Reassuring,
isn't it ?
--
Georges KO k...@amertume.ufr-info-p7.ibp.fr
M-x

Richard Coleman

未读,
1995年7月11日 03:00:001995/7/11
收件人
> I like to think about this everything-in-an-editor business in the
> following way: editing, whether we are talking programs or emails or
> commandlines, are the most abundant task any of us do. It therefore
> (IMHO) makes sense to stuff as many features into your editor as
> possible.
>
> The advantage of using emacs for both programming and compiling and
> emails and news are the tight and highly uniform integration you get
> between those different activities. You can for instance edit a C
> file, hit a key and start the compiler and if there are errors, hit
> yet another key and have emacs transfer you to the point of the
> error. This type of integration may not be unique for emacs, but no
> application goes as long as emacs.

Rather than all these products running `inside' of emacs, what would be
preferable is that all these products communicate through a common
protocol. That way your mail reader could add menus to your editor when
composing e-mail, etc... There are some decents examples of this, such
as certain tools written in Tk/tcl, and some of the Sun products (which I
think use tooltalk). But as you mention, none of these are as tightly
integrated, and with as many tools as using emacs.

If Guile possesses the ability to add such communication to a software
product, then maybe this could lead to a common way for various free
software products to be integrated in such a fashion.

Richard Coleman
col...@math.gatech.edu


Jim Wise

未读,
1995年7月17日 03:00:001995/7/17
收件人
lorien>timex emacs #wait for open, then C-x C-c

real 7.40
user 1.10
sys 0.48

lorien>timex vi #wait for open, then ZZ

real 0.41
user 0.00
sys 0.05

lorien>ls -l `which emacs`
-r-xr-xr-t 1 bin bin 3973696 Aug 15 1994 /usr/local/Gnu/bin/emacs

lorien>ls -l `which vi`
-rwxr-xr-t 6 bin bin 128540 Mar 24 1993 /usr/bin/vi

lorien>du -s /usr/lib/ex3.9preserve /usr/lib/ex3.9recover /usr/lib/ex3.9strings /usr/preserve
94 /usr/lib/ex3.9preserve
36 /usr/lib/ex3.9recover
14 /usr/lib/ex3.9strings
166 /usr/preserve

lorien>du -s /usr/local/Gnu/lib/emacs
31148 /usr/local/Gnu/lib/emacs

lorien>ps -l #note sizes
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME COMD
c510 S 1000 1559 1558 0 39 24 b96000 70 12fff000 p2 0:00 csh
4414 T 1000 1662 1559 0 64 24 4b4000 83 p2 0:00 vi
4414 T 1000 1663 1559 0 64 24 504000 455 p2 0:02 emacs
4410 R 1000 1675 1559 5 66 24 a94000 108 p2 0:00 ps

Jim Wise
wi...@acf4.nyu.edu

Per Abrahamsen

未读,
1995年7月17日 03:00:001995/7/17
收件人
>>>>> "Jim" == Jim Wise <wi...@acf4.nyu.edu> writes:

[ sad vi numbers deleted ]

What is your point? That vi completely fails to utilize a modern
(i.e. post PDP-11) computer? We already knew that.

Emacs will fully utilize even the fastest workstation.

Per Abrahamsen

未读,
1995年7月17日 03:00:001995/7/17
收件人
>>>>> "MY" == Marinos Yannikos <ni...@mips.complang.tuwien.ac.at> writes:

MY> That's a bit like telling someone who's been run over by a
MY> truck that he's fortunate, because the truck that hit him was
MY> one of the smallest. :-)

That sounds more like a description of why vi is such a great
editor... While it is incredible poorly designed and doesn't provide
any substantial help for the user, it does so while leaving your
computer mostly idle.


Kai Grossjohann

未读,
1995年7月17日 03:00:001995/7/17
收件人 Zdenek Salvet
>>>>> "Zdenek" =3D=3D Zdenek Salvet <sal...@anxur.dcs.muni.cz> writes:

Zdenek> Include your photo as MIME attachment, please.

In this news posting, I won't. But I could (if I had it scanned in).
Just get tm (tiny-mime) from somewhere, and you'll be all set.

regards,
\kai{}
--
Life is hard and then you die.


Oliver Laumann

未读,
1995年7月17日 03:00:001995/7/17
收件人
> -r-xr-xr-t 1 bin bin 3973696 Aug 15 1994 emacs
> -rwxr-xr-t 6 bin bin 128540 Mar 24 1993 vi

I don't really understand why people are constantly complaining about the
size of Emacs. What exactly is the problem? All modern workstations
have virtual memory with demand paging, so it's the resident set size
and virtual memory behavior of a process that counts, not just the size
of the a.out file.

If I'm not mistaken, the core image of Emacs includes the Lisp heap, most
of which is never accessed during a normal editing session (except maybe
when a garbage collection is triggered). Therefore the corresponding
pages usually do not consume any core memory, just swap space.

Sun's rpc.nisd routinely gets larger than 20 MBytes on our Solaris 2.4
machines, and the gated running on my workstation has a size of more
than 40 MBytes. Yet their average resident set sizes (the amount of
pages held in memory) are significantly smaller, less than 1 MByte in
case of gated.

If Emacs had a rude virtual memory behavior causing unacceptable paging
traffic on a machine with limited memory, _then_ maybe you would have a
point. In any case, just comparing the output of ls -l is a waste of time.

Jim Weirich

未读,
1995年7月17日 03:00:001995/7/17
收件人
>>>>> "Jason" == Jason F McBrayer <j...@bedroom.kevin.net> writes:

Jason> Correction -- (ding) GNUS certainly does have score files.

What are score files?

Jason> (ding) GNUS is also much faster than POG (plain ole gnus), but it's
Jason> currently not ready for wide release. It should be out RSN, though.

Where can you evaluate (ding) GNUS? (... and why is it called (ding) GNUS?)
--
-- Jim Weirich, Cincinnati, OH | Disclaimer:
-- E-Mail (day): j...@lexis-nexis.com | These opinions are mine.
-- E-Mail (night): jwei...@one.net | Do you hear me?
-- Web Page: http://w3.one.net/~jweirich/ | Mine!

Marcus Daniels

未读,
1995年7月17日 03:00:001995/7/17
收件人
>>>>> "Jim" == Jim Wise <wi...@acf4.nyu.edu> writes:
In article <3ud42a$6...@cmcl2.NYU.EDU> wi...@acf4.nyu.edu (Jim Wise) writes:


Jim> timex emacs #wait for open, then C-x C-c

Jim> real 7.40 user 1.10 sys 0.48

Jim> timex vi #wait for open, then ZZ

Jim> real 0.41 user 0.00 sys 0.05

Clue:

[~] $ time echo "e .emacs" | ex
0.1 real 0.0 user 0.0 sys
".emacs" 723 lines, 24629 characters
[~] $ time echo "e .emacs" | ex
0.1 real 0.0 user 0.0 sys
".emacs" 723 lines, 24629 characters
[~] $ time gnudoit '(find-file "~/.emacs")'
.emacs
1.0 real 0.0 user 0.0 sys
[~] $ time gnudoit '(find-file "~/.emacs")'
.emacs
0.3 real 0.0 user 0.0 sys


Michael A Connell

未读,
1995年7月18日 03:00:001995/7/18
收件人

What are score files?

Score files allow the automatic evaluation of how interesting an article is
based on its subject/author/date/&c.
Say you like reading about 'Foo' and 'Bar' but not 'Baz'.
Articles about 'Foo Bar' get a high score, 'Foo Baz' gets nothing, and
'Baz' gets a very low score, then you can have your threads sorted by score,
and find all the interesting ones at the top.
Thats the idea anyway :)
(ding) Gnus will also try to work out scoring patterns for you itself...

(ding) Gnus info can be found at:
http://www.ifi.uio.no/~larsi/

It's in beta at the moment, but it hasn't bitten me (yet :)

Mike.

--
Mike Connell / cgc...@swansea.ac.uk / PGP &c. / blahblahblahblahblahblahblah

Marinos Yannikos

未读,
1995年7月18日 03:00:001995/7/18
收件人
Oliver Laumann (n...@cs.tu-berlin.de) wrote:
: In any case, just comparing the output of ls -l is a waste of time.

See? That time is wasted because of Emacs too, in a way. :-)

Regards,
Marinos

Richard Pitre

未读,
1995年7月18日 03:00:001995/7/18
收件人
In article <3ugbav$q...@news.tuwien.ac.at> ni...@mips.complang.tuwien.ac.at

There is no mechanism whereby "About emacs" would terminate naturally i.e. this
intellectual dick bashing can't terminate without the actual removal of organs.
I believe alt.religion.emacs was created precisely for this purpose. Are we
stuck with this dialog? Does anyone know how to move it to a more appropriate
place.

richard

yw...@beta.wsl.sinica.edu.tw

未读,
1995年7月18日 03:00:001995/7/18
收件人
Jim Wise (wi...@acf4.nyu.edu) wrote:

: -r-xr-xr-t 1 bin bin 3973696 Aug 15 1994 /usr/local/Gnu/bin/emacs
: -rwxr-xr-t 6 bin bin 128540 Mar 24 1993 /usr/bin/vi

Looks as you are comparing a Porsche with a bicycle with their size. The only
similarity is both of them can transport you.

--
Yen-Wei Liu
Internet e-mail address:yw...@beta.wsl.sinica.edu.tw
yw...@gate.sinica.edu.tw
FAX: +886-2-783-6444

David Fox

未读,
1995年7月18日 03:00:001995/7/18
收件人
In article <3tv6lk$t...@caip.rutgers.edu> hal...@caip.rutgers.edu writes:

] In article <FOX.95Ju...@graphics.cs.nyu.edu>, f...@graphics.cs.nyu.edu (David Fox) writes
] > A valid point I suppose. I guess I'm lucky to have enough memory
] > that it doesn't bother me.
]
] Yes, you are. It alwais is nice to be rich.

You could be like me and make lots of money by getting a job
programming computers!
--
http://galt.cs.nyu.edu/students/fox/
David Fox xoF divaD
NYU Media Research Lab baL hcraeseR aideM UYN

David Fox

未读,
1995年7月19日 03:00:001995/7/19
收件人
In article <3ugd9b$g...@ra.nrl.navy.mil> pi...@n5160d.nrl.navy.mil (Richard Pitre) writes:

] ...I believe alt.religion.emacs was created precisely for this


] purpose. Are we stuck with this dialog? Does anyone know how to move
] it to a more appropriate place.

It is not possible to move a netnews discussion. It may be possible
to start a similar discussion elsewhere, but to what end?

Marinos Yannikos

未读,
1995年7月20日 03:00:001995/7/20
收件人
yw...@beta.wsl.sinica.edu.tw wrote:
: Jim Wise (wi...@acf4.nyu.edu) wrote:

: : -r-xr-xr-t 1 bin bin 3973696 Aug 15 1994 /usr/local/Gnu/bin/emacs
: : -rwxr-xr-t 6 bin bin 128540 Mar 24 1993 /usr/bin/vi

: Looks as you are comparing a Porsche with a bicycle with their size. The only
: similarity is both of them can transport you.

Incidentally, the bicycle would also be faster. :-)

Regards,
Marinos

Mr. Ogre

未读,
1995年7月20日 03:00:001995/7/20
收件人
In article <3ugd9b$g...@ra.nrl.navy.mil>,

Richard Pitre <pi...@n5160d.nrl.navy.mil> wrote:
>There is no mechanism whereby "About emacs" would terminate naturally i.e. this
>intellectual dick bashing can't terminate without the actual removal of organs.
>I believe alt.religion.emacs was created precisely for this purpose. Are we
>stuck with this dialog? Does anyone know how to move it to a more appropriate
>place.

Strike the non-believers with lighting from on high! Tear down
their false idol, the eVIl one! Let not these godless heathens invade
our newsgroup.

Invoke the mystical spell known by many as "Followup-to:" and surely
these infidels will be smitten. Failing that, the holy circle of
spells known collectively as "killfile" may also work miracles.

Joe
--
"Ogre is such a strong word" - Lisa Simpson

0 个新帖子