text:
Evolutionary Biology/Early History of Life on Planet Earth

< Evolutionary Biology

Introduction to the History of Life
It is very interesting that life began from simple chemical molecules. Starting from the formation of the universe from simple elements such as hydrogen and helium 13.7 billion years ago, until now, with Homo sapiens evolving and trying to expand its colony to a new planet, there is one great history of life. To understand those sequences in chronological order, it is important to understand the geologic time scale. There are two ways to represent geologic time: relative time, which deals with divisions and subdivisions of the Earth's geology in a specific order based on relative age relationships, and absolute time, which is usually obtained from radiometric dating methods performed on igneous rocks, such as volcanic ash layers or lava flows, to determine numerical ages.

Chemical Origins of Life
The study of evolution is incomplete without first a consideration for the origin of life itself. Any theory of biology would be incomplete without a finite and irreducible origin. Life emerging from non-life, or "abiogenesis" is a tricky subject to study because scientists are typically divided as to what precisely constitutes "life." In its simplest possible form, life consists only of simple replicating chemical structures, such as amino acids and short RNA chains. These simple molecules are typically not what people think of when talking about "life", although it does serve as a convenient starting point to further studies of evolution.

The atmosphere of earth was significantly different before the advent of living organisms. Without plants and a replicable process of photosynthesis, the atmosphere was almost completely devoid of oxygen. Nitrogen and Carbon rich compounds, such as ammonia and methane, were far more common in the environment then they are now. Combined with excess geothermal heat and lightning, it is hypothesized that genetic building blocks could have formed from these chemicals.

Wächtershäuser's Hypothesis
Chemist Gunter Wächtershäuser put forth a similar hypothesis to Miller and Urey, except that instead of external energy sources of electric arcs and UV radiation, energy required by organic molecule synthesis could have come from redox reactions involving sulfides of Iron. This theory is consistent with the idea that life may have originated near hydrothermal vents in the ocean floor. While Wächtershäuser's experiments did succeed in producing simple and more complicated amino acids, those acid chains were noted to hydrolyze quickly in the surrounding chemical environment.

Martin and Russell
Based off the Wächtershäuser hypothesis, William Martin and Michael Russell proposed that life could have had hydrothermal origins and microstructural origins. Ocean floor structures known as "black smokers", which provide essentially a mostly-enclosed microcavern filled with iron sulfides would provide both the geothermal energy necessary by Wächtershäuser's hypothesis, but also the security necessary to prevent the amino acid chains from hydrolyzing. In such a black smoker, it is theoretically possible for the various components of life: DNA and RNA chains, protein synthesis, and enzyme interaction could have all formed simultaneously, without having first to develop a lipid cell membrane. The eventual synthesis of a lipid membrane, possibly as a lipid coating of the inside of the black smoker, would have enabled the new protocell to leave the black smoker and travel the ocean independently.

It is interesting to note that Archaea, simple single-cell organisms, can be found to live in black smokers. Some recently-discovered forms of bacteria have been found that utilize the faint light of the black smokers for photosynthesis, the first recorded case of photosynthesis occurring without sunlight.

"Gene First" and "Metabolism First"
There are two competing theories of thought as to the origin of life. The first theory, "Genes First" hypothesizes that self-replicating molecules such as RNA were created from simple amino acids, and later evolved into more complex replicating systems. DNA is not usually considered a candidate, since its replication and formation require the use of complex protein structures to facilitate those tasks, proteins which are unlikely to be produced through non-biological means. This theory suffers from the fact that RNA and similar amino acid structures are sensitive to UV radiation, and they are also prone to hydrolyzing. In essence, a bare RNA chain would have a difficulty surviving both in and out of the ocean.

In contrast to the "Genes First" theory, the "Metabolism First" theory speculates that enclosed environments with metabolic pathways existed first, and later served as a secure enclosed location for the synthesis of Amino acid chains. Alexander Oparin hypothesized that primitive chemical structures could have been self-replicating without the need for RNA or other amino acid chains. Some support for this theory stem from the fact that the Acetyl-CoA metabolic pathway utilizes Iron-Nickel-Sulfur compounds (key to Wächtershäuser's hypothesis) and catalyzes key components in a single, simple step.

A commonality between these two approaches is seen with a simple analogy. Consider a completed grocery list. The list, analogous to genetic material, conveys a description of the contents of a bag of groceries. The bag itself, however, contains the same vital information, by virtue of its contents. Whereas the list contains the information in a coded fashion, the full bag itself contains the exact same information in physical form. The "metabolism first" theory proposes that this "full bag" scenario is in fact simpler than requiring genetic information prior to the production and assembly of proteins.

To further explain the "Metabolism First" theory, it helps to simplify what is meant by metabolism. In the simplest explanation, metabolism is the utilization of energy to construct more complex materials from simpler components. In the "metabolism first" theory, a boundary between the outside environment and the interior of the system is required. The abiosythesis of lipid bilayers similar to those found in the cell membrane of all living cells has been produced in the laboratory, though any physical means of separating the system from the environment at large would suffice. There must also be a source of energy to drive the reaction. This, according to many adherents, would be facilitated by what are known in chemistry as "redox" (an abbreviation of reduction/oxidation) reactions. When one chemical gains electrons, it is said to be reduced, the chemical losing electrons is said to be oxidized. Redox reactions occur in many current biological processes. It is responsible for the transfer of electrons in the light dependent phase of photosynthesis in photosynthetic bacteria and all chloroplast bearing eukaryotes, and the absorption of oxygen in our hemoglobin. However, any source of energy could be a candidate for the earliest forms of energy consumption, including pH differentials, sharp temperature gradients, even radioactivity.

Along with energy utilization, some mechanism of coupling must have existed in order to use the energy to drive further chemical reactions. Catalysts are chemicals that work as intermediaries between substrates and products. Consider hydrogen peroxide. Hydrogen peroxide will break down into water and oxygen gas when mixed with a catalyst. The catalyst itself is not consumed in the reaction, but is able to continue functioning after the reaction has taken place. Depending on the substrate, any number of naturally occurring minerals and chemicals can act as catalysts. Catalysts serve to speed up chemical reactions. Hydrogen peroxide will spontaneously degrade into water and molecular oxygen, however, the presence of a catalyst speeds up this reaction to the point that it has been used a fuel source for torpedoes and even spacecraft. With energy extracted from the environment, suitable substrates and a catalyst to speed up the reaction, energy storing intermediate materials could have been produced. These materials could later release their stored chemical energy to facilitate further reactions.

Some form of cyclic reaction is established in the "metabolism first" scenario. Consider an organic substrate A. When A is catalyzed and energy is introduced, a new chemical B is produced. B can now be used to carry out further chemical reactions, utilized by C, D, and so forth. In the end, B is reconverted to A, closing the cycle. Cyclic reactions are favorable in this scenario, since the replenishment of A does not require the further extraction of the material from the environment. This ensures that the system will be able to continue to exist even if A becomes scarce in the environment. The increased complexity of a cyclic system also allows for adaptation within the system. If one of the further pathways (C, D, etc.) is adversely affected by environmental conditions, different pathways can be included or take the place of the non-functioning portion.

Finally, the system must have some means of growing and reproducing in order to be considered life. To grow, the system must gain materials faster than it loses it, either by diffusion into the surrounding environment, or through some other means, such as precipitation of waste materials. Reproduction can be achieved as an accidental process. Consider a "compartment" of some kind, like a bubble of wax in a Lava Lamp. Within the bubble, the network of pathways extracts energy from the environment, creates some system of reactions that produce more materials for the chemical pathways. The bubble expands with the increase of its contents. Environmental conditions such as current or temperature gradients cause the bubble to pinch off, creating two bubbles containing similar concentrations of materials. If the concentrations are adequate, two separate networks have been formed. These two networks can continue to grow and split off into further networks, allowing them to compete for resources in the environment. This competition for resources is the beginnings of Darwinian evolution.

At some point in their evolution, these chemical networks must have made the leap from a content-based information storage to a coded form. As the networks grew in complexity, it would be more favorable to have some means of imprinting the necessary contents. A transferable coded form of information would allow a greater chance of sustainable systems to result from division of the parent system.

Mesozoic Era (245 million years ago)
The time period between 245 million years ago and 66 million years ago is called Mesozoic Era. Mesozoic Era is mostly known for many dinosaurs, which evolved in the Triassic and became very diverse in Jurassic Period. This Mesozoic Era lasted for about 180 million years and it is some times called the age of reptiles. Similar to the Paleozoic extinction, at the end of Mesozoic Era, dinosaurs became extinct. In this period, there were many changes to the terrestrial vegetation. For example, gymnosperms, such as conifers, were evolved in this Era and the earliest angiosperms were also diversifying in this Era. During Triassic Period, the first dinosaurs appeared. At this time, molluscs were the dominating invertebrates. In the Jurassic Period, many dinosaurs evolved and thrived. The first birds also evolved in this Period, of which the fossil Archaeopteryx is seen as an early example. For plants, the first flowering plant or angiosperms evolved together with gymnosperms. The Mesozoic Era ended with a large extinction of the dinosaurs. Mammalian creatures prospered after this.

Cenozoic Era (66 million years ago until now)
Compared to the other Eras that lasted for hundreds of million years, the Cenozoic Era spans only for about 66 million years. This era is divided into two major Periods; the Tertiary(now referred to as the Paleogene and Neogene) and Quaternary Periods. The Tertiary Period was when major radiation of mammals and birds occurred. Insects also predominated this Era. Similarly to the Mesozoic Era, angiosperms diversified. Around 35 million years ago, the first primate groups appeared. The first human-like apes appeared around 5 million years ago. The Ice Age marks the end of the Tertiary period and the beginning of the Quaternary period. As temperatures rose, extinctions were common. The Quaternary period is also known for evolution of Homo sapiens.


text:
User talk:Reytan

You are now a Wikibooks Admin. Congratulations! TUF-KAT 21:43, 16 Jun 2004 (UTC)
 * Thank You! How I see, I should spend more time on WikiBooks project (& my English :D). Take care, Reytan 15:02, 13 Jul 2004 (UTC)

De-Adminship vote.
A vote is being held to remove your sysop privileges. The basis for this vote is lack of use of these privileges. You may want to participate at Requests_for_adminship. See also the discussion at Staff_lounge. --JMRyan 22:49, 17 February 2006 (UTC)

Your De-Adminship
Hello. I would like to inform you that you will have your sysop rights removed here on 1 Nov 2006 due to inactivity. If you would like to discuss the matter, please see WB:RFA. You can re-apply for adminship at a later date if you wish. Thanks. -within focus 21:31, 1 October 2006 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User talk:Reytan


text:
Cookbook talk:Tarbes Salad

This recipe was the featured recipe on the main Cookbook page from June 1, 2004 - June 19, 2004. Gentgeen 22:37, 16 Jun 2004 (UTC)

title: Cookbook talk:Tarbes Salad


text:
Cookbook talk:Trout

This module was the featured ingredient on the main Cookbook page from June 1. 2004 - June 19, 2004. Gentgeen 22:43, 16 Jun 2004 (UTC)

Mirc trout do NOT count.

title: Cookbook talk:Trout


text:
User:PiaCarrot~enwikibooks

Other accounts
 * w:ja:利用者:PiaCarrot
 * w:en:User:PiaCarrot
 * wikt:ja:利用者:PiaCarrot
 * w:test:User:PiaCarrot
 * ja:利用者:PiaCarrot - Previously wrote some article for computer games, now I moved to ja.wikibooks.

/monobook.css /monobook.js

Works
Following pages are moved to ja.wikibooks
 * ファイナルファンタジーIV
 * ファイナルファンタジーVII

title: User:PiaCarrot~enwikibooks


text:
User:PiaCarrot~enwikibooks/monobook.css

font-size: 120%; font-family: Tahoma, sans-serif; } a { text-decoration: underline } a:active, a:hover { color: red !important }
 * 1) globalWrapper {
 * 1) bodyContent { font-size: 120% }

 * 1) content, p, ul, ol, dd, fieldset { line-height: 1.3 }

/* default link colors */
 * 1) bodyContent a { color: #c06000 }
 * 2) bodyContent a:visited { color: #ff8000 }

/* from wikistandard */
 * 1) bodyContent a.internal,
 * 2) bodyContent a.internal:visited { color: #c06000 }

 * 1) bodyContent a.stub,
 * 2) bodyContent a.stub:visited { color: #006000 }

 * 1) bodyContent a.new,
 * 2) bodyContent a.new:visited { color: #ba0000 }

 * 1) bodyContent a.external,
 * 2) bodyContent a.external:visited { color: #80f080 }

 * 1) bodyContent a.extiw,
 * 2) bodyContent a.extiw:visited { color: #8080f0 }

/* small pre */
 * 1) bodyContent pre { font-size: 90% }

/* h1, h2, h3, h4, h5, h6 { font-weight: bold !important }

dd {margin-bottom:0em;}

title: User:PiaCarrot~enwikibooks/monobook.css


text:
User:Gentgeen/monobook.js

function morelinks { var tabs = document.getElementById('p-cactions').cloneNode(true); tabs.id = 'mytabs'; var listitems = tabs.getElementsByTagName('LI'); for (i=0;i<listitems.length;i++) { if(listitems[i].id) listitems[i].id = 'mytabs-' + listitems[i].id; } document.getElementById('column-content').appendChild(tabs); } if (window.addEventListener) window.addEventListener("load",morelinks,false); else if (window.attachEvent) window.attachEvent("onload",morelinks);

title: User:Gentgeen/monobook.js


text:
Modern Physics/Maxwell's Equations

The next step on the road to relativity was the development of the equations of electromagnetism by James Clerk Maxwell. One direct consequence of these equations was the prediction of electromagnetic waves, which were quickly identified with things such as light.

One of the first difficulties of electromagnetic waves was the apparent lack of medium. Unlike other wave phenomena, like waves on a string or ocean waves, physicists knew little of what was "waving" in the case of an electromagnetic wave. To get around this difficulty, they just assumed that there was a medium filling all of space called the luminiferous aether, in which electromagnetic waves propagate.

A second difficulty was that Maxwell's equations predicted that these electromagnetic waves always traveled at the same speed c, regardless of the speed of the observer. This immediately led to the question "With respect to what?" Of course, the accepted answer at the time was with respect to the rest frame of the luminiferous aether, called the aether frame. This was an attempt to salvage Galilean relativity, which requires the speed of the wave to depend on the observer.

The next advance came from people attempting to study the aether.

title: Modern Physics/Maxwell's Equations


text:
User:Goodralph~enwikibooks

Find me at user:goodralph on wikipedia.

title: User:Goodralph~enwikibooks


text:
User:Tommyde~enwikibooks

My main interest is in passing the Japanese Language Proficiency test.

For that goal I am working on the Japanese Wikibook.

title: User:Tommyde~enwikibooks


text:
User:Nathan Hamblen~enwikibooks

I'm a software programmer in New York. During the school year of 2003 — 2004, I tought English in France to 8 year-olds (CE2) in three primary schools (Théophile Gautier, Paul-Bert, and Henri IV) in Tarbes, France. Leland and I started off the Teaching Assistant in France Survival Guide to help future assitants. We now live in New York.

See my user page at Wikipedia for more.

title: User:Nathan Hamblen~enwikibooks


text:
Learning the vi Editor/Details

This section describes some of the details of the vi program itself (such as command line features), and other advanced vi features for aspiring vi power users.

Command line invocation
Different vi clones of course have different ways of starting the program (invocation). Usually, however, command-line versions of vi share a common basic set of command line options. These following command line options and flags are typically available. In addition, vi can be started under different names. Depending on the name used to start vi, it may either behave slightly differently or load a different vi clone.

The common command line options and flags are

or
 * -s
 * Suppress. All interactive user feedback is suppressed (not written to the terminal). This allows to pipe editing commands through the editor, and use it as a kind of stream editor. There are probably better streaming editor tools on Unix, like sed(1), awk(1), or Perl(n).

 * Note, "-" is a common Unix notation to indicate standard input. It has been chosen as an alternative to -s by the vi authors to provide a familiar look when piping commands. It does not really mean 'read from standard input' since vi does that anyhow.

 * -C
 * Encryption. vi prompts the user for a key (a kind of password), and uses this key to encrypt its files before writing. It also uses this key to decrypt any file opened with vi. This feature is not supported by many clones, and the encryption algorithm is a very weak one (it is based on a 256-element one-rotor algorithm). The algorithm is easy to crack. It is compatible with the Unix crypt(1) command. See also -x.

 * -l
 * (lower-case letter L) Change some default settings so they are more useful for editing LISP source code.

 * -L
 * (upper case letter L) Lists all files which have been saved during a crash. See -r, too.

 * -r filename
 * Recover the file filename after a crash. Use -L to get a list of files which can be recovered.

 * -R
 * Readonly. Files can only be viewed, not written.

 * -S
 * Tags are not sorted. When a tag file is used, this flag tells vi that the tag file is not sorted, therefore vi will use a slower algorithm to look up tags. See -t, too.

 * -t tag
 * Edit (open) that file which contains the given tag. This of course requires that a tag file (called tags) is available.

 * -v
 * Start in visual mode. Only useful if the editor is started under the name ex and not vi.

 * -V
 * Verbose. Commands read via standard input are echoed to standard error. This is useful for debugging when the editor is used as a streaming editor.

 * -wnumber
 * Window size. Set the editor's number of lines to number. vi behaves as if the terminal has only number number of lines. This was used in the old days to speed up things when connecting via a slow terminal or modem line.

 * -x
 * Encryption. Similar to -C. The difference is that vi tries to guess if a file that is opened needs decryption or not. -C on the other hand always runs the decryption when a file is opened.

or
 * +command
 * -c command
 * Execute the command command before allowing the user to enter own commands. The most common usage is to use this to position the editor at some specific line in a file. E.g.

vi +10 list.txt

 * will open the file list.txt and position the cursor at line 10. Another common usage is to specify a pattern:

vi +/END script.awk

 * This will open the file <tt>script.awk</tt> and position the cursor at the first occurrence of the pattern 'END'.

As already mentioned, vi can be started using different names (all may not be available depending on the particular clone):

 * vi
 * The usual way to start vi.

 * view
 * vi starts in read-only mode.

 * vedit
 * A few settings are changed to better suit beginners: magic is cleared, showmode and novice are set, and report is set to 1.

 * ex -v
 * Same as just typing <tt>vi</tt>

General
Until now, this tutorial has just talked about commands, and that commands can be used in conjunction with things like word counts. E.g. <tt>d2w</tt> has been explained as the operator <tt>d</tt>elete applied to two words. Note the <tt>2w</tt> part. You have learned that this part specifies to which text the operator should apply. And indeed, the <tt>2w</tt> part specifies to which objects of the text (words, lines, characters etc.) the operator is supposed to be applied. And you have seen that the same object specifiers can be used with all types of operators - as long as the combination makes sense.

vi commands in fact follow a general schema. Commands are made up from operators and objects:

[[count] operator] [[number] object]

This means the operator should be executed count times on number of objects. Almost all parts are optional. Also, some operators don't take objects at all. This operator/operation syntax is vi's heart. It is why people either love or hate vi. People love it, because it is such a simple schema. Once one knows the few operators (not more than ten), and a few of the objects one can be very productive in vi. People who hate vi simply can't get this schema, and the fact that there is a difference between command and insert mode, into their heads.

Objects
We told you that things like the <tt>w</tt> command moves one word. We actually cheated a little bit when telling you this. There is no such thing as a <tt>w</tt> command. <tt>w</tt> is an object specification, not a command. The object specification was given without an explicit operator like <tt>d</tt>. In such a case vi uses the implicit default operator. And that operator is move.

Whenever you use an object specification without an operator, the operator move will be used. Therefore, object specifiers degrade to move commands. The following is a list and summary of all object specifier. Logically, you can use them in conjunction with operators, or to move around if used stand-alone. You have seen a few of them already:

Paragraph, Section, Sentence Objects

 * }
 * Everything until next paragraph end.

 * Everything until previous paragraph end.
 * Everything until previous paragraph end.

 * ]]
 * [Everything until next section end.]

 * [Everything until previous section end.]
 * [Everything until previous section end.]

 * Everything until next sentence end.
 * Everything until next sentence end.

 * Everything until previous sentence end.
 * Everything until previous sentence end.

Line Objects

 * [number]G
 * Everything until line number. If number is omitted, last (not first) line in file. The first line can be addressed as <tt>1G</tt> instead.

 * [number]H
 * number of lines after the first line currently on screen. If number is not given, the first line on the screen.

 * [number]L
 * number of lines before the last line currently on screen. If number is not given, the last line on the screen.

 * M
 * The middle line of the screen.

 * j
 * One line down from current line.

 * k
 * One line up from current line.

 * _
 * (underscore) The current line as a whole.

Positions within Lines

 * 0
 * (Digit 0). Backward to first column of line. Same as <tt>1|</tt> (not <tt>0|</tt>).

 * Backward to first non-whitespace character.
 * Backward to first non-whitespace character.

 * Forward to end of line.
 * Forward to end of line.

 * [number]|
 * Column number of the current line. If number is not given, column 1 is used.

 * tchar
 * Before the next appearance of character char on the current line.

 * Tchar
 * Backwards after the next appearance of character char on the current line.

 * fchar
 * Next appearance of character char on the current line.

 * Fchar
 * Previous appearance of character char on the current line.

 * Repetition of the last <tt>t</tt>, <tt>T</tt>, <tt>f</tt>, or <tt>F</tt> command.
 * Repetition of the last <tt>t</tt>, <tt>T</tt>, <tt>f</tt>, or <tt>F</tt> command.

 * Repetition of the last <tt>t</tt>, <tt>T</tt>, <tt>f</tt>, or <tt>F</tt> command, but in opposite direction.
 * Repetition of the last <tt>t</tt>, <tt>T</tt>, <tt>f</tt>, or <tt>F</tt> command, but in opposite direction.

or
 * <CR>
 * To the first non-whitespace character on the next line.

 * To first non-whitespace character on the previous line.
 * To first non-whitespace character on the previous line.

Word Objects

 * w
 * Forward to next begin of a word.

 * e
 * Forward to next end of a word.

 * b
 * Backwards to next begin of a word.

Character Object
or
 * h
 * <BS>
 * Left character.

or
 * l
 * <SPACE>
 * (lower-case letter L or space) Right character.

Pattern Matching Objects

 * : Forward to the beginning of the first match of pattern pattern.
 * : Backwards to the beginning of the first match of pattern pattern.
 * : Repeat the last <tt>/</tt> or <tt>?</tt>.
 * : Repeat the last <tt>/</tt> or <tt>?</tt> in opposite direction.
 * : To next matching (, {, or [.

Operators
The previously listed objects can be used as arguments to operators. If no operator is given, the default move operator is used. The number of operators in vi is surprisingly small - ten in total. Here is a list of the operators:

needs better descriptions, a few of them are separately described later in this module

Operators taking Objects

 * c : change - change the addressed objects. In fact, the text is replaced by what is typed in.

 * d : delete - delete the addressed objects. The deleted text is placed in the undo buffer.

 * y : yank - copy the text of the addressed objects into the buffer.

 * < : shift left - object arguments can only be objects which address lines Indenting and Shifting.

 * > : shift right - object arguments can only be objects which address lines Indenting and Shifting.

 * ! : bang filter-through - filter lines through an external program. Objects can only be objects addressing lines Filtering (stub).

Operators not taking Objects
r, s,

 * x : Delete character. Use the d operator for deleting other objects than characters.

 * ~ : Flip case of character at cursor position. An uppercase letter becomes its lowercase equivalent, and a lowercase letter becomes its uppercase equivalent.

Special Operator Forms
There are two special forms when typing an operator:

 * 1) Typing the character in upper-case, instead of lower-case. E.g. <tt>Y</tt> instead of <tt>y</tt>, and
 * 2) doubling the character. E.g. <tt>yy</tt> instead of <tt>y</tt>.

'Strange' lines on the screen
vi was written at a time when terminal or modem connections were slow. Therefore, vi used several optimisation techniques to limit the need for redrawing the whole screen. In such cases, vi used to display lines beginning with a special marker. Modern vi's seldom have the need for such performance optimizations any more, but they still have the habit to display such lines.

There are two special markers used:

~line A leading '~' indicates that the line is past the end of the file (non-existent). This can be observed, for example, when vi is started on a new or empty file.

@line The line is only on the screen, not in the file. This happens for deleted lines. If wrap is enabled (the default), this also happens for lines that are too long to show on the screen all at once.

Indenting and shifting
vi supports auto-indentation of text lines and also provides command for manual indentation. This is useful when editing program source code. It is a common convention in many programming languages to use indentation to increase readability of the source code.

Options
The option <tt>shiftwidth</tt> (sw) determines how much space is used for indentation. E.g.

shiftwidth=4 or sw=4

tells vi to use four spaces for indentation.

The option [<tt>no</tt>]<tt>autoindent</tt> (ai) tells vi to use auto indentation or not. Auto indentation is turned on by

autoindent or ai

And it is turned off by

noautoindent or noai

Command Mode
Shifting lines is done with the commands. < moves the text one <tt>shiftwidth</tt> to the left (outdenting), while > moves the text one <tt>shiftwidth</tt> to the right (indenting). The number of lines which can be affected are specified in vi's typical way. However, only  objects which identify lines, and not objects which identify words or individual characters can be used.

E.g.

>G

moves all lines from the current line until the end of the file to the right.

Or

<}

moves all lines from the current line until the end of the paragraph to the left. Of course, the shift commands can be used in conjunction with <tt>%</tt>, which indicates the next opening bracket. E.g. to shift the lines encompassing the current cursor position up to the first line with a matching (, {, or [ to the left one would type:

<%

Like with all commands it is also possible to specify a line count:

or
 * [number]<<
 * <[number]<
 * Moves number of lines, starting at the current line, one <tt>shiftwidth</tt> to the left (outdenting). If number is not given, 1 is assumed - this leads to the shifting of the current line to the left.

or
 * [number]>>
 * >[number]>
 * Moves number of lines, starting at the current line, one <tt>shiftwidth</tt> to the right (indenting). If number is not given, 1 is assumed - this leads to the shifting of the current line to the right.

The commands can also be used with a marker. In this case, the reference to the marker is placed between the two characters of the command:

 * <'m<
 * Shifts the lines from the marker m up and including the current line to the left.

 * >'m>
 * Shifts the lines from the marker m up and including the current line to the right.

Insert Mode

 * ^t
 * Moves shiftwidth to the right. Note, it is a common mistake to use the <TAB> key instead of <tt>^t</tt>. <TAB> inserts a Ctrl-I character and moves to the next multiple of tabstop, and not to shiftwidth. So <TAB> only works if tabstop and shiftwidth are set to the same value.

 * Since it is not a good idea to set tabstop to anything else than 8, <TAB> can only be used instead of <tt>^t</tt> for indenting when shiftwidth is also set to 8.

 * ^d
 * In autoindent mode, backtabs one shiftwidth. E.g. if autoindent is on, and one wants to enter the follwing text:

if(true) { printf("done"); // start sw indent return; } // bracket moved back to the left

 * one would type

if(true) {<CR> ^tprintf("done"); // start sw indent<CR> return;<CR> ^d} // bracket moved back to the left<CR>

There are some special variants of <tt>^d</tt>, too:

 * ^ ^d
 * (the letter ^ followed by Ctrl-D). When this is typed first on a new line, all autoindent is killed (the insertion point is moved to the beginning of the line). Autoindent is then continued on the next line.

 * E.g. to enter the following text when using autoindenting

an indented paragraph another line in the indented paragraph .F roff formating commands have to start at column one with a '.' more text in the indented paragraph

one would type

^tan indented paragraph<CR> another line in the indented paragraph<CR> ^^d.F roff formating commands have to start at column one with a '.'<CR> more text in the indented paragraph<CR>

 * 0^d
 * (the digit 0 followed by Ctrl-D). Kills all autoindent (moves cursor to the beginning of the line), and leaves autoindent off, until text is once manually indented (using <tt>^t</tt>).

 * E.g. to enter the following text when using autoindenting

INTEGER FUNCTION FAC(N) FAC = 1 DO 100 I = 2, N          FAC = I * FAC C C PROVIDE LABEL TO END LOOP C A HINT FOR THOSE GRASSHOPPERS: THIS IS FORTRAN CODE :-) C 100 CONTINUE      RETURN      END
 * one would type

<ESC>:set sw=5<CR> o^tINTEGER FUNCTION FAC(N)<CR> FAC = 1<CR> DO 100 I = 2, N<CR> ^tFAC = I * FAC<CR> 0^dC<CR> C PROVIDE LABEL TO END LOOP<CR> C A HINT FOR THOSE GRASSHOPPERS: THIS IS FORTRAN CODE :-)<CR> C<CR> 100 CONTINUE<CR> ^tRETURN<CR> END<CR>

Modelines
Modelines are lines in text files which are specially interpreted by vi when such a text file is opened. When the <tt>modeline</tt> (<tt>ml</tt>) (in some version of vi also called <tt>modelines</tt>) option is turned on (e.g. in the users <tt>.exrc</tt> file), vi scans the first and last five lines of each opened file for text of the form

unrelated text <tt>vi:</tt>command<tt>:</tt> more unrelated text

or

unrelated text <tt>ex:</tt>command<tt>:</tt> more unrelated text

Each command from such lines is taken and executed as it would have been typed by the user. Any text in front of the modeline-marker (<tt>vi:</tt> or <tt>ex:</tt>) or behind the closing <tt>:</tt> is ignored for the modeline interpretation. This can be used to place modelines in comments if they are used in some programming source code.

Here is an example Java source code file. It contains a modeline on the second and third line, in a Java comment:

/*  * vi:set sw=4 ai: * vi:set showmatch: */

package gnu.freesoftware; public class Interpreter { public Interpreter ...         ...

When modelines are turned on, and this file is opened, <tt>shiftwidth</tt> (<tt>sw</tt>) is set to 4, <tt>autoindent</tt> (<tt>ai</tt>) is turned on, and the <tt>showmatch</tt> (<tt>sm</tt>) option is turned on, too. There is no particular reason why two <tt>set</tt> commands on two modelines are used other than to demonstrate that all modeline commands found in the first and last five lines are executed, and not just the first.

Modelines can be used to play some practical jokes. E.g., a file with the modeline

vi:q!:

immediately closes the editor and makes it impossible to edit the file as long as modelines are turned on.

Modelines get outright dangerous if they mess with system files. E.g., if the super user (administrator) of a Unix system has modelines turned on, and is tricked into opening a file with the following modeline, the important Unix password file is overwritten with the contents of the opened file:

vi:2,$w! /etc/passwd: root:A shiny new root password:0:0:System Administrator:/:/bin/sh anotheruser:Another shiny new password:1:0:Just another user:/home/anotheruser:/bin/sh

Therefore modelines should only be turned on in a controlled environment. This is sad, since in principle it is a nice idea that files are able to provide the editor with a configuration best suited to edit that file.

There are some other problems with modelines. Classic vi versions always set a file's status to modified if they find a modeline, even if no editing in the file has taken place. This forces the user to leave the editor with <tt>:q!</tt> instead of just <tt>:q</tt>. If instead <tt>ZZ</tt> is used to leave, the file is written. This causes tools like make to think the file has changed if it in fact hasn't.

.exrc Configuration File
''This module is a stub. You can help Wikibooks by fixing it.'' For a start:

.exrc files are files containing vi (and ex) configuration data. The format of the data in such a file is that of ex commands, without the leading ':' (column). Typically, .exrc files are used to load some default mappings (map and map! ex commands) or define particular defaults. E.g. the following .exrc file would set autoindent and the shiftwidth when vi is started:

set ai set sw=4

Normally, a .exrc file is placed in the user's home directory. Since the file name starts with a '.', the file is hidden under Unix-like operating systems. It is possible to place .exrc files in other directories, too. Vi can read the .exrc file in the current directory from which it is started. However, this feature is considered a security risk and turned off by default. It is considered a risk, because similar jokes can be played with .exrc files as with what has been described for modelines. The .exrc file in a user's home directory is considered safe, because on a correctly configured Unix system only the particular user should have write access to it.

There are three important things which should be observed when working with a classic vi and .exrc files:

 * 1) .exrc files must not contain empty lines. Classic vi chokes on these lines with all kinds of cryptic error messages.
 * 2) There is no official way to place a comment in .exrc files. However, since the beginning of time the following hack is used and is known to work: A line which starts with a " (quotation character) is ignored by vi.
 * 3) Classic vi is very picky about map and map! commands. Definitions which by all means should work can trigger strange error messages. This is due to classic vi's limited parser and interpreter for such definitions. Spliting a map or map1 command in several smaller ones can sometimes help.

Many clones have relaxed these rules by allowing empty lines in an .exrc file, and by officially specifying the " as the comment character. Also, good clones should have no problem with map or map! specifications.

" " This is a comment in an .exrc file " A .exrc file must not contain empty lines, so " comment lines need to be used to separate entries " set sm set sw=8 " set wm=8 " " map 'g' to go to begin of file map g 1G " rcs check-out (/co) and check-in (/ci) map /co :w! %.co.bak^M:!co -l %^M:e! map /ci :w^M:!ci -u %^M:e!^M " " Abbreviations ab Lx Linux

Overview
Vi can use so called tag files (or tags) to allow for quick navigation (jump) to "interesting" information in a set of files. The most common usage for this is to navigate within source code files. E.g. to jump from the usage of a certain function to the function's definition, possibly in another file.

The mechanism is relatively simple. You tell vi to go to a particular tag. vi looks up the file in which the tag can be found, opens that file and jumps to the location of the tag in that file. In order to find the file and position of a tag, vi consults a tag file. A tag file contains an index of tags. A tag is an item (e.g. some programming language object) for which such an index entry can be found in a tag file. When vi is asked to jump to a particular tag, vi looks up the index entry for that tag, and uses the information to jump to the particular item.

In order to use this feature one first has to create a tag file, or a set of tag files, containing entries for all potentially interesting items. These tag file or files then need to be made known to vi - if the default file name is not used. This can e.g. be done by having appropriate commands in an <tt>.exrc</tt> file.

Modern IDEs provide similar navigation features, but without the need to build a tag file separately. IDEs build the necessary index on-the-fly or use fast brute-force full-text search algorithms. The need for the extra step of creating a tag file for vi is annoying by modern standards. Still, vi's tag file system works and is usable.

Tag File Format, Creation & ctags(1)
The creation of a tag file typically requires to use a tool which analyses the input text files (e.g. programming source code) and generates entries for each item of interest found in the input text file. The most common tool is called ctags(1) and is a standard Unix program. Several vi clones come with own versions of ctags, sometimes called differently.

ctags knows the syntax of a number of programming languages and generates index information for items like function names, and macro definitions.

In case ctags is not available, or the available version of ctags does not support the programming language in use it is also possible to generate tag files with text processing tools like awk(1), sed(1) or perl(n) and some clever scripts, because tag files are ASCII files.

Typically an entry in a tag file looks like

tag-name<TAB>file-name<TAB>ex-command

 * tag-name
 * The name of the item. E.g. a function name or macro name.

 * file-name
 * The name of the file in which the tag-name item can be found

 * ex-command
 * An ex editor command indicating how to locate the item in the file. This can be any ex command. But two types of ex commands make the most sense:

 * 1) In the simple form ex-command is a line number, which is indeed a valid ex command.
 * 2) Usually, however, it is a better idea to use a search pattern like <tt>/</tt>tag-name<tt>/</tt>. This provides some flexibility if the file is edited later. It reduces the number of times the tag file has to be re-build, because something moved inside a file. ctags also mostly generates pattern search commands and not line numbers.

Typically vi clones allow for some extensions of this format. Check the particular documentation.

A tag file should be sorted in alphabetic order to speed up operation. If this can't be done, vi's -S command line option can be used.

It is usually not a good idea to generate tag files by manually running ctags or an own tool. Instead the building of tag files is usually better integrated into the software build system. For Unix this means using Makefiles. Typically, the make(1s) targets for generating tag files are called tags, because that's the name of the to be created tag file:

SRCS = ... # all source code tags: $(SRCS) ctags -dt $(SRCS)
 * 1) Makefile snippet

Ex Commands
By default, vi looks in a file called <tt>tags</tt> for any tags. This file name can be changed with the following ex command. In fact, more than one file name can be specified. They are all loaded to find tags. The command is maybe best placed in a project-specific <tt>.exrc</tt> file.

 * : set tags=filename[\ filename ...]<CR>
 * Set name of files which contain tag information. The syntax of the command varies a little bit from vi to vi version if more than one tag filename is supposed to be provided. Filenames have either to be separated by "<tt>\ </tt>" (backslash space) or "<tt>;</tt>" (semicolon).

Naviation to tags can be done via the following ex command. There is also a vi command to do this.

 * : ta tag-name<CR>
 * or

 * : tag tag-name<CR>
 * Look up the tag-name in the tags file(s), open the file named in the index entry and execute the ex-command from the index entry. This effectively positions the user at the file and position where the symbol tag-name is defined. The command also remembers the current file and position on the tag stack.

EX commands in vi
Ex is a line editor that serves as the foundation for the screen editor vi. Ex commands work on the current line or on a range of lines in a file.

Syntax of Ex commands

':' specifies an Ex command.

Address

The 'address' specifies the lines number or range of lines that are the object of command.If no address is given, the current line is the object of the command.

Address Ranges can be specified by any of the following ways in Ex command syntax. Commands

Options

Vi Commands
Navigation to tags can be done via the following vi command:

 * ^]
 * Take the tag-name at the cursor position, look it up in the tag file(s) and navigate to it, similar to the <tt>:ta</tt> ex command. The command also remembers the current file and position on the tag stack.

The following command uses the tag stack to go back to the previous position. Older vi's don't have it implemented:

 * ^T
 * Get the previous position and file from the tag stack and return to it. The data is removed from the file.

Command Line
Vi can also be started with a tag name instead of a file name. See the -t command line option.

Shell escape
While one is working in vi there might arise a need to run another operating system command. In these modern days this is not a big issue. One can open another terminal window and do as pleased. However, this is not necessary when working with vi. Vi, like many of the older interactive Unix tools, contains features to run operating system commands or start a command line interpreter (shell) from within the editor. This dates back to the times when there were no graphical user interfaces and an editor like vi would take up the complete screen of the terminal (a real terminal of course, not a terminal emulation). Being able to run commands from vi spares one the need to first quit the editor just to look something up, e.g. in a manual page.

In addition, vi provides features to insert the text output of other commands directly into the text under editing.

Ex Commands
The editor commands to run another command from within vi are in fact implemented as ex commands. That is, they start with the familiar ':' in command mode.

To execute one command from within vi, one would type

<CR>

At the end of the command one has to hit Return (the second <CR> shown above) to go back to vi. Vi then repaints the screen and continues where editing was left.

In order to repeat the last command, one can simply type

<CR>

It is possible to append to a previous command by using <tt>:!!</tt>, followed by whatever should be appended. For example, the second of the following two commands

<CR> :!! | more<CR> <CR>

is actually equal to

<CR>

(Note, ls is the Unix command to list a directory, more is the Unix command to paginate output, so it doesn't just scroll off the screen).

Once something is appended to a command, it becomes part of the last remembered command. So in the example above, another

<CR>

would be equal to

<CR>

and not

<CR>

Two placeholders can be used in shell escapes to denote the current file name or the name of the previously edited file name:

 * % :is a placeholder for the current file name,
 * # :is a placeholder for the previously edited file name.

For example, if one is editing some shell script and wants to try it out, one could type the following commands to save the file (<tt>:w</tt>), set the file's attributes to executable (<tt>!chmod ...</tt>), and run it (<tt>!%</tt>):

:!chmod 755 %<CR> <CR> :!%<CR> <CR>

If the file's name is, e.g. script.sh, the above would be equal to typing

:!chmod 755 script.sh<CR> <CR> :!script.sh<CR> <CR>

Instead of running a command from within vi it is also possible to start the shell from within vi. vi has an own command for this, which looks up the user's default shell (e.g. the Bourne shell or the C shell) and starts it. It is important to note that a new shell is started. The user is not returned to the shell from which vi was started. The command is called :sh, and it can be used as it follows:

<ESC>:sh<CR> $ #shell commands, when done exit shells: $ exit<CR>

Vi Commands
It is possible to filter all or parts of a text currently under editing through an external program. The original text is then replaced with the output of the external command.

The classic example for this feature is the usage of the Unix text formatter fmt. vi itself doesn't have any specific formating capabilities, however, by running the text or parts of it through an external formater from within vi, the desired formatting is easily achieved.

The vi command for filtering text is <tt>!</tt> (note, as opposed to the ex shell escape command, there is no leading <tt>:</tt>). <tt>!</tt> follows the usual vi command format. So one can specify the scope to which it should apply. E.g. <tt>!!</tt> means to filter the current line, or <tt>!}</tt> means to filter the current paragraph.

The <tt>!</tt> vi command has to be followed by by the name of the external program to be used for filtering. E.g. in order to format the current paragraph with the already mentioned Unix text formatter fmt, one would type

!}fmt<CR>

<tt>!</tt> can also be used to just insert the output of some external command into the currently edited text. To do so, one would first create a new empty line (e.g. with <tt>o</tt>), and then use <tt>!!</tt> to replace the empty line with the output of a command. For example,

o<ESC>!!ls<CR>

would include a listing of the files in the current directory into the text under Unix.

Execute command from Buffer
''This module is a stub. You can help Wikibooks by fixing it.''

 * @b
 * Execute command stored in buffer b.

vi for Programmers
Classic vi provides a number of features which are useful for programmers. Vi was made by programmers for programmers -- but at a time when programming was different. Classic vi's programming support is, by today's standards, not too great, but of course still usable. And it is still more convenient to use vi for editing programming code than any of the ...pad editors like notepad (Windows) or dtpad (CDE/Motif). vi probably works best on Unix systems due to the many text filters that come with Unix and the ease with which additional special-purpose filters can be scripted.

Useful features in vi for programmers are:

Autoindent and manual Shifting of Lines
See Indenting and shifting

Modelines
Modelines to set per-language defaults - if security is not an issue (see Modelines)

Tags for Navigating
See Tags

Shell Escapes
See Shell escape

<ESC>:w<CR> :!make<CR>
 * One way to use shell escapes is to run a makefile or the compiler from within vi. It is in general a good idea to first save the current file before trying to compile it:

or <ESC>:w<CR> :!cc %<CR>

and afterwards <ESC>:w<CR> :!!<CR>

 * Another way is filter source code through an external command, e.g. through a comment-reformator for the specific language. For example, the following command will filter the current paragraph through a external comment-reformator called recomment (not a standard Unix program, but available as a separate script).

!} recomment
 * See for the recomment script for Unix.

Editing multiple Files
vi can be started with a list of files:

vi file1 file2 file3 ...

Combined with other Unix features, like file matching, this can be a powerful feature. E.g. to open all C source code, including header files in a directory (.h), the following command can be used:

vi *.[ch]

Or to find all files which contain a certain keyword and open them, something like

vi `grep -l Keyword *.txt`

can be used.

Once vi has been started with a list of files it is possible to navigate within the list with the following commands:

 * :n : next - Move to the next file in the file list
 * :rew : rewind - rewind the file list and open the first file in the list.

vi clones like vim typically provide more commands, e.g. to go back one file in the file list.

Flip between two Files
:e x.h <CR> some changes to x.h, then going back to x.c <ESC>:w<CR> :e#<CR>
 * Flip between two files using <tt>#</tt> as the name of the last file. E.g. to flip between a C source file and the corresponding header file.

 * Flipping between two files using <tt>CTRL-^</tt>. This is one of the forgotten vi commands.

The error(1) Program
The error(1) program on Unix can be used to capture error messages from compilers and later jump from error message to error message in the editor. error's way of working is archaic. It parses error messages from the compiler and inserts them as comments into the source file in which the compiler detected the error. Since error marks error messages with <tt>###</tt> and <tt>%%%</tt> in the source file, navigation can be done with vi commands like <tt>/</tt> and <tt>n</tt>.

There are two common ways to use error with vi: $ cc *.c 2>&1 | error -v # |     - the output is feed to error as input
 * 1) From outside vi and letting error start vi. error can start vi on all files which produced an error during compilation, using the <tt>-v</tt> flag:
 * 1) Notes:
 * 2)  cc    - the C compiler
 * 3)  *.c   - all C files in the current directory
 * 4)  2>&1  - Standard error output is redirected to normal standard output
 * 2. From inside vi, on the current file. First the file is saved, then it is tried to compile it, processing potential error messages with error, then the potentially changed source file is re-read (<tt>:e!</tt>), and finally the first mark is searched with <tt>/###</tt>:

first time <ESC>:w<CR> :!cc % 2>&1 | error <CR> :e! <CR> /###<CR>

and afterwards <ESC>:w<CR> :!! <CR> :e! <CR> /###<CR>

 * Note : : error is a horrible kludge and can really mess up source code and a version control system! We recommend you try it at least once and form your own opinion. Also have a look at error's man page first. vi clones like vim provide a much more sensible system. Here the editor executes the compiler (or make(1s)) and captures the output of the compiler. The information is recorded in an error message file by vim. vim then allows to navigate the source code by extracting file names and line numbers from the error message and jump to these positions. This is the same mechanism as provided by IDEs.

Macros & Shortcuts
vi's provides the <tt>:map</tt> and <tt>:map!</tt> commands to define useful shortcuts and macros, and <tt>ab</tt> to provide abbreviations.

 * Todo: Provide a few such macros?

qqI//<Esc>jq places a comment at the beginning of a line and moves down
 * Is this (above) what you mean by macro?

Overview
vi provides support for editing text files for the Unix typesetters nroff and troff. The most "common" usage for this typesetter these days is probably to write manual (man) pages for Unix applications.

The support for writing nroff/troff input text files is always active, there is no special vi mode or option which needs to be turned on. Already from this it can be concluded that there aren't too many nroff/troff specific operations in vi. In fact, vi just provides simple ways to navigate between nroff/troff paragraphs and sections. Nevertheless, these features help when editing nroff/troff files.

nroff's/troff's text file format is simple. Normal text and macros are mixed, where macros indicate how the text should be formatted. A macro starts with a '.' in column one, followed by a one or two letter macro name followed by optional macro arguments. A typical nroff/troff text file with some macros might look like:

.SH "A SECTION HEADER" Some text making up the first paragraph in the section. More text in the paragraph. .PP A new paragraph has been started. More text in this second paragraph. .PP Yet another paragraph. .\" .\" A comment infront of the next section header .\" .SH "SECTION HEADER 2" Paragraph text.

To simplify navigation in such a text file vi knows the common macro names for sections (the <tt>.SH</tt> in the above example) and paragraphs (the <tt>.PP</tt> in the example) and provides commands to move to the next/previous section. The list of macro names is configurable in vi.

Several of the common vi features also help when editing nroff/troff text. E.g. shell escapes to run the typesetter from within vi. The following will format the current file with the manual page macros:

<ESC>:w<CR> : !nroff -man % | more<CR>

Options
The following options are used to define the nroff/troff macro names as known by vi. Like all options, one changes them by using the <tt>:set</tt> ex command:

 * sections :List of macro names which vi interprets as section delimiters. Two consecutive characters in the list form one macro name. Typically, vi's default contains <tt>.SH</tt>, <tt>.NH</tt>, <tt>.H</tt>, and <tt>.HU</tt>. So the sections option reads like

sections=SHNHH HU

 * paragraphs :or
 * para :List of macro names which vi interprets as paragraph delimiters. Two consecutive characters in the list form one macro name. vi's default typically contains <tt>.IP</tt>, <tt>.LP</tt>, <tt>.PP</tt>, <tt>.QP</tt>, <tt>.PL</tt>, <tt>.Ib</tt>, <tt>.p</tt>. So the paragraphs option reads like

paragraphs=IPLPPPQPPLIbp

Vi Commands
When in command mode, the following commands relate to working on nroff/troff text:

 * [[ :Moves to the previous section.

 * ]] :Moves to the next section.

 * { :Moves to the previous paragraph.

 * } :Moves to the next paragraph.

And, for completeness:

 * ( :Moves to the previous sentence.

 * ) :Moves to the next sentence.

title: Learning the vi Editor/Details


text:
Talk:Modern Physics/Introduction to Special Relativity

Special relativity isn't that odd. Telling people it is only puts them off, and makes it harder for them to learn what is really quite simple.

We should try to sound reassuring, not scare the readers away. Carandol 12:40, 17 Jun 2004 (UTC) --

Actually my teaching experience has been the opposite:

1) People are more interested in odd things. Also there is a big difference between odd and simple.

 * Mildly odd things, which they can understand without too much effort, then move on to the next curiosity. I've put titbits in the earlier sections to quirk peoples curiosity, and encourage them to read further, but it's important not to overstate the problem, or people will be put off. Carandol

2) The biggest problem I've found in teaching special relativity is that people try to use their normal intuition, and this causes confusion. A blunt statement that your normal intuition about velocities won't work, helps a lot. Roadrunner 14:43, 17 Jun 2004 (UTC)

 * Blunt, to me, tends to convey the message, "if you don't like this, get lost." I'd rather aim for a clear but gentle statement, which tries to avoid discouraging anyone. Repeat the first few time that "classical physics gives this result, but that isn't quite right. The real answer is this" and I find people get the message. Carandol 20:57, 17 Jun 2004 (UTC)


text:
User:Kyungchoonpark

If you can read and write korean... please come and visit me~ ^^;;

CyWorld

Daum Cafe

title: User:Kyungchoonpark


text:
Talk:General Relativity/Einstein Summation Notation

I find the first example of summation confusing. I presume that in the rest of the book, the spatial part of the product will have negative signs. Maybe the expansion into component should be avoided at this point?

Bartosz, 16:54, 17 Jun 2004 (UTC)

Please clarify what is confusing and I will try to fix it. As far as the spatial parts having negative signs, I am using the standard of giving the Minkowski metric a signarure of $$(-+++)$$ (go to the main GR page and then go to the discussion-read the note about standardizing notation). So the time component will inherit the negative sign and the spatial part will have positive signs. However, in the first example in this section, the metric does not come into play (it is just a summation of numbers). -Lathem

Greek vs. Roman indices
Probably it's a good idea to include a comment in this section about the difference between Greek indices and Roman indices (one ranges from 0 to 3, the other from 1 to 3).

 * I agree completely; done.

-blathem

Identities
Could someone explain the derivations of the identities in the last section?

Also, why are both indicies in the Kroenecker delta written subscript?

__________

I actually disagree with the first identity; if i=k, but i≠j, then you have $$\delta^i_j\delta^j_k = (0)(0)$$, but $$\delta^i_k=1\,$$. It's true otherwise, however, by transitivity. And if it is using summation notation -- which, by the way, isn't exactly clear atm -- then the above case is the only case when it's true, and it seems false otherwise. Maybe someone can clarify/correct me? Anyway... The second identity is just the sum of the main diagonal. The differentiation identities say: the partial derivative of any tensor component with respect to itself is 1, and with respect to any other component is 0. Not sure how to include the explanations on the main page, but I'll leave this up here for now.

P.S. I fixed the indices. Luolimao (discuss • contribs) 23:54, 3 April 2013 (UTC)


text:
Teaching Assistant in France Survival Guide/Application

For the 2015-2016 program, approximately 1,850 people applied for roughly 1,100 available positions.This is not to say that the application process is easy, especially if you are unfamiliar with French paperwork. Don't be discouraged if there are parts of the application you do not understand. Ask your French teacher for help, or ask on the discussion page.

Note for those applying from the United Kingdom: The easiest route is via the British Council Assistantship Scheme, this requires no french paperwork. It is also worth noting are now entitled to an ERASMUS grant from the EU if you are applying through a UK University (and you are of EU nationality). This grant can be worth a lot of money, so it is well worth finding out more about it.

Technical details
The American version of the application, which is mostly in French but has some instructions specific to American assistants, is available at the French culture site.

The file is in Microsoft Word format, and it is possible to fill out almost the entire form on your computer. It's best to print the completed application in A4 size paper if you can find it; otherwise it will be shrunk to fit American paper's dimensions.

You will need a passport sized ID photo to attach to the application. Shop around a bit for these (drugstores, photo labs, copy shops…), as their prices are often unreasonable. Look for eight or more for less than $10 — you will need more photos for paperwork before and after you get to France. Remember that French passport pictures are 35mm by 45mm, not the American 2 by 2 inches. It's ok to have an American one for the application, but for later photos, they have to be French sized.

Regions
On page 10, the application asks for your “preferred geographical location.” You are allowed to specify three académies in order of preference — these educational divisions correspond with the administrative regions of France. All of them are large, and you will have no opportunity to make your request more precise. Many assistants request the Paris académie — dreaming of a glamorous life in the Marais — but are placed in some scary Paris suburb.

It's best to find an entire region that might be interesting to you. If you like mountains, select a region near the Pyrenees or the Alps. If you are attracted to Italy, Spain, Germany, Belgium, Luxembourg or Switzerland in addition to France, select a region close to the particular border. If travel is important to you, make sure you select a region that is well serviced by the SNCF (the railway).

Another consideration to take into account is the size of town/city you will be placed in. If you're placed in Paris or any other major metropolis you'll have a ready circle of fellow assistants. However, you can also be placed in a tiny village where you're the only language assistant (which can be lonely). There are three checkboxes for specifying the size of town/city on the application, from a rural town to large metropolis.

Here is a link to a well-detailed map of France.

Also, here are links to downloadable maps of the train network and TGV routes.

School level
You also must select what level of school you would like to work in. Different levels of school have different contract lengths. IUFM assistants work for 6 months; high school assistants for 7 months. Primary assistants have two options: a contract of 7 months where they work along side a French teacher, or a contract of 9 months where they are expected to plan the lessons and lead the class by themselves.

High school assistants generally speak much less French with their students and much more of the language they are teaching. If you teach in primary schools, you're likely to spend most of your 12-hour week speaking French (which can be good practice). Some high school assistants receive very little guidance from the teachers. It is not uncommon for a high school assistant to get nothing but a key to a classroom and a schedule of when they need to be there. It all depends on the individual school and the teachers there.

Acceptance
Your first acceptance letter (the lettre de présentation) only tells you which académie and school level you've been placed in, and it can come as late as mid-summer if you have previously been wait-listed (as of the 2011-12 application cycle, most acceptance e-mails seem to have gone out by late May for applicants chosen in the first 'round' of selections). Shortly afterwards, you'll receive an arrêté (administrative order) telling you in exactly which schools you've been placed. The arrêté can arrive as late as mid-August, so if you're still waiting on it as summer goes on, don't panic (yet)! Usually the TAPIF office in Washington, D.C. asks that participants who have not received arrêtés by mid-August contact them, so that they can try to track it down or at least help assistants determine the best course of action to try and get their visas and arrive in France on time. (NB: The most recent Assistant Handbook states that questions regarding the whereabouts of arrêtés will NOT be addressed before mid-August, so as hard as it might be to wait, hold off on e-mailing the program coordinator until that time. Chances are it IS on its way.)

If the first letter mentions “Toulouse,” however, don't start looking for apartments in Toulouse. Each académie is named for the largest city in the region, but only a few of the assistants in each académie will actually be assigned to schools in this 'capital' city. It is therefore best to wait until you get your specific placement to search for housing. Do, however, start looking for plane tickets.


text: Template:Teaching Assistant in France Survival Guide/TOC


text:
Teaching Assistant in France Survival Guide/Preparation

After you've received your letter of acceptance and decided once and for all to ignore the objections of your friends and family, it's time to prepare for your year abroad.

Travel dates
Before you buy tickets, you will need to decide if you want to travel around Europe before your assistantship. Although you may be anxious to tour the continent, there are a few reasons you may want to wait:
 * Your baggage for the full year is more than you will want to lug around Europe.
 * You will be living off your savings until the end of October when you receive your first salary payment.
 * You'll want to travel again during the two-week long toussaint vacation at the end of October.
 * You will need to have your arrêté de nomination and get your visa at your home (US) consulate before leaving.

If you aren't travelling beforehand, you should schedule your arrival for a few days before your contract begins. You should plan on returning from France at least a few days after the end of your contract to make sure you receive your last paycheck.

Airplane tickets
If you are not coming home for winter vacation, it may be cheapest to buy a single round trip ticket for earlier than you expect to return and then just change it once your return date is available on the airline website (depending on the airline, 9-11 months in advance.) Another possibility is to buy two roundtrip tickets and to not use the return on either of them (one-way tickets are almost always more expensive). It's difficult and expensive to find a plane ticket with a return longer than nine months, and “open return” tickets are even worse. In most cases you will be better off buying the cheapest ticket you can find for your arrival window. Having a return date that you may use to “bail out” after a month or two is not a bad idea either. StudentUniverse.com and BT-Store.com both offer cheap options for one-way tickets (just over half the cost of a round trip ticket). Better yet, buy a flexible ticket from statravel.com if it's not too much more expensive. You can't always book tickets more than six months in advance (and almost never more than 11 months), so you'll have to buy an early return ticket. But after a few months you'll be able to reschedule for April, May, or June for only the change fee ($50-$300 plus the difference between the original return flight cost and the cost of your new return flight. Keep in mind that the cost difference can be substantial, sometimes around $200 extra.)

Remember that there are several large airports in France. You can fly into Paris, Lyon, Nice, Toulouse, Bordeaux, and a few others. It's often not much more expensive to fly all the way to your region. Check train schedules and prices before you buy your plane tickets. If your academie is located near airports in another country, consider flying there instead. Flights to Brussels or Frankfurt, for example, are sometimes less expensive than flights directly into Paris.

Also, look into Prem's fares out of Paris. These are cheap train tickets that can be purchased from two weeks to two months in advance. It might be cheaper for you to fly into Paris and take a train. A Prem's fare from Paris to Toulouse or Nice can be as low as 25€.

Packing
It is hard to pack for a year in a foreign country. A rule of thumb is to lay out everything you think you need, and then get rid of half of it. Avoid bringing heavy things. Avoid bringing too much clothing. Remember that you're bound to buy quite a bit while you're in Europe. France has big, government-regulated sales two times a year (les soldes), in mid-January and early July, and are usually four to six weeks long.

If you have a digital camera, bring it. If you don't have one, and you can afford it, buy one (try Overstock). Film is expensive in France, and you'll want to take a lot of pictures of your travels and your friends. Also, MP3 players pack much better than your CD collection. Bring your mobile phone if it is GSM 900/1800 (not 1900) and will work in Europe, but leave its power adapter unless it is international (230V, you can easily buy an adapter in France for most phones). To use your GSM phone with a local subscription make sure it is not SIM-locked or network/operator locked. Don't use your US subscription, the roaming surcharge will cost you an arm and a leg, and the rest of your body. Get, for example, a prepaid local SIM card/subscription.

Be careful with WLAN equipment. France does not allow the usage of all WLAN channels in all locations or with the full transmission power or at all. The US FCC approval means nothing in France. And, at least in 2002, outdoor usage of WLAN equipment required a special license not to be issued to private persons. Make triple sure your equipment is legal in France, because some of the WLAN frequencies are used by the French military, and you might get in real serious trouble.

Here is a list of things that are more expensive or harder to find in France:

 * 1) Dental floss
 * 2) Sunscreen
 * 3) Peanut butter
 * 4) Electronic equipment
 * 5) Underwear
 * 6) Contact lens solution
 * 7) Over-the-counter medication (especially antacid)
 * 8) Blu-tack (and it's not blue here, it's yellow - le tac patafix!)

Not only is underwear expensive, but so is laundry. The more socks and underwear you have, the less often you'll have to go to the laundromat.

Bring as little as possible, because without a doubt you will bringing back much more. There is no reason to bring a heavy journal or a photo album with you. Think practically. Once you think you've packed, try walking around the block with everything. If it's too much to handle, you're bringing too much. You might be alone on a train or a bus somewhere in France. You'll be tired and hungry and it might be hot.

Do not bring your leather jacket. It rains most of the winter.

Teaching materials to bring (use your own judgment):
 * 1) Maps (one of your country is helpful), pictures, info about your hometown
 * 2) Photos of you and your family
 * 3) Restaurant menus, recipes, brochures, travel stuff about your country
 * 4) Magazines (ie Teen People, teen magazines)
 * 5) Popular music, especially with easy to understand lyrics
 * 6) High school yearbook (or copies of some pages)

You will be able to get plenty of information and lesson plan ideas over the internet, so don't overdo it, but it's always helpful to have props to use, no matter what you're teaching.

Making contact
Over the course of the summer you will likely receive further correspondence from your académie, some of it possibly from the establishment or school system where you'll be working. If someone is taking care of your lodging, this will likely be indicated.

In late August or September, someone from your school system may contact you by email to help arrange your arrival. If you don't hear from anyone, start trying to make contact yourself in September. The correspondence that you received earlier likely contains some email addresses; as much as they love paperwork and paper mail, everyone in the school administration has email. Making arrival arrangements by international post is expensive, slow, and unnecessary.

Be persistent! It's reasonable for you to expect some communication before you arrive in the country and to know whether or not you will immediately have somewhere to sleep. If emailing doesn't work, call the school and explain that you are the language assistant. And if writing emails and making phone calls in French intimidates you, remember that the alternative is walking out of a train station in France without knowing exactly where to go.