1Here is a collection of random rants from e93's author.
2
3This may help you understand why the editor does some things and does
4not do others.
5
6If this sounds pompous to you, it is because I can be a pompous
7bastard. Please excuse me.
8
9Control key vs. Alt key
10-----------------------
11This is for all Windows users out there who might be wondering why e93
12uses the "Alt" key to select menus (like Alt-X for cut, or Alt-C for
13copy...) instead of the "Control" key which they might be used to using...
14
15Let's see. Hmmm. How to put this gently...
16
17When the Mac came out, (and introduced the world at large to windowing
18systems) it had that strange looking clover key which was used to
19select menu items. It was quickly learned by users that that key did
20one and only one thing -- it accessed menu items from the keyboard.
21
22The Mac also had a Control key. That key did what all Control keys are
23supposed to do -- It allowed users to enter control codes which could
24be used to Control TTY style devices -- you remember those things??
25Guess what. Those things still exist, and although admittedly they are
26less important today than they used to be, the Control key is still
27needed.
28
29Anyway, if I ever had to write a Telnet client or terminal program for
30Windows, I would probably get fairly angry when I realized that I
31needed to give my users the ability to copy text (which is Control-C
32in Windows) AND the ability to send an ETX character to a process
33(which is Control-C in the rest of the world). If I used Control to
34send control codes (the original purpose for the Control key), it
35means that my users would not be able to access menus in the way that
36they were accustomed to. If I used the Control for menu shortcuts,
37users would have a difficult time using my program for its intended
38purpose (try using Telnet without a Control key).
39
40I don't know why the "engineers" at M$ chose the Control key over the
41Alt key when they were copying the Mac, but it is clear that they did
42not consider the consequences too carefully.
43
44Since I (thankfully) spend most of my time working in Unix, I think
45I'll use the Control key for its traditional purpose -- entering
46control codes.
47
48BTW: the above applies only to the Unix/X version of e93. For the
49Windows version (which fortunately I do not work on), it is clear that
50Control needs to be used for menu keys, since trying to use Alt when
51every other application uses Control (except maybe the terminal
52program ;-) would annoy people more than an inability to enter control
53codes into their documents.
54
55Oh, and if this rant gave you the impression that I am in love with
56the way X handles user interface, let me correct you now: X is my
57*least* favorite windowing system. It addresses almost no user
58interface issues, and in the process, causes every application running
59under it to be different. I tolerate X because it is the only GUI
60environment which runs on top of Unix, and is open source.
61(If there is another, I would appreciate someone letting me know.)
62
63
64Copy/Paste -- X style vs. Mac style
65-----------------------------------
66What could be more convenient? Just select some text with the left
67mouse button, and then paste it by pressing the middle button. Your
68hand would never have to leave the mouse. Sounds better than having to
69select the text with the mouse, then go to a menu, or hit a key
70combination to copy it, then do the same thing to paste -- right?
71
72Perhaps. But in practice I find the X selection mechanism annoyingly
73cumbersome.
74
75First, it is far too easy to hit the middle mouse button by accident,
76and paste unwanted text into whatever you happen to be working on. How
77many people reading this have ever pasted a bunch of garbage into an
78xterm, and ended up creating random files, or worse yet, deleting or
79over-writing important ones??
80
81Second, the copy-on-select mentality means that if I want to select a
82bunch of text to delete it, I end up putting it into the clipboard,
83writing over what I really wanted there. A good example of this is
84trying to copy a URL from some document into the address entry window
85of a browser -- Invariably I select the text of my document containing
86the URL, bring the browser window forward, notice that the address
87entry field is occupied by the last address I was looking at, select
88that address to get rid of it, hit delete, then try to paste... Oops.
89Damn. Now I go back to the original document and get the address
90again... Grrrr.
91
92Finally, having one selection for the entire windowing system means
93that I cannot leave text selected in one window or application, move
94to another to do something, then come back to the first without having
95my selections wiped out.
96
97
98Bracketing style
99----------------
100I do not really have a rant here, except that
101
102    if(blah)
103    {
104        printf("blah\n");
105    }
106    else
107    {
108        printf("no blah\n");
109    }
110
111is MUCH easier for me to follow than the K&R style.
112
113    if(blah) {
114        printf("blah\n");
115    }
116    else {
117        printf("no blah\n");
118    }
119
120If you submit code to be added to e93, do me a favor, and put it in
121the style I like :-) It will save me the time of doing the conversion
122myself, and make it more likely that I will take your code.
123
124
125Tabs vs. Spaces
126---------------
127This one is a bit more sticky. Lots of people like to use only spaces
128in their text documents. The argument is that spaces are always
129spaces, and the text will always look the same to anyone who reads it.
130If tabs are used, the argument is that different tools expand tabs
131differently, and therefore, documents with tabs in them may not always
132look as expected.
133
134I understand this argument.
135
136However, spaces are not as convenient as tabs when editing code.
137
138If you are editing code, it is nice to have the various indentation
139levels of the code represented as tabs. Tabs make it convenient to
140move over to the next indent level, or back up to the previous one.
141
142Many editors attempt to solve this tab/space issue by trying to guess
143what the user intends. When the tab key is hit, these editors add the
144correct number of spaces to the document to take the cursor to the
145next tab stop. When the user hits a backspace, the editor must guess
146that the intention was to back up over the "tab" and get rid of the
147correct number of spaces. The problem is that the editor cannot really
148know if what it is backing up over was typed as a tab, or was typed as
149spaces. Therefore, it can guess wrong, which I find confusing/bad.
150
151The best solution in my opinion is to have the editor do what the
152user asked it to do with a minimum of guessing. This means that if the
153user types a tab, he gets a tab. If the user hits backspace, he gets a
154backspace. To me, this is the most convenient way to edit code.
155
156If I need to export code to others who might be using tools which
157are different than mine, and I want them to be able to see the code
158as I intended it to look, I will convert tabs to spaces as a separate
159step. See expand(1), unexpand(1).
160
161
162Magic
163-----
164Some editors try to do things for their users by guessing what they
165would find useful, then doing those things without being asked.
166Here are some examples:
167
168Changing line termination into the default for the current platform.
169For example, some Unix editors might read a file which contained CRLF line
170termination, and convert it to LF-only line termination without asking.
171
172Adding a linefeed to the last line of a document.
173For example, some editors may discover that the last line of a document
174is lacking a line feed character, and automatically add one in.
175
176Deletion of extraneous control characters.
177
178Deletion of excess whitespace at the ends of lines.
179
180Conversion of tabs to spaces, or spaces to tabs.
181
182etc...
183
184e93 can be made to do any of these. But by default, it will never do
185*anything* to the text of a document without being explicitly
186commanded to do so. This guarantees that you can load any document
187into e93, make changes, save it, and know that the only differences are
188the changes *you* made.
189As a programmer's tool, I find this to be an important ability.
190
191If you want the editor to do these things automatically for you, e93
192is scriptable in Tcl. As a programmer, hopefully you will find such
193scripts easy to create.
194