|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
PushPop.vim - Pushd-Popd implementation for vim command-line vim online
The script provides a pushd/popd functionality for Vim taking Bash as a reference. It defines new commands called Pushd, Popd (and Pud, Pod as shortcuts), Cd and Dirs. It also defines abbreviations pushd, popd, pud, pod cd and dirs (the lower case versions) to make it easy to type and get used to, but if it causes any trouble for your regular command line typing, just set the g:pushpopNoAbbrev variable in your .vimrc.
- Most of the Bash pushd/popd syntax is supported.
- The plugin integrates seamlessly with the vim features such as 'cdpath'.
- Vim provides a "cd -" command to quickly jump back to the previous
directory on the lines of bash, but just to make it complete, the script
sets the g:OLDPWD variable to mimic the $OLDPWD variable of bash.
- The Cdp command will push the directory of the current file on to the
stack and cd into it.
- It provides commands to make it easy to manipulate the "cdpath" and save and
restore it, without needing to manually edit the vimrc, unless the
persistence feature of genutils.vim is disabled. The "AddDir" command
will allow you to add the specified directory or the current directory
(when no arguments are given) to "cdpath". The "RemoveDir" command can
be used to remove a directory by its name or index, or just the current
directory (when no arguments are given). To view the list of directories
in your "cdpath", just use the normal "set cdpath?" command or just
"Cdpath". In addition, the cd command accepts "-i" option to cd directly
into one of the directories in "cdpath". With no arguments, you will be
prompted with the list of directories to select from, and with an index
as the argument (starting from 0), you can directly cd into the
directory at that index.
- It also exposes the main functions as global functions, which can be used
by the script writers to write scripts that can move around in the
directory hierarchy and finally leave the working directory as the
Learning the vi Editor, 6th Edition [Chapter 8] vi Clones Feature Summary -- contains nice description of the "Exuberant ctags". BTW the Solaris 2.6 version of vi supports tag stacking.
The "Exuberant ctags" program was written by Darren Hiebert. Its home page is http://home.hiwaay.net/~darren/ctags/. As of this writing, the current version is 2.0.3. The following list of the program's features is adapted from the README file in the ctags distribution:
It is capable of generating tags for all types of C and C++ language tags, including class names, macro definitions, enum names, enumerators (values inside an enumeration), function (method) definitions, function (method) prototypes/declarations, structure members and class data members, struct names, typedefs, union names and variables.
It supports both C and C++ code.
It is very robust in parsing code and is far less easily fooled by code containing
#ifpreprocessor conditional constructs.
It can be used to print out a human-readable list of selected objects found in source files.
It supports generation of GNU emacs-style tag files (etags).
It works on UNIX, QNX, MS-DOS, Windows 95/NT, OS/2, and the Amiga. Some precompiled binaries are available on the web site.
Exuberant ctags produces tags files in the form described in the next subsection.
8.5.2 The New tags Format
Traditionally, a tags file has three tab-separated fields: the tag name (typically an identifier), the source file containing the tag, and an indication of where to find the identifier. This indication is either a simple line number, or a
nomagicsearch pattern enclosed either in slashes or question marks. Furthermore, the tags file is always sorted.
This is the format generated by the UNIX ctags program. In fact, many versions of vi allowed any command in the search pattern field (a rather gaping security hole). Furthermore, due to an undocumented implementation quirk, if the line ended with a semicolon and then a double-quote (
;"), anything following those two characters would be ignored. (The double-quote starts a comment, as it does in .exrc files.)
The new format is backwards-compatible with the traditional one. The first three fields are the same: tag, filename, and search pattern. Exuberant ctags only generates search patterns, not arbitrary commands. Extended attributes are placed after a separating
;". Each attribute is separated from the next by a tab character, and consists of two colon-separated subfields. The first subfield is a keyword describing the attribute, the second is the actual value. Table 8.2 lists the supported keywords.
Table 8.2: Extended ctags Keywords Keyword Meaning kind
The value is a single letter that indicates the lexical type of the tag. It can be
ffor a function,
vfor a variable, and so on. Since the default attribute name is
kind, a solitary letter can denote the tag's type (e.g.,
ffor a function).
For tags that are "static", i.e., local to the file. The value should be the name of the file.
If the value is given as an empty string (just
file:), it is understood to be the same as the filename field; this special case was added partly for the sake of compactness, and partly to provide an easy way to handle tags files that aren't in the current directory. The value of the filename field is always relative to the directory in which the tags file itself resides.
For local tags. The value is the name of function in which they're defined.
For fields in a
struct. The value is the name of the structure.
For values in an
enumdata type. The value is the name of the
For C++ member functions and variables. The value is the name of the class.
Intended mostly for C++ class member functions. It will usually be
privatefor private members or omitted for public members, so users can restrict tag searches to only public members.
For functions. The number of arguments.
If the field does not contain a colon, it is assumed to be of type
kind. Here are some examples:ARRAYMAXED awk.h 427;" d AVG_CHAIN_MAX array.c 38;" d file: array.c array.c 1;" F
ARRAYMAXEDis a C
#definemacro defined in awk.h.
AVG_CHAIN_MAXis also a C macro but it is used only in array.c. The third line is a bit different: it is a tag for the actual source file! This is generated with the
-i Foption to Exuberant ctags, and allows you to give the command
:tag array.c. More usefully, you can put the cursor over a filename and use the
^]command to go to that file.
Within the value part of each attribute, the characters backslash, tab, carriage return and newline should be encoded as
Extended tags files may have some number of initial tags that begin with
!_TAG_. These tags usually sort to the front of the file, and are useful for identifying which program created the file. Here is what Exuberant ctags generates:!_TAG_FILE_FORMAT 2 /extended format; ..../ !_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted/ !_TAG_PROGRAM_AUTHOR Darren Hiebert /email@example.com/ !_TAG_PROGRAM_NAME Exuberant Ctags // !_TAG_PROGRAM_URL http://home.hiwaay.net/~darren/ctags /.../ !_TAG_PROGRAM_VERSION 2.0.3 /with C++ support/
Editors may take advantage of these special tags to implement special features. For example, vim pays attention to the
!_TAG_FILE_SORTEDtag and will use a binary search to search the tags file instead of a linear search if the file is indeed sorted.
If you use tags files, we recommend that you get and install Exuberant ctags.
8.5.3 Tag Stacks
:tag excommand and the
^]vi mode command provide a limited means of finding identifiers, based on the information provided in a tags file. Each of the clones extends this ability by maintaining a stack of tag locations. Each time you issue the
:tagex command, or use the
^]vi mode command, the editor saves the current location before searching for the specified tag. You may then return to a saved location using (usually) the
^Tcommand or an ex command.
Solaris vi tag stacking and an example are presented below. The way each clone handles tag stacking is described in each editor's respective chapter.
22.214.171.124 Solaris vi
Surprisingly enough, the Solaris 2.6 version of vi supports tag stacking. Perhaps not so surprisingly, this feature is completely undocumented in the Solaris ex(1) and vi(1) manual pages. For completeness, we summarize Solaris vi tag stacking in Table 8.3, Table 8.4, and Table 8.5. Tag stacking in Solaris vi is quite simple.
 This information was discovered based on experimentation. YMMV (your mileage may vary).
Table 8.3: Solaris vi Tag Commands Command Function
Edit the file containing tagstring as defined in the tags file. The
!forces vi to switch to the new file if the current buffer has been modified but not saved.
Pop the tag stack by one element.
Table 8.4: Solaris vi Command Mode Tag Commands Command Function
Look up the location of the identifier under the cursor in the tags file, and move to that location. If tag stacking is enabled, the current location is automatically pushed onto the tag stack.
Return to the previous location in the tag stack, i.e., pop off one element.
Table 8.5: Solaris vi Options for Tag Management Option Function
Controls the number of significant characters in a tag that is to be looked up. The default value of zero indicates that all characters are significant.
The value is a list of filenames in which to look for tags. The default value is
When set to true, vi stacks each location on the tag stack. Use
:set notagstackto disable tag stacking.
To give you a feel for using tag stacks, we present a short example, using Exuberant ctags and vim.
Suppose you are working with a program that uses the GNU getopt_long function, and that you need to understand more about it.
GNU getopt consists of three files, getopt.h, getopt.c, and getopt1.c.
First, you create the tags file, then you start by editing the main program, found in main.c:$
lsMakefile getopt.c getopt.h getopt1.c main.c tags $
Edit main.c and move to the call to getopt_long.
Do a tag lookup on getopt_long. vim moves to getopt1.c, placing the cursor on the definition of getopt_long.
It turns out that getopt_long is a "wrapper" function for _getopt_internal. You place the cursor on _getopt_internal and do another tag search.
You have now moved to getopt.c. To find out more about
struct option, move the cursor to option and do another tag search.
The editor moves to the definition of
struct optionin getopt.h. You may now look over the comments explaining how it's used.
:tagscommand in vim displays the tag stack.
^Tthree times would move you back to main.c, where you started. The tag facilities make it easy to move around as you edit source code.
Cream for Vim
by digitect - Monday, July 15th 2002 11:21 EDT
About: Cream is a configuration of the famous Vim text editor that makes it easier to use, like an Apple- or Windows-style text editor. It uses Vim's own extensibility to improve menus, keyboard shortcuts, and editing behavior. Cream seamlessly maintains Vim's insertmode to access all the power of the original Vim plus many custom Cream extensions.
Changes: This release features a new case-sensitive, multi-lingual spell check. New English dictionaries have been provided, complete with options to select U.S., British, and Canadian dialects. A German dictionary is now available. Other new features include a file sort utility, better cross-platform flexibility, automatic loading of user customizations, simpler text reformatting, fixed word completion, a toolbar close button, and other minor fixes and keyboard shortcut adjustments.
Vim Outliner Ned Konz
I've used outliners for years to brainstorm and edit text. With the prospect of doing more writing, I've wanted to have an outliner that matched my editing style and wasn't too mouse-heavy.
Since I'm a Vim user, and since Vim 6.0 added folding, it seemed natural to make an outliner out of it.
By itself, Vim doesn't work quite right as an outliner. So I added a foldexpr() routine to make folding work right. Then I wanted keystroke macros. Then a menu. Then I wanted it to work with Vim Easy under Windows.
Anyway, here it is, although it's nowhere near ready for release. Unzip it into a directory on your Vim runtimepath (I put mine into my $HOME/.vim directory, but I'm running Linux. Your location may differ). Then add the contents of the filetype_otl.vim file to your filetype.vim file.
If any of this doesn't make any sense to you, you should wait until I release it.
Please email me with bug reports and suggestions.
Integration with Sun Visual Workshop Vim is designed to be embedded in other applications. support for which is included in the official version.
Slashdot The Union of Vim with KDE
[Jan 3, 2002] vim the popular text editor the paper of the author of VIM
I prefer to give users much freedom in using the Vim source code. The main reason to add restrictions is to avoid what happened to Elvis some time ago: someone took the Elvis source code, added a few nice Windows GUI things, and started selling it. Since those changes were not available as source code and most of that editor was still the original Elvis code, that didn't sound fair. Not only because people have to pay one guy for software that someone else made, but also because the author refused to publish the modified source code and allow others to further improve it. That's why I added the restriction that the source code of modifications must be made available to me. That still leaves room for a company to make a modified version of Vim and negotiate with me if their changes must be made public or not. This gives me the right to decide what happens with the software I created.
Why not use the GNU GPL?
The GNU General Public Licence (GPL) is more restrictive. Although it claims to ascertain the freedom of software, it restricts the changes you can make. That is, you can make changes, but when you distribute the modified software, you must make the modified sources available as well. Thus people are not free to keep these changes to themselves. I would say this in fact restricts your freedom. On the other hand, allowing anybody to make changes and keep those changes a secret, even though they profit from the part of the program that wasn't changed, also doesn't sound fair. That's why I decided to add the condition that the changes must be made available to me. I can then decide that these changes are useful for most people, and include them in Vim. Or decide that these changes have only a very small audience, and allow a company to make a bit of money from their work. After all, if the source code of a program must be freely available, it is quite difficult to require users to pay money and make a living out of your work.
I also don't agree with the idea that all software should be free and open-source. All people working on free software that I know somehow make a living out of commercial software, either with a full-time job or by studying to get a job later. Without commercial software, how would these people make a living? I think that free, open-source software and commercial software will co-exist. Most commercial software cannot be open-source, because a company would lose its advantage over competitors. Creating source code is very expensive, and a company would not want to allow others to get the results for free. Since software patents and copyrights are a very weak protection, keeping the source code a secret is still the best choice in most situations. Unfortunately, this means that you are not able to learn from how commercial software was implemented, or add a feature or fix a bug in the program you bought. A solution can be making most of the program open-source, and keeping a small but essential part a secret.
The future of open-source software
Which software will be open-source and which will not? I don't think there is a definitive answer to this question. For a given application, is there someone willing to create and maintain it as open-source software? That depends a lot on the motivation someone has to spend time on this without being paid for it. That is an uncontrollable process, with unpredictable results. Not too long ago it was thought that only small programs would be open-source, since large programs would require the long-term commitment and large investment that only commercial companies could afford. The development of Linux has proven this to be wrong, and that's not a one-off exception. Several other large projects have popped up and are successful, such as KDE.
In practice I see that most people are only motivated to make software they would use themselves. That's certainly the case for Vim: I use it myself every day. This is hardly a restriction though, since more and more people are learning how to write programs. It does restrict the number of people that are motivated to spend time working on a specific program. Theoretically it would be possible to compute the number of people that could work an open-source program:available = interested * ability * motivation
where:available [percentage of the] number of people available to work on an open-source program interested [percentage of the ] number of people interested in using the program ability percentage of this group that are able to write the program motivation [probability] chance that someone is motivated to write the program
Note that the number of people interested in the program also depends on the availability of existing programs. If there is no software that is good enough or it is too expensive, this number will be higher. If there's already a program available that's cheap and good, the number will be much lower.
Not everybody is able to write software and there is a large difference in required skills for different programs. If the goal is to make a program for software engineering, there is a large chance that the target audience includes people that have the skills to make the software. If the program is to process data for rare birds, the percentage is much smaller.
The motivation factor is the big unknown in this formula. How many of the people that are able to write the program are actually willing to do it? It would be interesting to perform a study on this, and find out if this factor can actually be estimated.
A correction to the formula needs to be made for people who are willing to write a program for others. That applies especially to software written for the disabled. Otherwise, I think this group is quite small.
If we have computed the number of people who are available to write the program, the big question is if it will actually happen. Or better: When it will happen. Given enough time, I'm sure that every program for which there is a need will be made. It should be possible to make a formula to compute the chance that the program will be written this year. That's left as an exercise to the reader...
Overall there are a lot of undetermined factors in this formula. I would conclude that it's unpredictable how much open-source software there will be in the future.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017