Description

GNU moe is a powerful, 8-bit clean, console text editor for ISO-8859 and
ASCII character encodings. It has a modeless, user-friendly interface,
online help, multiple windows, unlimited undo/redo capability, unlimited
line length, unlimited buffers, global search/replace (on all buffers at
once), block operations, automatic indentation, word wrapping, file name
completion, directory browser, duplicate removal from prompt histories,
delimiter matching, text conversion from/to UTF-8, romanization, etc.

Moe respects your work. By default it won't automatically add, change, or
remove not even one byte in your files. Moe is a WYTIWYG (what you type is
what you get) editor.

Moe can easily edit thousands of files at the same time.

Moe tries to rationalize the keyboard commands. The <Alt> key is used for
harmless commands like cursor movements and scrolling. The <Control> key is
used for more "dangerous" commands like copying text blocks, deleting lines,
or exiting. The <Tab> key is used for file name completion and also
shows/hides the directory browser when moe asks for a file name to save or
load. In any case, the unlimited undo/redo capability of moe makes very
difficult to accidentally cause an irreparable damage to your files.

Moe uses the function keys so that the most frequent commands can be issued
with only one finger. The function key <F1> shows the online help, and <F10>
allows you to change the options. The online help and some experience with
text editors is all you need to start using moe. Reading the manual is only
required for more advanced uses of moe.

To have moe used as your default editor you need to set the environment
variables 'EDITOR=moe' and/or 'VISUAL=moe' in your shell initialization file
($HOME/.profile if you are using bash).

Moe needs a screen size of at least 24 lines by 80 columns. Take this into
account if running it from a terminal emulator.

If your text console doesn't show all the ISO-8859-15 characters, try the
command 'setfont' from the package 'kbd'. If your terminal emulator shows
characters with codes >= 128 incorrectly, verify that the encoding is set to
ISO-8859-15. (Other ISO-8859 encodings may also work). Verify also with the
command 'kbd_mode' that the keyboard is in the default (ASCII) mode. Use the
following commands to set the text console in the right mode for moe:

	kbd_mode -a
	setfont -v lat9w-16.psfu

Why moe does not use UTF-8 or other form of Unicode?

Moe uses ISO-8859-15 instead of Unicode (ISO 10646) because an 8-bit
character set (combined with romanization if needed) can convey meaning
safely and more efficiently than Unicode can. For many everyday computing
and communication tasks, an 8-bit code like ISO-8859-15 is much more
practical, efficient, and reliable than UTF-8. There is no such thing as an
'ambiguous', 'invalid', or 'out of range' ISO-8859-15 character.

An Unicode text console is both a danger and a waste. The right mode for
presenting a large variety of complex glyphs is graphical mode using a
specialized program. The text console is for a limited, portable character
set. Namely, for an universal character set.

Unicode is not an universal character set, but a bag where a lot of
unrelated character sets are thrown, even character sets for invented
languages like Klingon, along with an ever growing set of emojis. Many
glyphs appear multiple times with different codes, breaking the
correspondence glyph<->code, which creates ambiguity and consequently
insecurity. Unicode even provides private areas where the glyph associated
to each code is user-defined. Most computer tools recognize characters by
their code, not by their glyph. Therefore Unicode should not be used in
texts parsable by a computer.

Unicode is fine for non-parsable, non-searchable documents that must look
'pretty' or must combine different scripts (say Greek and Chinese), but not
so fine for things like file names, configuration files, or C++ source code.
Invalid UTF-8 characters in file names make archiving and filesystem
operations unreliable. Unicode greatly hinders parsability, interferes with
spam filters, and may even become a security risk by providing multiple
similar-looking variations of basic alphabetic, punctuation, and quoting
characters. Unicode also makes search difficult, unreliable, and
inefficient. For example, searching for a word like "file" in an Unicode
document may fail if the document uses the presentation form (compound
character) 'fi' instead of the two-character string "fi".

Even the code examples inserted in pdf files fail to compile sometimes when
copied because the program that generated the pdf replaced some ASCII
characters in the example with "prettier" Unicode counterparts. Unlike moe,
those programs do not respect your work.

About the unreliability of searching in Unicode strings, the GNU grep manual
warns that the behavior of case insensitive search is well specified only
for lowercase-uppercase pairs, and it is unspecified in all other situations.

About the inefficiency of Unicode, see for example this quotation from the
GNU grep manual:

    Generally speaking grep operates more efficiently in single-byte
    locales, since it can avoid the special processing needed for multi-byte
    characters. If your patterns will work just as well that way, setting
    LC_ALL to a single-byte locale can help performance considerably. [...]
    Outside the C locale, case-insensitive search, and search for bracket
    expressions like [a-z] and [[=a=]b], can be surprisingly inefficient due
    to difficulties in fast portable access to concepts like multi-character
    collating elements.

Replacing all the 8-bit character sets with Unicode is like trying to
simplify transportation by standardizing on the same kind of (excessively)
large vehicle. I.e., forcing everybody to use a vehicle as large as the
largest vehicle anybody may need. Just like owning a normal car may be
orders of magnitude cheaper than owning a four-engined airliner, text tools
using an 8-bit character set may be orders of magnitude more efficient than
those using Unicode.

Unicode strings (and therefore UTF-8 strings) are not unique; Unicode allows
different ways of encoding the same character, for example using precomposed
characters, composing accents, or presentation forms. This (along with
zero-width characters) may be used to elude keyword-based spam filters, and
makes searching and parsing even more difficult.

Unicode allows user tracking by means of invisible text marking. Any string
can be converted into its binary form and then recoded into a string of
zero-width characters, which can then be invisibly inserted into the text.
If the text is posted elsewhere, the zero-width character string can be
extracted and the process reversed to figure out the identity of the person
who copied it. Using moe and ISO-8859-15 such invisible marking is more
difficult, more fragile, and easier to discover.

In my opinion, the greatest invention of humankind is the language, and the
greatest error was inventing more than one. The language barrier is the
ultimate obstacle to inclusiveness, and therefore linguistic diversity is a
problem that needs to be fixed. Every human being has the right to be taught
exactly one language that gives him or her full access to the whole human
culture and allows him or her communicate with everybody else. Equal rights
can't be achieved without equal language. Forcing someone to learn a second
language in order to access knowledge is wasteful and ineffective: twice as
many words need to be memorized and most people will never be so proficient
in the second language as they are in their native language. Language is a
tool, not an end in itself.

The only sane approach to software internationalization is to adopt or
develop a lingua franca. Such lingua franca should be fully phonetic and
should fit in an 8-bit character set like ISO-8859-15 for ease of use by
both humans and computers. Unicode is not a viable solution. It is just the
standardization of the current linguistic chaos.

Moe is an efficient and reliable ISO-8859 editor. If you need full Unicode
support or interfacing to an UTF-8 terminal, you'll need to use another
editor. If your distribution is forcing you to use Unicode, I advise you to
use another distribution or Operating System.


Copyright (C) 2005-2021 Antonio Diaz Diaz.

This file is free documentation: you have unlimited permission to copy,
distribute, and modify it.

The file Makefile.in is a data file used by configure to produce the
Makefile. It has the same copyright owner and permissions that configure
itself.
