Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!nucsrl!tellab5!vpnet!dattier
From: dattier@vpnet.chi.il.us (David W. Tamkin)
Newsgroups: comp.editors
Subject: Re: vi mapping difficulty
Message-ID: <1991Mar14.202058.4611@vpnet.chi.il.us>
Date: 14 Mar 91 20:20:58 GMT
References: <1991Mar08.205940.11108@vpnet.chi.il.us> <1991Mar13.084943.934@cs.ucla.edu>
Organization: VPnet Public Access Unix, Villa Park, Illinois  60181-2206
Lines: 111

gast@lanai.cs.ucla.edu (David Gast) wrote in <1991Mar13.084943.934@cs.ucla.edu>:

| In article <1991Mar08.205940.11108@vpnet.chi.il.us> [I wrote:]

| >I want to clear out any lines that don't have text on them.  The purpose is
| >to separate paragraphs in quoted text.  So I have this in my .exrc:
| >	map ^X :v/[0-9A-Za-z]/s/.*//^M

| I use map #4 mz:%s/[	 ][	 ]*$//^M`z
| where there is a tab and a space between every [ and ] pair.

| In re-reading your posting, I think you want to make a paragraph break
| whenever rn (or some other news server) has inserted a > (or related
| character) at the beginning of a blank line so that a line that only
| contains characters like "<>=" is made empty.  Is that what you mean by
| quoted text?

Yupper, that's what I meant, not only in rn but also in elm.

| Thus, you could use as the left hand side of the s command:
| 	^[^a-zA-Z0-9][^a-zA-Z0-9]*$
| where all the carets are literal.  Please note, however, while, I think,
| the change immediately above describes what you wrote, it may not be what
| you want.  For example, any lines that contain only a { or } (from a C
| program perhaps) will also be deleted.  You *may* want to change only
| those lines beginning with > or only those lines containing >*.

Yes, it's equivalent to what I wrote and it is what I want.  With unabashed
plagiarism from Barbara Tongue, when I see code, I run.  Not everyone (and
I'm an example) cites text with right-side angle brackets.  I do not intend
to preserve braces nor to operate only on lines with initial right-side angle
brackets.

I did, however, shorten the search string to /^[^0-9A-Za-z]*$/.  It doesn't
bother me if the report function includes lines that were blank all along
when it gives the count of lines changed, and I don't see any other
difference.  Perhaps when I put it into .exrc once and for all, I'll use
the longer form you recommend.

| My macro is superior in terms of speed (only an issue for large files)
| because s is much faster than v/g.  If you don't believe it, try two
| identical command on /usr/dict/words and notice the difference in time.
| That is, you should only use v or g when you want to do something that
| s alone cannot do like delete the line or change a different line.

Your advice did the trick.  Oh, I didn't even try to compare speeds, but :%s
works here and :g and :v do not, so speed comparisons don't even come into
play.

| >If I've just read the file into the buffer and made no changes yet, it works.
| >Otherwise, one or two occurrences of the pattern get replaced and the
| >operation stops with "Can't undo in global" -- so who asked for an undo?

| I have never had this happen with my macro and I don't see why you are
| having difficulties.  I did not try to investigate either.

Of course it doesn't happen with your macro.  Your macro doesn't have a
global operator in it.  Per your suggestion I changed the :v (:g syntax had
not worked either) to :%s with a search string.  It worked fine and was
reversible with u.  [Carelessly I first used :%s/[^0-9A-Za-z]*$// with only a
right anchor and managed to drop the end punctuation of every paragraph and
of every sentence that ended at the right margin.  With only a left anchor
I'd lose initial parentheses and asterisks, so clearly both anchors are
necessary.]

/* begin 100% unadulterated, unalloyed, certifiable speculation in a vacuum */

I guess that this is the problem: a key rebound with ":map" (unlike :map!)
is supposed to perform a reversible function, so including a :v or a :g in a
mapping might be the problem.  The undo buffer says that here is this
(possibly null, if the last operation was a, A, i, I, o, or O) text, and here
are two pointers into the current buffer, and the undo text used to go from
pointer #1 to pointer #2 instead of the (possibly null, if the last operation
was d or D) text that is between those points in the edit buffer now.  If you
use :v or :g you can make several changes to scattered, disparate, disjunct
areas of the text, and the undo buffer can't keep track of all those
beginnings and endings.  :%, on the other hand, simply holds the entire
previous condition of the document in the undo buffer and puts the pointers
at the beginning and the end, so :% is legal in mappings.

It was the :v or the :g that caused it, not the s command itself.

In fact, that goes along with my experience: the old macro, perhaps, was
changing one occurrence of the pattern (well, with :v syntax, one absence of
the pattern) or one group of consecutive lines that had (actually lacked) the
pattern.  That could well be that if there already was a blank line ahead of
any other line that fit (failed) the pattern (with the :v syntax a blank line
will always qualify as failing a pattern unless it's v/^$/), it changed the
blank line to still blank, reported "1 line changed" and quickly overwrote "1
line changed" with "Can't undo in global."  Yes, upon further experimentation
I saw that it was saying "1 line changed" but it was really hard to catch. 
If all the changes had been in a contiguous range of lines, it would have
been undoable and the macro would have proceeded.

So why would it work when I first read in a file?  Because, perhaps, it was
saving the entire document in the undo buffer and setting the undo pointers
at the beginning and ending of the edit buffer.  After any other changes the
numbered buffers would have started filling, and a :w wouldn't clear them
out, but an :e or :n would.  For some reason, having used the numbered
buffers makes a difference.

/* end speculation */

So you and I have different reasons for avoiding globals.  We very likely
have different reasons for reading netnews, but we both got here just the
same.  Thank you again, Mr. Gast.

David Tamkin  PO Box 7002  Des Plaines IL  60018-7002  dattier@vpnet.chi.il.us
GEnie:D.W.TAMKIN  CIS:73720,1570  MCIMail:426-1818  708 518 6769  312 693 0591

"Parker Lewis Can't Lose" mailing list:   write flamingo-request@ddsw1.mcs.com