🚀 go-pugleaf

Jianlin Chang wrote:
> 
> I am considering learning emacs after using  vi for a long time. Is
> the time spend on learning really worth the benefits of emacs vs vi?
> Thanks a lot.

It is in my opinion.  Emacs is a clear superset of vi functionality.

--blake

--
Download complete C source to my Dynace Object Oriented
Extension to C and Windows Development System from:
http://www.edge.net/algorithms
Blake McBride (blake@edge.net)
Algorithms Corporation - 615-791-1636 - USA

changj@jeff-lab@queensu.ca (Jianlin Chang):
> I am considering learning emacs after using  vi for a long time. Is
> the time spend on learning really worth the benefits of emacs vs vi?

<lemming>
"Oh, no!"
</lemming>

Here we go again.
Yet another Usenet flame war.
Set your killfiles on "plonk"!

Ready?  GO!


<lemming>
OooOOo.   .oOOOo.  OooOOo.  
O     `O .O     o. O     `O 
o      O O       o o      O 
O     .o o       O O     .o 
oOooOO'  O       o oOooOO'  
o        o       O o        
O        `o     O' O        
o'        `OoooO'  o'       
</lemming>

RIP, silly troll!
Good riddance!

Sven

-- 
"Yet another gruesome kill."  -Calvin

In article <4qf5lo$lhk@knot.queensu.ca>, Jianlin Chang wrote:
>I am considering learning emacs after using  vi for a long time. Is
>the time spend on learning really worth the benefits of emacs vs vi?
>Thanks a lot.
>

i like the full screen edit capabilities of emacs. but, if you want a
half-way house, try jove.

>--
>Jianlin Chang                    Internet: chang@mjs1.Phy.QueensU.CA
>Department of Physics            Bitnet:   changj@qucdn
>Queen's University               Tel: (613) 545-2723 (o)
>Kingston, Ontario K7L 3N6             (613) 547-1353 (h)
>Canada                           Fax: (613) 545-6463

--
        Dr. Tim Menzies               |  
        timm@insect.sd.monash.edu.au  | Life is what happens while you 
 ,-_|\  www.sd.monash.edu.au/~timm    | are making other plans.
/     \ Dept. Software Development,   |  -- John Lennon (1940-1980)
\_,-._/ Monash University, Caulfield, | 
     v  Melbourne, Australia, 3145.   | 
        +61-3-9903-1033(p)9903-1077(f)| 

changj@jeff-lab@queensu.ca (Jianlin Chang) writes:

>I am considering learning emacs after using  vi for a long time. Is
>the time spend on learning really worth the benefits of emacs vs vi?
>Thanks a lot.

Sure.  The power and flexibility that emacs gives you makes it well
worth knowing.  That said, I'm having a hell of a time making the switch
myself because editing in vi requires no conscious effort.  My emacs
documents tend to have a lot of jjjjj's or :wq's in them just from force
of habit.

The hardest part of making the switch, at least for me, is not trying
to learn/remember all of emacs's commands; there are only a handful
that you _need_ to know upfront.  The hardest part is overcoming the
subconscious.

Jim
-- 
jimhill@swcp.com                          http://www.swcp.com/~jimhill/

   "Iced tea keeps me in a summertime frame of mind."  --  Meldrick Lewis

>>>>> "J." == Jianlin Chang <changj@jeff-lab@queensu.ca> writes:

    J.> I am considering learning emacs after using vi for a long
    J.> time. Is the time spend on learning really worth the benefits
    J.> of emacs vs vi? 

If you want to use emacs `only' for the same tasks as vi, better stay
with vi.  Emacs is more a unified working environment.  You have to
change more things than just the way you edit files.  But if you do,
it could be worth it, depending on your needs.

-- 
------------------------------------------------------------------------
Jens Emmerich, Paul Scherrer Institut, CH-5232 Villigen PSI, Switzerland

In article <4qf5lo$lhk@knot.queensu.ca> changj@jeff-lab@queensu.ca (Jianlin Chang) writes:

   I am considering learning emacs after using  vi for a long time. Is
   the time spend on learning really worth the benefits of emacs vs vi?

You cannot really compare both. Mastering emacs takes about a time
factor of 400 over mastering vi.

You can, however, get along pretty well with emacs without mastering
it, which is true to a lot less degree with vi.

Once you're going with emacs, there are a lot of tasks which emacs can
tackle in handy ways.

I think for me it was worth the time.
-- 
David Kastrup     Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
Email: dak@neuroinformatik.ruhr-uni-bochum.de  Telephon: +49-234-700-5559

In article <jimhill.835463897@kitsune>,
	jimhill@swcp.com (Jim Hill) writes:
|> changj@jeff-lab@queensu.ca (Jianlin Chang) writes:
|> 
|>>I am considering learning emacs after using  vi for a long time. Is
|>>the time spend on learning really worth the benefits of emacs vs vi?
|>>Thanks a lot.
|> 
|> Sure.  The power and flexibility that emacs gives you makes it well
|> worth knowing.  That said, I'm having a hell of a time making the switch
|> myself because editing in vi requires no conscious effort.  My emacs
|> documents tend to have a lot of jjjjj's or :wq's in them just from force
|> of habit.
|> 
|> The hardest part of making the switch, at least for me, is not trying
|> to learn/remember all of emacs's commands; there are only a handful
|> that you _need_ to know upfront.  The hardest part is overcoming the
|> subconscious.
|> 
|> Jim
|> -- 
|> jimhill@swcp.com                          http://www.swcp.com/~jimhill/
|> 
|>    "Iced tea keeps me in a summertime frame of mind."  --  Meldrick Lewis

I too think it is worth the time learning emacs. I've got the version
for X-windows, with the menubar on it, which is great when learning
all the different things :)

The biggest problem I had was indeed finding out this handful of commands
which are essential. Maybe this is a good question for the FAQ:
what are the basic commands one needs to know, before one can use emacs?

An answer could be:

C-x C-f   load file
C-x k     kill buffer
C-x C-s   save file
C-x C-c   quit emacs
C-s       Search
C-h b     list key-bindings
C-h a     command apropos


Well, these are the commands I learned to use first YMMV.



Andries

-- 
------------------------------------------
Andries Kruithof         kruithof@slb.com
Geco-Prakla  
Kongeveien 79, N-3196 Horten (Norway)

These opinions are my own, not necessarily
those of my employer
------------------------------------------

In article <EMGERTZ.96Jun25115906@sdna6.ucsd.edu>, emgertz@sdna6.ucsd.edu (Mike Gertz) writes:
|> In article <4qoutt$97n@info.epfl.ch> "Stefan Monnier" <stefan.monnier@lia.di.epfl.ch> writes:
|>    In article <4qlah5$mek@ohnasn01.sinet.slb.com>,
|>    Andries Kruithof <kruithof@horten.geco-prakla.slb.com> wrote:

[]

|> 
|> I hope you are also asking the vi people, though. You are talking to
|> the converted.
|> 
|> --Mike
|> 
|> P.S. If you are going to do UNIX system admin, you do need to know vi,
|> even if you use emacs for your daily work.
|>  

Hopefully I can add more light than heat...

I use them both.  I would use emacs more if any of the 
local gurus here would take the time to show me more.
For instance, I am writing a small piece of C code that 
I know full well would be easier to do in emacs.  But I need
it done yesterday, and vi is extremely quick.  When I have time,
I will fire up emacs and learn some more.

I see it as a long term process.  Then again, I hope to be
a perfesser, so I got a real loonnggg term point of view.

So, if you are a emacs guru, take a newbie under your wing and
spend some time with him or her.  Don't just teach them 
C-X *; get them set up for programming or using TeX.  

Just another opinion ...

-- 
Dave Doolin             Institute for Geotechnology
doolin@cs.utk.edu       Department of Civil Eng. UTK	


__________________________________________________

You may add me to your junk email list for $1000.00,
payable in US currency.  Otherwise, don't call me,
I'll call you.  Sending me junk email from a list
obligates you to this contract.
_________________________________________________

Larry Riedel wrote:
> 

> 
> The vi editor provides a certain set of capabilities; these capabilities
> are isomorphically represented through the VIPER package which comes with
> GNU emacs, and the vastly larger set of capabilities provided by emacs is
> accessible concurrently with those provided through VIPER.  In my mind
> there is no concept of "emacs vs. vi" since emacs can be treated as an
> extension of vi.  There is a default key mapping in emacs for the basic
> editing commands which can easily be replaced by a vi key mapping.


Is this the same as the VIP mode?  I used this a couple of years ago,
and decided against using it when I found vile.  If the vi mode is improved
I would be interested in trying it again.


emil

In article <4qlah5$mek@ohnasn01.sinet.slb.com>,
Andries Kruithof <kruithof@horten.geco-prakla.slb.com> wrote:
] C-x C-f   load file
] C-x k     kill buffer
] C-x C-s   save file
] C-x C-c   quit emacs
] C-s       Search
] C-h b     list key-bindings
] C-h a     command apropos

I'd add

        C-k	kill-line
        C-y     yank

since it's so much more convenient than the copy/paste of the mouse.


        Stefan

In article <4qoutt$97n@info.epfl.ch> "Stefan Monnier" <stefan.monnier@lia.di.epfl.ch> writes:
   In article <4qlah5$mek@ohnasn01.sinet.slb.com>,
   Andries Kruithof <kruithof@horten.geco-prakla.slb.com> wrote:
   ] C-x C-f   load file
   ] C-x k     kill buffer
   ] C-x C-s   save file
   ] C-x C-c   quit emacs
   ] C-s       Search
   ] C-h b     list key-bindings
   ] C-h a     command apropos

   I'd add

	   C-k	kill-line
	   C-y     yank

   since it's so much more convenient than the copy/paste of the mouse.


	   Stefan

The other truly essential one for me was 

C-x 1 	delete-other-window

since it was initally pretty disconcerting to have windows appear and
have no idea how to get rid of them.

As for the original question -- I also had used vi long enough to make
it instinctive, but the syntax sensitive major editing modes really
won me over, along with the little niceties in emacs which help
prevent bonehead mistakes.

Also, the online help was a very big draw for me. I knew a lot of vi,
but there were always things I did infrequently that I couldn't figure
out, or forgot how to do, so I'd simply use brute force because
learning how to do them right would take more time.

I hope you are also asking the vi people, though. You are talking to
the converted.

--Mike

P.S. If you are going to do UNIX system admin, you do need to know vi,
even if you use emacs for your daily work.
 

Jianlin Chang (changj@jeff-lab@queensu.ca) wrote:
> I am considering learning emacs after using  vi for a long time. Is
> the time spend on learning really worth the benefits of emacs vs vi?

The vi editor provides a certain set of capabilities; these capabilities
are isomorphically represented through the VIPER package which comes with
GNU emacs, and the vastly larger set of capabilities provided by emacs is
accessible concurrently with those provided through VIPER.  In my mind
there is no concept of "emacs vs. vi" since emacs can be treated as an
extension of vi.  There is a default key mapping in emacs for the basic
editing commands which can easily be replaced by a vi key mapping.

I think it is worth taking time to become familiar with GNU emacs because
it is the most effective productivity enhancing software I have encountered
besides the Unix environment itself.  This familiarization can happen at a
comfortable pace.


Larry

In article <pxu3vxehbb.fsf@office.demon.net>,
Nicolai Guba <nicolai@demon.net> wrote:
>
>Anyway.  Emacs is the mother of any development environment I came across so
>far.  The only downside really are its size and thus its sometimes slow loading
>time.  You cannot expect emacs on your recovery floppies.  Thus, I would say
>that any serious UNIX user is at least familiar with both, vi and emacs.

The main problem I have with using emacs as a development/working
environment is that it isn't multithreaded.  If you try to read news or
fontify a large buffer, etc, all other work will come to a halt.  Is
multithreading planned in the next couple of years for (X)Emacs?

-Bruce
-- 
  Bruce A. Templeton                      brucet@engr.sgi.com
  Silicon Graphics Inc.                   (415) 933-3872

>>>>> Regarding Re: is it really worth the time to go from vi to emacs?; sailesh@wowbagger.torolab.ibm.com (Saileshwar Krishnamurthy) adds:
In article <u2688eftev.fsf@wowbagger.torolab.ibm.com> sailesh@wowbagger.torolab.ibm.com (Saileshwar Krishnamurthy) writes:

Andries> The biggest problem I had was indeed finding out this
Andries> handful of commands which are essential. Maybe this is a
Andries> good question for the FAQ: what are the basic commands
Andries> one needs to know, before one can use emacs?
Saileshwar> 
Saileshwar> I think the tutorial is really helpful here. I have converted 4
Saileshwar> people to date, and I always started out by setting up their
Saileshwar> environment and making them go through the tutorial. Once that's
Saileshwar> done it's a  breeze.
Saileshwar> 

Maybe the issue should not be in converting people.  This has a rather sour
aftertaste.   

Emacs is a lisp "interpreter".  It really is an environment, not an editor
(sounds like the GNU acronym <grin>).  Some cynics even call it an
"operating-system with a subshell called UNIX"!  

Anyway.  Emacs is the mother of any development environment I came across so
far.  The only downside really are its size and thus its sometimes slow loading
time.  You cannot expect emacs on your recovery floppies.  Thus, I would say
that any serious UNIX user is at least familiar with both, vi and emacs.
-- 
"Two of the most famous products of Berkley
 are LSD and BSD.  I don't think that this
 is a coincidence..."

Jianlin Chang wrote:
> 
> I am considering learning emacs after using  vi for a long time. Is
> the time spend on learning really worth the benefits of emacs vs vi?

imho: no.
i think, to really master emacs takes the same amount of time as it does for vi.
[by "really master" i mean more than just "read/type/save"... :) ].

if you're using "Vim", what do you really gain by switching over to emacs?
[besides syntax highlighting]
if you're using old vi, take my advice and switch to vim! that's a smooth
transition while still being a huge step! :)

if one has used an editor for a long time, its features are sort of
"hard-wired" in one's spine :) which speeds things up a lot -- by switching
to another editor you're starting that learning process over again.

-- 

Gabriel Zachmann

/----------------------------------------------------------------------------\
| Drei Dinge braucht der Mensch:                                             |
| eine Hoehle, eine Spielwiese,                                              |
| und ein Morgenrot.                                   (Sprichwort)          |
|                                                                            |
| mailto:zach@igd.fhg.de      __@/      http://www.igd.fhg.de/www/igd-a4/vr/ |
\----------------------------------------------------------------------------/

In gnu.emacs.help, Mike Gertz <emgertz@sdna6.ucsd.edu> writes:

> P.S. If you are going to do UNIX system admin, you do need to know vi,
> even if you use emacs for your daily work.
 
A lot of people seem to end up like me.  I love emacs and use it even to
read mail and news (Gnus is the greatest news reader and mail reader in
existence, no exceptions) and for all programming (automatic formatting,
once you've both gotten used to what it does and customized it for your
indentation style, is wonderful).  For almost everything else, I use vi
because it's extremely fast, comfortable, and small, and because I'm
guaranteed to always have it on any Unix system I happen to find myself in
front of.

Yes, I've been through gnuclient/emacsclient and the arguments there, and
yes, you can make emacs start very quickly (I do use gnuclient), but I
still like and use vi.  After the initial adjustment period, I've found it
much easier than I expected to just switch back and forth.

-- 
Russ Allbery (rra@cs.stanford.edu)      <URL:http://www.eyrie.org/~eagle/>

In article <31D0D15E.2312@best.com>, Emil P. Rojas <emilr@best.com> wrote:
) Larry Riedel wrote:
) > The vi editor provides a certain set of capabilities; these capabilities
) > are isomorphically represented through the VIPER package which comes with
) > GNU emacs, and the vastly larger set of capabilities provided by emacs is
) > accessible concurrently with those provided through VIPER.  In my mind
) > there is no concept of "emacs vs. vi" since emacs can be treated as an
) > extension of vi.  There is a default key mapping in emacs for the basic
) > editing commands which can easily be replaced by a vi key mapping.
) 
) Is this the same as the VIP mode?  I used this a couple of years ago,
) and decided against using it when I found vile.  If the vi mode is improved
) I would be interested in trying it again.

Viper is derived from VIP, but it's much improved.  I recommend
giving it a try.  If you prefer something smaller and lighter,
try Vim.
-- 
/George V. Reilly	Vim 4 (vi clone) for NT & Windows 95
<gvr@halcyon.com>	http://www.halcyon.com/gvr/
pgp fingerprint: e2 b4 83 64 11 52 21 ea  bf d8 51 c2 11 00 78 fc

In article <4quo35$8qv@murrow.corp.sgi.com> brucet@leviathan.engr.sgi.com (Bruce A. Templeton) writes:


   In article <pxu3vxehbb.fsf@office.demon.net>,
   Nicolai Guba <nicolai@demon.net> wrote:
   >
   >Anyway.  Emacs is the mother of any development environment I came across so
   >far.  The only downside really are its size and thus its sometimes slow loading
   >time.  You cannot expect emacs on your recovery floppies.  Thus, I would say
   >that any serious UNIX user is at least familiar with both, vi and emacs.

   The main problem I have with using emacs as a development/working
   environment is that it isn't multithreaded.  If you try to read news or
   fontify a large buffer, etc, all other work will come to a halt.  Is
   multithreading planned in the next couple of years for (X)Emacs?

That would be nice indeed. However until that time: I have usually a
couple of emacs'es running: One of them does the news and rmail stuff.
The rest is for development. Fontifying is sometimes to slow...

Avi.
-- 
A. B. Cohen Stuart, M.Sc.     |	Baron van Nagellstraat | Phone: +31 342 428229
Software Engineer/Logic Group |	P.O. Box 143	       | Fax  : +31 342 428787
Baan Research & Development   | 3770 AC  Barneveld     | Email: avi@baan.nl
                              | The Netherlands        |

In article <pxu3vxehbb.fsf@office.demon.net> nicolai@demon.net (Nicolai Guba) writes:

   Anyway.  Emacs is the mother of any development environment I came across so
   far.  The only downside really are its size and thus its sometimes slow loading
   time.

That's why it comes with emacsclient. You are supposed to start just
*one* emacs per computing session, then edit all the rest using
emacsclient resp. multiple frames.

Pretty workable, except if you tend to suspend emacs on text consoles.
-- 
David Kastrup     Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
Email: dak@neuroinformatik.ruhr-uni-bochum.de  Telephon: +49-234-700-5559

In article <u2688eftev.fsf@wowbagger.torolab.ibm.com>, sailesh@wowbagger.torolab.ibm.com (Saileshwar Krishnamurthy) writes:

|>>>>>> "Andries" == Andries Kruithof <kruithof@horten.geco-prakla.slb.com> writes:
|Andries> The biggest problem I had was indeed finding out this
|Andries> handful of commands which are essential. Maybe this is a
|Andries> good question for the FAQ: what are the basic commands
|Andries> one needs to know, before one can use emacs?

|> I think the tutorial is really helpful here. I have converted 4
|> people to date, and I always started out by setting up their
|> environment and making them go through the tutorial. Once that's
|> done it's a  breeze.

Or just print out the reference card.
-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"

In article <4quo35$8qv@murrow.corp.sgi.com>, brucet@leviathan.engr.sgi.com 
says...

>The main problem I have with using emacs as a development/working
>environment is that it isn't multithreaded.  If you try to read news or
>fontify a large buffer, etc, all other work will come to a halt.  Is
>multithreading planned in the next couple of years for (X)Emacs?

I, too, find that nowadays merely one Emacs is not enough
to satisfy my addiction; I am frequently seen with at least 
two open.

dak@neuroinformatik.ruhr-uni-bochum.de (David Kastrup):
> > Emacs is the mother of any development environment I came across so far.
> > The only downside are its size and thus its sometimes slow loading time.
> That's why it comes with emacsclient. You are supposed to start just *one*
> emacs per computing session, then edit all the rest using emacsclient resp.
> multiple frames.  Pretty workable, except if you tend to suspend emacs on
> text consoles.

The use of "emacs client" does not seem to be known to the casual user.
We often get a few people using emacs on the X server - and it sure keeps the
machine busy as hell.  That's why I tell newbies to use use a smaller editor.
Like "pico" for example.  As soon as they ask me about "search and replace"
I show them a slightly better editor.  Some even make it to Vi.
And only those who want everything in one program get to see emacs.  ;-)

Sven

In article <slrn4t8b7v.956.guckes@banach.math.fu-berlin.de> guckes@banach.math.fu-berlin.de (Sven Guckes) writes:

> The use of "emacs client" does not seem to be known to the casual user.
> We often get a few people using emacs on the X server

emacsclient doesn't make emacs multiuser. It just obviates the need to load
up emacs for every file to be edited, and eliminates load times. However,
on any decent OS the executable code of emacs is shared amongst all
invocations (is this true for executables that contain dumped bytecode?).
If the users constantly switch in and out of vi, such sharing cannot be
utilised. 

In article <yqpspbgicpi.fsf@green.baan.nl> avi@green.baan.nl (Avi Cohen Stuart) writes:

> Fontifying is sometimes to slow...
Use on-demand and stealthy fontification then (lazy-lock.el). I've never
had emacs halt for really long periods of time.

In article <omd92j9wov.fsf@tees.cs.ualberta.ca>,
Vladimir Alexiev  <vladimir@cs.ualberta.ca> wrote:
>In article <yqpspbgicpi.fsf@green.baan.nl> avi@green.baan.nl (Avi Cohen Stuart) writes:
>
>> Fontifying is sometimes to slow...
>Use on-demand and stealthy fontification then (lazy-lock.el). 

It seems you have to choose between slow startup or slow(er) scrolling.
Is there any way to combine the fontification methods.  Ideally it would
startup using on-demand fontification, then fontify the rest of the
buffer during idle time, and store it in the font info in the
font-lock-chache file (also during idle time ideally).

Alternatively, is there a way to specify font-lock for files < x lines
and lazy-lock for larger files?

>I've never
>had emacs halt for really long periods of time.

Then you must not read news with emacs, that's what really grinds it to
a halt for me.

-Bruce
-- 
  Bruce A. Templeton                      brucet@engr.sgi.com
  Silicon Graphics Inc.                   (415) 933-3872

%% brucet@leviathan.engr.sgi.com (Bruce A. Templeton) writes:

  >>> Fontifying is sometimes to slow...
  >> Use on-demand and stealthy fontification then (lazy-lock.el). 

  bat> It seems you have to choose between slow startup or slow(er)
  bat> scrolling.  Is there any way to combine the fontification
  bat> methods.  Ideally it would startup using on-demand fontification,
  bat> then fontify the rest of the buffer during idle time,

But... that's exactly what lazy-lock does...

  bat> and store it in the font info in the font-lock-chache file (also
  bat> during idle time ideally).

AFAIK you can't use both lazy-lock and fast-lock (caches font-lock info
in a file) at the same time.

  bat> Alternatively, is there a way to specify font-lock for files < x lines
  bat> and lazy-lock for larger files?

Sure:

 (defvar lazy-lock-minimum-size (* 25 1024)
   "*Minimum size of a buffer for demand-driven fontification.
 On-demand fontification occurs if the buffer size is greater than this value.
 If nil, means demand-driven fontification is never performed.
 If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE),
 where MAJOR-MODE is a symbol or t (meaning the default).  For example:
  ((c-mode . 25600) (c++-mode . 25600) (rmail-mode . 1048576))
 means that the minimum size is 25K for buffers in C or C++ modes, one megabyte
 for buffers in Rmail mode, and size is irrelevant otherwise.

 The value of this variable is used when Lazy Lock mode is turned on.")

  bat> Then you must not read news with emacs, that's what really grinds it to
  bat> a halt for me.

Odd, I have no problems whatsoever reading news with GNUS 5.x and
font-lock.  And I have the most aggressive angry fruit salad
fontification turned on, with full attribution fontification, etc.

Sure, articles over, say 500 lines take a few seconds, but anything less
than 250 or so is unnoticable.

Perhaps you should examine your setup more closely to be sure you're not
causing the slowdown inadvertently.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>         Network Management Development
 Senior Software Engineer                                   Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.

>>>>> %% brucet@leviathan.engr.sgi.com (Bruce A. Templeton) writes:

  bat> Then you must not read news with emacs, that's what really
  bat> grinds it to a halt for me.

>>>>> On 29 Jun 1996 23:52:09 -0400, psmith@baynetworks.com (Paul
>>>>> D. Smith) said:

  Paul> Odd, I have no problems whatsoever reading news with GNUS 5.x
  Paul> and font-lock.  And I have the most aggressive angry fruit
  Paul> salad fontification turned on, with full attribution
  Paul> fontification, etc.

I find that entering large groups (> 100 messages) takes its time.
Now that I've reverted back to the default summary line format, it's
better, but back when I included the date in the summary line --
rather slow.

Of course, this in no way dimishes the great work of Lars!

kai
-- 
Life is hard and then you die.

In article <vafd92hzr3e.fsf@ls6.informatik.uni-dortmund.de> Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de> writes:

> Now that I've reverted back to the default summary line format, it's
> better, but back when I included the date in the summary line --
> rather slow.

What could be the  reason for this?
- does the NOV format include dates? Otherwise Gnus would have to fetch
  full headers to get the date.
- have you complied with the requirement to keep the format relatively
  "fixed" (flags positions should not change), eg by using a fixed-length
  date field.
- have you compiled your new format spec? (I think this first appeared in
  Gnus 5.2) 

In article <31D2A134.446B@igd.fhg.de> "G. Zachmann" <zach@igd.fhg.de> writes:

   imho: no.
   i think, to really master emacs takes the same amount of time as it does for vi.
   [by "really master" i mean more than just "read/type/save"... :) ].
Having used both, I'd say mastering emacs takes a lot longer. But you
can do quite a lot with it without having mastered it.

   if one has used an editor for a long time, its features are sort of
   "hard-wired" in one's spine :) which speeds things up a lot -- by switching
   to another editor you're starting that learning process over again.

Yes, and learning is an utterly useless and bad thing. In addition,
you gain nothing. In principle editors edit text, and you can produce
any text with any editor. I don't know why I even have switched from
ed. Probably because its lines could be no longer than about 256
characters.
-- 
David Kastrup     Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
Email: dak@neuroinformatik.ruhr-uni-bochum.de  Telephon: +49-234-700-5559

In article <m2hgrs5sd1.fsf@mol.neuroinformatik.ruhr-uni-bochum.de>
dak@neuroinformatik.ruhr-uni-bochum.de (David Kastrup) writes:

    David> I don't know why I even have switched from ed.

If you're thinking of switching back, see emacs-19.31/etc/JOKES,
excerpted below.  I guess WYGIWYG means What You Get Is What You Get,
possibly an improvement over What You See Is All You'll Ever Get.

From: patl@athena.mit.edu (Patrick J. LoPresti)

When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow.  They print useless messages like,
'C-h for help' and '"foo" File is read only'.  So I use the editor
that doesn't waste my VALUABLE time.

And ed doesn't waste space on my Timex Sinclair.  Just look:

- -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
- -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
- -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!

"Ed is the standard text editor."

Let's look at a typical novice's session with the mighty ed:

golem> ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello? 
?
eat flaming death
?
^C
?
^C
?
^D
?

- ---
Note the consistent user interface and error reportage.  Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.

"Ed is the standard text editor."

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code!  I just want an EDitor!!
Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
you jest.  They chose the most karmic editor of all.  The standard.

Ed is for those who can *remember* what they are working on.  If you
are an idiot, you should use Emacs.  If you are an Emacs, you should
not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!

?

In article <4r43ps$k1d@murrow.corp.sgi.com>,
Bruce A. Templeton <brucet@leviathan.engr.sgi.com> wrote:
] Is there any way to combine the fontification methods.  Ideally it would
] startup using on-demand fontification, then fontify the rest of the
] buffer during idle time, and store it in the font info in the
] font-lock-chache file (also during idle time ideally).
] 
] Alternatively, is there a way to specify font-lock for files < x lines
] and lazy-lock for larger files?

You are describing lazy-lock.
I guess you haven't tried it since version 2.0


        Stefan

In article <vaohlzqged.fsf@dehn.math.nwu.edu> richter@dehn.math.nwu.edu (Bill Richter) writes:

       David> I don't know why I even have switched from ed.

   If you're thinking of switching back, see emacs-19.31/etc/JOKES,
   excerpted below.
...

Reminds me of an old fortune I got, something like that:

Ken Thompson has designed a new car. The entire dashboard has just one
display which will flash red entirely whenever something requires the
driver's attention.

Mr. Thompson: "The experienced driver usually will know what is wrong."


-- 
David Kastrup     Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
Email: dak@neuroinformatik.ruhr-uni-bochum.de  Telephon: +49-234-700-5559