HDTenEightyP/NetNews huggingface dataset:
From: rahardj@ccu.umanitoba.ca (Budi Rahardjo)
Newsgroups: comp.editors
Subject: Re: XVI
Date: 21 Aug 92 22:24:06 GMT
Organization: University of Manitoba, Winnipeg, Canada

In <4811@balrog.ctron.com> geremia@legolas (Peter P. Geremia) writes:
...
>	Well in my  quest for an X editor I realized that I do like
>the way vi gives you full access to all functionality through the
>keyboard.  BUT  It would be nice to also have the capability to be
>able to point the mouse at a character and the cursor moves to
>that location.  

You might want to try "fpted" then.

-- budi
-- 
Budi Rahardjo <rahardj@ccu.umanitoba.ca>
Unix Support - Computer Services - University of Manitoba
Xref: sparky comp.editors:2012 comp.os.minix:4229 comp.os.linux:8436
From: michael@gandalf.moria (Michael Haardt)
Newsgroups: comp.editors,comp.os.minix,comp.os.linux
Subject: New ftp location for the folding editor Origami
Keywords: origami
Date: 15 Aug 92 21:10:19 GMT
Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
Organization: Moria

The folding editor Origami is no longer available under the minix
directory, because it doesn't run on MINIX any longer.  It is too big for
16 bit MINIX and I don't know any 32 bit MINIX hackers.  (Guess why :)

Now you can get it from:

   ftp.thp.uni-koeln.de [134.95.64.1] : pub/linux/beta/origami
   or [134.95.80.1] : pub/thp/linux/beta/origami

if you are unable to reach the first machine.   

Version 1.6.48 is expected to be released soon.

Michael
Newsgroups: comp.editors
From: sjreeves@eng.auburn.edu (Stan Reeves)
Subject: Re: Why I love VI 
Organization: Auburn University Engineering
Date: Wed, 19 Aug 1992 22:41:30 GMT


I know this may sound almost oxymoronic, but has anyone ever considered
a menu/mouse-driven version of vi?  I wonder if it's even possible.  That
would seem to make most everyone happy.  Those of us who know better (;-) 
would ignore the menus, but it would make it much easier on novices.  And
I wouldn't have to endure Unix neophytes bad-mouthing my favorite 
editor.  :-)


--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
From: mcrowley@mtholyoke.edu (Michael A. Crowley)
Subject: Re: Why I love VI
Organization: Mount Holyoke College
X-Newsreader: Tin 1.1 PL3
Date: Fri, 14 Aug 1992 21:18:43 GMT


robert@isgtec.com (Robert Osborne) writes:
> 
> How can you be faster using arrow keys?  I lose almost 10 keystrokes
> whenever I leave the home row to use arrow keys  (which is why I
> hate DOS programs such as Wordperfect).
> 
You should try XyWrite and remap the keys to do exactly what you
want under your fingertips.  Of course with vendors putting
the control key in awkward places....  But that invites a whole new
thread.

Michael Crowley,  Mount Holyoke College

Newsgroups: comp.editors
From: rcarter@wpi.WPI.EDU (Randolph Carter <Joseph H. Allen>)
Subject: Re: Q: Line # addressing using buffer gap.
Keywords: Finseth, Craft, Of, Text, Editing, buffer, gap
Organization: Worcester Polytechnic Institute
Date: Wed, 19 Aug 1992 16:24:14 GMT

ant@mks.com (Anthony Howe) writes:
>
>Is there a reasonably fast technique, given a Buffer Gap structure,
>for finding line number X.  Currently, AE, just performs linear scans
>for <newline> marks when performing cursor motion, since the
>assumption is that the majority of movement is localized.

Here's a cute idea: change the LFs to CR-LF sequences.  Then you only need
to look at each other character to find the line ends and the search is
twice as fast. 

Or change the lines to <length><chars> sequences.  Perhaps make <length>
variable length so it doesn't waste so much space.  The search is then, say,
30 times as fast.

>Being able to find the start of a line quickly would help in
>implementing a Goto-Line command and possibly a better screen update
>manager.

I've found that the linear search is not so bad for the Goto-Line command,
but maybe if your going to add the full set of vi commands it will become
more important.

I don't know how your screen update/generation algorithm works, but you can
probably eliminate having to do a full screen generation on the simplest,
but most often used commands.  For example, prevent a full screen generation
when you type in characters and when you backspace.  When I added this to
joe, it changed the amount of CPU time it used from being close to that for
emacs to close to that for vi (and emacs does this optimization as well).
Also a hint with curses: if you make a one character change on one place on
the screen then curses does almost no work.  But if you make a one character
change on two places then curses checks all the characters between those two
places.

>I think I read somewhere about the idea of keeping a table of buffer
>indexes that correspond to each line.  Then as you insert or delete
>characters in a given line, all the indexes above line X would need to
>be updated.  This idea strikes me as being very ugly since the time to
>update the indexes is dependant on which line you are currently at.
>If you were at the end of the file, this would be very quick, but if
>you were at the beginning of the file, this time maybe unacceptable
>for large files.

Don't store the line addresses, store the line lengths in the buffer.  This
way you don't have to update anything (but you still have to read through
the buffer sequencially to accumulate the line address).  Actually you could
store the line lengths in a buffer gap and maintain both at the same time,
I.E., to eliminate copying in the table when you insert or delete a line.  
-- 
/*  rcarter@wpi.wpi.edu */      /* Amazing */             /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
From: ward@math.psu.edu (Brian Ward)
Newsgroups: comp.editors
Subject: Re: Why I love VI
Date: 20 Aug 92 01:06:32 GMT
Article-I.D.: cs.Bt9CEw.K42
Organization: The Society for Green Traffic Lights

In article <sjreeves.920819174130@fourier.ee.eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
|I know this may sound almost oxymoronic, but has anyone ever considered
|a menu/mouse-driven version of vi?  I wonder if it's even possible.
[..]
|Those of us who know better (;-) would ignore the menus, but it would make
|it much easier on novices.

that would probably, well, not probably, definitely, make it too slow.

|I wouldn't have to endure Unix neophytes bad-mouthing my favorite 
|editor.  :-)

that's an easy one to fix. our neophytes use Sun's silly textedit thing. some
stick with it, because they are too stuck up to learn anything more powerful,
but some see others using emacs or vi and stop wondering why the hell it
takes them twice as long as someone else to type in a paper.
Newsgroups: comp.editors
From: coactive@netcom.com (Coactive Aesthetics)
Subject: Re: vi dumps core (SunOS)
Date: Fri, 14 Aug 92 10:04:09 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL4

jakkanen@klaava.Helsinki.FI (Jukka Akkanen) writes:
: Today I discovered a mysterious bug in vi on both SunOS 4.1.1 and
: 4.1.2.  Marking a position in a file with letter d, moving below the
: marked line, and performing c'd causes segmentation violation.
: 
: Funny enough, by using any other letter than d for the mark, or `d
: instead of 'd as the cursor movement command, things work the way
: they're supposed to.
: 
: Any comments?
: 

This seems to be a generic bug in vi, since it does the same thing on a
NeXT station (vi version 3.7). I find it is interesting, because I have
been using vi for almost 6 years, and have found it very difficult to do
something which would dump a core file without a lot of work. BTW, I did
the same command in vile (my current editor of choice), and it did the
right thing.

Otto

---
Otto Lind                  Coactive Aesthetics
otto@coactive.com          P.O. Box 425967, San Francisco, CA 94142
netcom!coactive!otto       voice:(415)626-5152    fax:(415)626-6320
From: jack@dusky.UK.Sun.COM (Jack Cooper - Sun EHQ - IR contractor)
Newsgroups: comp.editors
Subject: Re: New ftp location for the folding editor
Date: 21 Aug 92 15:01:46 GMT
Reply-To: jack@dusky.UK.Sun.COM
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: dusky.uk.sun.com




	Anyone know how to increase enviroment space for vi ??


	Jack 
Newsgroups: comp.editors
From: rohit@NeoSoft.com (Rohit Mehrotra)
Subject: Re: Brief-like editor for UNIX?
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Fri, 14 Aug 1992 12:24:28 GMT
Keywords: editor computer UNIX

In article <1992Aug13.210919.29677@awdprime.austin.ibm.com> gbourque@austin.ibm.com (Gary Bourque) writes:
>
>I am looking for a editor for the UNIX (AIX) that is similar to the Brief editor
>for DOS and OS/2.  Does anybody have any suggestions?  Freeware or shareware
>preferred but not required.  Thanks beforehand!

Check CRISP out. It can emulate BRIEF and has a compatible macro language.
The one that is really good is commercial though. Send a mail to 
owner-crisp-list@uunet.uu.net for more info on it.

Rohit 
-- 
Rohit Mehrotra
------------------------------------------------------------------------------
VITAL				| 	10755 Meadowglen Lane, #238
Ph: 713-781-7406		| 	Houston, TX 77042.
Newsgroups: comp.editors
From: fin@unet.umn.edu (Craig A. Finseth)
Subject: Re:  Q: Line # addressing using buffer gap.
Keywords: Finseth, Craft, Of, Text, Editing, buffer, gap
Organization: University of Minnesota, Networking Services.
Date: Tue, 18 Aug 1992 16:55:08 GMT

In article <1992Aug18.132755.25619@mks.com>, ant@mks.com (Anthony Howe) writes:
|> Is there a reasonably fast technique, given a Buffer Gap structure,
|> for finding line number X.  Currently, AE, just performs linear scans
|> for <newline> marks when performing cursor motion, since the
|> assumption is that the majority of movement is localized.
	...
|> I think I read somewhere about the idea of keeping a table of buffer
|> indexes that correspond to each line.  Then as you insert or delete
|> characters in a given line, all the indexes above line X would need to
|> be updated.  This idea strikes me as being very ugly since the time to
|> update the indexes is dependant on which line you are currently at.
|> If you were at the end of the file, this would be very quick, but if
|> you were at the beginning of the file, this time maybe unacceptable
|> for large files.

Most buffer gap systems simply perform linear searches.  Thus, to go
to line X, the editor goes to the start of the buffer and searches
past X-1 newlines.

For most files on most systems, this is fast enough.  Hence, no more
hair is required.

If you need faster performance, you can keep the list as you
suggested, or you can track the current line number, updating it as
you move past newlines.  Marks can also record the line number (you
would have to update or invalidate the line number part of marks after
the point when changes were made).

But all of this is hairy, and I would first find out if
simple-and-straightforward is fast enough.

What to do if it isn't fast enough will vary depending upon the
characteristics of your system and the user's needs and expectations.

Craig
Newsgroups: comp.editors
From: ericm@ims.com (Eric Martinson)
Subject: Re: elvis 1.6 Was Re: elvis 1.6, Sun Sparc and cursors keys
Keywords: elvis 1.6 
Organization: Integrated Measurement Systems, Inc.
Date: Thu, 20 Aug 1992 18:21:42 GMT

Is Elvis V1.6 available ftp anywhere?  

-- 
==========================================================================
Remember, no matter where you go there you are......
ericm@ims.com                               Integrated Measurement Systems
==========================================================================
From: cnap34@ccsun.strath.ac.uk ("G.C.McGregor")
Newsgroups: comp.editors
Subject: TSR DOS editor
Date: 13 Aug 92 18:27:02 GMT
Organization: University of Strathclyde


	Can anyone recogmend a shareware / PD Terminate Stay Resident (TSR)
	editor for DOS . Does one exist ?
	I have looked in the FAQ and in comp.sources etc but cant find one
	anyhere.

	Replies to cnap34@ccsun.strath.ac.uk , an ftp site would be great or
	just a name.

			Many thanks in advance,

				Gordon
From: peter@ferranti.com (Peter da Silva)
Newsgroups: comp.editors
Subject: Re: buffer gap: actually writing an editor
Keywords: Finseth, Craft, Of, Text, Editing
Date: 18 Aug 92 15:30:01 GMT
Organization: Xenix Support, FICC

In article <1992Aug17.142553.28151@news2.cis.umn.edu> fin@unet.umn.edu (Craig A. Finseth) writes:
> I consider that the major issue modes is their psychological
> complexity.  Now, people _can_ learn to deal with anything.  The
> question is, what _should_ they learn.  It is my opinion that modes
> should not be present in core operations such as basic editing.

I believe that there is a certain amount of complexity involved in a
modeless editor, too: you have a smaller namespace available for commands
and the result is less mnemonic than you can get with a moded editor. The
biggest problem with vi is not that it is modeless, but that there is no
feedback on which mode it's in. Some versions will allow you to change the
cursor shape (or, since it's just a string sent when you enter a mode, you
could make it change screen color or something), and some have a mode line.

I really think that in the end it's a matter of what you're used to. The
most popular editor here is Intel's "aedit", which is a moded editor quite
different from vi, and I would unconditionally recommend its interface (the
implementation is pretty deficient in many areas... for example when you edit
a file it trashes all the permissions... but the interface is excellent) even
though I don't care for it myself. You have a status line at the bottom of
the screen, and the available commands are displayed in a paged list above
it. When you change modes the command line changes, to indicate what the
options for this mode are.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: comp.editors
From: s.telford@ed.ac.uk (Scott Telford)
Newsgroups: comp.editors,comp.os.minix,comp.os.linux
Subject: Re: New ftp location for the folding editor Origami
Keywords: origami
Date: 21 Aug 92 10:55:36 GMT
Organization: Dept of Computer Science, University of Edinburgh, UK.

In article <1992Aug19.134345.9845@wheaton.wheaton.edu>,
gmribeir@david.wheaton.edu (Glauber) writes:

> What is a folding editor?

A text editor that structures files in a hierarchical tree structure.
At each level the branches ("folds") are usually shown as single lines
(with some fold marker to show that they're folds, not just lines) and
the editor has functions to expand a fold line into the contents of
the branch, and to collapse the current fold and go back to the
next level up. The only special formatting requirements for the files
are beginning- and end-of-fold marker strings.

This is a simplified and inadequate description, you really need to
use one before you get a feel for the concept.

I think the first folding editor was the one (written in occam 1!)
that came with the old INMOS occam Programming System. (Does
anymbody know of pre-INMOS folding editors?) The later INMOS
Transputer Development System had a similar editor built-in, and the
original version of Origami (totally unlike the current one, thanks to
Michael) was a clone of this. There's at least one other one, AE
(Andy's Editor), a free/shareware DOS text editor.



-- 
Scott Telford, Dept of Computer Science,      electric mail: s.telford@ed.ac.uk
University of Edinburgh, Mayfield Rd, Edinburgh, EH9 3JZ, UK.
------- Rollin' over like a big, big cloud/Walkin' out in the Big Sky! --------
Newsgroups: comp.editors
From: sti@cs.hut.fi (Sami-Jaakko Tikka)
Subject: Re: Why I love VI
X-Md4-Signature: f140a9f888e7067361784c2fd9b5bbf9
Reply-To: Sami.Tikka@hut.fi
Organization: Helsinki University of Technology, Finland
	<fortony.713602130@murphy> <1992Aug12.143949.15498@PacBell.COM>
Date: Thu, 13 Aug 1992 21:03:16 GMT


Sorry, I just couldn't resist

In article <1992Aug12.143949.15498@PacBell.COM> jpglori@srv.PacBell.COM (John P. Gloria) writes:

>   Combine Vi with Eroff(Tm) and I can produce a document that other
>   users think I used a MAC to produce. Yes, I agree, it takes a
>   person with some bit of effort.

Weird.  After all the complaint about menus and mice.  "they think I
used a Mac".  Are you implying documents made with Mac are the
ultimate top?  Then maybe you should produce your documents on a Mac.

By the way Mac has both menus and mouse.
--
Sami.Tikka@hut.fi                                  "Live Long and Prosper!"
---------------------------------------------------------------------------
"I think there's a world market for about 5 computers."
        - Thomas J. Watson, Chairman of the Board, IBM (around 1948)
From: ward@math.psu.edu (Brian Ward)
Newsgroups: comp.editors
Subject: Re: Why I love VI
Date: 21 Aug 92 02:47:44 GMT
Organization: The Society for Green Traffic Lights

In article <STI.92Aug20232719@kuuppa.cs.hut.fi> Sami.Tikka@hut.fi writes:
|>   that would probably, well, not probably, definitely, make it too slow.
|
|Yes it probably would but that's not all vi's fault.

(did i hint at vi being the problem?)

|But there are a lot of faster GUIs out there. [stuff] MacIntoshes have a
|lean-and-mean window system too.

I tend to disagree with "lean-and-mean" being associated with a Mac, but if
you want a really quick windowing system, try out the Amiga's. It's fast,
but... not very portable or networkable.

I have a cute little windowing system for my MassComp 5450 sitting around
here somewhere. It's not very featureful, but it's pretty fast.

|Why is X so big and slow?!?!?

bitmaps, for one. X is bitmap based. but remember - X has to be portable
and networkable. But wait, it gets better :) A minimally-written X server
would be the slowest, because it would not know much about the framebuffer
that it is using. On Suns, for example, there is a tremendous difference
between the R4 and R5 servers on machines with a GX board, because the
server in R5 actually uses some of the GX's prime features.

but that's not the only reason X is so big. and slow.
Newsgroups: comp.editors
From: my2x@fermi.clas.Virginia.EDU (Munho Yi)
Subject: looking for tutorial for 'awk'.
Organization: The University of Virginia
Distribution: usa
Date: Sat, 15 Aug 1992 08:41:33 GMT

i am looking for anonymous ftp site for tutorial for 'awk'.
i should post this in comp.unix.???, but i am not sure
which group is better.  

i perfer answers on my mailbox.  thanks in advance.

munho
my2x@virginia.edu

Newsgroups: comp.editors
From: markm@ee.ubc.ca (mark milligan)
Subject: PD version of Crisp
Keywords: Crisp, Brief
Organization: University of BC, Electrical Engineering
Date: Wed, 12 Aug 1992 16:02:31 GMT

Hello:

I am trying to track down a PD copy of Crisp ( or any other Brief style editor).
It is no longer at the ftp site listed in the Editors list found in this group.

If anybody has a copy or knows where I can get one I would apreciate hearing frome you.


Thanks in advance:

Mark R. Milligan                ( markm@ee.ubc.ca )
University of British Columbia
Department of Electrical Engineering
2356 Main Mall
Vancouver, British Columbia
V6T 1W5				|" Don`t tell me whats happening!...          |
CANADA				|     Just tell me whats going on?    "       |
Phone: (604)822-4242		| infamous quote attributed to ...            |
Fax  : (604)822-9209		| boB (spelled  backwards with a B) J.D. Butt |

				
 


Newsgroups: comp.editors
From: rahardj@ccu.umanitoba.ca (Budi Rahardjo)
Subject: Re: Is there any MacWrite, Word etc like editor available for X-windows
Organization: University of Manitoba, Winnipeg, Canada
Date: Sat, 15 Aug 1992 03:04:48 GMT

hsingh@Turing.chem.uh.edu (Harpreet Singh) writes:
>	I wanted to know if there is any public domain MacWrite or Mac Word
>	like editor available for X - windows.

I don't think there is public domain MacWrite-like program.
(Correct me if I am wrong).
There are many commercial products though, like FrameMaker, Interleaf, 
Island Write, asterix (?) etc.

-- budi
-- 
Budi Rahardjo <rahardj@ccu.umanitoba.ca>
Unix Support - Computer Services - University of Manitoba
Xref: sparky comp.editors:2013 comp.os.minix:4230 comp.os.linux:8441
From: philip@cs.vu.nl (Philip Homburg)
Newsgroups: comp.editors,comp.os.minix,comp.os.linux
Subject: Re: New ftp location for the folding editor Origami
Keywords: origami
Date: 17 Aug 92 11:38:10 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <9208153116@gandalf.moria> u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt) writes:
%The folding editor Origami is no longer available under the minix
%directory, because it doesn't run on MINIX any longer.  It is too big for
%16 bit MINIX and I don't know any 32 bit MINIX hackers.  (Guess why :)

I think that if you can keep Origami more or less POSIX complient, porting
it to a (my) 32 bit version of Minix is not much work. At least the diffs
for 1.6.34 were very small.




						Philip Homburg



Philip Homburg 			   			<philip@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5483546
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands
Newsgroups: comp.editors,comp.os.minix,comp.os.linux
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: New ftp location for the folding editor Origami
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Fri, 21 Aug 92 11:29:05 GMT

I missed the base of this thread - where is the ftp site??

	-Mike
From: wyle@synopsys.com (Mitch Wyle)
Newsgroups: comp.editors
Subject: Re: Why I love VI
Summary: don't move char-at-a-time
Keywords: vi, speed, powern
Date: 13 Aug 92 04:28:42 GMT
Organization: Synopsys, Inc.

In <z551H51m=8@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
>In <4#4mt_p.messina@netcom.com> messina@netcom.com (Tony Porczyk) writes:
>>fortony@sonne.cso.uiuc.edu responds to Barbara Vaughan:
[...]
>>
>>>I only type around 130 wpm, but I guarantee that I with vi can outperform
>>>anyone using one of those silly mouse or F-key editors as long as they
>>>type less than 150 wpm.
>>
[...]
>your fingers to do what you want.  I don't buy the "remembering
>stupid commands" line.  95% of editing is rudimentary.  (move
>cursor, delete, insert, copy.)  For me, it's not my memory that
>slows me down, but rather the complexity and physical awkwardness
>of the keystrokes.
[...]
>After that, you can just spend your time perfecting the
>remaining 5% of your editor.

Moving from char-at-a-time entity commands for cursor movement, yanking,
deleting, and other functions to word, sentence, paragraph, section,
matching brace, or symbolic (find string) type commands for the same
purpose is fundamental to improving one's use of an editor.
Making larger mental chunks for edit tasks, such as using (e.g. in vi)
commands such as y}Gp without thinking much about the task is more
important than differences in typing speed.

Bringing users' skill levels beyond the bare essentials in *any* editor
is sadly neglected.

Peace,
Newsgroups: comp.editors