| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
.cc, moving its contents into the new stepdown.cc and strings.cc.
(The latter also got many donations from libutil.h.)
Down with stuff! Up the new flesh!
|
| |
|
|
|
| |
Sometimes, they're there to emphasize a break between two sections of code,
which is good. In a majority of cases, though, they're just inconsistent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I had to rename distance() (in coord.h) to distance2() because it conflicts
with the STL function to compare 2 iterators. Not a bad change given how it
returns the square of the distance anyway.
I also had to rename the message global variable (in message.cc) to buffer.
I tried to fix and improve the coding style has much as I could, but I
probably missed a few given how huge and tedious it is.
I also didn't touch crawl-gdb.py, and the stuff in prebuilt, rltiles/tool
and util/levcomp.*, because I have no clue about those.
|
| |
|
|
|
|
|
| |
They cause problems on Android, and were slightly wrong anyway (if a
single line of an included config file is encoded in UTF-16 and has a
monstrous length, we'd waste twice as much memory as needed to hold it.
A world-shattering bug.).
|
| |
|
|
|
|
|
| |
There's no point in accumulating a string of wchar_t and then immediately
converting it to utf8 if we can accumulate it in utf8. This solves problems
on Windows and Android (neither of whom can run webtiles servers currently)
and reduces the code size somewhat.
|
| |
|
|
|
| |
While webtiles are not supported on Windows, and no sane Unix uses encodings
other than UTF-8, we can have local webtiles some day.
|
| |
|
|
|
|
| |
They're not that interesting and cloud code readability. What humans care
about is the conversion of Crawl's internal format to native strings (OUTS)
or native wide strings (OUTW, Windows only).
|
| |
|
|
|
|
|
| |
You don't need to specify the charset anymore, save for cset_ibm and
cset_dec which are for compatibility with legacy config files.
You can even use cset_ibm without char_set=ibm, it will work.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There are sadly some redraw errors when there's line-wrapping involved,
especially if you're editing something not at the end of the buffer,
but these appear to be not regressions so I left them for now.
I am tempted to just brute-force it by redrawing the whole thing and
let ncurses optimize it...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The database files are assumed to be always in UTF-8. This can make editing
them harder on Windows (some editors do cope, even notepad), but assuming the
system's locale would break running directly from git without installing.
Current uses are merely: (all in quotes.txt)
* "Alain René"
* "Rabbi Löw"
* "Öland"
* "Min son på galejan"
* typographical apostrophes
but it's likely it will be a bigger issue in the future (and if we ever do
translations, a lot bigger).
|
| |
|
|
|
|
|
| |
I had to change wchar_t to ucs_t, as Windows cripples it to 16 bits,
making it impossible to support most of Unicode. 32 bits will allow
proper behaviour at least in tiles -- and we might replace the win32
console as well.
|
| | |
|
| | |
|
| |
|
|
|
| |
Using ofstream requires huge hacks on Polish/Russian/etc Windows,
and is outright impossible on Vietnamese.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CSET_IBM and CSET_DEC are now merely presets and don't change the I/O encoding.
Doing I/O using any encoding other than the one configured using LANG/LC_* is
just wrong and no well-behaving program should do that.
This does require changes on CAO/CDO, but they would fix problems with ttyrec
and spectating as well.
To fix: ncursesw replaces unrepresentable characters with spaces, we'll have
to replace them by hand.
|
|
|
Their intended use is:
* local: config files, morgues. File names (non-Windows).
* utf8: everything internal. Data files (des, database).
* utf16: (Windows only) file names and similar syscalls.
On Unix systems, the "local" charset is in a vast majority of cases UTF-8,
but we can't rely on that and have to convert anyway.
|
