variables are expanded too
			|expand-env|.

							*v_gf*
{Visual}[count]gf	Same as "gf", but the highlighted text is used as the
			name of the file to edit.  'isfname' is ignored.
			Leading blanks are skipped, otherwise all blanks and
			special characters are included in the file name.
			(For {Visual} see |Visual-mode|.)

							*gF*
[count]gF		Same as "gf", except if a number follows the file
			name, then the cursor is positioned on that line in
			the file.
			The file name and the number must be separated by a
			non-filename (see 'isfname') and non-numeric
			character. " line " is also recognized, like it is
			used in the output of `:verbose command UserCmd`
			White space between the filename, the separator and
			the number are ignored.
			Examples:
				eval.c:10 ~
				eval.c @ 20 ~
				eval.c (30) ~
				eval.c 40 ~

							*v_gF*
{Visual}[count]gF	Same as "v_gf".

These commands are used to start editing a single file.  This means that the
file is read into the buffer and the current file name is set.  The file that
is opened depends on the current directory, see |:cd|.

See |read-messages| for an explanation of the message that is given after the
file has been read.

You can use the ":e!" command if you messed up the buffer and want to start
all over again.  The ":e" command is only useful if you have changed the
current file name.

							*:filename* *{file}*
Besides the things mentioned here, more special items for where a filename is
expected are mentioned at |cmdline-special|.

Note for systems other than Unix: When using a command that accepts a single
file name (like ":edit file") spaces in the file name are allowed, but
trailing spaces are ignored.  This is useful on systems that regularly embed
spaces in file names (like MS-Windows).  Example: The command ":e   Long File
Name " will edit the file "Long File Name".  When using a command that accepts
more than one file name (like ":next file1 file2") embedded spaces must be
escaped with a backslash.

						*wildcard* *wildcards*
Wildcards in {file} are expanded, but as with file completion, 'wildignore'
and 'suffixes' apply.  Which wildcards are supported depends on the system.
These are the common ones:
	`?`	matches one character
	`*`	matches anything, including nothing
	`**`	matches anything, including nothing, recurses into directories
	[abc]	match 'a', 'b' or 'c'

To avoid the special meaning of the wildcards prepend a backslash.  However,
on MS-Windows the backslash is a path separator and "path\[abc]" is still seen
as a wildcard when "[" is in the 'isfname' option.  A simple way to avoid this
is to use "path\[[]abc]", this matches the file "path\[abc]".

					*starstar-wildcard*
Expanding "**" is possible on Unix, Win32, macOS and a few other systems (but
it may depend on your 'shell' setting on Unix and macOS. It's known to work
correctly for zsh; for bash this requires at least bash version >= 4.X).
This allows searching a directory tree.  This goes up to 100 directories deep.
Note there are some commands where this works slightly differently, see
|file-searching|.
Example: >
	:n **/*.txt
Finds files:
	aaa.txt ~
	subdir/bbb.txt ~
	a/b/c/d/ccc.txt ~
When non-wildcard characters are used right before or after "**" these are
only matched in the top directory.  They are not used for directories further
down in the tree. For example: >
	:n /usr/inc**/types.h
Finds files:
	/usr/include/types.h ~
	/usr/include/sys/types.h ~
	/usr/inc/old/types.h ~
Note that the path with "/sys" is included because it does not need to match
"/inc".  Thus it's like matching "/usr/inc*/*/*...", not
"/usr/inc*/inc*/inc*".

					*backtick-expansion* *`-expansion*
On Unix and a few other systems you can also use backticks for the file name
argument, for example: >
	:next `find . -name ver\\*.c -print`
	:view `ls -t *.patch  \| head -n1`
Vim will run the command in backticks using the 'shell' and use the standard
output as argument for the given Vim command (error messages from