modern Linuxes by a patch for UTF-8 console output.
Previously, only BeOS used UTF-8. Tested with:
- the linux console
- xterm
- gnome-terminal
- konsole
- rxvt-unicode
using Fedora 11.
Tested with
- gnome-terminal
- xterm
- konsole
using Ubuntu 9.04
Known "features":
* high intensity colours were actually normal intensity, with a bold attribute set.
This worked fine under gnome-terminal, but xterm didn't have bold versions of all cp437 characters,
which screwed up the window borders in the IDE. And although konsole had them, I didn't like the font -
it converted all the double window borders to a very thick single-line border.
So I disabled the bolding of high intensity colours in all X11 terminals (TERM=xterm)
and replaced it with another ANSI attribute, that actually sets high intensity
colours, but is not (in theory) supported by all terminals. The linux console doesn't
support it - it actually wants a bold attribute, to set high intensity,
so that's why I enabled it only for X11 terminals. All the ones,
that I tried, worked fine (xterm, gnome-terminal,
konsole, rxvt-unicode, also the plain old rxvt, with a non-UTF-8 locale).
* Fedora 11 by default uses a 512-characters font, called latarcyrheb-sun16
for the linux text mode console, which disables the high intensity colours,
effectively reducing the set of available colours to only 8.
This is a hardware limitation of the VGA hardware and can be avoided by
using a 256-character font. It does not need to be cp437,
but it has to have an unicode mapping.
* I haven't tried other linux distros (and unix-like OSes, i.e. FreeBSD and Mac OS X) -
although they should work in theory, they might look bad, due to different fonts, etc.
git-svn-id: trunk@13651 -
libtool from Xcode 3.2 (Mac OS X 10.6) does not support all new linker
options (in particular -no_order_inits and -no_order_data, both of
which must be specified when compiling dynamic libraries with FPC and
Xcode 3.2)
git-svn-id: trunk@13645 -
terminals with kbAltLeft. Only applied to Haiku to stay on the safe side.
Fix use of up, down and right arrow keys in fpide under Haiku
(mantis #14491)
git-svn-id: trunk@13644 -
routines (just like "varargs"), because if implemented in Pascal then
on the callee side this array of const parameter is treated as a Pascal-
style array of const
* don't give the "cdecl'ared functions have no high parameter" warning for
array of const parameters for cdecl external routines and procvars
git-svn-id: trunk@13618 -
Darwin platforms, so that no data can be placed below that address.
This fixes the strange Windows-compatible resource API, which
assumes that addresses <64kb do not exist.
git-svn-id: trunk@13600 -
* left old cpu-specific set helper code under ifdef FPC_OLD_BIGENDIAN_SETS
in case someone wants to write new assembler set helpers (although most
of them should be optimally generated by the compiler already if
http://wiki.freepascal.org/FPC_HowToDo#Bit.28field.29_getting.2Fsetting_primitives
are optimally implemented)
git-svn-id: trunk@13582 -
change, resulting in slightly different DWARF debug information
(mantis #13508)
The cause was saving a node pointer in a local variable, processing
it further, and later on checking whether it changed by comparing
the stored and the current instance pointer. The problem was that
the node could have been freed and reallocated at the same address
(but with different contents), so this check sometimes resulted
in (hard to reproduce) false negatives.
git-svn-id: trunk@13580 -
byte is used for zero-termination (so we now always read blocks of
exactly 32kb from disk)
* set the first byte of the buffer to #0 when opening a file initially
git-svn-id: trunk@13576 -
we support writing more digits than are defined (due to Delphi-
compatibility) and
a) correcting the precision of undefined digits makes no sense
b) as a result, this precision correction made some numbers that can be
represented exactly in single precision inexact
-- fixes mantis #14230
* no longer perform precision correction while determining the whole part
of numbers (usually did nothing anyway, and the rest is caught by the
final rounding)
git-svn-id: trunk@13574 -
