========================================================================
TeDit: A minimalistic editor with TECO tendencies
========================================================================
TeDit [Text Editor] is a simple text editor which behaves, or aims to
behave, in a similar fashion to TECO. It strives for simplicity and
transparency. It should be simple in design, and one day... simple to
use, extend, and love!
I have also written it entirely in TECO so far, and have banned the use
of other text editors than itself and TECO for the development. This
makes me see what I need to add, what works, and what can be improved.
It is in an early phase (just started) so do not expect much, but it's
something... Anyways, if you want to look at what gives me all ideas
for TeDit, look at TECO.
------------------------------------------------------------------------
Getting started, installation.
------------------------------------------------------------------------
The first step is to install the editor. This process will differ and
is explained on their designated pages. Two TECO editors I like so far:
* TECOC: A direct copy of older TECO in C for portability. It behaves
and works like TECO PID-11, which could be found at MIT at the time.
It lets me see the buffer I execute actions at, removes distractions,
and gives a broader context of earlier commands.
* SCITECO: A more modern editor featuring themes, optional GTK GUI,
syntax highlighting, and live previews before a command is executed.
I am currently writing this in TECOC with scroll/video mode enabled.
------------------------------------------------------------------------
TECO does not have a live update, at least not older TECO.
And so think of the `commands` you write as a small script that
gets executed on the text buffer before you save it.
------------------------------------------------------------------------
TECO cheat sheet
------------------------------------------------------------------------
Note: NUM = Integer, REG = Register (e.g., P, X, 1), STR = Text String.
------------------------------------------------------------------------
EBSTR$ - Opens file to buffer.
EX$$ - Saves and closes buffer/file.
ECSTR$ - Executes system command and drops output into buffer.
MSTR$ - Executes a named macro.
ISTR$ - Inserts STR at cursor position.
J - Puts cursor at the start of the buffer (1:1).
ZJ - Jumps to end of buffer.
L - Goes down one line.
D - Deletes char at cursor.
K - Delete from cursor to newline.
SSTR$ - Searches for STR; puts cursor after first match.
NSTR$ - Global search for STR.
FSSTR$STR$ - Search for first STR and replace with second STR.
NUM<...> - Loop body X times (10<FSWorld!$Alice.$>)[NUM<func>].
NUM"COND...' - If NUM gives TRUE with conditial do body
+ Conditials are: [E]qual to 0, [N]ot equal 0,
[G]reater than 0, [L]ess than 0.
NUMXREG$ - Saves X number of lines into X register.
GREG$ - Pastes data from X register into cursor position.
HT - Prints whole buffer.
V - Prints current line.
NUMT - Prints NUM number of lines from cursor down.
------------------------------------------------------------------------
END NOTE:
No command is executed before you hit ESC ESC (displays as `$$`)
To end a text insertion or search hit ESC once (`$`)
This is also in conds and loops.
Typing the char `$` yourself does not count as an ESC, even if it
produces the same char displayed in the command area.
Lower case and upper case are equal, I use upper case for
demonstration and as that is what is in documentation for legacy
reasons.
You may prefix commands with number in most cases. Those numbers
may also be negative, and basic math can be done.
------------------------------------------------------------------------
Quick-start : With an example
------------------------------------------------------------------------
First a simple example with commands explained above.
Here I start by searching for the string `Alice`, where you mark the end
of the string with a dollar-sign from pressing ESC, as you end any command.
If it is successfully it will return `-1`, and so if it does not find a
match for `Alice` it will return `0`.
You can then check that with `E`, and execute some command, where I
insert the string `Warning: Alice not found!`, you see that the end is
marked with the ESC dollar-sign. All commands end
like that, so its important to remember.
SAlice$"E IWarning: Alice not found!$ '
------------------------------------------------------------------------
Here is how you would write a "Hello World" program in pre-ANSI C inside
TECO (where '#' is the system prompt and '*' is the TECO prompt):
# teco -scroll:10
* EBmain.c$$
* Imain (void)
{
printf ("Hello, World!\n");
return 0;
}$$
* EX$$
The `EBmain.c` command opens the file buffer; if it does not exist, it
will create a new file on save. The dollar sign (`$`) represents the
escape character. Pressing ESC twice (`$$`) tells TECO to execute the
buffered commands. `I` stands for Insert, which is ended with a single
`$`. Finally, `EX$$` saves the buffer and closes the file.
------------------------------------------------------------------------
Updating to Modern C Standards:
To jump to the top of the file and add an include header:
# teco -scroll:10
* EBmain.c$$
* JI#include <stdio.h><LF>$
`J` moves the cursor to the very first position of the buffer (`1:1`).
`<LF>` represents a linefeed newline character.
------------------------------------------------------------------------
Replacing Text:
To change the output string from "Hello, World!" to "Hello Alice":
* Sello$DFSWorld!$Alice$$$
* EX$$
`S` searches for a string and places the cursor right after it. `D`
deletes the character under the cursor. `FS` performs a search-and-
replace operation, taking two arguments separated by a single `$`.
------------------------------------------------------------------------
What can modern software learn from TECO?
------------------------------------------------------------------------
The following views are entirely subjective notes on software design:
1. Command Chaining
If I need two commands to interact with each other, I can just chain
them directly. There is no need for the strict separation commonly
seen in modern CUA-bound user interfaces.
------------------------------------------------------------------------
2. Staged Execution
Separating command writing from execution—and then from final saving—
is incredibly powerful. I can run `FSfoo$bar$` and peek at the result
before committing to it, avoiding history pollution via "undo".
------------------------------------------------------------------------
3. UI Separation
Keeping the action/command logs separated from the actual content
buffer creates a cleaner visual workspace. It eliminates clutter and
reduces mental exhaustion. This also gives more context to the user
while they write commands.
------------------------------------------------------------------------
4. Simplicity in Design
We should value simplicity in design over simplicity in usage. Avoid
creating duplicate, slightly modified commands; instead, chain simple
primitives together to achieve a different output. A simple design will
be easier to manage, let grow and avoid unneccacary complexety.
Duplication shouldn\t be a thing, but rather find ways to use what you
alredy have, as well as not trying to overcomplicate it. If it is
simple the user will understand how to use it better.
------------------------------------------------------------------------
5. Extensible Macros
Macros allow complex actions to be recorded, replayed, and shared.
EMACS itself originally started as a collection of Editor Macros for
TECO. A simple system base that users can easily extend via macros is
highly valuable.
------------------------------------------------------------------------
So, what is TECO?
------------------------------------------------------------------------
To properly know where I get my inspiration for this editor, one should
look at TECO. This section is a quick look into TECO, the predecessor
of ED and EMACS.
TECO started as a corrector, where TECO stands for [T]ext [E]ditor and
[CO]rrector. It did not load files or whole pieces at once, as computers
at the time were simply not able to do that. Instead, it loaded pages
into the buffer—think of it like a section of the file.
In addition, when it was first made in 1962, it did not have fancy
features like TECO PID-11. TECO simply kept track of the cursor point,
and let you print a line. Luckily we have VIDEO now, enabled with the
"-scroll:x" flag where "x" is the number of lines reserved for the
command area. With VIDEO enabled, it will preview the buffer and the
area around the cursor as you execute commands.
While the history of this text editor is extensive, we should start with
how one uses it, what it offers over other editors, and what we can
learn from it. I am writing this partly to properly lay out my thoughts
and also so I can look back later. In addition, ED(1)JOYER on Discord
said he could be interested to see a basic, simple quick-start, so I
will refer him and others to this page.
------------------------------------------------------------------------
What TECO reinforce in me
------------------------------------------------------------------------
Simplicity promotes transparency, auditability, and trust. When a tool
is simple in design, it becomes much easier to inspect, catch bugs, and
verify that it contains no malicious behaviour.
Simplicity does not automatically mean a project must remain small.
EMACS is massive, yet it remains fundamentally simple because it is made
up of many small, understandable pieces of code working together. The
goal should always be clarity in how a program functions, rather than
chasing a high quantity of built-in features.
We can just look out at the tools that are popular today. VS Code (and
all of the forks), discord, postman and more are using a full blown,
modern and recource intensive browser (electron, which use chromium)
for what should be native apps. For most electron applications one
does not need a browser. It also is so complex and obscure and filled
with abstractions that it is more or less impossible to really know
what it does and happends under the hood. So here the `normal` tools
people use are so full of abstractions that few even know what really
happens, while Emacs, which can do more than VS code++ is native in
C and has a simple codebase I can just jump into and read and I will
understand it easily.
Simplicity keeps a codebase maintainable, but also explorable and easy
to look at as an outsider, but again, for the tooling I brought up here
the developers and owners of the companies do not want that to be easy
for someone to fork and make their own, and most are also propiatary,
a black box you just have to trust.
Simplicity is not just for the maintainer, but also the user. If a
developer thinks abstraction software to the point of it being unreadable
then one should ask themselves, excatly why do they do that, what do
they gain from it?