Vimorama 2002

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
  original.

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 #if preprocessor 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 nomagic search 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 f for a function, v for a variable, and so on. Since the default attribute name is kind, a solitary letter can denote the tag's type (e.g., f for a function).
file	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.
function	For local tags. The value is the name of function in which they're defined.
struct	For fields in a struct. The value is the name of the structure.
enum	For values in an enum data type. The value is the name of the enum type.
class	For C++ member functions and variables. The value is the name of the class.
scope	Intended mostly for C++ class member functions. It will usually be private for private members or omitted for public members, so users can restrict tag searches to only public members.
arity	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

ARRAYMAXED is a C #define macro defined in awk.h. AVG_CHAIN_MAX is 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 F option 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 \\, \t, \r, and \n, respectively.

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 protected]/
!_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_SORTED tag 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

The :tag ex command 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 :tag ex 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 ^T command 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.

8.5.3.1 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.[6]

[6] This information was discovered based on experimentation. YMMV (your mileage may vary).

Table 8.3: Solaris vi Tag Commands

Command	Function
ta[g][!] tagstring	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.
po[p][!]	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.
^T	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
taglength, tl	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.
tags, tagpath	The value is a list of filenames in which to look for tags. The default value is "tags /usr/lib/tags".
tagstack	When set to true, vi stacks each location on the tag stack. Use :set notagstack to 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:

$ ctags *.[ch]
$ ls
Makefile   getopt.c   getopt.h   getopt1.c   main.c   tags
$ vim main.c

Keystrokes	Results
/getopt

	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.

Keystrokes	Results
8jf_ ^]

	You have now moved to getopt.c. To find out more about struct option, move the cursor to option and do another tag search.
5jfo; ^]

	The editor moves to the definition of struct option in getopt.h. You may now look over the comments explaining how it's used.
:tags

The :tags command in vim displays the tag stack.

Typing ^T three 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.

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.

Download: http://bike-nomad.com/vim/vimoutliner.zip

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.

Continued

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019