Scwm: an Extensible Constraint-Enabled Window Manager

Total Page:16

File Type:pdf, Size:1020Kb

Scwm: an Extensible Constraint-Enabled Window Manager Scwm: An Extensible Constraint-Enabled Window Manager Greg J. Badros Jeffrey Nichols InfoSpace.com School of Computer Science, HCI Institute 2801 Alaskan Way, Suite 200 Carnegie Mellon University, 5000 Forbes Avenue Seattle, WA 98121, USA Pittsburgh, PA 15213, USA [email protected] [email protected] Alan Borning Dept. of Computer Science and Engineering University of Washington, Box 352350 Seattle, WA 98195-2350, USA [email protected] ABSTRACT Using C to implement a highly-interactive application We desired a platform for researching advanced win- also complicates extensibility and customizability. To dow layout paradigms including the use of constraints. add a new feature, the user likely must write C code, Typical window management systems are written en- recompile, relink, and restart the application before tirely in C or C++, complicating extensibility and pro- changes are finally available for testing and use. This grammability. Because no existing window manager was development cycle is especially problematic for software well-suited to our goal, we developed the Scwm window such as a window manager that generally is expected to manager. In Scwm, only the core window-management run for weeks at a time. Additionally, maintaining all primitives are written in C while the rest of the package the features that any user desires would result in terrible is implemented in its Guile/Scheme extension language. code bloat. This architecture, first seen in Emacs, enables program- An increasingly popular solution to these problems is ming substantial new features in Scheme and provides a the use of a scripting language on top of a core system solid infrastructure for constraint-based window layout that defines new domain-specific primitives. A prime research and other advanced capabilities such as voice example of this architecture is Richard Stallman’s GNU recognition. We have used Scwm to implement an in- Emacs text editor [40]. In the twenty years since the terface to the Cassowary constraint solving toolkit to introduction of Emacs, numerous extensible scripting permit end users to declaratively specify relationships languages have evolved including Tcl [34], Python [22], among window positions and sizes. The window man- Perl [42], and Guile [12, 37]. Each of the first three ager dynamically maintains those constraints and lets languages was designed from scratch with scripting in users view and modify them. Scwm succeeds in pro- mind. In contrast, Guile—the GNU Ubiquitous Intelli- viding an excellent implementation framework for our gent Language for Extension—takes a pre-existing lan- research and is practical enough that we rely on it ev- guage, Scheme, and adapts it for use as an extension eryday. language. KEYWORDS: constraints, Cassowary toolkit, Scheme, We are exploring constraint-based window layout Scwm, X/11 Window Manager paradigms and their user interfaces. Because we are most interested in practical use of constraints, we INTRODUCTION decided to target the X windows system and build We desired a platform for researching advanced window a complete window manager for X/11. We chose to layout paradigms including the use of constraints. Typi- use Guile/Scheme as the extension language for our Scwm cal window management applications for the X windows project that we named —the Scheme Constraints Scwm system are written entirely in a low-level systems lan- Window Manager. The most notable feature of guage such as C or C++. Because the X windows li- is constraint-based layout. Whereas typical window braries have a native C interface, using C is justified. management systems use only direct manipulation [38] Scwm However, a low-level language is far from ideal when of windows, also supports a user-interface for prototyping implementations of sophisticated window specifying constraints among windows that it then manager functionality. For our purposes, a higher-level maintains using our Cassowary Constraint solving language is much more appropriate, powerful, and sat- toolkit [1]. Much of the advanced functionality of Scwm isfying. is implemented in Scheme, thus exploiting the embedded-extension-language architecture. Embedded Constraint Solver Cassowary is a constraint solving toolkit that includes BACKGROUND support for arbitrary linear equalities and inequali- Scwm leverages numerous existing technologies to pro- ties [1]. Constraints may have varying strengths, and vide its infrastructure and support its advanced capa- constraint hierarchy theory [6] defines what constitutes bilities. a correct solution. We implemented the Cassowary toolkit in C++, Java, and Smalltalk, and created a X Windows and fvwm2 wrapper of the C++ implementation for Guile/Scheme. A fundamental design decision for the X windows sys- Thus, it is straightforward to use the constraint solver tem [33] was to permit an arbitrary user-level program in a broad range of target applications. to manage the various application windows. This open In addition, the Cassowary toolkit permits numerous architecture permits great flexibility in the way windows hooks for extension. Each constraint variable has an look and behave. optional attached object, and the constraint solver can X window managers are complex applications. They be instructed to invoke a callback upon changing the are responsible for decorating top-level application win- value assigned to any variable and also upon completion dows (e.g., drawing labelled titlebars), permitting resiz- of the re-solve phase (i.e., after all variable assignments ing and moving of windows, iconifying, tiling, cascading are completed). Scwm exploits these facilities to isolate windows, and much more. Many Xlib library functions the impact of the constraint solver on existing code. wrapping the X protocol are specific to the special needs CONSTRAINTS FOR LAYOUT of window managers. Because our goal is to do interest- Ordinary window managers permit only direct-manip- ing research beyond that of modern window managers, ulation as a means of laying out their windows. Al- we used an existing popular window manager, fvwm2,as though this technique is useful, a constraint-based ap- our starting point [13]. In 1997 when the first author be- proach provides a more dynamic and expressive system. Scwm gan the project with Maciej Stachowiak, fvwm2 In Scwm, we use the Cassowary constraint solving tool- was arguably the most used window manager in the X kit. On top of the primitive equation-solving capabilities windows community. It supports flexible configuration of Cassowary, Scwm adds a graphical user interface that capabilities via a per-user .fvwm2rc file that is loaded employs an object-oriented design. We specify numer- once when fvwm2 starts. To tweak parameters, end- ous constraint classes representing kinds of constraint users edit their .fvwm2rc files using an ordinary text relationships, and instances of each class are added to editor, save the changes, then restart the window man- the system for maintaining relationships among actual ager to activate the changes. The fvwm2 configuration windows. The interface allows users to create constraint language supports a very restricted form of functional objects, to manage constraint instances, and to create abstraction, but lacks loops and conditionals. new constraint classes from existing classes by demon- Despite these shortcomings, fvwm2 provides a good stration. amount of control over the look of windows. It also has Applying Constraints evolved over the years to meet complex specifications Applying constraints to windows is done using a tool- (e.g., the Interclient Communication Conventions bar. Each constraint class in the system is represented Manual [36]) and to deal with innumerable quirks by a button on the toolbar (figure 1). The user ap- of applications. By our basing Scwm on ,we fvwm2 plies a constraint by clicking a button, then selecting leveraged those capabilities and ensured that Scwm the windows to be constrained. Alternatively, the user was at least as well-behaved as . Our fundamental fvwm2 can first highlight the windows to be constrained and change to was to replace its ad-hoc configuration fvwm2 then click the appropriate button. Icons and tooltips language with Guile/Scheme [12]. with descriptive text assist the user in understanding Scheme for Extensibility what each constraint does. We consulted with a graphic artist on the design of our icons in an effort to make Guile [12] is the GNU project’s R4RS-compliant Scheme them intuitive and attractive. Preliminary user studies [9] system designed specifically for use as an embedded have demonstrated that users can determine the repre- interpreter. Scheme is a very simple, elegant dialect of sented relationship reasonably well from the icons even the long-popular Lisp programming language. It is easy without the supporting tooltip text. to learn and provides exceptionally powerful abstraction capabilities including higher-order functions, lexically- We provide the following constraint classes in our sys- scoped closures and a hygienic macro system. Guile ex- tem. Many interesting relationships are either present tends the standard Scheme language with a module sys- or can be created by combining classes in the list. tem and numerous wrappers for system libraries (e.g., POSIX file operations). Constant Height/Width Sum Keep the total of the 2 Figure 1: Our constraint toolbar. The text describes the constraint classes in the same order as they are laid out in the toolbar (from left to right). height/width of two windows constant. NW NNE 013 Horizontal/Vertical Separation Keep one window always to the left of or above another. WCE 345 Strict Relative Position Maintain the relative posi- tions of two windows. SWSSE 678 Vertical/Horizontal Maximum Size Keep height/ width of a window below a threshold. Figure 2: The nine nonants of a window. Vertical/Horizontal Minimum Size Keep height/ width of a window above a threshold. window and how that window will interact with other windows. Our constraint investigation interface allows Vertical/Horizontal Relative Size Keep the for all of these kinds of interactions. change in heights/widths of two windows constant (i.e., resize them by the same amount, together).
Recommended publications
  • MIT/GNU Scheme Reference Manual
    MIT/GNU Scheme Reference Manual Edition 1.99 for Scheme Release 7.7.90 18 September 2003 by Chris Hanson the MIT Scheme Team and a cast of thousands Copyright c 1991,1992,1993,1994,1995 Massachusetts Institute of Technology Copyright c 1996,1997,1999,2000,2001 Massachusetts Institute of Technology Copyright c 2002,2003 Massachusetts Institute of Technology Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Acknowledgements 1 Acknowledgements While "a cast of thousands" may be an overstatement, it is certainly the case that this document represents the work of many people. First and foremost, thanks go to the authors of the Revised^4 Report on the Algorithmic Language Scheme, from which much of this document is derived. Thanks also to BBN Advanced Computers Inc. for the use of parts of their Butterfly Scheme Reference, and to Margaret O’Connell for translating it from BBN’s text-formatting language to ours. Special thanks to Richard Stallman, Bob Chassell, and Brian Fox, all of the Free Software Foundation, for creating and maintaining the Texinfo formatting language in which this document is written. This report describes research done at the Artificial Intelligence Laboratory and the Laboratory for Computer Science, both of the Massachusetts Institute of Technology.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • Programming with GNU Emacs Lisp
    Programming with GNU Emacs Lisp William H. Mitchell (whm) Mitchell Software Engineering (.com) GNU Emacs Lisp Programming Slide 1 Copyright © 2001-2008 by William H. Mitchell GNU Emacs Lisp Programming Slide 2 Copyright © 2001-2008 by William H. Mitchell Emacs Lisp Introduction A little history GNU Emacs Lisp Programming Slide 3 Copyright © 2001-2008 by William H. Mitchell Introduction GNU Emacs is a full-featured text editor that contains a complete Lisp system. Emacs Lisp is used for a variety of things: • Complete applications such as mail and news readers, IM clients, calendars, games, and browsers of various sorts. • Improved interfaces for applications such as make, diff, FTP, shells, and debuggers. • Language-specific editing support. • Management of interaction with version control systems such as CVS, Perforce, SourceSafe, and StarTeam. • Implementation of Emacs itself—a substantial amount of Emacs is written in Emacs Lisp. And more... GNU Emacs Lisp Programming Slide 4 Copyright © 2001-2008 by William H. Mitchell A little history1 Lisp: John McCarthy is the father of Lisp. The name Lisp comes from LISt Processing Language. Initial ideas for Lisp were formulated in 1956-1958; some were implemented in FLPL (FORTRAN-based List Processing Language). The first Lisp implementation, for application to AI problems, took place 1958-1962 at MIT. There are many dialects of Lisp. Perhaps the most commonly used dialect is Common Lisp, which includes CLOS, the Common Lisp Object System. See http://www-formal.stanford.edu/jmc/history/lisp/lisp.html for some interesting details on the early history of Lisp. 1 Don't quote me! GNU Emacs Lisp Programming Slide 5 Copyright © 2001-2008 by William H.
    [Show full text]
  • Published with the Approbation of the Board of Trustees
    JOHNS HOPKINS UNIVERSITY CIRCULARS Published with the approbation of the Board of Trustees VOL. V.—No. 46.] BALTIMORE, JANUARY, 1886. [PRICE, 10 CENTS. RECENT PUBLICATIONS. Photograph of the Normal Solar Spectrum. Made Reproduction in Phototype of a Syriac Manuscript by PROFESSOR H. A. ROWLAND. (Baltimore, Johns Hopkins University, 1886). (Williams MS.) with the Antilegomena Epistles. Edited by IsAAC H. HALL. (Baltimore, Johns Hopkins University, 1886). [Froma letter to Science, New York, December 18, 1885]. The photographic map of the spectrum, upon which Professor Rowland [Froman article by I. H. Hall in the Journal of the Society of Biblical Literature and has expended so much hard work during the past three years, is nearly Exegesis for 1885, with additions]. ready for publication. The map is issued in a series of seven plates, cover- In September last (1884) I announced in The Independent the discovery ing the region from wave-length 3100 to 5790. Each plate is three feet of a manuscript of the Acts and Epistles, among which occur also the long and one foot wide, and contains two strips of the spectrum, except Epistles that were antilegomena among the Syrians; namely the Second plate No. 2, which contains three. Most of the plates are on a scalethree Epistle of Peter, the Second and Third Epistles of John, and the Epistle of times that of Angstrdm’s map, and in definition are more than equal to any Jude, in the version usually printed with our Peshitto New Testaments. It map yet published, at least to wave-length 5325. The 1474 line is widely is well known that the printed copies of these Epistles in that version all double, as also are b rest upon one manuscriptonly, in the Bodleian Library at Oxford, England, 3 and b4, while E may be recognized as double by the from which they were first published by Edward Pococke (Leyden, Elzevirs) expert.
    [Show full text]
  • Free As in Freedom (2.0): Richard Stallman and the Free Software Revolution
    Free as in Freedom (2.0): Richard Stallman and the Free Software Revolution Sam Williams Second edition revisions by Richard M. Stallman i This is Free as in Freedom 2.0: Richard Stallman and the Free Soft- ware Revolution, a revision of Free as in Freedom: Richard Stallman's Crusade for Free Software. Copyright c 2002, 2010 Sam Williams Copyright c 2010 Richard M. Stallman Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License." Published by the Free Software Foundation 51 Franklin St., Fifth Floor Boston, MA 02110-1335 USA ISBN: 9780983159216 The cover photograph of Richard Stallman is by Peter Hinely. The PDP-10 photograph in Chapter 7 is by Rodney Brooks. The photo- graph of St. IGNUcius in Chapter 8 is by Stian Eikeland. Contents Foreword by Richard M. Stallmanv Preface by Sam Williams vii 1 For Want of a Printer1 2 2001: A Hacker's Odyssey 13 3 A Portrait of the Hacker as a Young Man 25 4 Impeach God 37 5 Puddle of Freedom 59 6 The Emacs Commune 77 7 A Stark Moral Choice 89 8 St. Ignucius 109 9 The GNU General Public License 123 10 GNU/Linux 145 iii iv CONTENTS 11 Open Source 159 12 A Brief Journey through Hacker Hell 175 13 Continuing the Fight 181 Epilogue from Sam Williams: Crushing Loneliness 193 Appendix A { Hack, Hackers, and Hacking 209 Appendix B { GNU Free Documentation License 217 Foreword by Richard M.
    [Show full text]
  • Central Islip Union Free School District and Central Islip Teachers Association (2005)
    NYS PERB Contract Collection – Metadata Header This contract is provided by the Martin P. Catherwood Library, ILR School, Cornell University. The information provided is for noncommercial educational use only. Some variations from the original paper document may have occurred during the digitization process, and some appendices or tables may be absent. Subsequent changes, revisions, and corrections may apply to this document. For more information about the PERB Contract Collection, see http://digitalcommons.ilr.cornell.edu/perbcontracts/ Or contact us: Catherwood Library, Ives Hall, Cornell University, Ithaca, NY 14853 607-254-5370 [email protected] Contract Database Metadata Elements Title: Central Islip Union Free School District and Central Islip Teachers Association (2005) Employer Name: Central Islip Union Free School District Union: Central Islip Teachers Association Effective Date: 07/01/05 Expiration Date: 06/30/15 PERB ID Number: 4733 Unit Size: Number of Pages: 142 For additional research information and assistance, please visit the Research page of the Catherwood website - http://www.ilr.cornell.edu/library/research/ For additional information on the ILR School - http://www.ilr.cornell.edu/ CENTRAL,ISLIP ···TEACHERS·Xs§'6e!ATION TABLE OF CONTENTS ARTICLE Preamble 1 I Recognition 2 II Negotiation Procedure '" . 4 III Teacher Association & Board Rights 6 IV Grievance Procedure '" '" 10 V Teacher-Administration Liaison 15 VI Salaries , 16 VII Teaching Hours and Teaching Load................... ...18 VIII Class Size , 22 IX Specialists
    [Show full text]
  • Implementing Concurrency Abstractions for Programming Multi-Core Embedded Systems in Scheme
    Faculty of Engineering Implementing Concurrency Abstractions for Programming Multi-Core Embedded Systems in Scheme Graduation thesis submitted in partial fulfillment of the requirements for the degree of Master of Engineering: Applied Computer Science Ruben Vandamme Promotor: Prof. Dr. Wolfgang De Meuter Advisors: Dr. Coen De Roover Christophe Scholliers 2010 Faculteit Ingenieurswetenschappen Implementing Concurrency Abstractions for Programming Multi-Core Embedded Systems in Scheme Eindwerk ingediend voor het behalen van de graad van Master in de Ingenieurswetenschappen: Toegepaste Computerwetenschappen Ruben Vandamme Promotor: Prof. Dr. Wolfgang De Meuter Begeleiders: Dr. Coen De Roover Christophe Scholliers 2010 Acknowledgements This thesis would not have been possible without the support of various people. First, I would like to thank Professor Wolfgang De Meuter for promoting this thesis. In particular I would like to thank my advisors Christophe and Coen for their extensive and essential support throughout the year. Without their effort, this thesis would not have been what it is today. I thank my parents for making all this possible and for supporting me during my education at the Vrije Universiteit Brussel and during previous educations. And I cannot forget to thank Jennifer for her indispensable support during this undertaking. 1 Abstract This dissertation presents a study of the limitations and problems related to the prevalent way embedded systems handle signals from the outside world. Such signals are frequently handled using either polling or interrupts. Polling software will continually check whether a signal needs handling. In interrupt- driven embedded systems, on the other hand, the CPU will generate an asynchronous signal when an event from the outside arrives.
    [Show full text]
  • Gnu-Manifesto.Pdf
    This is a verbatim copy of www.gnu.org/gnu/manifesto.html, converted into pdf for inclusion in a course reader. The GNU Manifesto by Richard Stallman The GNU Manifesto (which appears below) was written by Richard Stallman at the beginning of the GNU Project, to ask for participation and support. For the first few years, it was updated in minor ways to account for developments, but now it seems best to leave it unchanged as most people have seen it. Since that time, we have learned about certain common misunderstandings that different wording could help avoid. Footnotes added in 1993 help clarify these points. For up-to-date information about the available GNU software, please see the information available on our web server, in particular our list of software. For how to contribute, see http://www.gnu.org/help. What’s GNU? Gnu’s Not Unix! GNU, which stands for Gnu's Not Unix, is the name for the complete Unix-compatible software system which I am writing so that I can give it away free to everyone who can use it.(1) Several other volunteers are helping me. Contributions of time, money, programs and equipment are greatly needed. So far we have an Emacs text editor with Lisp for writing editor commands, a source level debugger, a yacc-compatible parser generator, a linker, and around 35 utilities. A shell (command interpreter) is nearly completed. A new portable optimizing C compiler has compiled itself and may be released this year. An initial kernel exists but many more features are needed to emulate Unix.
    [Show full text]
  • Lisping Copyleft: a Close Reading of the Lisp LGPL 15
    Lisping Copyleft: A Close Reading of the Lisp LGPL 15 Lisping Copyleft: A Close Reading of the Lisp LGPL Eli Greenbaum a (a) Attorney, Yigal Arnon & Co. Jerusalem DOI: 10.5033/ifosslr.v5i1.75 Abstract: The idioms of both the General Public License (the “GPL”) and the Lesser General Public License (the “LGPL”) seem to be grounded in the C programming language. This article analyses the Lisp Lesser General Public License (colloquially and here referred to as the “LLGPL”), a specific attempt to apply the LGPL to a language with a programming paradigm and method of building and distributing programs that traditionally differs substantially from the approach of C. In addition, this article attempts to understand whether the LLGPL actually succeeds in its stated goal of translating the LGPL to the Lisp context or whether the LLGPL changes the requirements and philosophical moorings of the LGPL. Keywords: Law; information technology; Free and Open Source Software; copyleft, copyright; derivation; compilation; Lisp; LGPL; Introduction The idioms of both the General Public License (the “GPL”) and the Lesser General Public License 1 (the “LGPL”) seem to be grounded in the C programming language. The licenses refer to “compiling”, “linking” and “header files”, features of the C programming languages which may not be present in other languages that are not traditionally compiled. Similarly, the licenses do not expressly include provisions relating to features of object-oriented programming languages.2 Do the GNU licenses work as intended when applied in these other contexts? 3 This article analyses the Lisp 1 The LLGPL license is drafted as a preamble to version 2.1 of the LGPL.
    [Show full text]
  • GNU Emacs Lisp Reference Manual Volume 2 for Emacs Version 24.1 Revision 3.1, May 2012
    GNU Emacs Lisp Reference Manual Volume 2 For Emacs Version 24.1 Revision 3.1, May 2012 by Bil Lewis, Dan LaLiberte, Richard Stallman, the GNU Manual Group, et al. This is edition 3.1 of the GNU Emacs Lisp Reference Manual, corresponding to Emacs version 24.1. Copyright c 1990-1996, 1998-2012 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being \GNU General Public License," with the Front-Cover texts being \A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled \GNU Free Documentation License." (a) The FSF's Back-Cover Text is: \You have the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom." Published by the Free Software Foundation 51 Franklin St, Fifth Floor Boston, MA 02110-1301 USA ISBN 1-882114-74-4 Cover art by Etienne Suvasa. i Short Contents Volume 1 1 Introduction :::::::::::::::::::::::::::::::::::::::: I:1 2 Lisp Data Types ::::::::::::::::::::::::::::::::::::: I:8 3 Numbers :::::::::::::::::::::::::::::::::::::::::: I:33 4 Strings and Characters::::::::::::::::::::::::::::::: I:48 5 Lists ::::::::::::::::::::::::::::::::::::::::::::: I:64 6 Sequences, Arrays, and Vectors :::::::::::::::::::::::: I:86 7 Hash Tables ::::::::::::::::::::::::::::::::::::::: I:97 8 Symbols::::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Editor War - Wikipedia, the Free Encyclopedia Editor War from Wikipedia, the Free Encyclopedia
    11/20/13 Editor war - Wikipedia, the free encyclopedia Editor war From Wikipedia, the free encyclopedia Editor war is the common name for the rivalry between users of the vi and Emacs text editors. The rivalry has become a lasting part of hacker culture and the free software community. Many flame wars have been fought between groups insisting that their editor of choice is the paragon of editing perfection, and insulting the others. Unlike the related battles over operating systems, programming languages, and even source code indent style, choice of editor usually only affects oneself. Contents 1 Differences between vi and Emacs 1.1 Benefits of vi-like editors 1.2 Benefits of Emacs 2 Humor 3 Current state of the editor war 4 See also 5 Notes 6 References 7 External links Differences between vi and Emacs The most important differences between vi and Emacs are presented in the following table: en.wikipedia.org/wiki/Editor_war 1/6 11/20/13 Editor war - Wikipedia, the free encyclopedia vi Emacs Emacs commands are key combinations for which modifier keys vi editing retains each permutation of typed keys. are held down while other keys are Keystroke This creates a path in the decision tree which pressed; a command gets executed execution unambiguously identifies any command. once completely typed. This still forms a decision tree of commands, but not one of individual keystrokes. Historically, vi is a smaller and faster program, but Emacs takes longer to start up (even with less capacity for customization. The vim compared to vim) and requires more version of vi has evolved to provide significantly memory.
    [Show full text]
  • Open Source Takes Shape
    Chapter 3 Open Source Takes Shape ince all early software was assumed to be open Much of the letter, however, attacks the community source—open to improvement and reuse—and the of sharing that was prevalent at the time: Stechnology of the time largely required that soft- ware be distributed in a form that allowed those uses, As the majority of hobbyists must be aware, most there was little need or drive to formalize the concept.1 of you steal your software. Hardware must be paid Eventually, however, as software matured, the oppor- for, but software is something to share. Who cares tunity to charge for it emerged. if the people who worked on it get paid?6 Unix was born in AT&T’s Bell Labs in 1969, but it was raised at UC Berkeley, where students and faculty Commercialization of software might be seen as a added many of the features we now recognize as essential natural evolutionary landmark, but it also reflected a pro- to the operating system, including virtual memory and found philosophical shift: software that had been easy to Library Technology Reports Library Technology almost every aspect of modern networking.2 Berkeley’s copy, learn from, fix, and share was being restricted to fit enhancements were distributed widely as a package called the economics of scarcity. BSD (Berkeley software distribution), and over time they The commercialization of software was happening, became as important to a Unix system as the licensed and not in a graceful leap, but in lurched motions, and Richard purchased product from AT&T.3 M.
    [Show full text]