*ios_commands.txt*	For Vim version 8.1.	Last change: 2019 Dec 14

				iVim REFERENCE MANUAL	by Terry Chou

						*ios-commands* *icommands*

This file describes the details of the ex commands added by iVim to support 
its features.

1. Font Management		|font-management-icommands|
2. Share			|share-icommands|
3. Exuberant Ctags		|ctags-icommand|
4. Open URL			|open-url-icommand|
5. Set Extended Keyboard	|set-extended-keyboard-icommands|
6. Old Documents		|old-documents-icommands|

==============================================================================
1. Font Management				*font-management-icommands*

iVim adds two commands to assist the font management |ios-font-management|.

:ifo[nt] [fnum|fname] [fsize]				*:ifo* *:ifont*
		Without arguments, it shows all available fonts. Example: 

			*1	s	SourceCodePro-Regular	14.0 ~
			2	s	Menlo-Regular ~
			3	u	LucidaConsole ~

		The first column shows the order number of each font. The 
		currently used font has a `*` prepended to its number. The
		second column is the type indicator of the font:
			s  system font
			u  user font

		The third column stands for the font name. Also, the current
		font will have an extra column indicating its size. After
		new fonts are imported or existing ones deleted, this list
		will change accordingly.

		To set the current font, give the font number or font name as
		the argument. Example: >
			:ifont 3		"set the font to LucidaConsole
			:ifont Menlo-Regular	"set the font to Menlo-Regular
			:ifont Sou		"set the font to
						"SourceCodePro-Regular
<		Prefix can be given as the font name, the first matched font
		will be set.
		After the font number or name, a number can be given to set
		the font size at the same time. Example: >
			:ifont 3 12		"set the font to LucidaConsole
						"and to size 12.0
<		If the font size is not an integer, its fractional part will 
		be cut.
		You can use `_` as the font name to indicate that you want to
		keep the current font. Example: >
			:ifont _ 12		"keep the current font and set
						"its size to 12.0
<
		Note: the font setting of |:ifont| is temporary, it will 
		change back to the default one at next app launch. To set the 
		font permanently, add `set guifont={fname}:h{fsize}` into 
		vimrc.

:idel[etefont] [fnum|fname]				*:idel* *:ideletefont*
		Like |:ifont|, it shows all available fonts when no arguments
		are following.

		To delete a font, indicate the font number or font name as the
		target. Example: >
			:idel 3			"delete font LucidaConsole
			:idel Luc		"delete font LucidaConsole
<		If the current font is deleted, the first system font will be
		used.

		Note that only user fonts can be deleted.


==============================================================================
2. Share						*share-icommands*

iVim has two commands for sharing |ios-share|.

:[range]ish[are] [fname]				*:ish* *:ishare*
		Share files or text with other apps via the share extension.
		
		When [range] is given, text of lines in it of current buffer
		will be shared. Example: >
			:3,8ishare		"share text of line 3 thro 8
<
		Otherwise, the file represented by [fname] will be shared: >
			:ishare todo		"share file `todo` under 
						"current directory
			:ishare			"share file of current window 
<
		Note: only one file can be shared at a time.

:idoc[uments] [mode]				    *:idoc* *:idocuments*
		Pick documents from iCloud Drive or other document provider
		apps via the document picker.

		When the mode is `open` or omitted, the picked document will
		be edited in place, meaning that the modifications will be
		saved back to the original document directly. Example: >
			:idoc			"open the document picker
						"and edit the picked file
						"in place
<		
                Directories can also be opened in `open` mode. Before iOS 13,
                this needs explicit support from the document provider app.
                Since iOS 13, this becomes system-wide. However, it needs to
                be done in the separate UI opened with mode `dir`: >
                        :idoc dir               "open the document picker
                                                "specific for picking dirs
<
                iVim also provides a trash bin for each opened directory, so
                that the user has the chance to restore an item deleted by
                accident. See |:idocuments-trash|. Also note that the trash
                bin will be cleaned up after its associated directory is 
                closed.

                If the mode is `import`, the picked document will be copied
		into iVim's `Documents` directory and opened for further
		editing. 

		Note: the imported file will be renamed if there has been 
		a file already possesses that name.

:idoc[uments] trash[!] [indexes]                    *:idocuments-trash*
                Manage or restore deleted items in the trash bin of an opened
                directory.

                Without the bang, iVim lists items in the trash bin, Example:

                        1   10/27/19, 2:36:20 PM    test/ddd ~
                        2   10/26/19, 4:23:15 PM    test/aaa ~

                Each line represents an item. The first column is the index 
                of the item. The second is the date of the trashing. The last
                column is the path of the item when it was deleted, starting
                from the root opened directory (`test` here). Items are listed
                in the order of trashing date, the first one is the latest.
                When [indexes] are given, only items with those indexes are
                listed: >
                        :idoc trash 2 3         "only list items 2 and 3
<
                If any of the given indexes is invalid, iVim complains with
                an error.

                To restore items, run this command with the bang: >
                        :idoc trash! 5 3 1      "restore items 5, 3 and 1
<
                At least one index needs to be given to indicate the target
                item. Items are restored one by one in the given order. If an
                item already exists at the target path, the restoration fails
                for that item. However, the restoration attempt still goes on 
                for the rest items.

                Note that iVim complains if the current buffer does not belong 
                to an opened external directory.


==============================================================================
3. Exuberant Ctags					*ctags-icommand*

iVim offers one command to use the integrated Exuberant Ctags
|ios-exuberant-ctags|.

:ic[tags] {options} [fname]				*:ic* *:ictags*
		Run the integrated Exuberant Ctags like the shell command.
		
		Examples: >
			:ictags --help		"show help info of ctags
			:ictags -R .		"generate tags recusively
						"for files under current
						"working directory
<
		Also, it supports vim |wildcards| in file or directory names.
		Example: >
			:ictags *.c *.h		"generate tags for all .c and
						".h files under current dir
<
		Note: option 'fileignorecase' is on by default, it will ignore
		case in file names when expanding them.

		After the tags are generated, you can browse the codebase 
		easily by |tags| navigation commands.

		Note: big projects may take some time to finish.


==============================================================================
4. Open URL						*open-url-icommand*

iVim adds one command to support the URL scheme opening |ios-open-url|.

:io[penurl] {url}					*:io* *:iopenurl*
		Open the {url} to invoke the iOS URL scheme workflow.

		Example: >
			:io https://www.example.com/search?q={@*%[Q}
<
		It will launch Safari and open the site "www.example.com" and
		do a search with the contents in the clipboard as the query.
		
		Note that it opens only one URL at a time.

Variable token ~

You need to use variable tokens to include useful info into an URL. The format
for a variable token is "{expr%[encode}". 

a. the "{" and "}" are the opening and closing delimiter respectively. 

As a result, they need to be backslash-escaped if you want to use them 
literally in the URL. Note that nested token is not supported.

b. the "expr" is a vim |expression| which will be replaced with its value when 
the whole URL is opened.

This expression will be evaluated by vim and errors will be given if it is
invalid. Note a) only expressions with value type "string" and "number" are
supported. b) tokens are evaluated one by one from left to right.

c. the "%[" is the indicator for a following URL encoding type.

d. the "encode" is the URL encoding type which is explained in details below.

Backslash escape ~

Sometimes you need to put certain characters literally into an URL. You can 
put a backslash character before each to achieve this. For example, "\{expr\}"
will be treated literally instead of a variable token.

Because of its special meaning, a literal backslash always needs to be 
backslash escaped, e.g. "\\".

URL encoding ~

Certain characters in an URL need to be percent encoded for a successful
opening. Moreover, in different parts of an URL, the characters that need 
encoding differ. iVim provides an URL encoding type to help with this.

A typical URL skeleton is 
>
	scheme://user:password@host:port/path?query#fragment
<
The following encoding types are available:

	U:	indicates encoding for "user" part
	PW:	"password" part
	H:	"host" part
	PT:	"path" part
	Q:	"query" part, it is the default
	F:	"fragment" part

For example, if you will include a variable token into the "host" part, you
need to indicate it as "{expr%[H}". Then iVim will encode its value for the
specific part automatically. Omitting the encoding part, e.g. "{expr}", will 
encode it for the default "query" part. Note that they are case insensitive.
e.g. "%[Q" and "%[q" mean the same encoding.

Debug errors ~

iVim provides some debug errors when you try to open an URL but it has some
problems.

"token open character { expected":
	a closing delimiter is encountered before an opening one.
"token close character } expected": 
	one opening delimiter is expecting a closing one but none given.
"nested token not allowed":
	you are trying to put a variable token inside another one.
"unfinished character escaping":
	there is a backslash at the end of the URL.
"invalid path: ...":
	the URL is invalid
"failed to open URL: ...":
       	the system failed to open the given URL.
	
If the position of the problem can be located in the URL, it will be 
highlighted as ">...<".


==============================================================================
5. Set Extended Keyboard		*set-extended-keyboard-icommand*

iVim offers one command for customizing the extended keyboard.

:iset[ekbd][!] [operation] [configuration]		*:iset*	*:isetekbd*
		Set the extended keyboard according to the given [operation]
		or [configuration].

		If [!] presents, it won't record the editing into the history
		in `compose` mode |isetekbd-mode-compose|.
		
		"isetekbd" means "iset extended keyboard".

Concepts ~

The extended keyboard consists of compact buttons, each of which, in turn, 
contains some keys. By editing its default buttons or keys, you can customize
the extended keyboard to meet your own needs.

The editings such as `remove`, `append` or `insert` are called operations. 
According to the arguments obtained from the configuration, they change the 
buttons or keys. The format of the configuration is given below.

Configuration format ~				*isetekbd-config-format*

The configuration is written in vim's |dict|, |list| or their mixing. For 
example: >

	:isetekbd {'operation':'remove', 'locations':[0]}
<
this command will remove the button at location 0. The configuration is given
as a vim |dict|, and its property `locations` is a vim |list|.

						*isetekbd-operation-node*
This kind of dict in the above example is called a node. It contains necessary
properties to fulfill the operation. More specifically, the above dict is an
operation node, which may have the following properties:

a. operation

it gives the name of the operation. An error will emerge if it is not one of
the available operations |isetekbd-operations|. A special characteristic of 
this property is that you can use it as a subcommand of command |:isetekbd|
therefore put it outside of the dict: >

	:isetekbd remove {'locations':[0]}
<
this command is the same as the last one. The operation `remove` becomes the
[operation] part in the command's usage. When an operation is given as a
subcommand like this, it will be added to its following configuration as the 
`operation` property: one if the configuration is a single node (a dict); or 
one for each if an node group (a list of nodes). 

Note this property is mandatory.

b. locations

it means locations of buttons for this operation. As in the above example, it
is an integer list and zero-based (button location starts at zero). An error
appears if any location is outside of the legal range.

c. buttons

it is a list of button nodes (|isetekbd-button-node|) providing information on 
the button level for the operation. For example: >

	:isetekbd remove {'locations':[0], 'buttons':[{'locations':[1]}]}
<
this will remove the second key on the first button. In order to remove keys 
on a specific button, their locations need to be given in the button node.

d. arguments

it contains information for operations that require plain arguments. Such as
config file paths for `source` operation (|isetekbd-op-source|).

Except for `operation`, which property is necessary depends on the specific 
operation. Each operation will try and seek the properties it needs, and 
ignore the rest.

						*isetekbd-button-node*
A button node provides the button level information for an operation. It may 
have the following properties:

a. locations

it is an integer list indicating the locations of keys on this button. Like
button locations, it is zero-based and an error shows if any location is 
outside of the legal range.

b. keys

it is a list of key nodes (|isetekbd-key-node|).

						*isetekbd-key-node*
A key node contains information for making a new key. It has the following 
properties:

a. title

it is the text shown as the key on a button.

b. type

it is the name of the key type. Together with property `contents`, it decides
the function of the key. There are several key types for different scenarios:

1) command

it means that this key invokes an ex command in `contents`: >

	{'title':'Fs', 'type':'command', 'contents':'isetekbd source funcs'}
<
this runs command ":isetekbd source funcs", therefore changes the extended
keyboard according to the configuration file named "funcs", when this key is 
triggered.

2) insert

it means that this key inserts the characters in `contents`: >

	{'title':'A', 'type':'insert', 'contents':'A'}
<
this inserts the uppercase 'A' whenever the key is triggered.

3) modifier

it means that this key is a modifier key indicated in `contents`: >

	{'title':'D', 'type':'modifier', 'contents':'command'}
<
this makes the key the Command key |<D-|.

The following modifier keys are supported:	*isetekbd-modifier-keys*
	
	alt:		the alt key |<A-|
	command:	the Command key |<D-|
	control:	the control key |<C-|
	meta:		the meta key |<M-|
	shift:		the shift key |<S-|

If the key name is not found among the above, it shows an error.

Note that a modifier key will be sticky like the default `ctrl` key. And a
modifier key will lose its state after the extended keyboard is updated.

4) special

for iVim to work properly, some keys need to be handled in a special way. You
can make a special key by indicating it in `contents`: >

	{'title':'esc', 'type':'special', 'contents':'esc'}
<
this makes the key be the `esc` key. Note that this is different from simply 
running command ":call feedkeys('\<Esc>')" because iVim does extra things when
`esc` is pressed.

The following special keys are available:	*isetekbd-special-keys*

	esc:		the esc key
	up:		the arrow Up
	down:		the arrow Down
	left:		the arrow Left
	right:		the arrow Right
	tab:		the tab key

If the key name is not one of the above, it shows an error.

Note that it is an error if the key type is not one of the above.

c. contents

it provides the contents for a specific key type, as shown above.
 
Editing modes ~					*isetekbd-modes*

There are several different situations in which the editing behavior differs:

a. compose					*isetekbd-mode-compose*

when a |:isetekbd| command is ran directly from the ex command line, it is
in the compose mode. In this mode, each editing will be recorded into the
editing history unless the [!] presents. As a result, you can edit the 
editing by manipulating the history: you can give up the last editing with 
the `undo` operation; resume it with `redo`; save the editings in the history
into a config file for future use when you are content with the result, with 
`export`.

The result of each editing (i.e. each |:isetekbd| command) will be reflected
on the extended keyboard immediately.

b. vim source					*isetekbd-mode-vimsource*

if a |:isetekbd| command is from a file being sourced by vim, e.g. in the 
.vimrc file, it is in the vimsource mode. In this case, the editing will not 
be recorded into the editing history. However, the result of each editing 
will be applied immediately.

c. source					*isetekbd-mode-source*

editing items could also be saved into a config file that could be applied
by the `source` operation later. It is in the `source` mode during a `source`
operation. None of editing items in the config file will be recorded into the
editing history. Also for the sake of efficiency, the changes will not be 
applied to the extended keyboard until the end of the outmost `source`
operation.

iVim will change into the related mode automatically when the situation comes.

Operations ~					*isetekbd-operations*

The command |:isetekbd| fulfills its function through different operations.
The available operations and their details are listed as following:

a. remove					*isetekbd-op-remove*

it removes buttons or keys on specific buttons. 

For the locations of target buttons, it seeks the `locations` property of the 
operation node. For example: >

	:isetekbd remove {'locations':[3,7]}
<
this command removes buttons at locations 3 and 7.

If the property `buttons` also presents, it tries and associates button
locations with the button nodes in it one by one and orderly. If a button 
location finds its associated node and a non-empty `locations` property in the
node also presents, this button will be treated as a key-removing button and
the related keys will be removed from it. For example: >

	:isetekbd remove {'locations':[5,2],
			 \'buttons':[{'locations':[3]}]}
<
this removes key 3 on button 5, and then removes button 2. In this example, 
button 5 finds a associated node in the buttons list and is considered as a 
key-removing button. On the other hand, button 2 fails to associate any node 
therefore is removed as a whole button.

b. append					*isetekbd-op-append*

it appends new buttons to the end of the extended keyboard bar, or new keys
to the end of a specific button.

For the new buttons, it seeks the property `buttons`. Example: >

	:isetekbd append {'buttons':[
				    \{'keys':[
					     \{'title':'C',
					     \ 'type':'modifier',
					     \ 'contents':'control'}
					     \]},
				    \{'keys':[
					     \{'title':'D',
					     \ 'type':'modifier',
					     \ 'contents':'command'}
					     \]}
				    \]}
<
this appends two new buttons, the first with a modifier `control` key and the 
second a modifier `command`, to the end of the current extended keyboard.

If the property `locations` also presents in the operation node, it tries and 
associates the button nodes in `buttons` with locations in `locations` one by
one and orderly. Any associated button node will be key-appending, meaning
new keys generated from its property `keys` will be appended to the end of
the button. Example: >

	:isetekbd append {'buttons':[
				    \{'keys':[
					     \{'title':'C',
					     \ 'type':'modifier',
					     \ 'contents':'control'}
					     \]},
				    \{'keys':[
					     \{'title':'D',
					     \ 'type':'modifier',
					     \ 'contents':'command'}
					     \]}
				    \],
			 \'locations':[3]}
<
because of the presence of `locations`, this command appends a new modifier 
`control` key to the end of button 3, and a new button with a modifier 
`command` to the end of the extended keyboard.

Note that iVim will hide buttons or keys if they exceed their respective
visual limits (enough space on extended keyboard bar for buttons; 5 for keys).

c. insert					*isetekbd-op-insert*

it inserts new buttons or new keys to a specific button.

For the new buttons, it seeks the property `buttons`. For the target locations 
of them, it seeks `locations` of the operation node. Example: >

	:isetekbd insert {'buttons':[
				    \{'keys':[
					     \{'title':'C',
					     \ 'type':'modifier',
					     \ 'contents':'control'}
					     \]},
				    \{'keys':[
					     \{'title':'D',
					     \ 'type':'modifier',
					     \ 'contents':'command'}
					     \]}
				    \],
			 \'locations':[3,5]}
<
this inserts a button with a modifier `control` key to location 3, and a 
button with a modifier `command` to 5. Note that the insertion is processed in
the order of the locations, so later locations should take the results of the
earlier ones into account. e.g. the location 5 in the above example is the new 
location 5 after the insertion at location 3.

The locations are respected more, which means the size of button nodes for new 
buttons should be enough for locations, it is an error otherwise.

If a button node also has a non-empty `locations` property, it means the new
keys in the property `keys` will be inserted to this button. Example: >

	:isetekbd insert {'buttons':[
				    \{'keys':[
					     \{'title':'C',
					     \ 'type':'modifier',
					     \ 'contents':'control'}
					     \]},
				    \{'keys':[
					     \{'title':'D',
					     \ 'type':'modifier',
					     \ 'contents':'command'}
					     \],
				     \'locations':[2]}
				    \],
			 \'locations':[3,5]}
<
while this still inserts a new button generated by the first button node to 
location 3 like the last example did, it inserts a new `command` key at
location 2 on button 5 rather than inserting a new button at location 5, 
because the second button node has its `locations` property present.

Likewise, the key-insertion locations should also take the order significantly.
And the key nodes should always be enough for the target locations.

d. replace					*isetekbd-op-replace*

it replaces buttons or keys on a specific button with new ones.

It seeks the property `locations` for the locations of the buttons to be 
replaced. For the new buttons, it seeks `buttons`. Example: >

	:isetekbd replace {'buttons':[
				     \{'keys':[
					      \{'title':'C',
					      \ 'type':'modifier',
					      \ 'contents':'control'}
					      \]},
				     \{'keys':[
					      \{'title':'D',
					      \ 'type':'modifier',
					      \ 'contents':'command'}
					      \]}
				     \],
			  \'locations':[3,5]}
<
this replaces button 3 with a new one generated by the first button node, and
button 5 with one by the second.

Like operation `insert`, the size of button nodes should be enough for that of
the target locations. Or it is an error.

If a button node has its own `locations`, instead of replacing this button, it 
will replace the keys located by this property on this button, with new ones 
generated by its property `keys`. Example: >

	:isetekbd replace {'buttons':[
				     \{'keys':[
					      \{'title':'C',
					      \ 'type':'modifier',
					      \ 'contents':'control'}
					      \]},
				     \{'keys':[
					      \{'title':'D',
					      \ 'type':'modifier',
					      \ 'contents':'command'}
					      \],
				      \'locations':[2]}
				     \],
			  \'locations':[3,5]}
<
thanks to the property `locations` in the second button node, this replaces 
key 2 on button 5, rather than replacing button 5 altogether like the last
example did.

Also, the size of key nodes should be enough for the target locations for key
replacing.

e. clear					*isetekbd-op-clear*

it removes all existing buttons from the extended keyboard.

It requires no other properties. Example: >

	:isetekbd clear
<

f. default					*isetekbd-op-default*

it makes the extended keyboard revert to its default state.

It requires no other properties. Example: >

	:isetekbd default
<

g. source					*isetekbd-op-source*

it reads configuration files and applies them to the extended keyboard.

The trailing part of a |:isetekbd| invoking (the part without the command 
name, e.g. "remove {'locations':[3]}") is called an editing item. A config
file is comprised of editing items, one on each line.

The `source` operation reads the config file line by line and processes them
in order. As mentioned above, it is in the `source` mode while a config file 
is being sourced. Therefore, changes brought by each editing item won't be 
applied until the outmost (it could be recursive) sourcing is done.

It accepts multiple config files at once, and will process them in order: >

	:isetekbd source cfile1 cfile2 cfile3 ...
<

In a config file, all whitespaces at the beginning of each line will be
ignored. And a line will be treated as a comment if it begins with a double 
quote '"', for example: >

	"this is a comment
	remove {'locations':[3]}
<
and a line will be the continuation of its last line if it begins with a
backslash '\', and they will be treated as one line altogether, example: >

	replace {
		\'locations":[2],
		\'buttons':[
			\{'keys':[
				\{'title':'C',
				\ 'type':'modifier',
				\ 'contents':'control'}]}]
		\}
<

Note that any error during a `source` operation will stop the whole operation
and revert to the state before it.

The 7 operations above are ones that modify buttons or keys on the extended 
keyboard.

h. compose					*isetekbd-op-compose*

it resets the compose mode.

In the `compose` mode, this operation clears the existing editing history and 
sets the current state as the initial history entry. As a result, it makes a 
clean environment for its following composition. Example: >

	:isetekbd compose
<
Since it doesn't makes sense otherwise, it can only be called in `compose`
mode as a single operation (cannot be a member of a operation group): >

	:isetekbd [
		  \{'operation':'compose'},
		  \{'operation':'remove',...}
		 \]
<
the above example will show an error because the `compose` operation becomes a
member of an operation group.

i. undo						*isetekbd-op-undo*

it goes back to the previous state in the editing history.

It requires no further arguments, example: >

	:isetekbd undo
<
An error shows if there is no previous entry in the history.

Like operation `compose`, it is only allowed in `compose` mode as a single
operation. It is an error otherwise.

j. redo						*isetekbd-op-redo*

it goes to the next state in the editing history.

It requires no further arguments, example: >

	:isetekbd redo
<
An error shows if there is no more entry in the history.

Likewise, it is only allowed in `compose` mode as a single operation.

k. export					*isetekbd-op-export*

it writes current items in the editing history to configuration files.

The items in the editing history are those that have been making the extended
keyboard to its current state since the beginning of the related `compose` 
mode. Therefore, the outcome of the `export` operation is config files that 
can be re-applied by the `source` operation in the future.

It accepts multiple files at once, and writes the contents to each of them: >

	:isetekbd export cfile1 cfile2 ...
<
You can peek the contents by invoking it without any target files: >

	:isetekbd export
<
this prints the contents in the ex command line window.

It is only allowed as a single operation in `compose` mode.

The 4 operations above are helper ones to assist editing in `compose` mode.


==============================================================================
6. Old Documents				*old-documents-icommands*

iVim provides one command to manage the old documents |ivim-old-documents|

:iold[docs][!] [pattern|I1 I2 ...]		*:iold* *:iolddocs*
		Manage the old documents.

		Without any argument, it lists all the old documents: >

			1: /private/var/...
			2: /private/var/...
			3: /private/var/...
			...
<
		The first column is the index of the document; the second its
		original path. Note that the upper limit of saved entries is 
		100, the oldest and excessive ones will yield places for the 
		new ones.

		You can open the old documents by their indexes [I1 I2 ...]: >
			:iolddocs 4 2 8		"it opens documents 4, 2 and 8
<
		the documents will be opened in the given order. When a doc
		is already opened, iVim will jump to its containing window
		rather than open it again. Any invalid index will be reported
		as an error. Note that especially, if the first index is not
		valid, the arguments will be tried as [pattern] instead.

		If [!] presents, rather than opening the indexed docs, their
		records will be removed from the list permanently.

		Besides using the indexes to indicate the documents, you can
		also use [pattern] to filter them: >
			:iolddocs /test/	"it opens the first doc that
						"contains 'test' in path
<
		[pattern] is a vim search pattern. Any non-ID character (see
		|'isident'|), besides "/", can be used to enclose the pattern,
		as long as it does not in [pattern]. A pattern without a 
		enclosing character also works (its end is decided by a space)
		The [pattern] is matched against the document original path.
		Note that the last search pattern is used when [pattern] is
		empty.

		Also, the presence of [!] will change the operation from open
		the documents to remove related records: >
			:iolddocs! /test/	"it removes the first record
						"that contains 'test' in path
<
		There are several flags that could change the [pattern]'s
		behavior if present:

		g: "global". Rather than only the first one, all the matched 
		documents will be the targets: >
			:iolddocs /test/g	"it opens all docs whose path
						"contains 'test'
<
		p: "print". It prints the matched entries rather than doing
		opening or removing: >
			:iolddocs /test/p	"it prints the first entry 
						"whose path contains 'test'
<
		i: "ignore case". The pattern match will ignore the cases of
		letters: >
			:iolddocs /test/i	"the pattern will match 'test'
						"'TEST', or 'Test'
<
		n: "negate". The entries NOT matched will be the targets: >
			:iolddocs /test/n	"it opens the first doc whose 
						"path does not contain 'test'
<
		Flags can be mixed together to indicate more complicated 
		behaviors: >
			:iolddocs /test/gp	"it prints all entries whose
						"path contains 'test'
			:iolddocs /test/ng	"it opens all docs whose
						"path does not contain 'test'
<
		Note that any repetitive or invalid flag, or spaces in between 
		will be ignored.

		To provide flags to patterns without enclosing characters, use
		a space to separate them: >
			:iolddocs test gp
			:iolddocs test g p
<


 vim:tw=78:ts=8:noet:ft=help:norl:
