I'm filing this bug as a notice, as I don't think it will get fixed any time soon - the initial report was bug 101522 comment 33. The in-tree mc uses debian patches, I'll be talking about Redhat ones, but they (the patches) seem to have the same origin. There are 3 problems I've noticed: 1. view is broken - it simply doesn't display any double-width chars; the solution - a block that appeared in older utf-8 patches, but was removed later (probably cause the reason for it was forgotten) 2. in non-password input boxes, a dot appears beyond end of input for each double-width char entered 3. in password boxes two stars appear instead of one for each double-width char entered for those two, I added simple hacks, that seem to work, I'm not sure whether those are correct, but they seem to work
Created attachment 174081 [details, diff] diff between Redhat patch and the one I'm using As it's a diff between patches, it looks a bit silly, but should be readable. And if is still not clear, regardless of the fact, that Gentoo is using Debian patchset, it's affected by this bug too.
Yay! mc has a maintainer again (time for me to open some bottles of beer ;) happily reassigning to maintainer...
Frankly, I'd be much more happy if the upstream got back from the grave.
(In reply to comment #3) > Frankly, I'd be much more happy > if the upstream got back from the grave. > Exactly. I'm already handling a **** load of patchset for mc. I'll try to incorporate this into our patchset soon (this weekend, really it needs a lot of time to get these patches working together and applied in right order :-()
(In reply to comment #3) > Frankly, I'd be much more happy > if the upstream got back from the grave. Of course, I'd prefer this as well but I am also very happy that some Gentoo maintainer is taking care of one of those packages, I frequently use on nearly every Gentoo box I am involved in. Samuli, thanks for giving the mc-package some attention :)
Does this bug reproducible with mc 4.6.2?
(In reply to comment #6) > Does this bug reproducible with mc 4.6.2? > Definitely (you mean, if using that utf8 patch from your site, right ?). The fix is still working. As a sidenote: - on packaging: it should not use symlinks to autotools stuff and should not ship with autom4te.cache dir - on your new site: I thought ViewCVS would be hard to beat in "sucky VC web interface" category, but that trac view of git may just have done it, especially it's not working
(In reply to comment #7) > > Definitely (you mean, if using that utf8 patch > from your site, right ?). The fix is still working. > > As a sidenote: > - on packaging: it should not use symlinks to autotools stuff > and should not ship with autom4te.cache dir > - on your new site: I thought ViewCVS would be hard to beat > in "sucky VC web interface" category, but that trac view of git > may just have done it, especially it's not working > No, I'm not mc developer. But I consider developers should be aware of problems you described, so I'll give them link to this entry.
Please, test latest changes from git-repository of Midnight-commander (address: http://www.midnight-commander.org) UTF-8 sfutt completelly rewriten, I hope some bugs was closed.
(In reply to comment #9) > Please, test latest changes from git-repository of Midnight-commander (address: > http://www.midnight-commander.org) > > UTF-8 sfutt completelly rewriten, I hope some bugs was closed. > I will now use this bug to vent my frustration with the state midnight commander is, instead of restarting the flame war on mc-devel list, as I'm probably supposed to. First of all, I consider mc-4.6.2-pre1.tar.gz last valid mc release. I reject the 4.6.2 "release", among other for the use of mhl abomination. Yet I do disagree with the main mc "maintainer" (more like non-maintainer): till a valid release, midnight commander is, IMHO, dead upstream. Also, if a program in 2009 doesn't support utf8 on its own (without external patches), it's broken. And I still think, that track interface of git (at least the version used on www.midnight-commander.org/browser) is broken by design. While trac may work for svn (barely, though - I consider viewvc much more useful), for git it simply fails (unless I fail to see a link providing git's shortlog function, or at least something like viewvc's 'view=rev' - changeset link doesn't count, I'm talking about log view only, without changes). Having said all that, I still use midnight commander (with RedHat patches), cause it's simply too convenient. I do hope that the situation was solved during the time that passed since that discussion. I think I'll do a checkout and see if the git version works better.
OK, while this comment is posted just after the previous one, the former was written a couple hours ago. It seems that viewer was indeed fixed. However, editor seems completely broken. I'll try to see what the problem is.
Never mind, edit does work, I didn't know that I needed to configure that again - looks like it simply failed to accept old settings. So, right know, it seems to look fine. Don't mind the rant too much. On a minor note, autogen.sh seems unavoidable, cause simple autoreconf fails (problems related to creating po/Makefile)- that's bit annoying.
(In reply to comment #12) > On a minor note, autogen.sh seems unavoidable, cause simple autoreconf fails > (problems related to creating po/Makefile)- that's bit annoying. Another annoying thing for me is that I should have cvs to bootstrap mc, while cvs is mostly obsolete in present time. I already have git to get source tree, so why should I have cvs in addition to git?
> Another annoying thing for me is that I should have cvs to bootstrap mc, while > cvs is mostly obsolete in present time. I already have git to get source tree, > so why should I have cvs in addition to git? > mc isn't (almost) guilty! It just calls autopoint (distributed whith gettext, which "uses" CVS)
(In reply to comment #11) > OK, while this comment is posted just after the previous > one, the former was written a couple hours ago. > It seems that viewer was indeed fixed. > However, editor seems completely broken. > I'll try to see what the problem is. > Rafał, thank you for your attention to the draft, any speech and any criticism means that the project is interesting. Much worse, if not the comments and suggestions :) Tell all your comments and suggestions in the trac mc, please - tracking all messages in all bugzillas may dufficult work. :( We are ordinary people and we ready to listen any suggestions and comments. Only one requirement: the wishes of the constructive and without holywar and insults. Now about your problem. What configure options you use? Try to compile --enable-charsets After make && make install try to run mc and: F9 -> Options -> Display bits... Select "UTF-8" codepage, then save settings And only then open for editing any file. If some broken, select codepage for file by pressing CTRL+T in editor This don't intuitive, I know. This will fix in near time. P.S. Are there any who are here from China or Japan?
OK, so trac does have a sort of shortlog link, but it's placed, where it's hard to notice.
OK, my point was that this version failed to import the settings from the old one, that was already configured correctly. And referring to my rant: what exactly is situation now regarding who is now main developer/team ? And when are you planning to do a valid release ? (this would be nagging, if it were not for my opinion about 4.6.2 "release", as such 4.6.2-pre1 was released 2007-09-10)
(In reply to comment #14) > mc isn't (almost) guilty! > It just calls autopoint (distributed whith gettext, which "uses" CVS) I see. But there in the world should be another way to bootstrap it! And, once we have full UTF-8 support in the upcoming release, why not to bury support for all other codepages? Please correct me if I am wrong here.
(In reply to comment #18) > > mc isn't (almost) guilty! > > It just calls autopoint (distributed whith gettext, which "uses" CVS) > I see. But there in the world should be another way to bootstrap it! $ ./autogen.sh $ configure --options $ make $ sudo make install In future release tarball we will generate configure and Makefile.in files, of course > And, once we have full UTF-8 support in the upcoming release, why not to bury > support for all other codepages? Please correct me if I am wrong here. This planning. But not all codepages - just need for user. List of codepages will edited dynamically.
> > mc isn't (almost) guilty! > > It just calls autopoint (distributed whith gettext, which "uses" CVS) > I see. But there in the world should be another way to bootstrap it! We (gentoo community) can: * patch autopoint in gentoo gettext. I think it's the best and simplest working option, as bootstrapped intl allows us make normal tarballs without autopoint requirement on user's side. * use system's gettext facilities (http://www.midnight-commander.org/ticket/135) * write our own bootstrapper > And, once we have full UTF-8 support in the upcoming release, why not to bury > support for all other codepages? Please correct me if I am wrong here. We do not support _all_ other codepages. I'm sure mc will certainly have problems on non-UTF-8 miltibyte displaybits (SHIFT-JIS?), but it should not be hard to fix. Effectively, we have utf-8 strings (glib2 likes it) in mc internally. It gives us opportunity to support for ASCII based single character encodings without serious source complications. Some embedded devices, like routers and mobile phones(!) still use singlebyte encodings.
(In reply to comment #17) > OK, my point was that this version failed to import > the settings from the old one, that was already configured correctly. We will fix it in the nearest future, mc-4.7 won't out without this fix. > And referring to my rant: > what exactly is situation now regarding who is now > main developer/team ? midnight-commander.org team consists of 5-6 active developers (can be seen in 'git shortlog' for last months), most of them(us) are russian speaking. So we certainly need good UTF-8 support :] We have many ideas to implement (and features to steal) and bugs to fix. We: * have (still poorly documented at wiki) workflow * read mc@ and mc-devel@ lists :] * have jabber room mc-dev@jabber.org, where main international discussions take place. * have mc-commits@ and mc-bugs@ where trac sends notifications (http://midnight-commander.org/ here exact addresses can be found) I'd personally like to discuss everyhing in mc-devel@ ML, but as we are not "approved by official maintainer official mc" team ... > And when are you planning to do a valid release ? > (this would be nagging, if it were not for my opinion > about 4.6.2 "release", as such 4.6.2-pre1 was released 2007-09-10) Technically valid release will out in nearest future (don't know how long it will take). Current state is feature freeze (roadmap tab for mc-4.7 will be updated soon). Formally, we haven't still got permission from Pavel to release under "mc" name. In worst case we will have to change progect name to something ugly, like "mc+" or "mc-ng" and declare us as drop-in replacement for "mc". It will be a pain for every distro.
The unicode patch has been merged into 4.7.0_pre1. Please test, and reopen if this is still an issue.
