HDTenEightyP/NetNews huggingface dataset:
From: ttk@ucscb.UCSC.EDU (The Troglodyte Killer)
Newsgroups: comp.editors
Subject: Re: damn tabs
Date: 9 Oct 1992 14:22:57 GMT
Organization: University of California; Santa Cruz
Distribution: inet
NNTP-Posting-Host: ucscb.ucsc.edu


>>>Personaly I use 4 char indentation but provided we both expect the printer
>>>to use 8 char tabs we can either use a good editor or expand and both
>>>treat a tab character as tabbing to 8th coloumn positions we can both print
>>>on the same printer in a form that matches our screen displays.
 
>>If not why don't we just ban all editors and printers that are not the same as
>>yours - that ought to solve all our problems!
 
>But there's GOT to be a better solution than that. BTW nobody actually said we
>were really LOOKING for a solution to a problem of some kind. It was just a
>suggestion.
 
  It seems to me as though enough people have access to usenet 
that if there were a moderated usegroup "comp.standards" or 
somesuch, (with perhaps an accompanying comp.standards.discussion) 
the conventions posted there would start becoming standard 
practice, even if not de facto industry standards.
 
                                                      -- TTK
(Incidentally, I use an editor that allows me to set tabs at 3 spaces
and it actually stores 3 spaces instead of a ^I.)
Newsgroups: comp.editors
From: jc@skyking.uucp (J.C. Webber III)
Subject: Comments about vile
Summary: Why I like vile
Keywords: vile vi emacs
Organization: Skyking Enterprises
Date: Wed, 14 Oct 1992 19:47:09 GMT


I read with great interest the reasons why many people have switched
from vi to emacs.  In almost every case, I have found that the PD
program vile provided the features mentioned, but without having to
learn a new command set.  Vile has multiple named buffers, spit
windows, each window scrolls independantly.  You can compile from
within vile and it will jump to the file and line of code that
produced an error (even if you had not previously had that file loaded
into vile).  You can position the cursor on a filename within your
text and have vile load that file into the editor for editing (works
great with MANIFEST type files).  It also has builtin paragraph
reformating that will reformat an entire document paragraph by
paragraph preserving indentation and paragraph separation.  The name
is an acronym (sp) for Vi-Like-Emacs.  It gives you most of the emacs
benefits without requiring you to abandon vi commands.  It is still a
mode type editor, but it also allows you to use the arrow keys to
reposition the cursur without leaving the insert/append mode.  It has
a c-mode setting that does auto indenting and proper positioning of
braces and brackets.  Plus it is smart enough to leave any "#" type
entries in column 0 when using the c-mode.  I prefer it to emacs
because I just can't seem to remember all those control/meta commands.

Try it.  If you know vi, but you feel you are missing out on emacs
windowing and multiple buffer capability, you love vile.

Just a satisfied customer 8^).

-- 
J.C. Webber III			jc@skyking.UUCP
Systems Administrator		uunet!cadence!mips!skyking!jc
Silicon Graphics Inc.		{ames,decwrl,pyramid,prls)!mips!skyking!jc
(408)524-8256	"Sysadm, it's not just a job.....it's a way of LIFE!" - me
Newsgroups: comp.editors
From: lwv26@cas.org (Larry W. Virden)
Subject: vi question - how to join two lines together 
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Thu, 15 Oct 1992 11:56:30 GMT

I already know from command mode about the j command to join two lines.

What I have is a bunch of lines like:

abc \
	xyz

and I want to turn these into

abc xyz

What is the best way to do this in one command from within vi?
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
Newsgroups: comp.editors
From: richard@pegasus.com (Richard Foulk)
Subject: Re: vi question - how to join two lines together 
Organization: Pegasus,  Honolulu
Date: Fri, 16 Oct 92 15:04:05 GMT

In article <1992Oct15.115734.28806@cas.org> lvirden@cas.org (Larry W. Virden) writes:
>I already know from command mode about the j command to join two lines.
>
>What I have is a bunch of lines like:
>
>abc \
>	xyz
>
>and I want to turn these into
>
>abc xyz
>
>What is the best way to do this in one command from within vi?
>-- 

Try this:

	:g/\\$/s///|j


-- 
Richard Foulk		richard@pegasus.com
Newsgroups: comp.editors
From: jc@skyking.uucp (J.C. Webber III)
Subject: Re: Vi Formating without using fmt
Organization: Skyking Enterprises
Distribution: na
Date: Wed, 7 Oct 1992 00:36:38 GMT

In <92Oct06.1808.662@crash.canon.co.uk> tim@crash.canon.co.uk writes:

>rliles@spuds.mlb.semi.harris.com (Ray Liles) asks:

>|1. How do you insert text into an existing paragraph AND reformat/fill that
>|   paragraph so that all text observes the wrapmargin, without part of a word
>|   on one line and the rest of the word on the next?

>Insert the text and {!}fmt^M. Oops. I used fmt. What about {!}notfmt^M
>and ln -s /usr/ucb/fmt /usr/local/bin/notfmt? Why do you hate fmt so?
>What has it ever done to you?

Personally, I quit using fmt because it doesn't preserve indentation and
it loses the double space I like to put between sentences.  I use either
the public domain program mfold or I use vile with it's builtin reformatting
capabilities (^Af).  It can reformat an entire document, a paragraph, several
paragraphs or to a marker.  It understands paragraphs and preserves the
indentation.  Mfold has many other capabilities also, such as producing
multi-column output.
-- 
J.C. Webber III			jc@skyking.UUCP
Systems Administrator		uunet!cadence!mips!skyking!jc
Silicon Graphics Inc.		{ames,decwrl,pyramid,prls)!mips!skyking!jc
(408)524-8256	"Sysadm, it's not just a job.....it's a way of LIFE!" - me
Newsgroups: comp.editors
From: jaf@jupiter.sun.csd.unb.ca (J Anthony Fitzgerald)
Subject: vi does not scroll properly under some conditions
Organization: University of New Brunswick
Date: Thu, 15 Oct 1992 18:08:49 GMT

One of our users complained to me about the behaviour of vi when he
telnets to our server from his workstation.  The server is a SUN 670/MP
running SunOS 4.1.2 while the workstation is a SPARC station 2 running
SunOS 4.1.1.  The user typically uses a command tool from OpenWindows V2,
although I duplicated the problem by telnetting to his machine then back
to the server.  Setenv shows the TERM to be sun-cmd.

The problem is that when the arrow key (or the j key) is used to scroll
down, only the bottom two or three lines actually scroll and sometimes
text appears to get overlaid with lines which have already scrolled past.
The upper portion of the display do not change.  Entering cntl-L will
refresh the display and the text will be correctly displayed.

I have observed a similar behaviour when dialing in from home using an
IBM3151 terminal.  I have never observed this behaviour with any of the
other workstations connected to the server.  The difference between this
workstation and the others is that most of our workstations are on the
same ethernet segment as the server while this one workstation experiencing
the problem connects through a couple of routers with some non ethernet
segments in between.

I had thought that somehow vi was assuming the terminal to be "slow" and so
was not scrolling the entire text to save line traffic.  I tried using a
"set noslow", however, this made no difference.

Does anyone have any suggestions.  This is more in the area of annoyance
than severe problem, however, I would be grateful if someone could give me
some ideas as to how to address this person's problem.  Before he spoke to
me this morning, he was unaware that he could refresh the screen with ctl-L
or use ctl-f/ctl-b to scroll by entire pages which does not exhibit this
problem, so he's a little happier now.

-- 
J. Anthony Fitzgerald    jaf@UNB.ca	(506) 453-4573
Computing Services  UofNB  Box 4400	(506) 453-3590  (FAX)
Fredericton, NB,  CANADA,  E3B 5A3
Newsgroups: comp.editors
From: sue@netcom.com (Sue Miller)
Subject: Re: damn tabs
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Wed, 14 Oct 1992 19:38:07 GMT

In article <1992Oct12.020339.6920@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of rrb@seas.smu.edu (Robert R. Bailey):
>:for writing text, for which I seldom use tabs.  For programming I find the
>:8-space tab way too much.  Imagine 6 levels of indentation at 8 spaces each.
>:48 spaces just to the beginning of the line! :(  So I :set ts=4 .
>
>Evil.  Set sw=4 instead, and train yourself to use ^T or make a map.
>
>:yuck!!  So I need a way to convert tabs to the number of spaces that I like,
>:which is 4 and sometimes 2.
>
>Which is why it is evil.
>
>:I do not like sitting around waiting for the shell to fork 'expand', or
>:whatever.  I've got better ways to spend my time.  
>
>Are you working on an impoverished system?  What is this "waiting around"
>thing you're talking about?  I bet you "waste" more time between typing
>one shell command and the next.
>

A few years back I switched to the following setup in vi:
   ts=80  <--- I wouldn't need to do this if tabstops were 'standard'
   sw=4
   ai

This made my programming life happy, since tabs were no longer put
in my code.  It is less nice when I use vi on a file which contains,
and needs to contain, tabs.  So I went back to ts=8 in order to
be able to read files as well as write them, and I strip my
source files of tabs (cuz I hate them irrationally).

Having to perform tab-avoidance procedures is why I think tabs are 
really evil in straight ascii files: there is not enough information 
contained in such files to tell me (or my tools) what tab stop was 
used by the author.  It's no use telling everyone to use ts=8 (although 
it helps some), this only shifts the blame.  The computer should take care 
of bean-counting stuff like tabstops, not me.
From: larry@dprmpt.UUCP (Larry)
Newsgroups: comp.editors
Subject: Re: Vi help needed
Date: 12 Oct 92 04:24:50 GMT
Reply-To: larry@dprmpt.UUCP (Larry)
Organization: Data-Prompt

In article <"16177.Thu.Oct.8.06:25:10.1992"@bnr.ca> nickp@BNR.CA ("Nick  Pitfield", N.T.) writes:
> ...stuff deleted...
>so vi is a bit over the top, but it's too late to change now....
>
>It is imperative that users of this system are not able to shell out from vi to
>Unix, so we currently have an .exrc file (owner=root, group=root, perms=644) in
>the user's home directory which maps CTRL-C & CTRL-Z to ESC and sets 'shell' to
>'NOSHELL'. However, we've found that the knowledgeable user can still shell out
>by resetting shell to /bin/sh or similar.
>
>Does anybody know a sure-fire way of preventing shelling out to Unix ? I tried
>mapping ':' to ESC but vi complained that this was too dangerous to map....
>
>Regards.
>
>
>	Nick Pitfield.
>
>/==============================================================================\
>|| INTERNET  : Nick.Pitfield@x400gate.bnr.ca                                  ||
>|| VOICE     : ITN - (590) 4476 : BT - +44 628 794476                         ||
>|| SNAILMAIL : BNR Europe Ltd, BNR Park, Maidenhead, Berkshire SL6 4AG, UK.   ||

We didn't have access to the source for 'vi' and we had a similar need
to prevent users from "shelling out" of vi.  In addition we didn't
want users to be able to directly read or write files (via :r or :w),

We got "stevie", a public domain "vi" clone and I made a few changes to 
prevent disable escapes and other "dangerous" capabilities.  This has 
worked out very well for us.

"stevie" is available from the Usenet source archives.

* - * - * - * - * - * - * - * - * - * - *
* Larry Johnson                         *
* UUCP:      ...!uunet!dprmpt!larry     *
* - * - * - * - * - * - * - * - * - * - *
Newsgroups: comp.editors
From: wlaite@hydra.unm.edu (Winter Laite LAW)
Subject: SUREFIRE document processor
Date: Sun, 11 Oct 92 20:24:57 GMT
Organization: University of New Mexico, Albuquerque

This got PC Magazine's Best New Product award. It is, apparently,
a document processor that can add spreadsheets and databases
to your documents. It is shareware.

Anybody have any comments about it? Know where to FTP it
from?

Thanks in advance
Winter Laite
wlaite@carina.unm.edu


Newsgroups: comp.editors
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Re: damn tabs
Organization: PTT Research
Date: Thu, 8 Oct 1992 08:33:51 GMT


>:> I never understand why people object to tabs apart from when perverts
>:> decide to treat them as other than every 8th position.

>:our printer setup assumes, by default, that they mean 3!  

Which is a hell of a lot more practical than 8. I don't know who invented the
eight but s/he must have been stupid. Of course you would want one level of
indentation to be the same as one tab. I think either we should stop using tabs
at all or abolish the tab=8 standard and make it tab=3. I would love to swap
printers (mine does tab=8 so that I need to expand tabs before I send sth to
the printer) but I suppose you're not interested in a 9 pin matrix printer.


-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: jxh@math.ksu.edu (James C. Hu)
Newsgroups: comp.editors
Subject: elvis 1.6, MSDOS, embedded CR's
Date: 10 Oct 1992 01:38:56 -0500
Organization: Dept. of Mathematics, Kansas State University
Distribution: inet
NNTP-Posting-Host: hilbert.math.ksu.edu
Summary: Fix?

After kicking this around for a better part of this evening, and
probably for a few more evenings to come, I have achieved a partial
fix for elvis 1.6 on MSDOS, compiling with bcc 3.1.

In ex.c, in doexrc(), add "| O_BINARY" to the line that opens the exrc
file, and then in exstring(), add some code to handle '\r' when it is
immediately followed by a '\n'.

Similar changes are required in tmp.c.

Apparently, when a file is read in as text, the read() command strips
the buffer of all CR's.  This includes imbedded ones.  I would call
this a bug in the read() library routine.  Note, that I only have bcc
3.1.  I do not know what the behavior of other DOS compilers are.
But, I will try to dink with the library source, and make it strip
only CR's that are immediately followed by a NEWLINE.
-- 
James C. Hu (jxh@math.ksu.edu), 1804 Denholm Dr., Manhattan, KS 66502
I speak for me, the whole me, and nothing but for me.  So help me me.
Newsgroups: comp.editors
From: annius@nanna.research.ptt.nl (Annius Groenink)
Subject: Re: damn tabs
Organization: PTT Research
Date: Fri, 9 Oct 1992 12:30:26 GMT

nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:


>I am curious to know where you get the idea that one level of indentation
>is 3 spaces? If that's the way you like it then it is fine by me but I think
>that you should know that you are in a (possibly large) minority.

I took that conclusion from the posting I was following up to.

>> at all or abolish the tab=8 standard and make it tab=3. I would love to swap
>> printers (mine does tab=8 so that I need to expand tabs before I send sth to
>> the printer) but I suppose you're not interested in a 9 pin matrix printer.

>The whole point about tabs=8 spaces is that is a standard. I have never yet
>seen a printer using a fixed width font which did not use 8 nor any widely
>used software although I grant you that they can be and often are reprogrammed.

>Personaly I use 4 char indentation but provided we both expect the printer
>to use 8 char tabs we can either use a good editor or expand and both
>treat a tab character as tabbing to 8th coloumn positions we can both print
>on the same printer in a form that matches our screen displays.

>I do hope that your suggestion to make 3 a standard was meant tongue in cheek.

I meant something around 3 as a standard. I could work with 4, but 8 just seems
useless and solely there for the sake of being a historical standard.

>If not why don't we just ban all editors and printers that are not the same as
>yours - that ought to solve all our problems!

But there's GOT to be a better solution than that. BTW nobody actually said we
were really LOOKING for a solution to a problem of some kind. It was just a
suggestion.

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
Newsgroups: comp.editors
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: damn tabs
Organization: AT&T
Date: Fri, 9 Oct 1992 07:38:42 GMT

From article <annius.718533231@freyr>, by annius@sif.research.ptt.nl (Annius Groenink):
> 
>>:> I never understand why people object to tabs apart from when perverts
>>:> decide to treat them as other than every 8th position.
> 
>>:our printer setup assumes, by default, that they mean 3!  
> 
> Which is a hell of a lot more practical than 8. I don't know who invented the
> eight but s/he must have been stupid. Of course you would want one level of
> indentation to be the same as one tab. I think either we should stop using tabs

I am curious to know where you get the idea that one level of indentation
is 3 spaces? If that's the way you like it then it is fine by me but I think
that you should know that you are in a (possibly large) minority.

> at all or abolish the tab=8 standard and make it tab=3. I would love to swap
> printers (mine does tab=8 so that I need to expand tabs before I send sth to
> the printer) but I suppose you're not interested in a 9 pin matrix printer.
> 

The whole point about tabs=8 spaces is that is a standard. I have never yet
seen a printer using a fixed width font which did not use 8 nor any widely
used software although I grant you that they can be and often are reprogrammed.

Personaly I use 4 char indentation but provided we both expect the printer
to use 8 char tabs we can either use a good editor or expand and both
treat a tab character as tabbing to 8th coloumn positions we can both print
on the same printer in a form that matches our screen displays.

I do hope that your suggestion to make 3 a standard was meant tongue in cheek.
If not why don't we just ban all editors and printers that are not the same as
yours - that ought to solve all our problems!

> 
> -- 
> Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
> Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
> Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
> _____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: jim@n5ial.chi.il.us (Jim Graham)
Newsgroups: comp.editors
Subject: Vi Formating without using fmt 
Distribution: world
Date: Fri, 16 Oct 92 22:07:05 GMT
Organization: Me? Organized? Hah! :-)

In article <1992Oct13.021338.9503@chpc.utexas.edu>
pejj232@chpc.utexas.edu writes:

> It seems you are probably on a poor Ultrix machine. Sun, Convex, etc have
> fmt [-width] in man pages.:^)

I can't exactly double-check this these days, but I seem to recall that
the Ultrix man pages did, in fact, include the -width bit.  of course,
it's been a long time, and I learned about this through examples posted
to this group, so I could be mistaken.....

but I can certainly tell you that the bit I'd posted before about fmt
properly handling hanging indentation, 2 spaces after the period, and
(although I didn't mention it in that post) variable widths to format
to, all includes the Ultrix machine I ran for several years (among
others).

   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/9)
------------------------------------------------------------------------------
INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
ICBM:  41.70N 87.63W                    UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO: n5ial@n9hsi (Chicago.IL.US.Earth)    AMTOR SELCAL:  NIAL
------------------------------------------------------------------------------

Newsgroups: comp.editors
From: pejj232@chpc.utexas.edu (@8^>)
Subject: Re: Vi Formating without using fmt 
Organization: The University of Texas System - CHPC
Date: Tue, 13 Oct 92 02:13:38 GMT

In article <1992Oct12.113207.14013@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>In article <718826842snx@n5ial.chi.il.us> jim@n5ial.chi.il.us (Jim Graham) writes:
>>In article <1992Oct7.003638.14933@skyking.uucp> jc@skyking.uucp writes:
>>
>>> Personally, I quit using fmt because it doesn't preserve indentation and
>>> it loses the double space I like to put between sentences.
>>
>>*** SINCE WHEN??? ***  fmt does indeed preserve indentation, and it does
>>*NOT* lose the standard 2 spaces after a period.  are you sure you don't
>>just have a broken clone of fmt?
>
>A lot of the man pages for fmt do not list its full capabilities, yet the
>program still performs them.  For instance, my man pages say nothing about
>controlling the column width through format, and that its output will only
>be in 72 columns.  Well, sure enough, I tried using "fmt -68" and voila, 68
>columns.  Maybe there are some options that person needs to use which are
>"undocumented".

It seems you are probably on a poor Ultrix machine. Sun, Convex, etc have
fmt [-width] in man pages.:^)

Luke
From: bshaw@spdc.ti.com (Bob Shaw)
Newsgroups: comp.editors
Subject: using TMPDIR in vi as an env variable ?
Date: 11 Oct 92 20:06:08 GMT
Article-I.D.: bobasun.bshaw.718833968
Organization: TI Semiconductor Process and Design Center


Hi 
I was asked the other day to help this lady edit a file
using vi .  This file was ~ 20mbyte ascii file.  

Of course, my system (a sun4) complained about not enough
room in /tmp (or /var/tmp).  

I had remembered the env variable TMPDIR and tried 
setenv TMPDIR /u1/jane_doe/newtmp  where I had lots 
of room.


This didn't work.  Is there a simple way around this problem
other than dividing the file into smaller files to edit and 
then rebuild the file?

I know I could have temp linked /tmp to another dir but just
wondered if there was a way to make TMPDIR work for this.

Thanks in advance for any comments.

Thanks

Bob
bshaw@spdc.ti.com
Newsgroups: comp.editors
From: gmribeir@david.wheaton.edu (Glauber)
Subject: Re: Vi Formating without using fmt
Organization: (n.) Body of persons united for a specific purpose.
Distribution: na
Date: Thu, 8 Oct 1992 15:00:22 GMT

In article <1992Oct7.171302.25614@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of jc@skyking.uucp (J.C. Webber III):
>:Personally, I quit using fmt because it doesn't preserve indentation and
>:it loses the double space I like to put between sentences.  
>
>Funny, the version of fmt I use (straight BSD, I think) does indeed
>do those things you say yours does not.
>
>--tom
>-- 

The fmt that comes with elVIs also preserves identation and
spacing. I compiled it and use it with the vi we have here.

						Glauber
-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  glauber@david.wheaton.edu 
                  glauber@vpnet.chi.il.us
Newsgroups: comp.editors