On 19.11.2010 01:12, Damian Okrasa wrote:
#define TNAME st
Nice, that worked, thanks!
On 17.11.2010 14:54, Damian Okrasa wrote:
changed FONT and BOLDFONT, more fonts are selected
fixed bug in ttyread, does ncurses apps work correctly?
The cursor keys did not work in midnight commander (they did last
version), and i get a lot error messages like this one:
erresc: unknown csi ESC
2010/11/18, Stefan Mark m...@unserver.de:
On 17.11.2010 14:54, Damian Okrasa wrote:
changed FONT and BOLDFONT, more fonts are selected
fixed bug in ttyread, does ncurses apps work correctly?
The cursor keys did not work in midnight commander (they did last
version), and i get a lot error
changed FONT and BOLDFONT, more fonts are selected
fixed bug in ttyread, does ncurses apps work correctly?
st-utf8.diff
Description: Binary data
On Wed, Nov 17, 2010 at 2:54 PM, Damian Okrasa dokr...@gmail.com wrote:
changed FONT and BOLDFONT, more fonts are selected
fixed bug in ttyread, does ncurses apps work correctly?
It's much better now. Curses apps still have the same problem, but
changing TERM back to xterm made them work
I've committedpushed your patch.
If someone has a problem with a curse app make sure TERM is set to xterm.
Also, drawing is a bit slower now that it support utf8.
2010/11/15, Aurélien Aptel aurelien.ap...@gmail.com:
On Sat, Nov 13, 2010 at 10:53 PM, Damian Okrasa dokr...@gmail.com wrote:
I removed the wchar_t completely, added some UTF-8 parsing functions.
No support for combining, bidi, doublecolumn etc. Markus Kuhn's UTF-8
stress test file is not
On Sat, Nov 13, 2010 at 10:53 PM, Damian Okrasa dokr...@gmail.com wrote:
I removed the wchar_t completely, added some UTF-8 parsing functions.
No support for combining, bidi, doublecolumn etc. Markus Kuhn's UTF-8
stress test file is not working 100% correctly (the decoder works
however, even
On Tue, Nov 16, 2010 at 12:16 AM, Aurélien Aptel
aurelien.ap...@gmail.com wrote:
...And gmail sent my email in ISO-2022-JP. Just perfect...
Anyway, the japanese string comes from here[1] (in utf8) in case you
can't read it.
1: http://www.columbia.edu/kermit/utf8.html
*sigh*
2010/11/14, cryptix cryp...@riseup.net:
Hi,
On 13.11.2010, at 22:53, Damian Okrasa wrote:
I removed the wchar_t completely, ...
great! After a small adaption it seems to work flawlessly.
In the form you posted, my compiler doesn't like the first constant B0.
st.c:65:8: error: expected
On Sun, Nov 7, 2010 at 10:50 PM, Moritz Wilhelmy c...@wzff.de wrote:
Whatever you want, wchar_t is not the solution.
Amen.
Added it to the cat-v fortunes file:
http://fortunes.cat-v.org/cat-v/
uriel
On Sun, Nov 07, 2010 at 10:09:28PM +0100, Damian Okrasa wrote:
LC_CTYPE=en_US.UTF-8 should be set for UTF-8, it has some bugs and
sometimes doesn't recognise good UTF-8 string.
http://img51.imageshack.us/img51/4591/201011072157261024x768s.png
I started with something similar last week.
On 07.11.2010 22:09, Damian Okrasa wrote:
LC_CTYPE=en_US.UTF-8 should be set for UTF-8, it has some bugs and
sometimes doesn't recognise good UTF-8 string.
http://img51.imageshack.us/img51/4591/201011072157261024x768s.png
Woah, Great patch! Thanks a lot!
Hi,
First of all, thanks Damian! Always nice to see some contribution.
On Mon, Nov 8, 2010 at 9:53 AM, Petr Sabata psab...@redhat.com wrote:
I started with something similar last week. However, as already mentioned;
wouldn't it be better to go with just char* and Xutf8* functions instead
of
Whatever you want, wchar_t is not the solution.
15 matches
Mail list logo
