We have application which is written in Python in linux enviromet which is legacy code.I have task to document which help other in wiki page. I thought, Can I add one file into Existing code. So I can add documentation into another File. So if user open file it will pop us with code detail. if user does not want to see that file they can close this File. for Example
sample.py ( A File which contain code)
demo.txt ( which contain documentation file)
So if I open sample.py using vi like vi sample.py than demo.txt open by default like pop us or simple way which contain documentation part. I think it is like windows tool when we open tool it pop us infront of user. it is my idea I am not sure really it is valid or not. I have searched but could not find any useful information.
What you want to do will most likely confuse the user. If one types vi sample.py one expects to read this file. Now what you can do as #HAL said in his comment is add a comment in your code saying that the documentation for this code is in the demo.txt accessible at /path/to/demo.txt.
I think this is the common way to do it, and you will probably frustrate the user if you don't do it this way. (at least I would be ;) )
I am not aware of any Linux specific include functionality and I do not think that it exists, because the program you are executing is vi and not the Linux kernel. But editors support editor specific functions for hyper links. Here is an example for vim. vim: Add clickable label
Another way would be to replace vi with a shell script which does what you want. This is an example:
#! /bin/bash
if [ "$1" = "sample.py" ] ; then
vim demo.txt "$1"
fi
This will open the documentation together with the program in two vim buffers.
Related
I am trying to write my first vim script, so I apologize if this question boils down to not understanding the basics.
The main goal is that I want to call out to an external command from inside vim and read the results back into the file.
I know how to do this with simple shell commands, e.g. r !ls. However the command I want to interact with is "interactive".
I don't know if this is a meaningful description. But calling this command in the shell opens a TUI, then after interacting with the TUI the command will exit and put things into standard output. I want to read that standard output back into vim.
Possibly it will help to discuss the specific command, which is papis a cli citation manager. If you call, e.g. papis list --format '{doc[title]} {doc[author]}' in the shell it will open up a TUI that allows me to filter down and select a document. After selecting the document it will put the title and author into the standard output. This is what I want to read into vim.
However, my first few attempts have not been successful. Trying the naive :r !papis list results in an error, even though that command is valid in the shell and would result in the TUI being opened. So I'm obviously missing something.
Can anyone recommend a guide or suggest a possible solution for correctly calling out to TUI-based external commands and reading back their standard output?
Is there a semi-universal mechanism by which to reveal files as selected in various *nix window managers via the command line? For example, in Windows I can say the following:
explorer.exe /select,C:\TestDir\TestFile.txt
…and Explorer will reveal the file and select it for you. In OS X I can say the following:
osascript -e 'Tell application "Finder" to reveal "MacHD:Users:myaccount:Desktop:filename.txt"'
…and it will do the same. My question is, is there any way to do the exact same thing (somewhat universally) in any of the various popular *nix flavors across window managers? Obviously "Open Containing Folder" is simple enough, but I want to go the extra step of actually opening it with the specific file selected. Any assistance is appreciated.
Best.
I don't about other file managers (other answers can add that) but for nautilus it's been recently fixed
This allows to call nautilus
uri:///path/to/file from the command
line to open uri:///path/to with file
pre-selected.
For OSX AppleScript works for all versions, but if you know you'll be dealing with 10.6 or later you'd be better served by using the -R option for "open". It's around 30 times faster.
open -R "/Volumes/Users/Desktop/file-to-open.txt"
For Linux Nautilus allows for direct calling of the file, a generic solution for GNOME (you won't find one for "Linux") is the "gnome-open" command, which currently could open the directory but won't highlight the file:
"gnome-open /tmp/file.txt"
First off, I was about to write a long list of if/else statements in vim and realized that 1) there was a better way to do what I was trying to do and 2) SO would be ripe with help on the subject. So! I have a variety of files spread about like
foo/src/file01.C
foo/src/file02.cc
foo/src/file03.c
foo/include/file01.hh
foo/include/file02.h
foo/include/file03.h
If you notice that the C/H, cc/hh, c/h extension may or may not match then you are keen and I'd like you to please help. I've look at things like the following vim scripts from the Vim wiki for "Easily switch between source and header file" and although I only dumped a few hours into a.vim without success, it doesn't seem that the others would work via the docs on that page. So can anyone help out on how to make this work?
A good lead I had was a quick How to Easily Switch between Header and Source topic, but still couldn't make it work.
I guess what I really want is how to avoid the multiple if statements and use real matching to do what I want. I want to look into another directory and if look for a header file of the same name with any familiar extension if it was a source C/C++ file, or look for a source file of any regular extension if it was a header file. Thanks for your help!
UPDATE: I specifically want to open the file in a new tab. I live on vim tabs!
I recommend using the FSwitch plugin. https://github.com/derekwyatt/vim-fswitch
This does exactly what you need out of the box. It is better than a.vim in more than one way, being a rewrite of the idea behind a.vim.
The link you posted presents it as a solution, too.
I have just installed it to my vim configuration and it does its job well.
Enjoy.
Just to make sure I was using the most current version, I downloaded the latest a.vim script (2.18) and copied it into my ~/.vim/plugin directory.
You can define certain variables in your ~/.vimrc file to get a.vim to recognize alternate file extensions.
To get the files in your example to match their alternates I added the following to my ~/.vimrc:
let g:alternateExtensions_C = "H,hh"
let g:alternateExtensions_hh = "C"
These are global variables that allow you to override what's already defined. You'll have to define
both relationships (they don't work both ways).
You can see what the current mappings are by typing:
:echo g:alternateExtensionsDict
If you need to define other mappings, follow the same pattern. What comes after the underscore is the file extension you're editing. What's in the double quotes is a comma-separated list of alternate extensions.
let g:alternateExtensions_<ext> = "<list,of,alt,ext>"
If you have a different directory structure, you can define what paths to search by overriding the g:alternateSearchPath variable. ../src and ../include are already included by default.
:echo g:alternateSearchPath
To open the alternate file in a new tab:
:AT
By the way, the a.vim script is pretty well documented. You might want to open it up and take a look. I found a setting or two that I didn't know about and I've been using it for years ;o)
I hope that helps.
IMO your best option is to adopt existing scripts to use :tabf instead of :e or whatever the scripts use right now to open the counterpart file. You can also try to make the change configurable and submit it to the script author. (I'm pretty sure many would find the enhancement useful.)
That reminded me of a trick I used very long time ago. Instead of guessing where the corresponding source/header files are, I have used at the top of file special comment containing relative path to the counterpart file. Switching was as simple as finding the special comment, extracting file name and opening it. Problem was similar to yours in that file extensions were not predictable. My rational solution was to stop guessing and denote counterparts explicitly in the source code. (This days I would have probably tried to put the relationship table into an external file with a standard name and look it up in VIM using the upward search.)
Two helpful things
:he 'path'
:he tabfind
So you would do
:set path=../,/usr/include/,/home/buildagent/SDKROOT/mysdk/inc
:tabfind error_codes.h
to open error_codes.h from somewhere exotic without having to specify it. Note how vim globbing is very very flexible, so you might not need mucht
:argadd ./**/*.[h,H] | tab sall
will open all header files under the current directory, regardless of how many levels deep. Be careful running this command on a large tree or with symlinks outside the tree
I have some directories with a number of "hidden" files. One example of this is I'm in a source controlled sandbox and some of the files have not been checked out yet.
When I hit TAB, I'd like the option of seeing these files.
A similar question has been asked before: CVS Tab completion for modules under linux
The answers to that question summarize to: "Ubuntu's got that built in".
I don't have the option of switching to Ubuntu, but surely I can use the same mechanisms.
how can I hook into the TAB-completion feature of tcsh to add additional file Support for CVS, SVN and BitKeeper would all be useful.
More important than support for a specific source control system is the ability to control the returned list myself.
An acceptable solution would also be to use a key-binding other than TAB. (ctrl- perhaps)
From the manpage:
the complete builtin command can be used to tell the shell how to complete words other than filenames, commands and variables
might get you started
I do not know how to program in tcsh. But if you can, then you could look at the file named "bash_completion" from the archive (find the download link here.)
On line 1673 begins CVS completion code - and this might be portable to csh if you are familiar with the differences between bash/tcsh.
On my ubuntu machine, there is also a section for SVN completion (in /etc/bash_completion) that doesn't seem to be present in the maintainer's archive.
That's not Ubuntu-specific behavior, it's the bash-completion project.
You could use that, if you can switch from tcsh to bash.
On Gnome/KDE you can select in which application you want to open file (Right click on file -> Open With -> Other). Is it possible open file that way, but from console?
For example: you print " file.ext" and instead of opening in concrete application, there are that application selection window forced and then users chooses - starts selected program.
I tried to figure out that myself, but not found anything like that.
"edit file.ext" doesn't fits my needs, because it starts preferred application and you cannot choose which. And also on my desktop it says:
"Error: no "edit" mailcap rules found for type "image/jpeg"
So, am I able to forse that "open with" window from console? If yes, can you say how?
Both on windows and mac you can do such things.
//edit at 2009-02-10 14:17
Thank you very much for answers. Command will be used in program code, so unfortunately probably I would not be able to make some extra bash scripts.
For GNOME:
gnome-open <file>
For KDE:
kfmclient exec <file>
These commands should open up the <file> in the preferred application in GNOME or KDE respectively, although I don't have an installation of either to test on.
Take a look at man run-mailcap, you can change or add selected applications for each mimetype modifying the /etc/mailcap, ~/.mailcap files and some others.
Traditionally, on Unix systens (and therefore Linux, too), you start applications from the console (and not from a UI). The command line (or console) expects you to enter the name of the application and then the filename (plus some options).
This allows to use applications (or commands) in shell scripts.
On Windows, there is no real console (the DOS box is just a reminiscence of the dark ages of MS DOS). So the MS developers came up with the idea to have the OS treat anything as a command. If it's not a real command or application, the OS will determine the file type (by extension on Windows and by some header information on Mac). For each file type, there will be an associated application in a look up table.
This is why on Windows, it appears that you can enter the name of a file on the console and you will get the application to edit that file.
If you want a quick way to fix this in the Unix console, create a script called "open" or "o" and use the file command with the option --mime to identify the file type. You can then use a case statement to launch your favorite editor.
As for the error about "mailcap rules": There is a file called "mailcap" on Unix where you can define abstract "commands" (open, edit, view, print) for file types. See the mailcap man page.