I downloaded the DrawIt plugin to draw a diagram in vim. I successfully installed that plugin.
Then I found DrawIt.vba file in my home directory and opened the file. It had the following content:
" Vimball Archiver by Charles E. Campbell, Jr., Ph.D.
UseVimball
finish
+-- 67 lines: plugin/DrawItPlugin.vim--------------------------------------------
+--484 lines: plugin/cecutil.vim ------------------------------------------------
+--1662 lines: autoload/DrawIt.vim-----------------------------------------------
+--401 lines: doc/DrawIt.txt-----------------------------------------------------
In that file, I placed the cursor in the + (plus) and I pressed the right arrow key(->).
It opens the specified path (plugin/DrawItPlugin.vim) of the file.
I really wonder about that one.
I want to create something like this. I searched in NET, but I didn't get any proper way to do it.
Can you help me do this?
Actually, that is not what is happening.
"Vimball" files are archive type files that contain number of other files in them. When you "source" such file, Vim extracts these files into specified paths, for example the content under plugin/DrawItPlugin.vim will get extracted into a file with that name inside your $VIM directory.
What you actually describe is an example of folding. Vim can "fold" parts of a file, so that they are hidden, and replaced by just one line.
+-- 67 lines: plugin/DrawItPlugin.vim--------------------------------------------
means that there is 67 lines of hidden content, starting with the text plugin/DrawItPlugin.vim. When you navigate the cursor into this text, it gets unfolded.
Type :he folding in Vim to read the Vim help on folding.
You can "jump" to a file whose path is under cursor with gf (goto file). Type :he gf for details.
Finally, using the "VimWiki" plugin, you can create files that link to other files, in a Wiki fashion.
Related
I have indexed my c++ codebase with ctags, I can open a header file as follows:
:tag myfile.h
(It doesn't matter where myfile.h is located, as long as it is inside the indexed codebase it will open correctly in vim)
When I'm editing a c++ file, I can get the header filename as follows:
:e%<.h
e.g. when editing myfile.cpp, executing this command will display myfile.h on the command line.
A file can be opened in vertical split, by issuing:
:vs <myfile>
Now what I want to accomplish, is to have 1 command or function which I can use to open a header file of the corresponding c++ file that I'm currently editing in vertical split. Hence basically I want to combine the 3 above commands as if I would be doing a Unix pipe, e.g.:
:vs tag | e%<.h
" :vs to open file in vertical split
" :tag to find tag
" :e%<.h to get header filename
Obviously the Unix pipe doesn't work on vim, alternatively I've tried to write a function at which I assign the result of a command to a variable, e.g.
headerFileName = :e%<.h
Which apparently is not the correct way of doing this, I'm a bit lost here so I hope somebody can provide some help.
There exist several plugins that already do this (without needing a ctags database BTW).
For instance, with alternate (aka a.vim), you just have to type :VS from the header file or the source file to open the other one in a vertically split window.
Note that alternate have an option to tell where to find the other file (same directory, substitute on directory name, ...)
Otherwise, I suspect you are looking for expand() and :exe. If you write a function it may be
function! s:whatever() abort
let crt = expand('%:t:r')
vnew
exe 'tag '.crt.'.h'
endfunction
command! whatever call s:whatever()
I've created a help file under $VIM\vimfiles\doc. After nearly deleting it I wanted to edit it elsewhere and then copy it to the doc directory and then regenerate the tags.
The tags are generated , I can see them in the tagfile, but the file that I copy in, unique name, when I do :h sfcontents for eg and then ctrl-] on a tag I get the error "e426 tag not found"
If I edit the file in the $VIM\vimfiles\doc directory and then run either :Helptags or :helptags $VIM\vimfiles\doc the tag jump works
I can't attach a file but the help file looks something like
vim: filetype=help foldmethod=indent foldclose=all modifiable noreadonly
Table of Contents *sfcontents*
*sfsearch* - Search specific commands help
|count-matches-of-pattern|
|match-specific-column|
...
==============================================================================
count-matches-of-pattern
*count-matches-of-pattern*
:%s/pattern//gn
counts the number of the matches in a file eg count the number of spaces
not at the beginning of a line
:%s/[^ ]\+//gn
==============================================================================
*match-specific-column*
c=column l=line v=virtual column, ie ignore tabs and special chars
/\%5cx will match all occurrences of x at column 5.
/\%>5vx will match all occurrences of x after character 5. If there is a
tab character between poition 1 and position 5 the /\%5>v. against the
following line with a tab at position 4 will return the number 4
123 45
/\%>4cx\%<7cx will match all occurrences of x after column 4 and before
column 7
Or use |YankMatchesToReg| eg YankMatchesToReg /\%265v./x which copies
column 265 to register x across the whole file
==============================================================================
...
vim:tw=88:ts=4:ft=help:norl
I've ended up doing the archive out of the vim directory with the following;
nmap <leader>c :sp C:\Progra~2\vim\vimfiles\doc\commands.txt<cr>
nmap <leader>co :call BackupCommands()<cr>
function! BackupCommands()
exec "silent! !copy C:\\Progra~2\\Vim\\vimfiles\\doc\\commands.txt
C:\\Progra~2\\vimutils\\vimtips\\commands_back.txt"
exec "helptags C:\\Progra~2\\Vim\\vimfiles\\doc\\"
endfunction
I'd prefer to copy from the archive to the doc directory rather than the other way round. Any suggestions.
Straight from Vim's help files (:h write-local-help):
The first line is actually the only one for which the format matters. It will
be extracted from the help file to be put in the "LOCAL ADDITIONS:" section of
help.txt |local-additions|. The first "*" must be in the first column of the
first line. After adding your help file do ":help" and check that the entries
line up nicely.
Short: You're missing *sfsearch.txt* as first characters in your file!
Vim wont add to |local-additions|, therefore wont be searched, assuming your tags file was generated correctly. You can verify that by opening the tags file in the /doc directory and finding your tags there manually. There should be a tags file in each correctly helptagged /doc directory (:helptags <doc-dir>).
IMO, fear of "nearly deleting" a file is not a proper reason for editing in another location and copying back and forth. In fact, you've now introduced another risk of accidentally losing file contents via a wrong copy command.
Instead, use proper version control (Git, Mercurial, etc.), or, if that's too heavyweight, you can try my writebackup plugin, a pure Vimscript implementation. With the companion writebackupToAdjacentDir plugin, you can even backup to other directories.
That said, tag jumping should work even with your copy regime, provided that you run :helptags $VIM\vimfiles\doc after copying your help file to that exact location.
Is there a way to set a PATH-like sequence of directories to search for files in vim? My project has C files split across many directories, and it would be nice to jump back and forth without remembering the full path each time.
For instance, if I have:
platform/drivers/uart.c
ui/display/menu.c
cpu/registers/regs.h
I would like to be able to set PATH to "platform/drivers:ui/display:cpu/registers". Then when I want to switch to a file, I can just type:
:e uart.c
instead of
:e platform/drivers/uart.c
I understand that I can change the working directory, but then I have to type
:e ../../ui/display/menu.c
to get to another directory.
Alternatively, is there a better way to navigate a project like this than using :edit?
There is, and it's called path. The way you use path is with the :find command: :find menu.c would search for menu.c in the directories in path and edit it. There are other commands that use path, like :sfind that opens the found file in a new split. See the documentation of path for details and other commands that use it.
Another thing that may help you find your files is the **-wildcard that can expand to any directory path. For example :edit **/menu.c will look for menu.c in subdirectories, so you don't have remember and type the full path.
I just ran :help registers in Vim and noticed that # 'contains the name of the alternate file'.
I have seen an example for renaming files that goes like this:
" Save the current file, foo.txt, as bar.txt
:w bar.txt
" Start editing bar.txt
:e#
So apparently in that case, the file you just saved out is the "alternate file."
Can someone give me a more general definition for the "alternate file" and what else you might use it for?
The alternate file is the file that was last edited in the current window. Actually when you use some command to open a new buffer, if the buffer that was displayed had a filename associated with it, that filename is recorded as alternate file name.
See :help alternate-file.
Very useful for...
Pasting in the name of a file I've just been looking at into the current file.
You can use <C-R># for this in insert mode or "#p in normal mode.
Not that useful for...
Jumping back and forth between two files. It does the job very well, but this is just something I don't generally need to do.
Even in the example given, I'd probably use:saveas bar.txt instead.
An Example:
Say if you're doing a bit of C programming and want to call some function. You can't remember the name of the function, so you place a mark on your current location mA and jump into several different files using tags or grep to find out where the function is declared and what it's actually called.
Ah - found it. You can copy the name and return to the mark yiw'A
Uh-oh - we also need to #include the file! Easy - just use the alternate file name register to paste the file name in... Gi#include"<C-R>#"
Be pleased that you've avoided the distraction of having to go back to the function's declaration and copy out the file name via :let #"=#% or something similar.
What I'd rather do when jumping between files:
When editing two files, it's probably easier to split them, so you can keep both on screen at the same time. If I'm editing 2 files I'll usually be comparing them in some way.
Usually I'm interested in 1-3 files (any more and I get confused). I'll often jump into or directly open many other files. Marking the interesting files, or traversing the jump list is usually the way to get around in this case.
If you're editing C/C++ where you're switching between a file and it's header, use a plugin! It will be much more convenient.
I use it in the buffer context to return to the last buffer that I was editing
vim foo bar
:n
:e#
will take you back to foo in that case
I 've always interpreted the "alternate file" as being the "previous file", so it is an handy way to jump back to the buffer you were editing.
If :h is used in VIM, it will automaticall follow |links| via CTRL+], opening new help topics and maintaining tag jumps list (CTRL+T will go back in jumps history). How to implement such behavior in my own file format? For example, i want CTRL+] on text inside {} to open a file named something.txt and CTRL+T to go back. How to implement this?
It's all done with tags. Essentially the vim files are simple text files, but they're supported by a file in the same directory named 'tags'. All this file contains is entries that look like:
'bg' options.txt /*'bg'*
'bh' options.txt /*'bh'*
'bin' options.txt /*'bin'*
'binary' options.txt /*'binary'*
'biosk' options.txt /*'biosk'*
'bioskey' options.txt /*'bioskey'*
Each line is a tag entry, split over three fields: the tag identifier, the file the tag lives in, and the ex command to find that tag: any ex command works; as can be seen in the example above though, the vim help files just use the search command: '/'.
You can either write a tags file manually, or use a program such as Exuberent ctags to create the file automatically. The tags file is generally read from the same directory the file you're editing lives in, but you can change this in Vim by adjusting the value of the 'tags' option.
More details in vim if you type ":help tags"