/usr/share/doc/ne/html/Motivations-and-Design.html is in ne-doc 2.5-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 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 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 | <html lang="en">
<head>
<title>Motivations and Design - ne's manual</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="ne's manual">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="prev" href="Hints-and-Tricks.html#Hints-and-Tricks" title="Hints and Tricks">
<link rel="next" href="The-Encoding-Mess.html#The-Encoding-Mess" title="The Encoding Mess">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
pre.display { font-family:inherit }
pre.format { font-family:inherit }
pre.smalldisplay { font-family:inherit; font-size:smaller }
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
span.sc { font-variant:small-caps }
span.roman { font-family:serif; font-weight:normal; }
span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
</head>
<body>
<div class="node">
<a name="Motivations-and-Design"></a>
<p>
Next: <a rel="next" accesskey="n" href="The-Encoding-Mess.html#The-Encoding-Mess">The Encoding Mess</a>,
Previous: <a rel="previous" accesskey="p" href="Hints-and-Tricks.html#Hints-and-Tricks">Hints and Tricks</a>,
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
<hr>
</div>
<h2 class="chapter">7 Motivations and Design</h2>
<p><a name="index-Mode-232"></a><a name="index-curses-233"></a><a name="index-POSIX-234"></a><a name="index-terminfo-235"></a><a name="index-termcap-236"></a><a name="index-Magic-cookie-terminals-237"></a><a name="index-Resource-usage-238"></a><a name="index-Interrupt-character-239"></a>
In this chapter I will try to outline the rationale behind <code>ne</code>'s
design choices. Moreover, some present, voluntary limitations of the current
implementation will be described. The intended audience of such a
description is the programmer wanting to hack up <code>ne</code>'s sources, or the
informed user wanting to deepen his knowledge of the limitations.
<p>The design goal of <code>ne</code> was to write an editor that is easy to use
at first sight, powerful, and completely configurable. Making <code>ne</code>
run on any terminal that <code>vi</code> could handle was also a basic issue,
because there is no use getting accustomed to a new tool if you cannot
use it when you really need it. Finally, using resources sparingly was
considered essential.
<p><code>ne</code> has no concept of <em>mode</em>. All shortcuts are defined by a
single key, possibly with a modifier (such as <Control> or <Meta>).
Modality is in my opinion a Bad Thing unless it has a very clear visual
feedback. As an example, menus are a form of modality. After entering the
menus, the alphabetic keys and the navigation keys have a different meaning.
But the modality is clearly reflected by a change in the user
interface. The same can be said about the input line, because it is always
preceded by a (possibly highlighted) prompt ending with a colon.
<p><code>ne</code> has no sophisticated visual updating system similar to, for
instance, the one of <code>curses</code>. All updating is done while
manipulating the text, and only if the turbo flag is set can some iterated
operations delay the update. (In this case, <code>ne</code> keeps track in a
very rough way of the part of the screen that changed.) Moreover, the
output is not preempted by additional input coming in, so that along a
slow connection the output could not keep up with the input. However,
along reasonably fast connections, the responsiveness of the editor is
greatly enhanced by the direct update. And since we update the screen in
parallel with the internal representation, we can exploit our knowledge to
output a very small number of characters per modification. As it is
typical in <code>ne</code>, when such design tradeoffs arise, preference is
given to the solution that is effective on a good part of the existing
hardware and will be very effective on most future hardware.
<p><code>ne</code> uses a particular scheme for handling text. There is a doubly
linked list of line descriptors that contain pointers to each line of text.
The lines themselves are kept in a list of pools, which is expanded and
reduced dynamically. The interesting thing is that for each pool <code>ne</code>
keeps track just of the first and of the last character used. A character is
free iff it contains a null, so there is no need for a list of free chunks.
The point is that the free characters lying between that first and the last
used characters (the <dfn>lost</dfn> characters) can only be allocated
<em>locally</em>: whenever a line has to grow in length, <code>ne</code> first
checks if there are enough free characters around it. Otherwise, it remaps
the line elsewhere. Since editing is essentially a local activity, the
number of such lost characters remains very low. And the manipulation of a
line is extremely fast and independent of the size of the file, which can be
very huge. A mathematical analysis of the space/time tradeoff is rather
difficult, but empirical evidence suggests that the idea works.
<p><code>ne</code> takes the <span class="sc">posix</span> standard as the basis for <span class="sc">un*x</span>
compatibility. The fact that this standard has been designed by a worldwide
recognized and impartial organization such as <span class="sc">ieee</span> makes it in my
opinion the most interesting effort in its league. No attempt is made to
support ten thousand different versions and releases by using conditional
compilation. Very few assumptions are made about the behaviour of the system
calls. This has obvious advantages in terms of code testing, maintenance, and
reliability. For the same reasons, the availability of an <span class="sc">ansi</span> C
(C90) compiler is assumed.
<p>If the system has a <code>terminfo</code> database and the related functions
(which are usually contained in <code>curses</code> library), <code>ne</code> will
use them. The need for a terminal capability database is clear, and the
choice of <code>terminfo</code> (with respect to <code>termcap</code>) is compulsory
if you want to support a series of features (such as more than ten
function keys) that <code>termcap</code> lacks. If <code>terminfo</code> is not
available, <code>ne</code> can use a <code>termcap</code> database, or, as a last
resort, a built-in set of ANSI control sequences. Some details about
this can be found in <a href="Portability-Problems.html#Portability-Problems">Portability Problems</a>.
<p><code>ne</code> does not allow redefinition of the <Escape>, <Tab> or
<Return> keys, nor of the interrupt character
<kbd><Control>-\</kbd>. This decision has been made mainly for two
reasons. First of all, it is necessary to keep a user from transforming
<code>ne</code>'s bindings to such a point that another unaware user cannot
work with it. These two keys and the alphabetic keys allow activating
any command without any further knowledge of the key bindings, so it
seems to me this is a good choice. As a second point, the <Escape>
key usage should generally be avoided. The reason is that most escape
sequences that are produced by special keys start with the escape
character. When <Escape> is pressed, <code>ne</code> has to wait for one
second (this timing can be changed with the <code>EscapeTime</code> command),
just to be sure that it did not receive the first character of an escape
sequence. This makes the response of the key very slow, unless it is
immediately followed by another key such as ‘<samp><span class="samp">:</span></samp>’, or by <Escape>,
again. See <a href="Hints-and-Tricks.html#Hints-and-Tricks">Hints and Tricks</a>.
<p>Note that, as has been stated several times, the custom key bindings also work
when doing a long input, navigating through the menus or browsing the
requester. However, this is only partially true. To keep the code size
and complexity down, in these cases <code>ne</code> recognizes only direct bindings to
commands, and discards the arguments. Thus, for instance, if a key is bound to
the command line <code>LineUp 2</code>, it will act like <code>LineUp</code>, while a
binding to <code>Macro MoveItUp</code> would produce no result. Of course full
binding capability is available while writing text. (This limitation will
probably be lifted in a future version: presently it does not seem to limit
seriously the configurability of <code>ne</code>.)
<p><code>ne</code> has some restrictions in its terminal handling. It does not support
highlighting on terminals that use a magic cookie. Supporting such terminals
correctly is a royal pain, and I did not have any means of testing the code anyway.
Moreover, they are rather obsolete. Another lack of support is for the
capability strings that specify a file to print or a program to launch in
order to initialize the terminal.
<p>The macro capabilities of <code>ne</code> are rather limited. For instance, you
cannot give an argument to a macro: macros are simply scripts that can be played
back automatically. This makes them very useful for everyday use in a
learn/play context, but rather inflexible for extending the capabilities of the
editor. However, it is not reasonable to incorporate in an editor an
interpreter for a custom language. Rather, a system-wide macro language should
control the editor <i>via</i> interprocess communication. This is the way of the
REXX language, and it is likely that future versions of <code>ne</code> will
support optionally macros written in REXX.
<p><code>ne</code> has been written with sparing resource use as a basic goal.
Every possible effort has been made to reduce the use of <span class="sc">cpu</span> time and
memory, the number of system calls, and the number of characters output to
the terminal. For instance, command parsing is done through hash
techniques, and the escape sequence analysis uses the order structure of
strings for minimizing the number of comparisons. The optimal cursor
motion functions were directly copied from <code>emacs</code>. The update of
files using syntax highlighting is as lazy as possible: modifications
cause just the update of the current line, and the rest of the screen is
updated only when you move away. The search algorithm is a simplified
version of the Boyer-Moore algorithm that provides high performance with a
minimal setup time. An effort has been taken to move to the text segment
all data that do not change during the program execution. When the status
bar is switched off, additional optimizations reduce the cursor movement
to a minimum.
<p>A word should be said about lists. Clearly, handling the text as a
single block with an insertion gap (a la <code>emacs</code>) allows you to
gain some memory. However, the management of the text as a linked list
requires much less <span class="sc">cpu</span> time, and the tradeoff seems to be
particularly favorable on virtual memory systems, where moving the
insertion gap can require a lot of accesses to different pages.
<p>In practice, <code>ne</code> occupies less memory than any memory-based editor
we are aware of. (Of course, this does not take into account some
sophisticated features of <code>ne</code>, such as unlimited undo/redo, which
can cause major memory consumption.)
</body></html>
|