Re: [Midnight Commander] #2: savannah: UTF-8 locales not supported
Hi all, On po 5. ledna 2009, Ticket System wrote: #2: savannah: UTF-8 locales not supported -+- - Reporter: slavazanko | Owner: slavazanko Type: defect | Status: accepted Priority: major | Milestone: UTF8 Support Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+- - Changes (by slavazanko): * owner: = slavazanko * status: new = accepted * milestone: Recode Support = UTF8 Support Comment: I propose this patches: http://www.fi.muni.cz/~xbenes5/projects/mc/mc- utf8.tar.gz Link from: http://mail.gnome.org/archives/mc- devel/2007-December/msg1.html IMHO, this more right patches than patches from Fedora, Suse etc (no stupid #ifdef..#else...#endif in many source files). The ifdefs should not be the main criteria to judge the quality of patches. They are there to allow compilation without wchar.h. I think that they can be easily replaced by some wrapper functions if neccessary. Here are other points: The distributions patches: - are much more tested and the most of places in the code that needs changes was already identified and fixed somehow - the implementation uses utf-8 strings in mc itself and wchar_t strings in editor Patches from http://www.fi.muni.cz/~xbenes5: - do not include utf-8 support in editor at all - there was not so much testing - I didn't look at the implementation details Vladimir ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24505] loading X11 library is broken
URL: http://savannah.gnu.org/bugs/?24505 Summary: loading X11 library is broken Project: GNU Midnight Commander Submitted by: nadvornik Submitted on: Thu 09 Oct 2008 09:55:07 AM GMT Category: Keyboard input Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: 4.6.2-pre1 Operating System: GNU/Linux ___ Details: mc loads X11 library via the symlink libX11.so. This symlink is usually not available on production systems, because it belongs to development package. mc should load libX11.so.6 or better detect the library version in configure. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24505 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: comparing our patches
On neděle 09 březen 2008, Patrick Winnertz wrote: Hello, I guess a good start to get a repository with a set of all of our patches is to get a overview about all of them, in order to find patches which are identical in every distribution. In order to do this I've set up a git repository on my own server. (I think when we have a freedesktop project I'll surely move everything to freedesktop's git). (See https://git.der-winnie.de) I've created in this git repo several branches. For each distribution one. It would rock if you can send me a login name + a ssh-key and I'll give you ssh access to this repository. Then we can start slowly to add patches there. (Not everything at once, but one patch per commit, in order to make merging easier). Please give the patches useful names (not something like: main.c.patch but: adding_feature_foo.patch). After each distribution has checked in the patches, I would suggest that we start to have a look at patches/patchseries with a specific aim. Unfortunately I could not find time to read git documentation. Can you please send a short description how to submit the patches? Vladimir ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc and utf-8 again but different
On pondělí 12 listopad 2007, Rostislav Beneš wrote: Problems: invalid strings - I chose a defensive way, no invalid strings are loaded in mc. Only panels can handle invalid file names. I'm not sure, that I found every place, where invalid strings can appear. API functions like str_next_char, str_prev_char, str_length do not support invalid strings. Invalid strings support str_term_* function (formation for drawing on screen). It seems that there is the same bug as in the old utf8 patches: move and copy should preserve the original broken sequences, i.e. it should be possible to copy a file with 8859 name even if mc is in utf-8 mode. Both versions of utf-8 patch replace the invalid utf-8 sequences with questionmarks in target file name. -- Vladimir Nadvornik ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc and utf-8 again but different
Hi Rostislav, On pondělí 12 listopad 2007, Rostislav Beneš wrote: But when I swad my edits in mc, I changed my mind. I rejected utf-8 everywhere idea and checked out the newest version of mc. I designed api for strings (I assumed it before, so no big problem) and make variant for ascii, 8bits encodings and utf-8 (and possibly other encodings, that support backward reading). I imported good ideas from previous attempt and created final set of 30 patches. Each patch has small comment in mc-utf8.txt. Utf-8-patch don't occur in my pathces. The string api is a great improvement over the original utf-8 patches. The code is now much more readable. Nice work. I can see that you did not patch the internal editor. Did you look into it? Do you have any comments? http://www.fi.muni.cz/~xbenes5/projects/mc/mc-complete.tar.gz I tried to run this in utf-8 xterm and it does not work. It seems that a call to SLutf8_enable(-1) in slang_init() is missing. What version of slang did you use? -- Vladimir Nadvornik ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Switching the internal editor between byte and UTF-8 mode
On čtvrtek 18 říjen 2007, Roland Illig wrote: Hi, in recent discussions, there has often been the question whether the editor should be converted to UTF-8, and indeed, many Linux distributions have chosen to patch mc so that it does. I would at least like to keep the possibility of editing plain binary files, so I suggest The UTF-8 patch does not break editing binary files. The invalid UTF-8 sequences are preserved. Or do you mean anything else? to add a new option to the editor configuration where you can swap between byte-mode and UTF-8 mode. IMHO this is not necessary. The UTF-8 patch for editor uses wchar_t internally and it should work for all cases. What is missing is a possibility to use different encodings for filesystem and terminal, but it is a problem of whole MC, not limited to the editor. I currently don't have time to implement it, it's just that it would be nice to have. :) Vladimir Nadvornik ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #19328] MC fail to notice when archive is replaced
Follow-up Comment #1, bug #19328 (project mc): Some VFS (for example tar and cpio) can detect changed archives, others (bzip, extfs) can't. There is no consistent support of change detection in VFS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19328 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Request for discussion - how to make MC unicode capable
On Sunday 25 February 2007 14:41, Leonard den Ottolander wrote: Hello Pavel, On Sat, 2007-02-24 at 14:57 +0200, Pavel Tsekov wrote: I'd like to initiate a discussion on how to make MC unicode deal with multibyte character sets. The current utf-8 patches are based on utf-8 support in glibc. I don't know if utf-8 is needed on other systems. Just a few thoughts: - Because multibyte is rather more memory hungry I think the user should still have the option to toggle the use of an 8bit path either in the interface or at compile time. This means where the UTF-8 patches replace paths we should preferably implement two paths. The situation with the utf-8 patches is following: In editor the utf-8 charset is converted to wchar. This requires 4 times more of memory, but allows to keep the code almost the same. In the rest of mc the utf-8 charset is used directly and the memory requirements are more or less the same as with 8bit charsets. - I suppose a lot of the code of the UTF-8 patch can be reused, only we will need to add iconv() calls in the appropriate places. libiconv is already expected so not much trouble with the make files there. Iconv should only be used for the multibyte path, not the 8bit path. Using the multibyte path would still enable users to translate from one 8bit charset to another. - Unsupported character substitution character should be an ini option (and define some defaults for all/many character sets). (I'm not sure question mark is supported in all character sets.) - Users should be able to set character set per directory (mount). Of course there should be a system wide default taken from the environment (but also overridable). - Copy/move dialogs should have a toggle to iconv the file name or do a binary name copy. - Maybe copy/move dialogs should also have a toggle to iconv file content, which could be quite usable for text files. A warning dialog on every copy/move (that the user explicitly has to disable) might be a good addition then, to help uninformed users avoiding to screw up their data. The code in charsets.c is not compatible with utf-8 and needs to be completely rewritten. For example, the function convert_to_display(char *str) can't be used for converting to utf-8 where the string actually grows. With the current utf-8 patches charsets can't be used in utf-8 locales. -- Vladimir Nadvornik developer - SUSE LINUX, s. r. o.e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel:+420 284 028 967 190 00 Praha 9 fax:+420 284 028 951 Czech Republic http://www.suse.cz ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
On Monday 12 June 2006 10:55, Jindrich Novy wrote: Please take notice. It would probably be good if Vladimir and you could keep your UTF-8 patch sets in sync. It just seems wasted effort to do this in two places independently. Some inter-distro communication is not going to hurt. Maybe these patches should be centrally maintained in a contribs tree. The problem is that Vladimir and me use different versions of mc. My approach is to be more in sync with upstream so that there's a more recent CVS snapshot in Fedora for now because of a very rare release period of mc. This helps me to do only minimal changes when I want to send a patch to upstream. SuSE uses the stable mc-4.6.1, AFAIK. It would not be a problem to have a more recent mc snapshot in openSUSE Factory. Even better, if it is synced with Fedora. +1 for storing useful patches in contrib. It would be quite hard to keep them in sync with devel mc though. Good idea. However we need a long-term solution. We should discuss what must be done to have UTF support in upstream. -- Vladimir Nadvornik ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
In non-UTF-8 mode slang2 behaves a bit different than the patched slang1. As a result, mc does work with 8bit encodings, like 8859-2 or KOI8. The attached patch fixes the SLsmg_write_nwchars() function to be fully compatible with the slang1 version and uses it consistently instead of SLsmg_write_char(). It should be applied on top of all the previous patches. Thanks for the patch. The last hunk didn't apply as there's no view_add_character used in editdraw.c. My patch is based on mc-4.6.1 The idea is to replace all occurrences of SLsmg_write_char with the now fixed SLsmg_write_nwchars, because it is the only way that works in all locales. -- Vladimir Nadvornik ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
On Saturday 12 November 2005 20:59, Leonard den Ottolander wrote:
Hi Bart, list,
On Tue, 2005-09-20 at 08:14 +1200, Bart Oldeman wrote:
Basically you'd need to apply Fedora's patch, and then (sorry no proper
patch here but it's not a big deal)
Attached you'll find a proper patch. I've moved the hunk from global.h
to myslang.h (and dropped the inclusion of slang.h as it is redundant).
Jindrich, please merge this patch with the UTF8 patch. You might even
consider to build the next mc for FC --with-screen=mcslang, as I see the
FC development tree does not yet feature slang-2.
Hi all,
In non-UTF-8 mode slang2 behaves a bit different than the patched slang1.
As a result, mc does work with 8bit encodings, like 8859-2 or KOI8.
The attached patch fixes the SLsmg_write_nwchars() function to be fully
compatible with the slang1 version and uses it consistently instead of
SLsmg_write_char(). It should be applied on top of all the previous patches.
--
Vladimir Nadvornik
developer
-
SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED]
Drahobejlova 27 tel:+420 2 9654 2373
190 00 Praha 9 fax:+420 2 9654 2374
Ceska republika http://www.suse.cz
diff -ruN mc-4.6.1.orig/edit/editdraw.c mc-4.6.1/edit/editdraw.c
--- mc-4.6.1.orig/edit/editdraw.c 2006-06-07 11:57:19.0 +0200
+++ mc-4.6.1/edit/editdraw.c 2006-06-07 11:56:30.0 +0200
@@ -234,7 +234,7 @@
lowlevel_set_color (color);
}
#ifdef UTF8
- SLsmg_write_char(textchar);
+ SLsmg_write_nwchars(textchar, 1);
#else
addch (textchar);
#endif
diff -ruN mc-4.6.1.orig/src/help.c mc-4.6.1/src/help.c
--- mc-4.6.1.orig/src/help.c 2006-06-07 11:57:19.0 +0200
+++ mc-4.6.1/src/help.c 2006-06-07 11:56:30.0 +0200
@@ -461,7 +461,7 @@
len = mbrtowc(wc, p, MB_CUR_MAX, mbs);
if (len = 0) len = 1; /* skip broken multibyte chars */
- SLsmg_write_char(wc);
+ SLsmg_write_nwchars(wc, 1);
p += len - 1;
} else
#endif
diff -ruN mc-4.6.1.orig/src/util.c mc-4.6.1/src/util.c
--- mc-4.6.1.orig/src/util.c 2006-06-07 11:57:19.0 +0200
+++ mc-4.6.1/src/util.c 2006-06-07 11:56:30.0 +0200
@@ -58,8 +58,26 @@
#if SLANG_VERSION = 2
void SLsmg_write_nwchars(wchar_t *s, size_t n)
{
- while(n--)
- SLsmg_write_char(*s++);
+if (SLsmg_is_utf8_mode()) { /* slang can handle it directly */
+ while(n-- *s)
+ SLsmg_write_char(*s++);
+}
+else { /* convert wchars back to 8bit encoding */
+mbstate_t mbs;
+ memset (mbs, 0, sizeof (mbs));
+ while (n-- *s) {
+ char buf[MB_LEN_MAX + 1]; /* should use 1 char, but to be sure */
+ if (*s 0x80) {
+ SLsmg_write_char(*s++); /* ASCII */
+ }
+ else {
+ if (wcrtomb(buf, *s++, mbs) == 1)
+ SLsmg_write_char((wchar_t)(buf[0]));
+ else
+ SLsmg_write_char('?'); /* should not happen */
+ }
+ }
+}
}
#endif
diff -ruN mc-4.6.1.orig/src/view.c mc-4.6.1/src/view.c
--- mc-4.6.1.orig/src/view.c 2006-06-07 11:57:19.0 +0200
+++ mc-4.6.1/src/view.c 2006-06-07 11:56:30.0 +0200
@@ -852,7 +852,7 @@
#ifndef UTF8
#define view_add_character(view,c) addch (c)
#else /* UTF8 */
-#define view_add_character(view,c) SLsmg_write_char(c)
+#define view_add_character(view,c) {wchar_t tmp=c; SLsmg_write_nwchars(tmp, 1);}
#endif /* UTF8 */
#define view_add_one_vline() one_vline()
#define view_add_string(view,s)addstr (s)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15576] Switching panels in long mode
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15576 Summary: Switching panels in long mode Project: GNU Midnight Commander Submitted by: nadvornik Submitted on: Mon 01/30/06 at 16:58 Category: Core Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Release: current (CVS or snapshot) Platform Version: GNU/Linux ___ Details: We got this bugreport in our bugzilla: == Either in console or X terminal start mc , press F9 and customize directory listing mode for both panels as 'long file list' . Now after you have each pannels fit on the entire entrminal, on the directory listing press inserttabtabinsert . On my system I see another panel instead of panel I was marking files on. Same for downtabtabdown and generally the last key may be any cursor movement key. === The bug seems to be introduced between 4.6.0 and 4.6.1pre3. I can reproduce it also with current snapshot mc-2006012023-1.i386.rpm. The original report is here: https://bugzilla.novell.com/show_bug.cgi?id=143265 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15576 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
