vi/comp.editors/ced.tips.2

675 lines
25 KiB
Groff
Raw Permalink Normal View History

2024-06-16 21:59:42 +02:00
From kirkenda@eecs.cs.pdx.edu (Steve Kirkendall)
Subject: Quoting in ex/vi -- more info
Date: 12 Nov 91 01:15:09 GMT
Organization: Portland State University, Portland, OR
Status: O
The first results are in on my question about character quoting in ex/vi.
The table below shows what I've learned from e-mail, and a few tests.
Please check it out, and let me know of any errors or omissions.
ex vi .exrc characters to quoted
----+----+------+--------------------------------------------------------
\ \ ^V The | command separator
\ ^V n.a. Special control characters on any command line
^V ^V^V ^V Whitespace in a :map or :unmap command
\ \ \ Whitespace in a :set command
\ \ \ Meta-characters in a regexp or substitution text
\ \ \ The %, #, and ! characters in a shell escape/filename
The "ex" column refers to command lines that are interactively typed
into ex, or for ex macros executed via ":@x".
The "vi" column refers to ex command lines that are interactively typed
using vi's ":" command. It also works for vi macros/maps which use ":".
Please note that when you're defining the macro, though, you'll need to
quote any ^Vs to delay their effect until the macro is applied. Also,
to quote a whitespace character in a :map command, you need to actually
insert a ^V into the command line, which is done by hitting ^V twice.
The ".exrc" column refers to commands in the .exrc file, or a file
which is executed via the ":so" command, or for the value of EXINIT.
The quoting character for special control characters is different, but
this is probably due to the serial line discipline, and not so much
ex/vi itself. This also explains why ^V must be typed twice in vi but
only once in ex, to quote whitespace in a :map. Bearing this in mind,
the quoting character is consistent in all contexts except when the
'|' command separator is to be quoted in .exrc files.
-------------------------------------------------------------------------------
Steve Kirkendall kirkenda@cs.pdx.edu Grad student at Portland State U.
From abed@saturn.wustl.edu (Abed M. Hammoud)
Newsgroups: comp.editors
Subject: Vi and Tags file...(please help).
Date: 23 Nov 91 18:36:18 GMT
Organization: Washington University, ESSRL
Status: O
hello, I have been a very..very..dedicated vi user for a long
time now. I was always wondering about what people meant by tag files (I
program in C). I looked up the manuals we have in the lab and I could not
find something that was enough for me to understand what is a tag file
and how to use tags. I do a lot of programming...I have a big library
of functions that I usually call from within my programs...so what can
tags do for me....Please if any body can help me understand this I
would be very thankful.
PS: Please no flames
Thanks a million,
+-------------------------------------------------+-----------------------+
|Abed M. Hammoud (KB0INX) | abed@saturn.wustl.edu |
|Washington University. | Office: |
|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 |
|Department of Electrical/Biomedical Engineering. | -FAX: (314) 935-4842 |
|Campus Box 1161, One Brookings Drive. | |
|St. Louis, MO , 63130 USA | |
+-------------------------------------------------+-----------------------+
From kev@sol.acs.unt.edu (Mullet Kevin Wright)
Subject: piping in an ex keymap
Date: 23 Nov 91 19:34:38 GMT
Organization: University of North Texas
Status: O
Recently, I posted a request for a way to do a pipe in an ex keymap.
My post got garbled becuase I left the actual control characters from my
.exrc in and they, and everything east of them, got dropped in my post.
A few intuitive folks knew what I meant anyway and gave me this really
nice solution (that I wasn't able to find in my O'Reilly & Associates
_Learning the vi Editor_ book.
To place a | in an ex shell command, do a ^V^V| to put a literal ^V in front
of it. One ^V will just leave you with a |, you need an actual ^V| in the
text.
Thanks to Steve Kirkendall and Hans Mulder for their insight. I'm writing
this in the inside of my O'Reilly book now. :)
-Kevin Mullet
University of North Texas
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: EX / VI delete up-to and including
Summary: Addressing lines in vi and ex
Keywords: vi, ex
Date: 24 Nov 91 02:53:20 GMT
Organization: Telecom Research Labs, Melbourne, Australia
Status: O
I use vi, and I frequently work with logical blocks using ``/'' or
``?'' to find the end or beginning of the block. For example, here is
a LaTeX construct:
\begin{environment}
\begin{environment2}
sfdasfda
sfdafasd
asfdasfdfdas
\end{environment2}
\end{environment}
If I want to delete the inner environment, I usually type:
d/^ \\/ or d?^ \\?
Unfortunately, this leaves the closing symbols behind, i.e:
\begin{environment}
\end{environment2}
\end{environment}
I noticed that the whole inner environment is deleted if I typed:
d/^ \\/+0 or d?^ \\?+0
The ``+0'' after the pattern match makes vi think the line containing
the pattern is included in the text to be deleted. The SunOS 4.0.3
manual on vi make no mention of this. As far as addressing lines is
concerned, what does the trailing ``+0'' mean to vi?
(On a related matter, this operation seems to be equivalent to typing
the following in ex: :.,/^ \\/d and ?^ \\?,.d)
The system I am using: SparcStation 1+, SunOS 4.1.1
Regards,
---
Soh, Kam Hung | h.soh@trl.oz.au | Telecom Research Laboratories,
| +61 3 253 6638 | POB 249 Clayton, Victoria 3168, Australia
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: EX / VI delete up-to and including
Keywords: vi, ex
Date: 25 Nov 91 14:07:11 GMT
Sender: news@sci.kun.nl (NUnet News Owner)
Organization: University of Nijmegen, The Netherlands
Status: O
In <1991Nov24.025320.16271@trl.oz.au> soh@andromeda.trl.OZ.AU (Kam Hung Soh) writes:
>I use vi, and I frequently work with logical blocks using ``/'' or
>``?'' to find the end or beginning of the block. For example, here is
>a LaTeX construct:
>\begin{environment}
> \begin{environment2}
> sfdasfda
> sfdafasd
> asfdasfdfdas
> \end{environment2}
>\end{environment}
>If I want to delete the inner environment, I usually type:
>d/^ \\/ or d?^ \\?
>Unfortunately, this leaves the closing symbols behind, i.e:
>\begin{environment}
> \end{environment2}
>\end{environment}
>I noticed that the whole inner environment is deleted if I typed:
>d/^ \\/+0 or d?^ \\?+0
>The ``+0'' after the pattern match makes vi think the line containing
>the pattern is included in the text to be deleted. The SunOS 4.0.3
>manual on vi make no mention of this. As far as addressing lines is
>concerned, what does the trailing ``+0'' mean to vi?
Vi distinguishes "line" moves and "character" moves. If you apply the 'd'
operator to a line move, vi deletes the starting line, the target line and
all intervening lines. If you apply the 'd' operator to a character move
that ends on a different line, the parts of the starting and target line not
moved over are not deleted. The '/' operator usually produces character
moves, but the "+0" suffix makes it a line move.
You can replace the "0" by an other line count, e.g. d/foo/+3 deletes line
up to and including the third line following the next occurrence of "foo";
and
d/^\\/-1
does what Kam Hung Soh wants with fewer keystrokes. Actually, he can save
one more keystroke: the '1' is optional, so
d/^\\/-
would also work. FWIW the '+' is also optional.
And you can type several of these offsets, e.g.
d/foo/++
is equivalent to
d/foo/+2
Finally, there is the possibility to tack on another search:
d/foo/;/bar/
deletes up to (but not including) the first occurrence of "bar" after the next
occurrence of "foo".
Oh, and all trailing delimiters are optional.
>(On a related matter, this operation seems to be equivalent to typing
>the following in ex: :.,/^ \\/d and ?^ \\?,.d)
They are exactly equivalent if you :set nowrapscan. Under wrapscan, there
are situations where :.,/foo/d would reply "First address exceeds second",
while d/foo/0 would merrily delete a large part of your buffer.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From mrd@ecs.soton.ac.uk (Mark Dobie)
Subject: Re: Vi and Tags file...(please help).
Date: 25 Nov 91 09:52:58 GMT
Sender: news@ecs.soton.ac.uk
Status: O
In <1991Nov23.183618.21929@wuecl.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes:
> hello, I have been a very..very..dedicated vi user for a long
>time now. I was always wondering about what people meant by tag files (I
>program in C). I looked up the manuals we have in the lab and I could not
>find something that was enough for me to understand what is a tag file
>and how to use tags.
I used vi for a few years before I found out about tags. Tags is one
of the features that sets vi apart from a lot of other editors.
> I do a lot of programming...I have a big library
>of functions that I usually call from within my programs...so what can
>tags do for me....Please if any body can help me understand this I
>would be very thankful.
Here is how I use them. You need to run "ctags" to generate a tags file
for vi to use. I usually have a target in my makefile and type "make
ctags" occaisionally to keep it up to date. The ctags command (in the
makefile) looks like,
ctags *.c *.h libsrc/*.c libsrc/*.h
This generates a file called tags with references to all the functions
in the program and library source.
Now in vi, you can place the cursor at the start of a function name and
press ctrl-]. This will take you to the function definition (even in
another directory). You can read it or edit it and then you press
ctrl-^ to return to where you were. That's the simplest way to use
tags.
Any more advanced users out there who might have built a hypertext
system :-)
Mark.
From hansm@cs.kun.nl (Hans Mulder)
Newsgroups: comp.editors
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 26 Nov 91 16:29:09 GMT
Organization: University of Nijmegen, The Netherlands
Status: O
In <1991Nov26.135248.6911@cc.ic.ac.uk> cyber@sig.ee.ic.ac.uk (Nick Sales) writes:
>There is also a ":pop" command, which, not unreasonably, pops you up one
>tag, so returning you to your previous pre-push position.
In this version of vi (the one that comes with SunOS 4.1.1, :version says
Version SVR3.1) control-T is bound to :pop.
>There are some (undocumented at my site) options to do with the tagstack
>too: taglength/tl (how long it is), and tagstack/tgstck (?).
Tagstack is a Boolean option, :set notagstack disables the :pop command
(why would anybody want to do that?). There is also a "tags" option,
specifying the list of files to be searched for tag definitions.
>BTW, I also found option "window/wi" in there: anyone know what it does?
It defines the number of lines drawn initially when you jump to a different
part of the buffer. More lines are drawn if you move around locally.
Useful when editing at low baud rates. On some versions of vi you can put
in your .exrc (for example)
:set w300=5 w1200=11
This :sets the window option to 5 when working on 300 baud (or lower),
to 11 when using 1200 baud and the default (screen height-1) when using
a higher line speed.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.unix.misc,comp.editors
Subject: What does this do? (was Re: Vi internal design doc. needed)
Date: 26 Nov 91 14:16:06 GMT
Organization: UniSoft Ltd., London, England
Status: O
In <8460@autodesk.COM> dansmith@Autodesk.COM (Daniel Smith) writes:
> quick! What does this do?
>map ]/ lbywo/^[p"xdd@x
There's no quick answer, because the behaviour depends on the current
cursor position and, if autoindent is set, on whether the current line
is indented and how far.
The following analysis is all done from memory of the behaviour of the
vi commands used, not from trying out the macro, so please accept my
apologies for any inaccuracies. Note that the phrase "beginning of line"
refers to the first non-white-space character on the line.
1. If the cursor is not on the last line of the file and not at the
end of a line, and either the line is not indented or autoindent is
not set, then it searches for the first occurrence of the word under
the cursor plus any white space which follows it, starting the search
from the beginning of the next line.
2. If the cursor is on the last line of the file, then it behaves as in
(1) except that the search starts at the beginning of the current line.
3. If the cursor is at the end of a line, then it beeps and does nothing.
4. If autoindent is set and the current line is indented:
4a. If the indent extends beyond the first tabstop, and tab is not
mapped, then it beeps and moves the cursor to the start of the
next line.
4b. If the indent does not extend beyond the first tabstop, and
the number of spaces of indent does not exceed the number of
characters on the next line (not including any leading white
space), then it behaves as in (1) except that the search begins
N characters from the beginning of the next line, where N is
the number of spaces of indent.
4c. If the indent does not extend beyond the first tabstop, and
the number of spaces of indent exceeds the number of
characters on the next line (not including any leading white
space), then it beeps and moves the cursor to the end of the
next line.
I think that's enough to show that the macro is rather inconsistent in
its behaviour. I can suggest a number of improvements:
If "wb" is used instead of "lb", then it will not fail at the end
of a line, except on the last line of the file.
If "deu" is used instead of "yw", then white space following the
word will not be included in the search.
If "o^[pI/^[" is used instead of "o/^[p", then it will work properly
when autoindent is set and the current line is indented.
If "mx" is added at the start of the macro and "`x" is added before
the "@x", then the search will start from the current cursor
position instead of from the beginning of the next line (or the
current line if it is the last line of the file).
Moral: there's more to writing good vi macros than you might think.
--
Geoff Clare <gwc@root.co.uk> (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
From jimc@isc-br.ISC-BR.COM (Jim Cathey)
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 26 Nov 91 21:58:07 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company
Status: O
>Now in vi, you can place the cursor at the start of a function name and
>press ctrl-]. This will take you to the function definition (even in
>another directory). You can read it or edit it and then you press
GNU Emacs also can use tag files. I believe it can read the files
made by ctags, and it also reads the files made by emacs' etags
program (which I think also will tag lisp files as well as C files).
I believe you follow a tag with M-C-., or something like that (it's
a single keystroke [not counting shifties]). You get back to where
you were with the normal C-X b <ret> command for moving to the
previous buffer. Just fanning the flames...
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
"PC's --- the junk bonds of the computer industry"
From steveha@microsoft.com (Steve Hastings)
Date: 26 Nov 91 22:08:08 GMT
Reply-To: steveha@microsoft.UUCP (Steve Hastings)
Organization: Microsoft International Products Group
Status: O
In article <1991Nov23.183618.21929@wuecl.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes:
> hello, I have been a very..very..dedicated vi user for a long
>time now. I was always wondering about what people meant by tag files (I
>program in C).
Tags are a limited, but nevertheless extremely useful, form of hypertext.
You run a program, usually called "ctags", on your C source code files; it
looks for interesting text, mainly function declarations, and adds what it
finds to your "tags" file.
The "tags" file (which is usually called "tags" -- no big surprise there)
is an index into your sources. Once you have it built, you can type
":ta foo" from vi, and vi will load in the source file where foo() was
defined, and position the cursor on the line where foo() was defined.
There is also a shortcut key, Ctrl+] (to remember this, think "go right
to"). You put the cursor on the first letter of the function you are
interested in, hit Ctrl+], and it jumps to the definition as above.
Depending on the version of vi you have, you may have a "tags stack", where
vi keeps track of where you were before you jumped to the tags reference.
If you have this, Ctrl+T in vi command mode will return you to where you
were before you used Ctrl+] or the :ta command. If you do have the tags
stack feature, you can make multiple jumps with the tags commands, and
still be able to return to where you started; each Ctrl+T takes you
backwards one jump, until you wind up where you started.
Here are two lines from one of my tags files:
AbortLayout layout.c ?^AbortLayout()$?
AddBarChr print3.c ?^AddBarChr( a, b)$?
The first field is the tag to search for, the second field is its filename,
and the last field is a search pattern to use to find the definition line.
Note that vi uses a search command, instead of an absolute line number, so
that the tags file will not be useless after you add or delete lines from
your sources.
If you don't have a tags generator, you can write one using the above
format, or you can manually add tags that weren't automatically generated.
For example, I wrote a program that makes tags from AWK source files.
Other text editors have tags, too. I'm pretty sure EMACS has them.
Words do not adequately describe how handy this feature can be. You want
to know what a function will do with its arguments? Zap -- you are looking
at the function declaration. Done looking? Zap -- you are back where you
were. No time wasted. I never even print out source listings anymore.
--
Steve "I don't speak for Microsoft" Hastings ===^=== :::::
uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
From mrd@ecs.soton.ac.uk (Mark Dobie)
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 27 Nov 91 12:09:22 GMT
Sender: news@ecs.soton.ac.uk
Status: O
In <1991Nov26.162909.23029@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
>In <1991Nov26.135248.6911@cc.ic.ac.uk> cyber@sig.ee.ic.ac.uk (Nick Sales) writes:
>>There is also a ":pop" command, which, not unreasonably, pops you up one
>>tag, so returning you to your previous pre-push position.
>In this version of vi (the one that comes with SunOS 4.1.1, :version says
>Version SVR3.1) control-T is bound to :pop.
How could I miss this? Thanks very much. Forget ctrl-^ and use ctrl-T
instead... :-)
Mark.
--
Mark Dobie M.Dobie@uk.ac.soton.ecs (JANET)
University of Southampton M.Dobie@ecs.soton.ac.uk (The World)
From emcmanus@gr.osf.org (Eamonn McManus)
Subject: Fun with tags
Date: 29 Nov 91 16:17:05 GMT
Sender: news@osf.org (USENET News System)
Organization: Open Software Foundation Research Institute, Grenoble
Status: O
I originally posted this message a couple of months back, but have since
discovered that no messages were getting out from OSF at that time.
Since it contains interesting information, I am reposting it.
tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of mrd@ecs.soton.ac.uk (Mark Dobie):
>:Tags are one of vi's best features. They could be used for so much
>:more...
>
>We need a 'next-tag' function though. Sometimes there are multiple
>possibilities. This could happen because of having a taglength or
>tagprefix set, but it could also happen in the normal course of events --
>you might have ifdef's around something, etc.
>
>Does anyone have a patch to do this?
In fact with a bit of ingenuity it is possible to do multiple tag
searches without changing vi. One way is to have as many tags
files as there can be entries for a particular tag, and have the
lookup command change to a new tags-file, like this:
<File tags:>
a file1 set tags=tags1|/pattern for a/
b file1 set tags=tags1|/pattern for b/
c file1 /pattern for only occurrence of c/
...
<File tags1:>
a file2 set tags=tags|/pattern for second a/
b file2 set tags=tags2|/pattern for second b/
<File tags2:>
b file3 set tags=tags|/pattern for third b/
Then you map something like this:
" ^\ looks for first definition of following word
map ^\ :set tags=tags^M^]
" ^_ looks for next definition
map ^_ :tag
I imagine the ctags program is among those that have been freed by
Berkeley, so it should be fairly easy to modify it so it can do
this instead of complaining when there are multiple definitions.
It might be better for every tagsX file to have an entry for every
tag than only to have entries in the first N files when there are
N definitions; then you can always use :tag and have it do something
sensible.
Another interesting possibility is to use `command` as the filename
in a tags entry. Thus you would like to have entries like this:
a `lookuptag a` source where
The hypothetical lookuptag program can do arbitrarily complex
processing to determine where a is. It outputs the name of the
file, and puts a pattern or other ex command into the file "where".
There is a small problem with the above scheme, which is that vi
considers the file field in tags to end at the first space or tab;
hence in the above entry it will try to edit "`lookuptag". The
easiest way around this is to define SPACE=' ' in the environment
and use entries like `lookuptag${SPACE}a`. Bourne-ish shell users
can say `lookuptag${IFS}a` instead.
,
Eamonn
From specht.kd@sni-usa.com (Uwe Specht, D10 PU231)
Subject: Re: Vi and Tags file...(please help).
Date: 29 Nov 91 15:42:59 GMT
Sender: specht@usun01.UUCP
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
Status: O
you can create your own tags-file with the following syntax:
search_string "filename" ^/search_string .. .. /$
you call this file 'tags' and you can search for it with the
command
vi -t search_string
or when you are in a file you can search with the command
:tags search_string
I hope, that help you a little bit
--
MfG/Regards
Siemens Nixdorf Informationssysteme AG
/ / Specht Abt.: D10 PU2232
/ / ___ Heinz Nixdorf Ring
/ / \ /\ / /__/ W-4790 Paderborn, Germany
\__/ \/ \/ /____ NERV:specht.kd
---------------------------------------------------------------------
Email: specht.kd@sni-usa.com (America (North & South))
specht.kd@sni.de (Rest of world)
From stanj@hpnmdla.sr.hp.com (Stan Jaffe)
Subject: Re: VI search for begin/end of blocks
Date: 4 Nov 91 22:33:30 GMT
Organization: HP Network Measurements Div, Santa Rosa, CA
Status: O
In comp.editors, mrd@ecs.soton.ac.uk (Mark Dobie) writes:
>> I would suggest an approach based on the level of indentation.
Yes, that would be nice. However, the code typically isn't indented.
If it was, I wouldn't need this feature in the first place!
map ^T mx:%s/BEGIN/{@/g^M:%s/END/}@/g^M'x%mz:%s/}@/END/g^M:%s/{@/BEGIN/g^M'z
The macro above maps to cntrl-T, marks the present position, substitutes a
{@ for the BEGIN, a }@ for the END, goes back to the original position,
finds the matching curly-brace, marks that position, then substitutes back
the BEGIN and END, and finally returns to the marked matching position.
This works, but looks like the editor is doing the cha-cha (top to bottom to
etc).
Does anyone have a better way to do this???
Stan Jaffe stanj@sr.hp.com
From dattier@vpnet.chi.il.us (David W. Tamkin)
Subject: Re: how do I macroize c --> |c|
Keywords: vi, macros
Date: 14 Nov 91 22:58:35 GMT
Organization: VPNet Public Access Unix, Villa Park, Illinois 60181-2206
Status: O
rouben@math9.math.umbc.edu (Rouben Rostamian) wrote in
<1991Nov14.120529.13092@umbc3.umbc.edu>:
| In article <ki3ul7INNsfh@agate.berkeley.edu> casterln@are.Berkeley.EDU
| (Gary Casterline) writes:
| >I can't seem to get this to work.
| >:map 'p i|la|
|
| You need to escape the expansion of the | characters by preceeding
| them with ^V.
You need to escape the pipes by preceding each of them with a HARD ^V;
you'll have to type ^V twice before each pipe. Rouben did not make that
clear.
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@vpnet.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
"Parker Lewis Can't Lose" mailing list:
flamingo-request@esd.sgi.com (reflector) flamingo-request@mcs.com (digest)