Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!pierson@mist
From: pierson@mist (Dan Pierson)
Newsgroups: comp.editors
Subject: Re: Editor extensibility
Message-ID: <4210@encore.UUCP>
Date: 16 Nov 88 16:23:34 GMT
References: <4052@enea.se> <97@usl-pc.usl.edu>
Sender: news@encore.UUCP
Reply-To: pierson@mist (Dan Pierson)
Organization: Encore Computer Corp
Lines: 28
In-reply-to: jpdres10@usl-pc.usl.edu (Green Eric Lee)

In article <97@usl-pc.usl.edu>, jpdres10@usl-pc (Green Eric Lee) writes:
 >> Also, I don't want a move-by-word command pass line borders. 
 >
 >What's a line border? Sounds like YOU are making artificial
 >assumptions here! Why should a \n be any different from any other
 >white-space character in a file (as defined by the syntax-table)? 

Sounds like he wants vi-like behavior, some people do.  Much as I like
it, Emacs behavior is not the revealed truth, in fact the quarter
plane model used by the Yale and Rand editors is sometimes very useful.

 >GNU Emacs, I know you COULD write a Lisp function which goes snooping
 >character-by-character and won't pass the end-of-line... but I'd hate
 >to see how slow that'd be (even byte-compiled Lisp is slower than
 >compiled "C").

It shouldn't really be that bad, just find the appropriate line
boundary (e.g. try ^H-f end-of-line) get the char pos, notice if word
movement took you past it, and back up and stop moving if so.  Sure,
this won't be quite as fast as a compiled "C" search, but there aren't
very many words on a line of reasonable length so it'll still be much
faster than you can see.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@multimax.encore.com