text: Prepared Statement of The Federal Trade Commission Presented by Robert Pitofsky Before The July 24, 1997 I. Introduction Mr. Chairman and members of the Subcommittee, I am pleased to appear before you today to present the testimony of the Federal Trade Commission concerning the important topic of mergers and acquisitions in the defense industry.(1) The testimony addresses the environment facing the defense industry after the Cold War, the policy implications of applying the antitrust laws to defense industry mergers, and the process by which that application takes place. This testimony will discuss what the Commission believes to be the proper role of antitrust law enforcement in the ongoing consolidation among companies that supply goods and services to the Defense Department. It will also cover the process by which the Commission identifies, investigates, and analyzes mergers(2) in order to make a determination whether it has reason to believe a particular merger will harm competition, with particular emphasis on the analysis articulated in the Merger Guidelines jointly issued by the Commission and the Department of Justice,(3) and also the role of the Defense Department in the merger review process. II. Conditions Underlying Consolidation in the Defense Industry The end of the Cold War ushered in an era of declining defense budgets and sharply reduced expenditures for military procurement, which forced deep cuts in the number and size of weapons programs. In fact, the overall U.S. defense budget has decreased from a peak of $390 billion in 1985 (in constant fiscal year 1997 dollars) to $252 billion in 1997 -- a reduction of about 35%.(4) More important from the defense contractors' perspective, however, the procurement budget has incurred the brunt of these cuts, sinking from about $125 billion (fiscal year 1997 dollars) in 1985 to about $44 billion in 1997, a 65% reduction.(5) A decline in demand of this magnitude, which occurred in an industry that had invested heavily in plants and infrastructure in the early 1980's based on expectations of continued growth in the demand for weapons and military systems, led quickly to overcapacity among defense contractors.(6) This overcapacity, in turn, contributed to excess overhead and higher costs for U.S. military programs.(7) The defense industry responded by reducing capacity through consolidation, which has resulted in a significant decline in the number of defense contractors. Defense Department officials have encouraged consolidation within the industry as an inevitable consequence of shrinking procurement budgets. It has been widely reported, for instance, that in 1993 then-Deputy Defense Secretary William Perry urged defense industry executives to combine into a few, large companies to eliminate costly overcapacity.(8) In addition, in 1994, then-Deputy Secretary of Defense John Deutch stated in testimony before the House Armed Services Committee that the Defense Department saw consolidation as "inevitable and necessary."(9) More recently, Deputy Under Secretary of Defense John Goodman reiterated the Defense Department's support for the consolidation process.(10) III. Competition Policy Concerns in Defense Industry Mergers The antitrust laws are designed to protect competition and, ultimately, consumers from the exercise of market power. Congress long ago decided that a competitive economy would provide maximum benefits for consumers in the form of lower prices, optimal quality and quantity of goods and services, and greater innovation than an economy based on government control or the accumulation of market power by private interests. Over one hundred years of experience have proved that to be correct. Thus, the Commission views the application of the antitrust laws to defense industry mergers as squarely in the public interest. Effective antitrust review by the Commission and the Department of Justice protects the Defense Department, and ultimately the American taxpayer, from the risk that a firm or group of firms could exercise market power by raising prices or reducing output, quality, service or innovation. In analyzing a proposed merger, the Commission focuses on one overriding issue: the likelihood that the transaction will harm customers in any relevant market through increased prices; lower product quantity, quality or service levels; or reduced technological innovation. Such negative effects are likely to occur when a merger results in the accumulation of market power sufficient to raise prices or reduce quality, service or innovation. If the Commission has reason to believe that a merger will create or enhance market power or facilitate its exercise, and there are no countervailing considerations, it is authorized to seek an injunction in federal court to block the merger or to fashion a remedy that will eliminate the competitive problem. If anticompetitive effects are not likely, the Commission will not challenge the transaction. The framework used by the Commission to analyze mergers is set out in the joint Department of Justice and Federal Trade Commission Merger Guidelines. The Guidelines are a flexible tool designed to be used in all kinds of industries. They anticipate that particular industries have structural and behavioral characteristics that distinguish them from other industries, and provide an analytical framework that takes these characteristics into account. The characteristics of the defense industry fit into the framework of the Guidelines' analysis, leading a Defense Science Board Task Force that analyzed the application of the antitrust laws to defense industry mergers to conclude that "current antitrust law and enforcement, including the exercise of prosecutorial discretion by the federal antitrust enforcement agencies, is sufficiently flexible to take these important differences into account."(11) The analysis of mergers in the defense industry is challenging because of the special characteristics of the industry. The Defense Department is often the only buyer for the products and services of the merging firms, and its procurement processes are different from those in most industries. The products (e.g., weapons systems) being procured are often complex and heterogeneous systems that are frequently purchased on a winner-take-all basis, making cartel behavior less likely. Finally, national security may be implicated in a defense industry merger. This final point requires further emphasis. The Commission is sensitive to considerations of national security and in particular that a merger will enable the Defense Department to achieve its national security objectives in a more effective manner. The Commission strongly believes, however, that competition produces the best goods at the lowest prices and is also most conducive to innovation. We believe that there is generally no conflict between antitrust enforcement and national security. The following testimony will review the analytical framework of the Merger Guidelines and explain how that framework applies to defense industry mergers. IV. Analytical Framework a. Market Definition The first step in analyzing any merger is to determine where the potential anticompetitive effects will be felt. This requires defining both relevant product and geographic markets and assessing the impact of the merger on the structure and behavior of those markets. The Commission may need to look at a number of potential markets in any one merger. For instance, if both merging firms make missiles, aircraft, and submarines, the Commission would look at all three of those weapons systems to see if they qualify as relevant product markets. Intermediate products also can constitute relevant markets. Components (such as electronic systems), supplies (such as ammunition), or services (such as systems engineering and technical services) can also be relevant markets. A relevant product market is one in which many consumers of the product would not switch to an alternative product if the price of the first product were increased by a small but significant amount. In this scenario, a monopolist producer of the relevant product would be said to possess market power because it would have the ability to raise prices profitably without fear of losing business to other products. Once one or more product markets have been defined, we know where to look for the potential exercise of market power by the post-acquisition firm. In the defense industry, relevant product markets may consist of an existing product, such as tank ammunition, or of the development effort for a future weapon system, such as the design and development of the next generation of tactical aircraft. The "missions" for which the weapons systems are designed will often establish the parameters of the relevant market. For instance, tactical and strategic missile systems are unlikely to be substitutes for one another and therefore are unlikely to be in the same relevant market. In determining the weapon systems that effectively compete with each other, the Commission collects information from a variety of sources. The records of the merging companies provide substantial information, including detailed descriptions of their respective products and the kinds of products that the companies consider to be alternatives.(12) The Commission also interviews other industry participants, such as competitors and potential competitors, as well as suppliers to the companies. We also obtain information from the customers of the merging parties. In the defense industry, this always includes the Defense Department, which has substantial information on the products the companies produce and the technical capabilities of each as well as alternative products. For example, if the potential relevant product market is the research effort to design a new weapon system, the Defense Department, as sole purchaser of that effort, is likely to have information that will enable the Commission to identify the firms capable of participating in that market. Identifying a relevant geographic market requires a similar analysis. The Commission attempts to identify alternative suppliers in other geographic areas to which customers could turn if prices rose in the relevant product market. In the defense industry, the relevant geographic market almost always encompasses the entire United States. The inquiry typically is whether foreign firms should also be included. In certain instances, the Defense Department limits bidders for contracts to U. S. firms. In other instances, no foreign firms may be capable of producing or designing the product. For those cases, the relevant geographic market is limited to the United States. Once the relevant markets have been determined, the Commission must identify the participants and their market shares. Market participants include firms that currently sell in the market and firms that could enter relatively quickly and easily. The same sources of information that the Commission uses to define the relevant markets can also be used to identify the actual and potential participants. A market that is divided evenly among many participants will rarely be susceptible to abuse of market power. Conversely, in a market with only a few participants, the elimination of one of them through merger may substantially increase the risk of anticompetitive effects. The analysis requires more than a simple counting procedure. In rapidly changing industries, such as the defense industry, historical market share statistics may provide an incomplete or inaccurate picture of competitive conditions. Because of declining demand, the nature of the procurement process, and the technological complexity of many new weapons systems, the analysis of current market indices in the defense industry must be supplemented by a forward-looking analysis of the relative cost structures and technological capabilities of the market participants. For any number of reasons, historically strong performers may not be effective competitors in the future. Conversely, a small company that in the past was not a competitive factor may possess new technology that will enable it to capture major contracts in the future. b. Conditions of Entry Once the Commission has defined the relevant market and its participants, it must assess the conditions of entry into that market. If entry is easy, post-merger market participants likely will be unable profitably to increase prices above the pre-merger level. According to the Merger Guidelines, entry is regarded as easy if it would be "timely, likely and sufficient in its magnitude, character and scope to deter or counteract the competitive effects of concern."(13) In terms of timeliness, the Commission generally uses a two year period. If entry takes longer than that, current market participants may not be deterred from raising prices in the interim. In addition, entry that may occur in the distant future is more uncertain and may not occur at all. In the defense industry, however, the entry period may be shortened or lengthened depending on scheduled procurements. For instance, if the merging parties competed to build fighter aircraft and the next major fighter procurement was scheduled to take place in six months, potential entrants would probably be limited to those companies planning or able to bid in six months' time. The likelihood of entry depends on whether the potential entrant would find it profitable to enter after the acquisition. Sufficiency of entry is determined by the ability of new entrants to force a roll back of prices that may have increased after the acquisition. Entry analysis in the defense industry may be different in one respect from that applied in other industries. The Defense Department has sometimes provided financial or other assistance to encourage entry by private firms. At other times, the Department has entered into the supply of defense-related products or services on its own. Thus, the Department may be uniquely positioned to provide information about entry conditions and potential participants. This information will be considered with that more routinely collected from the merging parties and knowledgeable third parties in order to make the proper determination of the probability of timely, likely and sufficient entry. c. Competitive Effects Once the Commission has collected the necessary information on the relevant markets and entry conditions, it must decide whether it has reason to believe that the merger is likely to have anticompetitive effects. That question is likely to be answered in the affirmative if the merger allows the merging firms or post-merger participants in the relevant market to exercise market power. Market power can be exercised by a price increase or can affect non-price aspects of competition, such as product quality, innovation, service and timely and efficient performance of contractual obligations. In the defense industry, these non-price indicators may be as important as, or even more important than, price. Merger analysis focuses primarily on the potential of the post-merger firms to lessen competition through unilateral competitive effects or coordinated interaction, either tacitly or through overt collusion. In the defense industry, unilateral anticompetitive effects may be more likely than coordinated interaction.(14) Unilateral effects can occur if the merging firms can raise prices without the cooperation of other industry participants. The majority of recent merger challenges in the defense industry have been based on a unilateral anticompetitive effects theory. Two scenarios of competitive harm are typical in the defense industry: where the merging parties are the only capable bidders for an upcoming procurement(15) and where the merging parties are the best two potential bidders in terms of cost, technology, or other competitively significant factors.(16) d. Efficiencies The determination that a merger may have anticompetitive effects typically does not end the Commission's inquiry. The primary benefit of mergers to the economy is their potential to create economic efficiencies that can increase competition and lead to lower costs, lower prices and increased quality to customers.(17) The smaller the potential for anticompetitive effects, the greater a role potential efficiencies will play in the Commission's analysis of a transaction. Some of the efficiencies we might recognize include economies of scale, integration of production facilities, enhanced research and development capability, plant specialization and lower transportation costs. Not every efficiency that will lower costs to the merging parties is a cognizable antitrust efficiency. The Commission will consider only efficiencies that benefit consumers. Thus, the parties must show that potential efficiencies will be greater than the likely anticompetitive effects of the merger, are unlikely to be accomplished in the absence of either the proposed merger or another means having comparable anticompetitive effects, and are likely to occur. The Commission's experience is that efficiency claims rarely justify mergers to monopoly or near monopoly. The requirement that efficiencies are likely to occur is difficult to fulfill. Efficiencies are easy to claim but the likelihood of such efficiencies is difficult to demonstrate. Most of the information on efficiencies will be in the hands of the merging parties, who may make broad estimates of cost savings. Nevertheless, the Commission is experienced in analyzing efficiency claims and has developed a number of methods of verifying such claims. The Commission typically contacts other participants in the market who have achieved, or attempted to achieve, efficiencies through similar transactions. We also seek information from firms that have tried to achieve similar efficiencies through less anticompetitive means, such as joint ventures or temporary teaming arrangements. Customers, such as the Defense Department, are also good sources of information regarding potential efficiencies because of their experience as purchasers from the merging firms and in the industry generally. e. Vertical Mergers The discussion so far has focused on horizontal mergers between direct competitors. Anticompetitive effects may also occur through vertical mergers that combine a customer and a supplier. The framework for analysis of vertical mergers is similar to that of horizontal mergers with some additional analysis of the unique competitive effects that may be present in a vertical merger. Such a merger is examined to determine, among other things, whether the transaction is likely to raise barriers to entry to potential competitors, foreclose rivals from access to critical components, or create the potential for anticompetitive exchanges of information. Analytical differences in horizontal and vertical mergers can be seen most easily in the types of remedies the Commission typically imposes in such cases. Horizontal mergers can often be cured of their anticompetitive potential by divestiture of certain assets that would leave the remaining post-merger firm unable to exercise unjustified market power. In vertical mergers, including a number of recent defense industry mergers, the Commission has imposed conduct remedies sufficient to eliminate potential anticompetitive effects. For instance, where vertical mergers create a concern over the transfer of competitively sensitive information, "firewalls" have been imposed to prevent the exchange of a competitor's proprietary information within the different divisions of the combined firm. V. Commission Investigations of Defense Mergers The antitrust enforcement agencies review mergers and acquisitions involving defense firms to analyze whether any transaction is likely to diminish price or technology competition for any military program. The Commission has not hesitated to challenge proposed mergers that unduly threaten the Defense Department's ability to obtain the best mix of price and quality for its military requirements. If the Commission believes that a proposed merger is likely to be anticompetitive, it may proceed in one of two ways: (1) the Commission may authorize its staff to seek a preliminary injunction in federal court to block the merger pending final appeal of an administrative complaint; or (2) the Commission and the parties to the transaction may enter into a consent agreement designed to remedy the anticompetitive aspects of the merger. The Commission in recent years obtained preliminary injunctions in district court against two defense industry mergers, Alliant Techsystems(18) and Imo Industries.(19) Both of those transactions were ultimately abandoned. More recently, the Commission investigated defense industry mergers that it had reason to believe were anticompetitive as presented, but we negotiated effective remedies that protected the Defense Department and taxpayers without blocking the entire transaction. These mergers include Lockheed's merger with Martin Marietta (1995), Hughes Aircraft's acquisition of Itek's Optical Systems Division (1996), Litton Industries' acquisition of PRC (1996), Raytheon Company's acquisition of Chrysler Technologies Holding, Inc. (1996), Lockheed Martin's acquisition of Loral (1996), and Boeing's acquisition of Rockwell's aerospace and defense businesses (1996). Lockheed's merger with Martin Marietta is an example of a defense merger in which we entered into a consent agreement to resolve a significant anticompetitive problem. This merger raised substantial antitrust concerns in the market for Space-Based InfraRed Early Warning (SBIR) Satellite Systems, a $22 billion satellite system that uses highly sophisticated electro-optical sensors to detect hostile missile launches against the United States or its allies. Lockheed and Martin Marietta were competing as prime contractors for the SBIR contract and had entered into exclusive teaming agreements with the top two sensor providers, Hughes and Northrop Grumman, respectively. Because the merger would have combined the top two SBIR teams, the Lockheed team and the Martin Marietta team, the combined Lockheed Martin would have been in a position to raise price or decrease quality unilaterally on one or both teams without fear of losing the SBIR competition. The Commission's consent order remedied the merger's anticompetitive effects by prohibiting Lockheed and Martin Marietta from enforcing their exclusive teaming agreements with Hughes and Northrop Grumman for the critical sensor components in the SBIR systems. This allowed Lockheed Martin to continue working with those teammates, but also freed Hughes and Northrop Grumman to team with additional satellite companies. As a result of the Commission's order, additional teams were formed to compete against Lockheed Martin for the Defense Department's SBIR contract. The Commission recently announced its decision not to challenge Boeing's acquisition of McDonnell Douglas, following one of the most detailed and wide-ranging investigations in the history of merger enforcement.(20) A large team of Commission attorneys, economists and accountants gathered a tremendous volume of evidence on the acquisition's potential effects on competition in the worldwide commercial aircraft industry and in military programs. On the commercial side, the Commission staff interviewed over forty airlines (including almost every U.S. carrier, large and small, and many foreign carriers), as well as other industry participants, such as regional aircraft producers and foreign aerospace companies. Staff deposed McDonnell Douglas and Boeing officials responsible for marketing commercial aircraft, assessing their firms' financial conditions, and negotiating the proposed acquisition. The Commission staff also reviewed hundreds of boxes of documents submitted by the merging companies and third parties, such as airlines and aircraft manufacturers. A majority of the Commission concluded that the acquisition would not substantially lessen competition or tend to create a monopoly in the global commercial aircraft market. On the military side, the Commission assessed the acquisition's likely impact on future prices and technology innovation for Defense Department programs where Boeing and McDonnell Douglas would be expected to compete. After receiving a significant volume of information from Boeing and McDonnell Douglas, other industry participants, and Defense Department officials, the Commission found that Boeing and McDonnell Douglas currently develop fighter aircraft and military helicopters for different missions, and there are no anticipated Defense Department procurements of fighter aircraft or military helicopters or other domestic military markets in which the two firms would likely compete. VI. Conclusion The defense industry is undergoing a period of significant consolidation, spurred in part by significant reductions in defense procurement budgets. Policy makers, however, cannot acquiesce in anticompetitive mergers. Consolidation can occur in ways that protect the major buyer of weapons systems from the creation of market power in its supplier base. The Defense Science Board Task Force concluded that "as a matter of law, as well as expertise and experience, the antitrust agencies bear responsibility for determining the likely effects of a defense industry merger on the performance and dynamics of a particular market and whether a proposed merger should be challenged on the grounds that it may violate the antitrust laws."(21) The Defense Department has had, and will continue to have, a major role in cooperating with the antitrust agencies in their analysis of the competitive implications of defense industry mergers. The Defense Department has a vast and unique array of information that is important to antitrust analysis. Over the past few years, the Defense Department has been able to assemble and convey this information to the antitrust agencies in a timely manner. Because the Defense Department is the major customer of defense industry firms, its views on the likely impact of a transaction are given great weight. Nevertheless, the final decision whether to challenge a proposed defense industry merger remains--as it must--with the antitrust enforcement agencies. Antitrust policy, including the policy of challenging consolidations that create or increase the potential for abuse of market power, is designed to apply to all industries. By promoting a competitive economy, the antitrust laws ensure that consumers will receive the best quality goods and services at the lowest prices. As the major consumer of defense industry products, the Defense Department seeks the same goals. Vigorous enforcement of the antitrust laws is thus entirely consistent with the goal of preserving a strong national defense. 1. This written statement represents the views of the Federal Trade Commission. My oral presentation and response to questions are my own, and do not necessarily represent the views of the Commission or any other Commissioner. 2. The federal antitrust laws that apply to mergers include section 5 of the Federal Trade Commission Act, section 7 of the Clayton Act, and section 1 of the Sherman Act. The Commission has enforcement authority under section 5 of the FTC Act and section 7 of the Clayton Act. Each of these statutes applies to mergers, acquisitions and cash tender offers. The term "mergers" is a shorthand for all of these types of consolidations unless the text indicates otherwise. 3. U. S. Department of Justice and Federal Trade Commission, Horizontal Merger Guidelines, 4 Trade Reg. Rep. (CCH) ¶ 13,104 (April 2, 1992), as amended, April 8, 1997. 4. Statement of John B. Goodman, Deputy Under Secretary of Defense (Industrial Affairs and Installations), Before the Subcommittee on Acquisition and Technology of the Senate Committee on Armed Services, at 2 (April 15, 1997). 5. Id. 6. Office of the Under Secretary of Defense for Acquisition & Technology, Report of the Defense Science Board Task Force on Antitrust Aspects of Defense Industry Consolidation, at 8 (April 1994) ("Task Force Report"). 7. Though excess capacity drives competitive prices down in most industries, it causes prices to increase for many military programs because contract prices for many weapons systems are based on costs. With excess capacity and declining demand, overhead costs are assigned to ever shrinking volumes, with the result that each unit of hardware gets more expensive. (Task Force Report at 8) 8. "How a Dinner Led to a Feeding Frenzy," Washington Post, July 4, 1997, at G1. 9. Defense Industry Mergers, Hearing of the Oversight and Investigation Subcommittee of the House Armed Services Committee, Statement of John Deutch (Fed. News Service, July 27, 1994). 10. Statement of John B. Goodman, Deputy Under Secretary of Defense (Industrial Affairs and Installations), before the Subcommittee on Acquisition and Technology of the Senate Committee on Armed Services, at 3 (April 15, 1997). 11. Task Force Report at 15. The Task Force was composed of defense and antitrust experts, government enforcement officials and consumer representatives, and was charged by the Under Secretary of Defense to "provide advice on how the Department of Defense can play a constructive role in antitrust review by the Department of Justice and the Federal Trade Commission of mergers and joint ventures in the defense industry." Memorandum for Chairman, Defense Science Board from Task Force Chairman Robert Pitofsky, at 1 (March 24, 1994). The Task Force recommended that the Defense Department develop an institutional capacity to collect and transmit information and its views on the competitive consequences of a merger to the antitrust agencies. Id. Since the issuance of the Task Force Report, the Federal Trade Commission and the Antitrust Division of the Department of Justice have received the extensive analysis of the Department of Defense on numerous proposed mergers. 12. Pursuant to the Hart-Scott-Rodino Antitrust Improvements Act of 1976, 15 U.S.C. § 18a, the parties to mergers that meet specified thresholds are required to file certain information with the antitrust agencies and refrain from consummating the transaction for 30 days (15 days for a cash tender offer). If the information indicates that the merger may have potential anticompetitive effects, the agency reviewing the transaction may request additional information from the parties, extending the waiting period for 20 days (10 days for a cash tender offer) following compliance by the parties with the requests for additional information. 13. Horizontal Merger Guidelines, at § 3.0. 14. That does not mean that coordinated effects are invariably unlikely. For example, in 1994, the Justice Department secured a consent decree in a case where the only two competitors for a competition teamed together to submit a joint bid. United States v. Alliant Techsystems Inc., 1994-1 Trade Cas. (CCH) ¶ 70,595 (C.D. Ill. 1994). 15. See FTC v. Alliant Techsystems Inc., 808 F. Supp. 9 (D.D.C. 1992). 16. See FTC v. Imo Industries Inc., 1992-2 Trade Cas. (CCH) ¶ 69,943 (D.D.C. Nov. 22, 1989)(redacted memorandum opinion). 17. Horizontal Merger Guidelines, at § 4.0. 18. 808 F. Supp. 9 (D.D.C. 1992). 19. 1992-2 Trade Cas. (CCH) ¶ 69,943 (D.D.C. Nov. 22, 1989). 20. Four Commissioners explained their decision not to challenge the merger in a majority statement. See Statement of Chairman Robert Pitofsky and Commissioners Janet D. Steiger, Roscoe B. Starek, III and Christine A. Varney in the Matter of The Boeing Company/McDonnell Douglas Corporation, File No. 971-0051 (July 1, 1997). Commissioner Mary L. Azcuenaga issued a separate statement, disagreeing, in part, with the majority's conclusions. See Statement of Mary L. Azcuenaga, File No. 971-0051 (July 1, 1997). 21. Task Force Report at 38. |


text:
0cart: $0.00
Sort By:
Relevance Popularity Top Rated Name Low Price High Price
16 Per Page 48 Per Page 96 Per Page
Viewing Page 1 of 1
Festive Hanukkah - Lunch Napkins
In stock, ready to ship!
Old Price: $3.49
Our Price: $1.69
Festive Hanukkah Dinner Plates
Our Price: $2.99
Festive Hanukkah Dessert Plates
Festive Hanukkah Plastic Tablecover
Old Price: $5.49
Our Price: $2.29
Hanukkah Cutouts
Retail Value: $4.99
Old Price: $3.99
Our Price: $1.99
Festive Hanukkah 9 oz. Cups
Our Price: $0.59
Hanukkah Activity Peel 'N Place
Festive Hanukkah - Beverage Napkins
Old Price: $2.99
Our Price: $1.39
Star of David Photo / Balloon Holder
Hanukkah Playful Menorah - Lunch Napkins
Our Price: $1.79
Hanukkah Playful Menorah 9 oz. Paper Cups
Hanukkah Playful Menorah - Beverage Napkins
Hanukkah Playful Menorah Paper Tablecover
Menorah Window Poster
Old Price: $14.99
Our Price: $9.99
Star of David Confetti
Hanukkah Foil Menorah Silhouette
Old Price: $1.99
Our Price: $0.89
Hanukkah Playful Menorah - Foil Balloon
Retail Value: $2.99
Old Price: $2.39
© CelebrateExpress.com. All Rights Reserved.CEWEB02

subset: commoncrawl


text:
Do you have old audio gear you need to get rid of? Gather all your gear and bring it to Parts Express during the Midwest Audio Fest on July 14th for an Audio Swap Meet! Everyone is welcome to buy and swap anything and everything that's of interest to other electronic and audio enthusiasts, because it's a treasure to someone! Space is limited, register today!
Register at http://midwestaudiofest.com/index.php


text:
Do you have a question? Chat with Us Live
Engrave & Ship Same Day! Approve your standard order proof by 3pm ET and we'll engrave and ship same day! Standard orders approved after 3pm ET will ship the following day. Same-day shipping does not apply to custom orders.
All of our in-stock items ship the same day you order if your order is placed by 6 p.m. ET. Engrave & Ship today items will be shipped out the same day if personalization is approved by 3pm ET. Delivery to the 48 contiguous states takes 2-5 business days. Delivery to Hawaii, Alaska and Puerto Rico takes 5-7 business days. We will not deliver to a Post Office box.
We stand behind our products, period. If you need to return an unused stock product, we'll be happy to credit your account, exchange the item or give you a merchandise refund if returned within 30 days from receipt of your order.
(based on 2 reviews)
Ratings Distribution
5 Stars
4 Stars
3 Stars
2 Stars
1 Stars
Reviewed by 2 customers
Sort by
Displaying reviews 1-2
Back to top
Great holiday gift for the staff
By Jen
from Springfield, IL
About Me Executive Assistant, Marketing Assistant
Best Uses
Comments about Baudville Spinner Ornament - Snowman Hat: Thanks to You:
We ordered these as holiday gifts for our staff, and they turned out great. The ornaments are beautiful and good quality pieces. I loved the little keepsake box each one came in! We had them engraved with our company logo and the year. We wanted something to commemorate a fantastic year for our business and the teamwork demonstrated by our staff - these ornaments fit the bill.
A sentimental keepsake
By Mellie
from Nsw, Australia
An ornament to thank a teacher that is far better than any Xmas bauble! Putting a personalised message on the back adds to making it a treasured keepsake.
Want this item customized with your logo or organization's name?


text:
Often compared to Alexis Texas Alexis Texas because shes a bubble butt whooty pawg from Texas and a blonde with ass and does do nasty anal. However unlike Alexus Texas she does black dick and doesnt say NO to interracial. ( I mean seriously does it really matter what color the dick is going into you? at the end of the day your prostitute whore for pay anyway) Look at her from the front and she looks like a regular white trailer park ho, but turn her around and you will see that ass on swole like whoa. her other name is mariah kiss. (hey its a porn thing to have numerous alias to appeal to different audiences) she knows how to used it in hardcore porn including interracial. shes also starred in Deep Tushy Massage, Buttmans League, and Squirt class. Hey Squirt is like Autotune in the music biz. everybody wants to do it.. fantastic this is what hardcore porn is supposed to be. hoes with big juicy asses fucking EVERYBODY and everything on film for you to fap off to! I know i will Im weak for big bootie blondes that take anal wreakage. doggystyle! thanks to azz overload dot net!
Also See
Sex Tape Blogs
Amatuer Sex Flicks
Big Tits Round Asses
Tumblr XXX
Mexican Lust
Black Fucking White
Meet Real Pussy In Your City
Adult Friend Finder
Cam Crush
Naked Dot Com


text: I don't believe in changing adult people's behaviors except for traumatic events. And trying to change your boss's behavior is often a very bad approach based on expectations that will never come true. I think that some relationships will never work so there is no use to try to fix them.


text:
You must login before you can run this tool.
SCHEDULED MAINTENANCE - nanoHUB.org will be completely unavailable on Wednesday, December 11, 2013 from 7AM EST (12:00 UTC) to approximately 6PM EST (23:00 UTC) for significant hardware and software upgrades. Please plan accordingly and watch this space for further information. We apologize for any inconvenience.
Find information on common issues.
Ask questions and find answers from other users.
Suggest a new site feature or improvement.
Check on status of your tickets.
A computational model for the thermal interaction between laser light and an atomic force microscope (AFM) cantilever.


text:
I have been learning from tutorials on lynda.com as hwo to use dreamweaver. When I first purchased it I didnt think it would be such an advanced program. Its certainly not one you can start suing straight away. I am thinking whether I should use html5 or not? All the tutorials on lynda.com are on html5 and none on the old html or xhtml 1.0 transitional. I am purely thinking from an SEO point of view as the word I am targetting the top person in google is using xhtml 1.0 transitional. Would appreciate any input from experts. Thanks again for all the help. Iv learnt a lot using this site alone
You can use the html5 doctype now without any problems across all browsers. The problems start when one has to support IE8 or older, as these browsers do not recognize any of the html5 specific mark-up. One can use the html5 shiv for this, which makes it possible to style the html5 semantic mark-up but the shiv itself does not provide any of the html5 api functionality.
From an SEO point of view html5 is a much better alternative than the old html/xhtml mark-up, as it provides much richer features for the search engines to use when indexing the site.
IE8 has very good support for css 2.1, but none for css3, so providing you layout your page using css2.1 it will look the same as in other browsers. The differences will happen when you start to apply and css3 to the layout, but providing one is aware that the css3 will not work in IE8 or below, any other differences will be minimal.
You are encouraged to learn HTML5 and CSS3. Go ahead jump in the water, the water is fine.
As you know, HTML and CSS evloves. Now that HTML5 and CSS3 has arrived. It is more simpler and more pleasant experience in terms of "ONE" web platform regardless (ONE means ONE website) and the website can be viewed seamlessly (almost effortlessly)... UNLESS if you know HTML and CSS inside out. By getting both of your hands dirty under the hood of HTML5 and CSS3, it can be done. It takes lot of practice, practice and practice. AND lots of patience. Perhaps lots of coffee.
Have a look and research on topic "responsive web design" on Google.
Also media queries on Google and on Adobe website at Dreamweaver Developer Center and other links referred by Google search queries.
Like I said, go ahead dive in and water is fine.


text:
From: | Stefan Monnier |
Subject: | [Emacs-diffs] /srv/bzr/emacs/emacs-23 r100281: * doc/lispref/modes.texi (Auto-Indentation): New section to document SMIE. |
Date: | Tue, 07 Dec 2010 14:44:38 -0500 |
User-agent: | Bazaar (2.0.3) |
------------------------------------------------------------ revno: 100281 committer: Stefan Monnier <address@hidden> branch nick: emacs-23 timestamp: Tue 2010-12-07 14:44:38 -0500 message: * doc/lispref/modes.texi (Auto-Indentation): New section to document SMIE. (Major Mode Conventions): * doc/lispref/text.texi (Mode-Specific Indent): Refer to it. modified: doc/lispref/ChangeLog doc/lispref/modes.texi doc/lispref/text.texi
=== modified file 'doc/lispref/ChangeLog' --- a/doc/lispref/ChangeLog 2010-12-04 16:01:30 +0000 +++ b/doc/lispref/ChangeLog 2010-12-07 19:44:38 +0000 @@ -1,3 +1,9 @@ +2010-12-07 Stefan Monnier <address@hidden> + + * modes.texi (Auto-Indentation): New section to document SMIE. + (Major Mode Conventions): + * text.texi (Mode-Specific Indent): Refer to it. + 2010-12-04 Eli Zaretskii <address@hidden> * display.texi (Other Display Specs): Document left-fringe and @@ -12,8 +18,8 @@ 2010-11-21 Chong Yidong <address@hidden> - * nonascii.texi (Converting Representations): Document - byte-to-string. + * nonascii.texi (Converting Representations): + Document byte-to-string. * strings.texi (Creating Strings): Don't mention semi-obsolete function char-to-string. @@ -44,8 +50,8 @@ * customize.texi (Composite Types): Lower-case index entry. - * loading.texi (How Programs Do Loading): Document - load-file-name. (Bug#7346) + * loading.texi (How Programs Do Loading): + Document load-file-name. (Bug#7346) 2010-11-10 Glenn Morris <address@hidden> @@ -152,8 +158,8 @@ * keymaps.texi (Menu Bar): Document :advertised-binding property. - * functions.texi (Obsolete Functions): Document - set-advertised-calling-convention. + * functions.texi (Obsolete Functions): + Document set-advertised-calling-convention. * minibuf.texi (Basic Completion): Document completion-in-region. (Programmed Completion): Document completion-annotate-function. @@ -278,8 +284,8 @@ * minibuf.texi (Basic Completion): 4th arg to all-completions is obsolete. - * processes.texi (Process Buffers): Document - process-kill-buffer-query-function. + * processes.texi (Process Buffers): + Document process-kill-buffer-query-function. 2009-12-05 Glenn Morris <address@hidden> @@ -726,8 +732,8 @@ (Suspending Emacs): Mark suspend-emacs as a command. (Processor Run Time): Mark emacs-uptime and emacs-init-time as commands. - (Terminal Output): Remove obsolete function baud-rate. Document - TERMINAL arg for send-string-to-terminal. + (Terminal Output): Remove obsolete function baud-rate. + Document TERMINAL arg for send-string-to-terminal. * nonascii.texi (Terminal I/O Encoding): Document TERMINAL arg for terminal-coding-system and set-terminal-coding-system. @@ -831,8 +837,8 @@ 2009-05-09 Eli Zaretskii <address@hidden> * nonascii.texi (Default Coding Systems): Document - find-auto-coding, set-auto-coding, and auto-coding-alist. Add - indexing. + find-auto-coding, set-auto-coding, and auto-coding-alist. + Add indexing. (Lisp and Coding Systems): Add index entries. 2009-05-09 Martin Rudalics <address@hidden> @@ -874,8 +880,8 @@ 2009-04-22 Chong Yidong <address@hidden> - * os.texi (Command-Line Arguments): Document - command-line-args-left. + * os.texi (Command-Line Arguments): + Document command-line-args-left. (Suspending Emacs): Adapt text to multi-tty case. Document use of terminal objects for tty arguments. (Startup Summary): Add xref to Session Management. @@ -951,13 +957,13 @@ 2009-04-09 Chong Yidong <address@hidden> * text.texi (Yank Commands): Note that yank uses push-mark. - (Filling): Clarify REGION argument of fill-paragraph. Document - fill-forward-paragraph-function. + (Filling): Clarify REGION argument of fill-paragraph. + Document fill-forward-paragraph-function. (Special Properties): Remove "new in Emacs 22" declaration. (Clickable Text): Merge with Links and Mouse-1 node. - * display.texi (Button Properties, Button Buffer Commands): Change - xref to Clickable Text. + * display.texi (Button Properties, Button Buffer Commands): + Change xref to Clickable Text. * tips.texi (Key Binding Conventions): Change xref to Clickable Text. @@ -1019,8 +1025,8 @@ 2009-03-29 Chong Yidong <address@hidden> - * help.texi (Accessing Documentation, Help Functions): Remove - information about long-obsolete Emacs versions. + * help.texi (Accessing Documentation, Help Functions): + Remove information about long-obsolete Emacs versions. * modes.texi (Mode Line Variables): The default values of the mode line variables are now more complicated. @@ -1063,8 +1069,8 @@ 2009-03-23 Chong Yidong <address@hidden> * minibuf.texi (Intro to Minibuffers): Remove long-obsolete info - about minibuffers in old Emacs versions. Copyedits. Emphasize - that enable-recursive-minibuffers defaults to nil. + about minibuffers in old Emacs versions. Copyedits. + Emphasize that enable-recursive-minibuffers defaults to nil. (Text from Minibuffer): Simplify introduction. 2009-03-22 Alan Mackenzie <address@hidden> @@ -1118,8 +1124,8 @@ * customize.texi (Common Keywords): It's not necessary to use :tag to remove hyphens, as custom-unlispify-tag-name does it automatically. - (Variable Definitions): Link to File Local Variables. Document - customized-value symbol property. + (Variable Definitions): Link to File Local Variables. + Document customized-value symbol property. (Customization Types): Move menu to end of node. 2009-03-10 Chong Yidong <address@hidden> @@ -1230,8 +1236,8 @@ * text.texi (Commands for Insertion): * commands.texi (Event Mod): * keymaps.texi (Searching Keymaps): - * nonascii.texi (Translation of Characters): Reinstate - documentation of translation-table-for-input. + * nonascii.texi (Translation of Characters): + Reinstate documentation of translation-table-for-input. (Explicit Encoding): Document the `charset' text property produced by decode-coding-region and decode-coding-string. @@ -1260,8 +1266,8 @@ 2009-01-22 Chong Yidong <address@hidden> * files.texi (Format Conversion Piecemeal): Clarify behavior of - write-region-annotate-functions. Document - write-region-post-annotation-function. + write-region-annotate-functions. + Document write-region-post-annotation-function. 2009-01-19 Chong Yidong <address@hidden> @@ -1328,8 +1334,8 @@ * processes.texi (Serial Ports): Improve wording, suggested by RMS. - * nonascii.texi (Lisp and Coding Systems): Document - inhibit-null-byte-detection and inhibit-iso-escape-detection. + * nonascii.texi (Lisp and Coding Systems): + Document inhibit-null-byte-detection and inhibit-iso-escape-detection. (Character Properties): Improve wording. 2009-01-09 Chong Yidong <address@hidden> @@ -1337,8 +1343,8 @@ * display.texi (Font Lookup): Remove obsolete function x-font-family-list. x-list-fonts accepts Fontconfig/GTK syntax. (Low-Level Font): Rename from Fonts, move to end of Faces section. - (Font Selection): Reorder order of variable descriptions. Minor - clarifications. + (Font Selection): Reorder order of variable descriptions. + Minor clarifications. * elisp.texi (Top): Update node listing. @@ -1359,8 +1365,8 @@ * elisp.texi: Update node listing. * display.texi (Faces): Put Font Selection node after Auto Faces. - (Face Attributes): Don't link to Font Lookup. Document - font-family-list. + (Face Attributes): Don't link to Font Lookup. + Document font-family-list. (Fonts): New node. 2009-01-08 Jason Rumney <address@hidden> @@ -1588,8 +1594,8 @@ * windows.texi (Window Hooks): Remove *-end-trigger-functions vars, which are obsolete. Mention jit-lock-register. - * modes.texi (Other Font Lock Variables): Document - jit-lock-register and jit-lock-unregister. + * modes.texi (Other Font Lock Variables): + Document jit-lock-register and jit-lock-unregister. * frames.texi (Color Parameters): Document alpha parameter. @@ -1661,8 +1667,8 @@ 2008-11-01 Eli Zaretskii <address@hidden> * nonascii.texi (Text Representations): Rewrite to make consistent - with Emacs 23 internal representation of characters. Document - `unibyte-string'. + with Emacs 23 internal representation of characters. + Document `unibyte-string'. 2008-10-28 Chong Yidong <address@hidden> @@ -1775,8 +1781,8 @@ * processes.texi (Synchronous Processes): Document `process-lines'. - * customize.texi (Variable Definitions): Document - `custom-reevaluate-setting'. + * customize.texi (Variable Definitions): + Document `custom-reevaluate-setting'. 2008-10-18 Martin Rudalics <address@hidden> @@ -1792,13 +1798,13 @@ * maps.texi (Standard Keymaps): Document `multi-query-replace-map' and `search-map'. - * searching.texi (Search and Replace): Document - `replace-search-function' and `replace-re-search-function'. + * searching.texi (Search and Replace): + Document `replace-search-function' and `replace-re-search-function'. Document `multi-query-replace-map'. * minibuf.texi (Text from Minibuffer): Document `read-regexp'. - (Completion Commands, Reading File Names): Rename - `minibuffer-local-must-match-filename-map' to + (Completion Commands, Reading File Names): + Rename `minibuffer-local-must-match-filename-map' to `minibuffer-local-filename-must-match-map'. (Minibuffer Completion): The `require-match' argument to `completing-read' can now have the value `confirm-only'. @@ -2143,7 +2149,7 @@ 2007-12-30 Richard Stallman <address@hidden> - * commands.texi (Accessing Mouse): Renamed from Accessing Events. + * commands.texi (Accessing Mouse): Rename from Accessing Events. (Accessing Scroll): New node broken out of Accessing Mouse. 2007-12-28 Richard Stallman <address@hidden> @@ -2187,8 +2193,8 @@ 2007-11-29 Glenn Morris <address@hidden> - * functions.texi (Declaring Functions): Add findex. Mention - `external' files. + * functions.texi (Declaring Functions): Add findex. + Mention `external' files. 2007-11-26 Juanma Barranquero <address@hidden> @@ -2315,8 +2321,8 @@ * display.texi (Display Property): Explain some display specs don't let you move point in. - * frames.texi (Cursor Parameters): Describe - cursor-in-non-selected-windows here. Explain more values. + * frames.texi (Cursor Parameters): + Describe cursor-in-non-selected-windows here. Explain more values. * windows.texi (Basic Windows): Don't describe cursor-in-non-selected-windows here. @@ -2395,8 +2401,8 @@ 2007-08-16 Richard Stallman <address@hidden> - * processes.texi (Asynchronous Processes): Clarify - doc of start-file-process. + * processes.texi (Asynchronous Processes): + Clarify doc of start-file-process. 2007-08-08 Martin Rudalics <address@hidden> @@ -2463,8 +2469,8 @@ 2007-06-27 Richard Stallman <address@hidden> - * files.texi (Format Conversion Piecemeal): Clarify - `after-insert-file-functions' calling convention. + * files.texi (Format Conversion Piecemeal): + Clarify `after-insert-file-functions' calling convention. 2007-06-27 Michael Albinus <address@hidden> @@ -2519,8 +2525,8 @@ 2007-05-30 Nick Roberts <address@hidden> - * commands.texi (Click Events): Layout more logically. Describe - width and height. + * commands.texi (Click Events): Layout more logically. + Describe width and height. (Drag Events, Motion Events): Update to new format for position. 2007-06-02 Richard Stallman <address@hidden> @@ -2926,8 +2932,8 @@ 2007-03-05 Richard Stallman <address@hidden> - * variables.texi (File Local Variables): Update - enable-local-variables values. + * variables.texi (File Local Variables): + Update enable-local-variables values. 2007-03-04 Richard Stallman <address@hidden> @@ -2998,8 +3004,8 @@ 2007-02-03 Eli Zaretskii <address@hidden> * elisp.texi (Top): Make the detailed menu headers compliant with - Texinfo guidelines and with what texnfo-upd.el expects. Add - comments to prevent people from inadvertently modifying the key + Texinfo guidelines and with what texnfo-upd.el expects. + Add comments to prevent people from inadvertently modifying the key parts needed by `texinfo-multiple-files-update'. 2007-02-02 Eli Zaretskii <address@hidden> @@ -3086,8 +3092,8 @@ 2006-12-24 Richard Stallman <address@hidden> - * customize.texi (Variable Definitions): Document - new name custom-add-frequent-value. + * customize.texi (Variable Definitions): + Document new name custom-add-frequent-value. 2006-12-19 Kim F. Storm <address@hidden> @@ -3386,8 +3392,8 @@ 2006-09-01 Chong Yidong <address@hidden> - * buffers.texi (Buffer Modification): Document - buffer-chars-modified-tick. + * buffers.texi (Buffer Modification): + Document buffer-chars-modified-tick. 2006-08-31 Richard Stallman <address@hidden> @@ -3449,7 +3455,7 @@ 2006-08-12 Chong Yidong <address@hidden> * text.texi (Near Point): Say "cursor" not "terminal cursor". - (Commands for Insertion): Removed split-line since it's not + (Commands for Insertion): Remove split-line since it's not relevant for Lisp programming. (Yank Commands): Rewrite introduction. (Undo): Clarify. @@ -3480,7 +3486,7 @@ (Major Mode Basics): Mention define-derived-mode explicitly. (Major Mode Conventions): Rebinding RET is OK for some modes. Mention change-major-mode-hook and after-change-major-mode-hook. - (Example Major Modes): Moved to end of Modes section. + (Example Major Modes): Move to end of Modes section. (Mode Line Basics): Clarify. (Mode Line Data): Mention help-echo and local-map in strings. Explain reason for treatment of non-risky variables. @@ -3979,7 +3985,7 @@ 2006-05-25 Chong Yidong <address@hidden> - * keymaps.texi (Key Sequences): Renamed from Keymap Terminology. + * keymaps.texi (Key Sequences): Rename from Keymap Terminology. Explain string and vector representations of key sequences. * keymaps.texi (Changing Key Bindings): @@ -4028,8 +4034,8 @@ 2006-05-15 Oliver Scholz <address@hidden> (tiny change) - * nonascii.texi (Explicit Encoding): Fix - typo (encoding<->decoding). + * nonascii.texi (Explicit Encoding): + Fix typo (encoding<->decoding). 2006-05-14 Richard Stallman <address@hidden> @@ -4079,8 +4085,8 @@ 2006-05-09 Richard Stallman <address@hidden> - * variables.texi (File Local Variables): Document - safe-local-eval-forms and safe-local-eval-function. + * variables.texi (File Local Variables): + Document safe-local-eval-forms and safe-local-eval-function. 2006-05-07 Kim F. Storm <address@hidden> @@ -4564,8 +4570,8 @@ 2005-12-03 Eli Zaretskii <address@hidden> - * hooks.texi (Standard Hooks): Add index entries. Mention - `compilation-finish-functions'. + * hooks.texi (Standard Hooks): Add index entries. + Mention `compilation-finish-functions'. 2005-11-27 Richard M. Stallman <address@hidden> @@ -4788,8 +4794,8 @@ buffer-local. (Undo): Note that buffer-undo-list is buffer-local. - * windows.texi (Buffers and Windows): Document - buffer-display-count. + * windows.texi (Buffers and Windows): + Document buffer-display-count. 2005-09-06 Richard M. Stallman <address@hidden> @@ -5030,7 +5036,7 @@ * display.texi (Displaying Messages): New node, with most of what was in The Echo Area. - (Progress): Moved under The Echo Area. + (Progress): Move under The Echo Area. (Logging Messages): New node with new text. (Echo Area Customization): New node, the rest of what was in The Echo Area. Document message-truncate-lines with @defvar. @@ -6345,8 +6351,8 @@ (Scroll Bars): Add scroll-bar-mode and scroll-bar-width. (Usual Display): Move tab-width up. - * customize.texi (Variable Definitions): Replace - show-paren-mode example with tooltip-mode. + * customize.texi (Variable Definitions): + Replace show-paren-mode example with tooltip-mode. (Simple Types, Composite Types, Defining New Types): Minor cleanups. @@ -6582,8 +6588,8 @@ (Display Fringe Bitmaps): New node. (Images): Add 'Image Slices' to menu. (Image Descriptors): Add `:pointer' and `:map' properties. - (Showing Images): Add slice arg to `insert-image'. Add - 'insert-sliced-image'. + (Showing Images): Add slice arg to `insert-image'. + Add 'insert-sliced-image'. 2004-09-20 Richard M. Stallman <address@hidden> @@ -6596,8 +6602,8 @@ 2004-09-07 Luc Teirlinck <address@hidden> - * locals.texi (Standard Buffer-Local Variables): Add - `buffer-auto-save-file-format'. + * locals.texi (Standard Buffer-Local Variables): + Add `buffer-auto-save-file-format'. * internals.texi (Buffer Internals): Describe new auto_save_file_format field of the buffer structure. * files.texi (Format Conversion): `auto-save-file-format' has been @@ -6985,8 +6991,8 @@ 2004-04-05 Jesper Harder <address@hidden> - * variables.texi (Variable Aliases): Mention - cyclic-variable-indirection. + * variables.texi (Variable Aliases): + Mention cyclic-variable-indirection. * errors.texi (Standard Errors): Ditto. @@ -7165,7 +7171,7 @@ 2004-02-07 Jan Djärv <address@hidden> - * positions.texi (Text Lines): Added missing end defun. + * positions.texi (Text Lines): Add missing end defun. 2004-02-07 Kim F. Storm <address@hidden> @@ -7188,12 +7194,12 @@ read-minibuffer. (Minibuffer History): Clarify description of cons values for HISTORY arguments. - (Basic Completion): Various corrections and clarifications. Add - completion-regexp-list. + (Basic Completion): Various corrections and clarifications. + Add completion-regexp-list. (Minibuffer Completion): Correct and clarify description of completing-read. - (Completion Commands): Mention Partial Completion mode. Various - other minor changes. + (Completion Commands): Mention Partial Completion mode. + Various other minor changes. (High-Level Completion): Various corrections and clarifications. (Reading File Names): Ditto. (Minibuffer Misc): Ditto. @@ -7268,8 +7274,8 @@ * functions.texi: Various small changes in addition to the following. - (What Is a Function): `functionp' returns nil for macros. Clarify - behavior of this and following functions for symbol arguments. + (What Is a Function): `functionp' returns nil for macros. + Clarify behavior of this and following functions for symbol arguments. (Function Documentation): Add `\' in front of (fn @var{arglist}) and explain why. (Defining Functions): Mention DOCSTRING argument to `defalias'. @@ -8065,7 +8071,7 @@ 2003-01-31 Joe Buehler <address@hidden> - * os.texi (System Environment): Added cygwin system-type. + * os.texi (System Environment): Add cygwin system-type. 2003-01-25 Richard M. Stallman <address@hidden> @@ -8098,7 +8104,7 @@ * README: Target for Info file is `make info'. - * files.texi (File Name Components): Fixed typos in + * files.texi (File Name Components): Fix typos in `file-name-sans-extension'. (Magic File Names): Complete list of operations for magic file name handlers. @@ -8114,7 +8120,7 @@ 2002-08-05 Per Abrahamsen <address@hidden> - * customize.texi (Splicing into Lists): Fixed example. + * customize.texi (Splicing into Lists): Fix example. Reported by Fabrice Bauzac <address@hidden>. 2002-06-17 Juanma Barranquero <address@hidden> @@ -8154,8 +8160,8 @@ 2001-11-17 Eli Zaretskii <address@hidden> - * permute-index: Don't depend on csh-specific features. Replace - the interpreter name with /bin/sh. + * permute-index: Don't depend on csh-specific features. + Replace the interpreter name with /bin/sh. * two-volume-cross-refs.txt: New file. * two.el: New file. @@ -8293,8 +8299,8 @@ * numbers.texi (Integer Basics): Document CL style read syntax for integers in bases other than 10. - * positions.texi (List Motion): Document - open-paren-in-column-0-is-defun-start. + * positions.texi (List Motion): + Document open-paren-in-column-0-is-defun-start. * lists.texi (Sets And Lists): Document member-ignore-case. @@ -8489,7 +8495,7 @@ 1995-06-19 Richard Stallman <address@hidden> * Makefile (VERSION): Update version number. - (maintainer-clean): Renamed from realclean. + (maintainer-clean): Rename from realclean. 1995-06-07 Karl Heuer <address@hidden> @@ -8561,11 +8567,11 @@ 1991-11-26 Richard Stallman (address@hidden) - * Makefile (srcs): Added index.perm. + * Makefile (srcs): Add index.perm. (elisp.dvi): Remove erroneous shell comment. Expect output of permute-index in permuted.fns. Save old elisp.aux in elisp.oaux. - (clean): Added index.texi to be deleted. + (clean): Add index.texi to be deleted. 1990-08-11 Richard Stallman (address@hidden) === modified file 'doc/lispref/modes.texi' --- a/doc/lispref/modes.texi 2010-12-01 22:42:36 +0000 +++ b/doc/lispref/modes.texi 2010-12-07 19:44:38 +0000 @@ -24,10 +24,11 @@ * Major Modes:: Defining major modes. * Minor Modes:: Defining minor modes. * Mode Line Format:: Customizing the text that appears in the mode line. -* Imenu:: How a mode can provide a menu +* Imenu:: How a mode can provide a menu of definitions in the buffer. -* Font Lock Mode:: How modes can highlight text according to syntax. -* Desktop Save Mode:: How modes can have buffer state saved between +* Font Lock Mode:: How modes can highlight text according to syntax. +* Auto-Indentation:: How to teach Emacs to indent for a major mode. +* Desktop Save Mode:: How modes can have buffer state saved between Emacs sessions. @end menu @@ -332,7 +333,7 @@ programming language, indentation of text according to structure is probably useful. So the mode should set @code{indent-line-function} to a suitable function, and probably customize other variables -for indentation. +for indentation. @xref{Auto-Indentation}. @item @cindex keymaps in modes @@ -3214,6 +3215,665 @@ reasonably fast. @end defvar address@hidden Auto-Indentation address@hidden Auto-indention of code + +For programming languages, an important feature of a major mode is to +provide automatic indentation. This is controlled in Emacs by address@hidden (@pxref{Mode-Specific Indent}). +Writing a good indentation function can be difficult and to a large +extent it is still a black art. + +Many major mode authors will start by writing a simple indentation +function that works for simple cases, for example by comparing with the +indentation of the previous text line. For most programming languages +that are not really line-based, this tends to scale very poorly: +improving such a function to let it handle more diverse situations tends +to become more and more difficult, resulting in the end with a large, +complex, unmaintainable indentation function which nobody dares to touch. + +A good indentation function will usually need to actually parse the +text, according to the syntax of the language. Luckily, it is not +necessary to parse the text in as much detail as would be needed +for a compiler, but on the other hand, the parser embedded in the +indentation code will want to be somewhat friendly to syntactically +incorrect code. + +Good maintainable indentation functions usually fall into 2 categories: +either parsing forward from some ``safe'' starting point until the +position of interest, or parsing backward from the position of interest. +Neither of the two is a clearly better choice than the other: parsing +backward is often more difficult than parsing forward because +programming languages are designed to be parsed forward, but for the +purpose of indentation it has the advantage of not needing to +guess a ``safe'' starting point, and it generally enjoys the property +that only a minimum of text will be analyzed to decide the indentation +of a line, so indentation will tend to be unaffected by syntax errors in +some earlier unrelated piece of code. Parsing forward on the other hand +is usually easier and has the advantage of making it possible to +reindent efficiently a whole region at a time, with a single parse. + +Rather than write your own indentation function from scratch, it is +often preferable to try and reuse some existing ones or to rely +on a generic indentation engine. There are sadly few such +engines. The CC-mode indentation code (used with C, C++, Java, Awk +and a few other such modes) has been made more generic over the years, +so if your language seems somewhat similar to one of those languages, +you might try to use that engine. @c FIXME: documentation? +Another one is SMIE which takes an approach in the spirit +of Lisp sexps and adapts it to non-Lisp languages. + address@hidden +* SMIE:: A simple minded indentation engine address@hidden menu + address@hidden SMIE address@hidden Simple Minded Indentation Engine + +SMIE is a package that provides a generic navigation and indentation +engine. Based on a very simple parser using an ``operator precedence +grammar'', it lets major modes extend the sexp-based navigation of Lisp +to non-Lisp languages as well as provide a simple to use but reliable +auto-indentation. + +Operator precedence grammar is a very primitive technology for parsing +compared to some of the more common techniques used in compilers. +It has the following characteristics: its parsing power is very limited, +and it is largely unable to detect syntax errors, but it has the +advantage of being algorithmically efficient and able to parse forward +just as well as backward. In practice that means that SMIE can use it +for indentation based on backward parsing, that it can provide both address@hidden and @code{backward-sexp} functionality, and that it +will naturally work on syntactically incorrect code without any extra +effort. The downside is that it also means that most programming +languages cannot be parsed correctly using SMIE, at least not without +resorting to some special tricks (@pxref{SMIE Tricks}). + address@hidden +* SMIE setup:: SMIE setup and features +* Operator Precedence Grammars:: A very simple parsing technique +* SMIE Grammar:: Defining the grammar of a language +* SMIE Lexer:: Defining tokens +* SMIE Tricks:: Working around the parser's limitations +* SMIE Indentation:: Specifying indentation rules +* SMIE Indentation Helpers:: Helper functions for indentation rules +* SMIE Indentation Example:: Sample indentation rules address@hidden menu + address@hidden SMIE setup address@hidden SMIE Setup and Features + +SMIE is meant to be a one-stop shop for structural navigation and +various other features which rely on the syntactic structure of code, in +particular automatic indentation. The main entry point is address@hidden which is a function typically called while setting +up a major mode. + address@hidden smie-setup grammar rules-function &rest keywords +Setup SMIE navigation and indentation. address@hidden is a grammar table generated by @code{smie-prec2->grammar}. address@hidden is a set of indentation rules for use on address@hidden address@hidden are additional arguments, which can include the following +keywords: address@hidden address@hidden address@hidden:forward-token} @var{fun}: Specify the forward lexer to use. address@hidden address@hidden:backward-token} @var{fun}: Specify the backward lexer to use. address@hidden itemize address@hidden defun + +Calling this function is sufficient to make commands such as address@hidden, @code{backward-sexp}, and @code{transpose-sexps} be +able to properly handle structural elements other than just the paired +parentheses already handled by syntax tables. For example, if the +provided grammar is precise enough, @code{transpose-sexps} can correctly +transpose the two arguments of a @code{+} operator, taking into account +the precedence rules of the language. + +Calling `smie-setup' is also sufficient to make TAB indentation work in +the expected way, and provides some commands that you can bind in the +major mode keymap. + address@hidden Command smie-close-block +This command closes the most recently opened (and not yet closed) block. address@hidden deffn + address@hidden Command smie-down-list &optional arg +This command is like @code{down-list} but it also pays attention to +nesting of tokens other than parentheses, such as @code{begin...end}. address@hidden deffn + address@hidden Operator Precedence Grammars address@hidden Operator Precedence Grammars + +SMIE's precedence grammars simply give to each token a pair of +precedences: the left-precedence and the right-precedence. We say address@hidden < T2} if the right-precedence of token @code{T1} is less than +the left-precedence of token @code{T2}. A good way to read this address@hidden<} is as a kind of parenthesis: if we find @code{... T1 something +T2 ...} then that should be parsed as @code{... T1 (something T2 ...} +rather than as @code{... T1 something) T2 ...}. The latter +interpretation would be the case if we had @code{T1 > T2}. If we have address@hidden = T2}, it means that token T2 follows token T1 in the same +syntactic construction, so typically we have @code{"begin" = "end"}. +Such pairs of precedences are sufficient to express left-associativity +or right-associativity of infix operators, nesting of tokens like +parentheses and many other cases. + address@hidden ¡Let's leave this undocumented to leave it more open for change! address@hidden @defvar smie-grammar address@hidden The value of this variable is an alist specifying the left and right address@hidden precedence of each token. It is meant to be initialized by using one of address@hidden the functions below. address@hidden @end defvar + address@hidden smie-prec2->grammar table +This function takes a @emph{prec2} grammar @var{table} and returns an +alist suitable for use in @code{smie-setup}. The @emph{prec2} address@hidden is itself meant to be built by one of the functions below. address@hidden defun + address@hidden smie-merge-prec2s &rest tables +This function takes several @emph{prec2} @var{tables} and merges them +into a new @emph{prec2} table. address@hidden defun + address@hidden smie-precs->prec2 precs +This function builds a @emph{prec2} table from a table of precedences address@hidden @var{precs} should be a list, sorted by precedence (for +example @code{"+"} will come before @code{"*"}), of elements of the form address@hidden(@var{assoc} @var{op} ...)}, where each @var{op} is a token that +acts as an operator; @var{assoc} is their associativity, which can be +either @code{left}, @code{right}, @code{assoc}, or @code{nonassoc}. +All operators in a given element share the same precedence level +and associativity. address@hidden defun + address@hidden smie-bnf->prec2 bnf &rest resolvers +This function lets you specify the grammar using a BNF notation. +It accepts a @var{bnf} description of the grammar along with a set of +conflict resolution rules @var{resolvers}, and +returns a @emph{prec2} table. + address@hidden is a list of nonterminal definitions of the form address@hidden(@var{nonterm} @var{rhs1} @var{rhs2} ...)} where each @var{rhs} +is a (non-empty) list of terminals (aka tokens) or non-terminals. + +Not all grammars are accepted: address@hidden address@hidden +An @var{rhs} cannot be an empty list (an empty list is never needed, +since SMIE allows all non-terminals to match the empty string anyway). address@hidden +An @var{rhs} cannot have 2 consecutive non-terminals: each pair of +non-terminals needs to be separated by a terminal (aka token). +This is a fundamental limitation of operator precedence grammars. address@hidden itemize + +Additionally, conflicts can occur: address@hidden address@hidden +The returned @emph{prec2} table holds constraints between pairs of tokens, and +for any given pair only one constraint can be present: T1 < T2, +T1 = T2, or T1 > T2. address@hidden +A token can be an @code{opener} (something similar to an open-paren), +a @code{closer} (like a close-paren), or @code{neither} of the two +(e.g. an infix operator, or an inner token like @code{"else"}). address@hidden itemize + +Precedence conflicts can be resolved via @var{resolvers}, which +is a list of @emph{precs} tables (see @code{smie-precs->prec2}): for +each precedence conflict, if those @code{precs} tables +specify a particular constraint, then the conflict is resolved by using +this constraint instead, else a conflict is reported and one of the +conflicting constraints is picked arbitrarily and the others are +simply ignored. address@hidden defun + address@hidden SMIE Grammar address@hidden Defining the Grammar of a Language + +The usual way to define the SMIE grammar of a language is by +defining a new global variable that holds the precedence table by +giving a set of BNF rules. +For example, the grammar definition for a small Pascal-like language +could look like: address@hidden address@hidden +(require 'smie) +(defvar sample-smie-grammar + (smie-prec2->grammar + (smie-bnf->prec2 address@hidden group address@hidden + '((id) + (inst ("begin" insts "end") + ("if" exp "then" inst "else" inst) + (id ":=" exp) + (exp)) + (insts (insts ";" insts) (inst)) + (exp (exp "+" exp) + (exp "*" exp) + ("(" exps ")")) + (exps (exps "," exps) (exp))) address@hidden group address@hidden + '((assoc ";")) + '((assoc ",")) + '((assoc "+") (assoc "*"))))) address@hidden group address@hidden example + address@hidden +A few things to note: + address@hidden address@hidden +The above grammar does not explicitly mention the syntax of function +calls: SMIE will automatically allow any sequence of sexps, such as +identifiers, balanced parentheses, or @code{begin ... end} blocks +to appear anywhere anyway. address@hidden +The grammar category @code{id} has no right hand side: this does not +mean that it can match only the empty string, since as mentioned any +sequence of sexps can appear anywhere anyway. address@hidden +Because non terminals cannot appear consecutively in the BNF grammar, it +is difficult to correctly handle tokens that act as terminators, so the +above grammar treats @code{";"} as a statement @emph{separator} instead, +which SMIE can handle very well. address@hidden +Separators used in sequences (such as @code{","} and @code{";"} above) +are best defined with BNF rules such as @code{(foo (foo "separator" foo) ...)} +which generate precedence conflicts which are then resolved by giving +them an explicit @code{(assoc "separator")}. address@hidden +The @code{("(" exps ")")} rule was not needed to pair up parens, since +SMIE will pair up any characters that are marked as having paren syntax +in the syntax table. What this rule does instead (together with the +definition of @code{exps}) is to make it clear that @code{","} should +not appear outside of parentheses. address@hidden +Rather than have a single @emph{precs} table to resolve conflicts, it is +preferable to have several tables, so as to let the BNF part of the +grammar specify relative precedences where possible. address@hidden +Unless there is a very good reason to prefer @code{left} or address@hidden, it is usually preferable to mark operators as associative, +using @code{assoc}. For that reason @code{"+"} and @code{"*"} are +defined above as @code{assoc}, although the language defines them +formally as left associative. address@hidden itemize + address@hidden SMIE Lexer address@hidden Defining Tokens + +SMIE comes with a predefined lexical analyzer which uses syntax tables +in the following way: any sequence of characters that have word or +symbol syntax is considered a token, and so is any sequence of +characters that have punctuation syntax. This default lexer is +often a good starting point but is rarely actually correct for any given +language. For example, it will consider @code{"2,+3"} to be composed +of 3 tokens: @code{"2"}, @code{",+"}, and @code{"3"}. + +To describe the lexing rules of your language to SMIE, you need +2 functions, one to fetch the next token, and another to fetch the +previous token. Those functions will usually first skip whitespace and +comments and then look at the next chunk of text to see if it +is a special token. If so it should skip the token and +return a description of this token. Usually this is simply the string +extracted from the buffer, but it can be anything you want. +For example: address@hidden address@hidden +(defvar sample-keywords-regexp + (regexp-opt '("+" "*" "," ";" ">" ">=" "<" "<=" ":=" "="))) address@hidden group address@hidden +(defun sample-smie-forward-token () + (forward-comment (point-max)) + (cond + ((looking-at sample-keywords-regexp) + (goto-char (match-end 0)) + (match-string-no-properties 0)) + (t (buffer-substring-no-properties + (point) + (progn (skip-syntax-forward "w_") + (point)))))) address@hidden group address@hidden +(defun sample-smie-backward-token () + (forward-comment (- (point))) + (cond + ((looking-back sample-keywords-regexp (- (point) 2) t) + (goto-char (match-beginning 0)) + (match-string-no-properties 0)) + (t (buffer-substring-no-properties + (point) + (progn (skip-syntax-backward "w_") + (point)))))) address@hidden group address@hidden example + +Notice how those lexers return the empty string when in front of +parentheses. This is because SMIE automatically takes care of the +parentheses defined in the syntax table. More specifically if the lexer +returns nil or an empty string, SMIE tries to handle the corresponding +text as a sexp according to syntax tables. + address@hidden SMIE Tricks address@hidden Living With a Weak Parser + +The parsing technique used by SMIE does not allow tokens to behave +differently in different contexts. For most programming languages, this +manifests itself by precedence conflicts when converting the +BNF grammar. + +Sometimes, those conflicts can be worked around by expressing the +grammar slightly differently. For example, for Modula-2 it might seem +natural to have a BNF grammar that looks like this: + address@hidden + ... + (inst ("IF" exp "THEN" insts "ELSE" insts "END") + ("CASE" exp "OF" cases "END") + ...) + (cases (cases "|" cases) (caselabel ":" insts) ("ELSE" insts)) + ... address@hidden example + +But this will create conflicts for @code{"ELSE"}: on the one hand, the +IF rule implies (among many other things) that @code{"ELSE" = "END"}; +but on the other hand, since @code{"ELSE"} appears within @code{cases}, +which appears left of @code{"END"}, we also have @code{"ELSE" > "END"}. +We can solve the conflict either by using: address@hidden + ... + (inst ("IF" exp "THEN" insts "ELSE" insts "END") + ("CASE" exp "OF" cases "END") + ("CASE" exp "OF" cases "ELSE" insts "END") + ...) + (cases (cases "|" cases) (caselabel ":" insts)) + ... address@hidden example +or address@hidden + ... + (inst ("IF" exp "THEN" else "END") + ("CASE" exp "OF" cases "END") + ...) + (else (insts "ELSE" insts)) + (cases (cases "|" cases) (caselabel ":" insts) (else)) + ... address@hidden example + +Reworking the grammar to try and solve conflicts has its downsides, tho, +because SMIE assumes that the grammar reflects the logical structure of +the code, so it is preferable to keep the BNF closer to the intended +abstract syntax tree. + +Other times, after careful consideration you may conclude that those +conflicts are not serious and simply resolve them via the address@hidden argument of @code{smie-bnf->prec2}. Usually this is +because the grammar is simply ambiguous: the conflict does not affect +the set of programs described by the grammar, but only the way those +programs are parsed. This is typically the case for separators and +associative infix operators, where you want to add a resolver like address@hidden'((assoc "|"))}. Another case where this can happen is for the +classic @emph{dangling else} problem, where you will use @code{'((assoc +"else" "then"))}. It can also happen for cases where the conflict is +real and cannot really be resolved, but it is unlikely to pose a problem +in practice. + +Finally, in many cases some conflicts will remain despite all efforts to +restructure the grammar. Do not despair: while the parser cannot be +made more clever, you can make the lexer as smart as you want. So, the +solution is then to look at the tokens involved in the conflict and to +split one of those tokens into 2 (or more) different tokens. E.g. if +the grammar needs to distinguish between two incompatible uses of the +token @code{"begin"}, make the lexer return different tokens (say address@hidden"begin-fun"} and @code{"begin-plain"}) depending on which kind of address@hidden"begin"} it finds. This pushes the work of distinguishing the +different cases to the lexer, which will thus have to look at the +surrounding text to find ad-hoc clues. + address@hidden SMIE Indentation address@hidden Specifying Indentation Rules + +Based on the provided grammar, SMIE will be able to provide automatic +indentation without any extra effort. But in practice, this default +indentation style will probably not be good enough. You will want to +tweak it in many different cases. + +SMIE indentation is based on the idea that indentation rules should be +as local as possible. To this end, it relies on the idea of address@hidden indentation, which is the indentation that a particular +program point would have if it were at the beginning of a line. +Of course, if that program point is indeed at the beginning of a line, +its virtual indentation is its current indentation. But if not, then +SMIE uses the indentation algorithm to compute the virtual indentation +of that point. Now in practice, the virtual indentation of a program +point does not have to be identical to the indentation it would have if +we inserted a newline before it. To see how this works, the SMIE rule +for indentation after a @address@hidden in C does not care whether the address@hidden@{} is standing on a line of its own or is at the end of the +preceding line. Instead, these different cases are handled in the +indentation rule that decides how to indent before a @address@hidden + +Another important concept is the notion of @emph{parent}: The address@hidden of a token, is the head token of the nearest enclosing +syntactic construct. For example, the parent of an @code{else} is the address@hidden to which it belongs, and the parent of an @code{if}, in turn, +is the lead token of the surrounding construct. The command address@hidden jumps from a token to its parent, but there are +some caveats: for @emph{openers} (tokens which start a construct, like address@hidden), you need to start with point before the token, while for +others you need to start with point after the token. address@hidden stops with point before the parent token if that is +the @emph{opener} of the token of interest, and otherwise it stops with +point after the parent token. + +SMIE indentation rules are specified using a function that takes two +arguments @var{method} and @var{arg} where the meaning of @var{arg} and the +expected return value depend on @var{method}. + address@hidden can be: address@hidden address@hidden address@hidden:after}, in which case @var{arg} is a token and the function +should return the @var{offset} to use for indentation after @var{arg}. address@hidden address@hidden:before}, in which case @var{arg} is a token and the function +should return the @var{offset} to use to indent @var{arg} itself. address@hidden address@hidden:elem}, in which case the function should return either the offset +to use to indent function arguments (if @var{arg} is the symbol address@hidden) or the basic indentation step (if @var{arg} is the symbol address@hidden). address@hidden address@hidden:list-intro}, in which case @var{arg} is a token and the function +should return address@hidden if the token is followed by a list of +expressions (not separated by any token) rather than an expression. address@hidden itemize + +When @var{arg} is a token, the function is called with point just before +that token. A return value of nil always means to fallback on the +default behavior, so the function should return nil for arguments it +does not expect. + address@hidden can be: address@hidden address@hidden address@hidden: use the default indentation rule. address@hidden address@hidden(column . @var{column})}: indent to column @var{column}. address@hidden address@hidden: offset by @var{number}, relative to a base token which is +the current token for @code{:after} and its parent for @code{:before}. address@hidden itemize + address@hidden SMIE Indentation Helpers address@hidden Helper Functions for Indentation Rules + +SMIE provides various functions designed specifically for use in the +indentation rules function (several of those functions break if used in +another context). These functions all start with the prefix address@hidden + address@hidden smie-rule-bolp +Return address@hidden if the current token is the first on the line. address@hidden defun + address@hidden smie-rule-hanging-p +Return address@hidden if the current token is @emph{hanging}. +A token is @emph{hanging} if it is the last token on the line +and if it is preceded by other tokens: a lone token on a line is not +hanging. address@hidden defun + address@hidden smie-rule-next-p &rest tokens +Return address@hidden if the next token is among @var{tokens}. address@hidden defun + address@hidden smie-rule-prev-p &rest tokens +Return address@hidden if the previous token is among @var{tokens}. address@hidden defun + address@hidden smie-rule-parent-p &rest parents +Return address@hidden if the current token's parent is among @var{parents}. address@hidden defun + address@hidden smie-rule-sibling-p +Return non-nil if the current token's parent is actually a sibling. +This is the case for example when the parent of a @code{","} is just the +previous @code{","}. address@hidden defun + address@hidden smie-rule-parent &optional offset +Return the proper offset to align the current token with the parent. +If address@hidden, @var{offset} should be an integer giving an +additional offset to apply. address@hidden defun + address@hidden smie-rule-separator method +Indent current token as a @emph{separator}. + +By @emph{separator}, we mean here a token whose sole purpose is to +separate various elements within some enclosing syntactic construct, and +which does not have any semantic significance in itself (i.e. it would +typically not exist as a node in an abstract syntax tree). + +Such a token is expected to have an associative syntax and be closely +tied to its syntactic parent. Typical examples are @code{","} in lists +of arguments (enclosed inside parentheses), or @code{";"} in sequences +of instructions (enclosed in a @address@hidden@}} or @code{begin...end} +block). + address@hidden should be the method name that was passed to +`smie-rules-function'. address@hidden defun + address@hidden SMIE Indentation Example address@hidden Sample Indentation Rules + +Here is an example of an indentation function: + address@hidden +(eval-when-compile (require 'cl)) ;For the `case' macro. +(defun sample-smie-rules (kind token) + (case kind + (:elem (case token + (basic sample-indent-basic))) + (:after + (cond + ((equal token ",") (smie-rule-separator kind)) + ((equal token ":=") sample-indent-basic))) + (:before + (cond + ((equal token ",") (smie-rule-separator kind)) + ((member token '("begin" "(" "@{")) + (if (smie-rule-hanging-p) (smie-rule-parent))) + ((equal token "if") + (and (not (smie-rule-bolp)) (smie-rule-prev-p "else") + (smie-rule-parent))))))) address@hidden example + address@hidden +A few things to note: + address@hidden address@hidden +The first case indicates the basic indentation increment to use. +If @code{sample-indent-basic} is nil, then SMIE uses the global +setting @code{smie-indent-basic}. The major mode could have set address@hidden buffer-locally instead, but that +is discouraged. + address@hidden +The two (identical) rules for the token @code{","} make SMIE try to be +more clever when the comma separator is placed at the beginning of +lines. It tries to outdent the separator so as to align the code after +the comma; for example: + address@hidden +x = longfunctionname ( + arg1 + , arg2 + ); address@hidden example + address@hidden +The rule for indentation after @code{":="} exists because otherwise +SMIE would treat @code{":="} as an infix operator and would align the +right argument with the left one. + address@hidden +The rule for indentation before @code{"begin"} is an example of the use +of virtual indentation: This rule is used only when @code{"begin"} is +hanging, which can happen only when @code{"begin"} is not at the +beginning of a line. So this is not used when indenting address@hidden"begin"} itself but only when indenting something relative to this address@hidden"begin"}. Concretely, this rule changes the indentation from: + address@hidden + if x > 0 then begin + dosomething(x); + end address@hidden example +to address@hidden + if x > 0 then begin + dosomething(x); + end address@hidden example + address@hidden +The rule for indentation before @code{"if"} is similar to the one for address@hidden"begin"}, but where the purpose is to treat @code{"else if"} +as a single unit, so as to align a sequence of tests rather than indent +each test further to the right. This function does this only in the +case where the @code{"if"} is not placed on a separate line, hence the address@hidden test. + +If we know that the @code{"else"} is always aligned with its @code{"if"} +and is always at the beginning of a line, we can use a more efficient +rule: address@hidden +((equal token "if") + (and (not (smie-rule-bolp)) (smie-rule-prev-p "else") + (save-excursion + (sample-smie-backward-token) ;Jump before the "else". + (cons 'column (current-column))))) address@hidden example + +The advantage of this formulation is that it reuses the indentation of +the previous @code{"else"}, rather than going all the way back to the +first @code{"if"} of the sequence. address@hidden itemize + @node Desktop Save Mode @section Desktop Save Mode @cindex desktop save mode === modified file 'doc/lispref/text.texi' --- a/doc/lispref/text.texi 2010-12-01 22:42:36 +0000 +++ b/doc/lispref/text.texi 2010-12-07 19:44:38 +0000 @@ -2209,7 +2209,7 @@ In Lisp mode, the value is the symbol @code{lisp-indent-line}; in C mode, @code{c-indent-line}; in Fortran mode, @code{fortran-indent-line}. -The default value is @code{indent-relative}. +The default value is @code{indent-relative}. @xref{Auto-Indentation}. @end defvar @deffn Command indent-according-to-mode
[Prev in Thread] | Current Thread | [Next in Thread] |


text:
Need it by Christmas Eve?
Men's adidas Soccer Apparel
CD Guadalajara Home Jersey
Light Scarlet/White (G81610)
Size Chart
+ Save To Wishlist
Rated 5 out of 5Â by 1
Rated 5 out of 5Â by ThatSoccerGirl Love at first sight
As I waited anxiously for the jersey to come out all I hoped for was that I wouldn't be disappointed. I was not! every investment in a chivas item is worth every penny. I LOVE this jersey. The quality is amazing. It may be a little spendy, but it was worth it!
August 3, 2013
1-1 of 1


text:
Our Racing Pedigree
A History of Castrol's Passion for Racing
Castrol has consistently been at the forefront of motor racing since the sport began in the early 1900s.
Our long term technical partnership with motorcycle manufacturers and the use of the highest level of motorcycle racing as a testing ground is a very important part of our never-ending development of high quality products, both for competition racers and enthusiast bikers around the world.
Castrol's success in motorcycle racing goes back to the very beginnings of racing at the Isle of Man TT in 1907 through to the bikes in today's powerful MotoGP series.
Throughout the 1920s and 30s the sport began to gather momentum across Europe but the onset of World War 2 meant that official racing was suspended, and it wasn't restarted until 1949 when the new World championship was created. Yet throughout this time Castrol had remained close to the heart of motorcycle racing, and between1922 and 1947 all bar two Isle of Man TT winners used Castrol oil.


text:
Remember When
If the sample ballots for the November election delivered this week to Plumas County Clerk John Donnenwirth had weighed 50 pounds more, there would have been exactly a ton of them. The Plumas County Clerk's office postage bill for mailing the sample ballots to the county's 6000 voters was $158.00.
Soaking rains this week brought an end to the years high fire hazard in the Plumas National Forest. Small mudslides occurred on the Feather River Highway near Pulga and Jarbo Gap.
The Standart Mine near Greenville is milling 80 tons of ore daily. Ore is coming from a tunnel 2400 feet long, employing 30 local men.
The new Gulf Red Cedar Company being built in Greenville will produce pencil stock that will be shipped to Germany and Czecho-Slovakia.
Commercial cutting of Christmas trees in the Plumas National Forest will not be permitted this year due to scarcity of trees in the Plumas National Forest, however individual cutting will be allowed.
Plumas County Sheriff Braden was ordered by Plumas County Superior Court Judge Moncur Monday to destroy 19 slot machines that were seized in Blairsden and Portola.
The deadly blister rust, deadly to white pine trees, has gained a foothold in the Plumas National Forest. Presence of the disease was found on the underside of leaves of gooseberry plants on the Plumas.
A hearing on a petition to incorporate Portola as a city will be held before the Plumas County Board of Supervisors this week.
Pavement is being laid on the new nine mile section of the Feather River Highway built last year from Spanish Creek to the entrance of Quincy from the north.
The contract was awarded for $5,000 and the gravel is being taken from Spanish Creek.
Remember When
The 20 room Mt. Tomba Hotel in Sloat burned to the ground last week on September 28. Incendiarism is suspected. Total damage is estimated at $12,000. The restaurant and some other property was saved by a forest service tank crew summoned from Mohawk Ranger Station.
Advertisement: This Fall see more of Mexico City by train. Travel via Southern Pacific Railroad train service. Only $105.00 round trip from San Francisco to Mexico City.
More Articles...
Page 2 of 41


text:
promotional discount applied. Cart total will refelect savings.
Buy 2 or more, each at $129.99
Quantity discount will reflect in cart.
This product may only be purchased with the approval of a veterinarian and may require verification. We will collect any necessary information at checkout and verify a prescription if required.
Sometimes, manufacturers require that products be advertised only at their suggested prices. When we choose to sell these items for less, we display the sale price only in the cart. To see the price, click Add to Cart.
One-time delivery
Save 10% with Auto Ship (Details) Deliver Every: 2 Weeks 3 Weeks 4 Weeks 5 Weeks 6 Weeks 7 Weeks 8 Weeks 1 Month 2 Months 3 Months 6 Months
Outback Trading Pak-a-Roo Parka
Starting from: $99.99
Outback Trading Camo Packable Overpant
Starting from: $79.99
Product Summary:
Camo Packable Jacket
The brushed Mossy Oak new Break-up shell, of the collection, allows the hunter to blend and keep silent.
We know that every day in a tree stand is a day well spent. Weather is never a worry with this Camo combo. The Pak-A-Roo jacket and packable pants have hidden features. They pack into themselves making a backpack and pouch, allowing them to be easily stored in a field bag or your vehicle.
· Polyester outershell, waterproof, seamsealed, breathable
· Moisture-wicking mesh lining
· Two-way zipper with storm flap
· Drawstring waist, covered zippered pockets
· Snap-open gusseted back vents
· Scrunches into inside back zipper opening, becoming a waterproof backpack with room to carry extra gear
· Machine washable
Item Specifications:
Product Reviews by Customers