Re: utf8 patch for mc, slang 2 version
On Tue, Sep 20, 2005 at 10:11:28PM +0200, Bálint Kardos wrote: But even with all patches and stuff, I see the following Unicode glitches: - the utf-8 chars are not diplayed in the dir list (on Ubuntu, everything is OK) for ÉÁŰŐÚÖÜÓ I see EAUOUOUO (upper, lowercase all wrong) - the files/dirs that contain the unicode chars, are still not properly aligned to the grids What could cause Darwin to behave such unpredictably? In the filesystem, there's another error: if you do 'ls', the alignment of the columns after the unicode chars are broken as well. Unices use NFC, while MacOS uses NFD representation of accents (at least for filenames, I don't know how about file contents). NFC means each accented character has its own composed value, that is, one Unicode entity, which is usually stored as two (maybe three) bytes in UTF-8. NFD composes the characters from two Unicode entities, first the unaccented letter, followed by an accent on its own. Its UTF-8 representation hence takes three bytes (one for the unaccented letter and two more for the accent). There are different levels of Unicode specified, I guess supporting NFD requires a higher level of conformance since it's a harder job than supporting NFC. I bet mc's UTF-8 patch only supports NFC. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #7936] UTF-8 locales not supported
Follow-up Comment #2, bug #7936 (project mc): I saw the UTF-8 problem addressed for the 4.7 branch, which probably is not to be expected in the really near future. Since for multi-language requirements (German, English, Russian, Hebrew) I am depending on the UTF-8 environment, I would be more happy to see at least the filenames and editor issues addressed earlier (I can live with the English localization of the menus etc ;) As Egmont already wrote almost a year ago: There are patches available with the sources from Fedora and SuSE. For an experienced programmer, hence, it should not be too difficult to apply them? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7936 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
Hi, I've debuged it from the beginning, and: screen.c 762: // inserted wchar_t lonaka[100]; memcpy(lonaka,buffer,txtlen*sizeof(wchar_t)); lonaka[txtlen]=0; // end inserted printw (%*s, still, ); printw(%ls,lonaka); //SLsmg_write_nwchars ((wchar_t *) buffer, txtlen); printw (%*s, len - txtwidth - still, ); printw(/ls,lonaka); handles everything as expected, the right UTF-8 chars appeared on the screen. So text in the buffer is properly encoded. It is an Slang2 issue, but it's too compicated to figure out for the first blick, the problem in the slsmg.c file. Does anyone know why #define unix != 1 for darwin-ppc in mc (and/or) slang regards, Bálint Unices use NFC, while MacOS uses NFD representation of accents (at least for filenames, I don't know how about file contents). NFC means each accented character has its own composed value, that is, one Unicode entity, which is usually stored as two (maybe three) bytes in UTF-8. NFD composes the characters from two Unicode entities, first the unaccented letter, followed by an accent on its own. Its UTF-8 representation hence takes three bytes (one for the unaccented letter and two more for the accent). There are different levels of Unicode specified, I guess supporting NFD requires a higher level of conformance since it's a harder job than supporting NFC. I bet mc's UTF-8 patch only supports NFC. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
Hello, Maybe this discussion should be moved to general list - mc at gnome dot org. On Wed, 21 Sep 2005, [ISO-8859-1] Bálint Kardos wrote: Hi, I've debuged it from the beginning, and: screen.c 762: // inserted wchar_t lonaka[100]; memcpy(lonaka,buffer,txtlen*sizeof(wchar_t)); lonaka[txtlen]=0; // end inserted printw (%*s, still, ); printw(%ls,lonaka); //SLsmg_write_nwchars ((wchar_t *) buffer, txtlen); printw (%*s, len - txtwidth - still, ); printw(/ls,lonaka); handles everything as expected, the right UTF-8 chars appeared on the screen. So text in the buffer is properly encoded. It is an Slang2 issue, but it's too compicated to figure out for the first blick, the problem in the slsmg.c file. Does anyone know why #define unix != 1 for darwin-ppc in mc (and/or) slang regards, Bálint Unices use NFC, while MacOS uses NFD representation of accents (at least for filenames, I don't know how about file contents). NFC means each accented character has its own composed value, that is, one Unicode entity, which is usually stored as two (maybe three) bytes in UTF-8. NFD composes the characters from two Unicode entities, first the unaccented letter, followed by an accent on its own. Its UTF-8 representation hence takes three bytes (one for the unaccented letter and two more for the accent). There are different levels of Unicode specified, I guess supporting NFD requires a higher level of conformance since it's a harder job than supporting NFC. I bet mc's UTF-8 patch only supports NFC. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13729] ctrl- hotlist key won't work under ttyi
Follow-up Comment #1, bug #13729 (project mc): i came up with this hack - it just makes the right alt key not be recognized as an alt key at all. i have no idea how to fix it properly - one'd have to ask the keymap whether the ralt is part of the keycode or an additional modifier. hard-coding exceptions activated after a keymap query might work, but is utterly ugly. well, the code already has similar hacks to accomodate all types of terminals ... ___ Additional Item Attachment: File name: ctrl-backsl-de-fix.diffSize:0 KB work-around hack http://savannah.gnu.org/bugs/download.php?item_id=13729item_file_id=2983 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13729 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #9257] Segmentation fault when returning from stopped state
Ok. I was the bug reporter, and I could only reproduce the bug on a MC distributed with a SuSE release. It doesn't seem to happen with newer versions. Luciano Pavel Tsekov wrote: Follow-up Comment #4, bug #9257 (project mc): I think this can be closed as fixed now. If the bug manifests itself again the bug entry could be reopened. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=9257 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
