Yes, yes, it probably made sense 30 years ago as a way to save a tiny
amount of memory, but especially when interspersed in structures that
have pointers (aligned to 64 bits these days), it's not even saving
memory today. And it makes us fail in nasty ways when looking at files
with long lines.
So just make them 'int'. And if you have a line that is longer than
2GB, you only have yourself to blame. I no longer care.
In case anybody care, the "test-case" for this was a lovely UDDF file
with a binary divecomputer dump encoded as an XML element. Resulting in
a lovely 41kB single line. Not what poor micro-emacs was designed for,
I'm afraid.
I really should just learn another editor, rather than continue to
polish this turd.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This uses the four high bits for the meta and control key sequences.
This means that we will be limiting our Unicode space to 28 bits, but
that's more than we really need.
It *would* be nicer if we just used the sign bit to mark "we have meta
character information") but that would require bigger changes. And we
really don't need to worry about 30-bit unicode. Small steps, remember.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Let's just plan on being fully utf8 some day. We're not there yet, and
maybe we'll never be, but having the halfway mode is not useful either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This constant is used only there, so there is no reason for it to be
in estruct.h
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These two constants are only needed/used by the posix.c file,
so just define them there.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This constant is only used in line.c. So just keep it there.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
uemacs is not a subprogram and doesn't seem it will be, so there is no reason
to leave this macro. And this macro is defined to 0, so we never reach the path
where we test for this macro.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The implementation of these functions are doing anything at all at this moment.
So cleanup a bit the code by removing fnclabel and spal functions completly.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Compiles on Mac OS X 10.6.4.
setmode() is renamed to setemode() to avoid conflict with OS X's unistd.h's
setmode().
Modify Makefile to enable the appropriate DEFINES to compile on Mac OS X.
Signed-off-by: Yong Luk Stanley Elijah Goh <stan@t0xt.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a basic usage() function to support the --help option.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
NOTE! MicroEmacs is very much a byte-based editor, and the new utf-8
support is purely an issue of terminal input and output. The file
contents themselves are in the 8-bit space. In that space, Unicode is
the same as Latin1.
The new mode is called "utf-8", and is enabled automatically by the
new emacs.rc when $LANG contains the substring "UTF-8".
I'm sure people would like to some day also edit real UTF-8 contents,
rather than just edit old 8-bit Latin1 contents in a UTF-8 terminal.
However, that's an independent (and much bigger and thornier) issue.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is a slightly updated version of uemacs-PK (PK is Pekka
Kutvonen) which was used at Helsinki University a long time
ago. My fingers cannot be retrained.
