ranger - mirror of ranger - a simple, vim-like file manager

	Commit message (Expand)	Author	Age	Files	Lines
*	ranger.py: improved handling of bad import	hut	2010-01-26	1	-1/+2
*	ranger.py: more fixes	hut	2010-01-12	1	-2/+2
*	ranger.py: cleanup/fix	hut	2010-01-11	1	-9/+8
*	fixed #31, cd-after-exit works even after pressing ^C	hut	2010-01-11	1	-1/+12
*	added license information	hut	2010-01-08	1	-3/+17
*	F1 key (inside console) for viewing information about the command	hut	2009-12-29	1	-1/+1
*	shorten comment in ranger.py	hut	2009-12-26	1	-11/+5
*	implemented OpenConsole	hut	2009-12-25	1	-2/+2
*	random updates	hut	2009-12-25	1	-3/+16
*	tons of stuff	hut	2009-12-17	1	-1/+1
*	merged main with __init__	hut	2009-12-12	1	-1/+1
*	restructurations	hut	2009-12-11	1	-2/+4
*	changing implementation of options	hut	2009-12-06	1	-3/+6
*	structural improvements	hut	2009-12-01	1	-46/+9
*	random improvements	hut	2009-11-29	1	-2/+2
*	implemented colorschemes.	hut	2009-11-29	1	-10/+10
*	started to implement colorschemes	hut	2009-11-29	1	-6/+11
*	restructuration	hut	2009-11-28	1	-33/+33
*	embedded wrapper.sh into ranger.py	hut	2009-11-27	1	-0/+12
*	cd-after-exit	hut	2009-11-27	1	-4/+17
*	general improvement	hut	2009-11-27	1	-1/+1
*	more VROOM	hut	2009-11-27	1	-0/+38

59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>Mu - 000organization.cc</title> <meta name="Generator" content="Vim/8.1"> <meta name="plugin-version" content="vim8.1_v1"> <meta name="syntax" content="cpp"> <meta name="settings" content="number_lines,use_css,pre_wrap,no_foldcolumn,expand_tabs,line_ids,prevent_copy="> <meta name="colorscheme" content="minimal-light"> <style type="text/css">  </style> <script type='text/javascript'>  </script> </head> <body onload='JumpToLine();'> <a href='https://github.com/akkartik/mu/blob/master/000organization.cc'>https://github.com/akkartik/mu/blob/master/000organization.cc</a> <pre id='vimCodeElement'> 1 //: You guessed right: the '000' prefix means you should start reading here. 2 //: 3 //: This project is set up to load all files with a numeric prefix. Just 4 //: create a new file and start hacking. 5 //: 6 //: The first few files (00*) are independent of what this program does, an 7 //: experimental skeleton that will hopefully make it both easier for others to 8 //: understand and more malleable, easier to rewrite and remould into radically 9 //: different shapes without breaking in subtle corner cases. The premise is 10 //: that understandability and rewrite-friendliness are related in a virtuous 11 //: cycle. Doing one well makes it easier to do the other. 12 //: 13 //: Lower down, this file contains a legal, bare-bones C++ program. It doesn't 14 //: do anything yet; subsequent files will contain :(...) directives to insert 15 //: lines into it. For example: 16 //: :(after "more events") 17 //: This directive means: insert the following lines after a line in the 18 //: program containing the words "more events". 19 //: 20 //: A simple tool is included to 'tangle' all the files together in sequence 21 //: according to their directives into a single source file containing all the 22 //: code for the project, and then feed the source file to the compiler. 23 //: (It'll drop these comments starting with a '//:' prefix that only make 24 //: sense before tangling.) 25 //: 26 //: Directives free up the programmer to order code for others to read rather 27 //: than as forced by the computer or compiler. Each individual feature can be 28 //: organized in a self-contained 'layer' that adds code to many different data 29 //: structures and functions all over the program. The right decomposition into 30 //: layers will let each layer make sense in isolation. 31 //: 32 //: "If I look at any small part of it, I can see what is going on -- I don't 33 //: need to refer to other parts to understand what something is doing. 34 //: 35 //: If I look at any large part in overview, I can see what is going on -- I 36 //: don't need to know all the details to get it. 37 //: 38 //: Every level of detail is as locally coherent and as well thought-out as 39 //: any other level." 40 //: 41 //: -- Richard Gabriel, "The Quality Without A Name" 42 //: (<a href="http://dreamsongs.com/Files/PatternsOfSoftware.pdf">http://dreamsongs.com/Files/PatternsOfSoftware.pdf</a>, page 42) 43 //: 44 //: Directives are powerful; they permit inserting or modifying any point in 45 //: the program. Using them tastefully requires mapping out specific lines as 46 //: waypoints for future layers to hook into. Often such waypoints will be in 47 //: comments, capitalized to hint that other layers rely on their presence. 48 //: 49 //: A single waypoint might have many different code fragments hooking into 50 //: it from all over the codebase. Use 'before' directives to insert 51 //: code at a location in order, top to bottom, and 'after' directives to 52 //: insert code in reverse order. By convention waypoints intended for insertion 53 //: before begin with 'End'. Notice below how the layers line up above the "End 54 //: Foo" waypoint. 55 //: 56 //: File 001 File 002 File 003 57 //: ============ =================== =================== 58 //: // Foo 59 //: ------------ 60 //: <---- :(before "End Foo") 61 //: .... 62 //: ... 63 //: ------------ 64 //: <---------------------------- :(before "End Foo") 65 //: .... 66 //: ... 67 //: // End Foo 68 //: ============ 69 //: 70 //: Here's part of a layer in color: <a href="http://i.imgur.com/0eONnyX.png">http://i.imgur.com/0eONnyX.png</a>. Directives 71 //: are shaded dark. 72 //: 73 //: Layers do more than just shuffle code around. In a well-organized codebase 74 //: it should be possible to stop loading after any file/layer, build and run 75 //: the program, and pass all tests for loaded features. (Relevant is 76 //: <a href="http://youtube.com/watch?v=c8N72t7aScY">http://youtube.com/watch?v=c8N72t7aScY</a>, a scene from "2001: A Space 77 //: Odyssey".) Get into the habit of running the included script called 78 //: 'test_layers' before you commit any changes. 79 //: 80 //: This 'subsetting guarantee' ensures that this directory contains a 81 //: cleaned-up narrative of the evolution of this codebase. Organizing 82 //: autobiographically allows newcomers to rapidly orient themselves, reading 83 //: the first few files to understand a simple gestalt of a program's core 84 //: purpose and features, and later gradually working their way through other 85 //: features as the need arises. 86 //: 87 //: Programmers shouldn't need to understand everything about a program to 88 //: hack on it. But they shouldn't be prevented from a thorough understanding 89 //: of each aspect either. The goal of layers is to reward curiosity. 90 //: 91 //: More information: <a href="http://akkartik.name/post/wart-layers">http://akkartik.name/post/wart-layers</a> 92 93 // Includes 94 // End Includes 95 96 // Types 97 // End Types 98 99 // Function prototypes are auto-generated in the 'build' script; define your 100 // functions in any order. Just be sure to declare each function header all on 101 // one line, ending with the '{'. Our auto-generation scripts are too minimal 102 // and simple-minded to handle anything else. 103 #include "function_list" // by convention, files ending with '_list' are auto-generated 104 105 // Globals 106 // 107 // All statements in this section should always define a single variable on a 108 // single line. The 'build' script will simple-mindedly auto-generate extern 109 // declarations for them. Remember to define (not just declare) constants with 110 // extern linkage in this section, since C++ global constants have internal 111 // linkage by default. 112 // 113 // End Globals 114 115 int <a href='000organization.cc.html#L115'>main</a>(int argc, char* argv[]) { 116 atexit(<a href='000organization.cc.html#L150'>reset</a>); 117 // we require a 32-bit little-endian system 118 assert(sizeof(int) == 4); 119 assert(sizeof(float) == 4); 120 <a href='000organization.cc.html#L154'>assert_little_endian</a>(); 121 122 // End One-time Setup 123 124 // Commandline Parsing 125 // End Commandline Parsing 126 127 // End Main 128 129 return 0; 130 } 131 132 // Unit Tests 133 // End Unit Tests 134 135 //: our first directive; insert the following headers at the start of the program 136 :(before "End Includes") 137 #include <assert.h> 138 #include <stdlib.h> 139 140 //: Without directives or with the :(code) directive, lines get added at the 141 //: end. 142 //: 143 //: Regardless of where functions are defined, we can call them anywhere we 144 //: like as long as we format the function header in a specific way: put it 145 //: all on a single line without indent, end the line with ') {' and no 146 //: trailing whitespace. As long as functions uniformly start this way, our 147 //: 'build' script contains a little command to automatically generate 148 //: declarations for them. 149 :(code) 150 void <a href='000organization.cc.html#L150'>reset</a>() { 151 // End Reset 152 } 153 154 void <a href='000organization.cc.html#L154'>assert_little_endian</a>() { 155 const int x = 1; 156 const char* y = reinterpret_cast<const char*>(&x); 157 if (*y != 1) { 158 cerr << "SubX requires a little-endian processor. Do you have Intel (or AMD or Atom) inside?\n"; 159 exit(1); 160 } 161 } 162 :(before "End Includes") 163 #include<iostream> 164 using std::cerr; </pre> </body> </html>