Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
On Sun, 2009-01-04 at 17:01 +0100, Enrico Weigelt wrote: * Pavel Roskin pro...@gnu.org schrieb: Hi, I really don't see the problem. The problem is that the mirror already existed on that site. Now we have two mirrors. It's confusing to the users. Some may be tracking my mirror now. Instead of giving you control over the existing mirror, I'll need to ask the site administration to remove my mirror. The users will have to switch to your repository. Why do you have to close your mirror ? I dont see any reason. Thousands of OSS projects get mirrored all around the world, even without explicit knowledge of the devs, and - as far as I know - nobody feels pissed about that. What's the problem ? I don't want to be responsible for an obsolete repository. I believe it's important that the project developers act as a team and coordinate their actions. What is there to coordinate on just some dumb unofficial mirror ? Its name and who is responsible for mirroring. I realize I'm not a team member anymore, but I've been maintaining the mirror for along time. Wait, you really feel kicked-away, just because your mirror isn't the only one anyomore ? Quite strange, IMHO. There is no need for two mirrors on one site. The only problem with the existing mirror was that you didn't control it. Otherwise, it was perfectly usable. I spent quite a lot of time mapping CVS authors to the real names, and that mapping is used in your repository. Right, and you did a great job. You volunteered to do an dirty, but important job, nobody else was willing to do. And I don't think anyone here won't appreciate that. So you *are* a valueable member of the team, and I don't see how some additional, uninteresting git mirror can change that fact. Thanks. I'm unsubscribing from the lists now and I'm not going to continue this discussion. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
Quoting Enrico Weigelt weig...@metux.de: * Pavel Roskin pro...@gnu.org schrieb: Hi, What's the point? I could have given you full access to the mc repository on the same site. After all, it's just a mirror. You could have rewritten the whole repository. Now we have two competing mirrors for the same project. I'm not going to keep it this way. Hey, it's just dumb *readonly* mirror. nobody can commit there (not even me) - it just syncs itself from the master periodically. the idea behind is nothing more to have yet another publically available copy to keep some unncessary traffic from the weak mc.o server. and in case something bad happens to the server, we've got an backup. It's not a fork or anything like that. I understand that it's a mirror and not a fork. I really don't see the problem. The problem is that the mirror already existed on that site. Now we have two mirrors. It's confusing to the users. Some may be tracking my mirror now. Instead of giving you control over the existing mirror, I'll need to ask the site administration to remove my mirror. The users will have to switch to your repository. I believe it's important that the project developers act as a team and coordinate their actions. I realize I'm not a team member anymore, but I've been maintaining the mirror for along time. I spent quite a lot of time mapping CVS authors to the real names, and that mapping is used in your repository. It's just not nice to set up an alternate mirror without bothering to ask me. It's not like I'm going to spend much time on the project anyway, but such treatment will discourage me from dealing with the new team. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
Quoting Enrico Weigelt weig...@metux.de: JFYI: just created a git mirror ... ... http://repo.or.cz/m/editproj.cgi?name=midnight-commander What's the point? I could have given you full access to the mc repository on the same site. After all, it's just a mirror. You could have rewritten the whole repository. Now we have two competing mirrors for the same project. I'm not going to keep it this way. I'll ask the admins to get mc offline. I can tell from my experience that failure to cooperate is destructive for any project. Creating a mirror without asking others is an example of such failure. Sure, you saved a day or two by not asking me and not waiting for my reply. But by not asking, you made a little step towards excluding others from the development. If people see that their opinion doesn't matter, they stop participating. This leads to a one-person project, which stops when that person gets tired. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hello, Miguel! Quoting Miguel de Icaza mig...@ximian.com: I would personally like to see mc move to git, there are nice hosting services like github, it is easy to fork and it is easy to review patches from third parties. I'm maintaining a git mirror of the mc repository: http://repo.or.cz/w/mc.git It's updated automatically. It can be just cloned for further development. I took care to provide full names of all committers ever committing anything to the mc repository. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Removing myself from the project
Hello! Most messages posted to the mailing lists are spam. Most comments added to the bug tracker are spam. I simply don't have to deal with it every day. Neither do I have time to deal with site administrators to fix the spam problem upstream. Therefore, I'm removing myself from the list of mailing list moderators and from the list of project members on Savannah. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Removing myself from the project
On Wed, 2008-12-17 at 20:07 +0100, Patrick Winnertz wrote: Hey Pavel, Could you please be so kind and add me to the list of people who are allowed to commit into the cvs? I would like to work further on mc and integrate patches from the mc clone into mc. It would be very sad if mc will die out. I don't have such permission. The usual approach is that somebody wishing to contribute code posts patches to the mailing list. Other developers review the patches and commit them. Once the contributor posts many consistently good patches, he or she is granted commit access by the project administrator. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Updated Czech translation
On Wed, 2008-06-04 at 15:54 +0200, Jindrich Novy wrote: Hi mc-devel, Anna Katerina Talianova sent me updated Czech mc translation. I'm not sure whether the strings are complete for the current head mc, but fixes some typos in previous translations. Anna claims the translations are based on 4.6.1. po file attached. I've merged the result of merging the current and the new translations, giving preference to the new translation: msgmerge --update --compendium=cs.po.old --no-location cs.po mc.pot msgfmt -c --statistics -o cs.gmo cs.po 978 translated messages, 5 fuzzy translations, 4 untranslated messages. Please considering crediting the translators in the header next time. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: unable to updated translation file
On Sun, 2008-04-06 at 10:47 +0200, Marco Ciampa wrote: I've done cvs up then ./configure --prefix=/usr [] config.status: WARNING: intl/Makefile.in seems to ignore the --datarootdir setting config.status: error: cannot find input file: po/Makefile.in.in any hint? There is no configure in CVS. Please read HACKING. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16908] Missing manpage for the binary cons.saver
Follow-up Comment #4, bug #16908 (project mc): I'm afraid your description it too confusing for users. Users who read that manual page will have a wrong impression that they have to run cons.saver manually by pressing Ctrl-O, and also that they will need to perform some administrative tasks for security. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16908 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote: This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I can set up a git mirror on http://repo.or.cz/ and keep it updated from the cron script. I'm doing it for another project already. The greatest thing about git (especially when used with StGIT frontend) is that is allows working on several patches at once. Complete switching to git would be great, but it would need getting rid of changelogs and relying on the commit messages for the history. That's something only the maintainers can decide. But just having a git mirror would help those who cannot stand working in CVS after trying git or another modern version control system. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Hello mc Maintainers! :)
On Fri, 2008-03-07 at 21:50 +0100, Patrick Winnertz wrote: On Friday 07 March 2008 19:55:10 Pavel Roskin wrote: On Fri, 2008-03-07 at 17:23 +0100, Patrick Winnertz wrote: This is basically the same as your wiki idea only using a VCS instead. git would do the job quite good, but cvs will work, too, I guess. I am most familiar with cvs and svn, but maybe git would fit better. I am most familiar with svn and cvs, too but there are some things I really miss in svn ... I dislike the idea of branching there. git is quite new for me, too, but as I heard from different people it should be exactly what is needed here. I can set up a git mirror on http://repo.or.cz/ and keep it updated from the cron script. I'm doing it for another project already. This would rock.. Please do. It took me some time to make a list of all committers. I never expected it to be so long - 105 committers! I could not recover names of davidsa, gertd and martin because they never committed any ChangeLog entries. The final (hopefully) import is in progress. I hope it will complete overnight. The project patch is http://repo.or.cz/w/mc.git If something is wrong, please let me know. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Missing M-H key binding entry in hungarian man page
On Mon, 2008-02-18 at 11:32 +0100, Bozo Lajos wrote: Hallo Dear Developers, In MC among other things my favorite feature is the directory history (M-H) and I searched info about key bindings for this feature in the hungarian man page. Unfortunately I found only the description of the feature but key binding is not mentioned. The description is appended tightly to the description of 'M-u' feature. Inserting new lines and the 'M-H' string before the description would correct this little bug. This bug can be found at the last entry of the 'Directory Panels' section of the hungarian man page. Fixed in CVS. Thanks! -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New virtual file systems
On Sat, 2008-01-12 at 09:50 -0500, Jacques Pelletier wrote: but after doing ./autogen.sh, it won't consider my new scripts: they won't be renamed without the '.in' extention. I think you forgot to add them to AC_CONFIG_FILES in configure.ac. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Moving the MC homepage to www.gnu.org
On Wed, 2007-09-05 at 19:09 +0200, Alexander Kriegisch wrote: OT: Damn, this happens *every time* I do not explicitly remember not to answer e-mails from this list directly: They are sent to the person whose message I answer instead of to the list, so I have to create another copy with the right address. Can this be fixed? That's what the reply all option is for, and it's present in all decent mail clients. This way, you have a choice whether to reply personally or to the list. What you probably expect from your experience with some other list is that the reply would default to the list address. This is implemented using the reply-to line in the message header. The problem with this approach is that it gives you less flexibility. If you want to reply privately, you have to instruct your mail client to ignore reply-to, which is rarely supported. More discussion here: http://marc.merlins.org/netrants/reply-to-harmful.html -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugs should be reported to [EMAIL PROTECTED]
On Tue, 2007-04-10 at 09:10 +1000, Jeremy Dawson wrote: Bugs should be reported to mc-devel@gnome.org If an email to this address is to be replied to in this fashion, it would be preferable if the address was not publicised. I disagree. There is no guarantee that you get an acceptable reply or any reply at all from a mailing list. It's determined by many factors, such as the quality of the original post and the availability of the subscribers who want to reply. I think a public mailing list is still a better than other alternatives. It's archived, so all replied are visible to others. It encourages good replies. It also discourages rude and stupid replies, since they will stay online for everybody to see. It's not to say that it doesn't happen, but other subscribers can take corrective actions, and do it in public view. Mailing lists split the load between participants, so nobody is under pressure to respond. Every subscriber makes a choice whether to subscribe, so they are in control. Getting support requests by private e-mail may be an annoyance for somebody who chose to stop working on the project or who cannot comment on a specific issue. Bug tracking may be also adequate for some more specialized tasks, but they are less visited by anyone but core developers. In any case, mailing lists are superior to personal e-mail. I believe the mailing lists should stay and should continue to be publicized as the place to report bugs. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Request for discussion - how to make MC unicode capable
On Sat, 2007-02-24 at 14:57 +0200, Pavel Tsekov wrote: Hello, I'd like to initiate a discussion on how to make MC unicode deal with multibyte character sets. I'd like to hear from the developers of the UTF-8 patch and from the ncurses maintaner. Anyone else who can help with their expertise is also welcome. This has been a major drawback for quite some time and it needs to be addressed ASAP. Yes, thank you for addressing this issue! I just want to give you some general advice based on my experience. Don't try to keep backward compatibility from the beginning, no matter how important it is. Code for the most advanced API first, and then backport the changes to older APIs if needed. The main reason is that the new API introduces new concepts. The concepts are based on better understanding if the issue. Retaining the code that is not based on those conceptions next to the new code would create a maintenance nightmare. In some cases, the new API enforces the new rules. Don't let the offenders to hide behind conditional statements. In case of Unicode, the new concept is distinction between bytes and characters. Many functions need to be checked that they don't mix them. It's totally impractical to write a preprocessor conditional every time something is changed. It's better to change to code for Unicode support and then think how to provide backward compatibility for the whole source tree with minimal changes throughout the code. Another reason is that the programmer's time is very expensive and should be used properly. A programmer should be testing how his code is working rather than whether it compiles for an old libc. Very few actual bugs (i.e. incorrect runtime behavior, as opposed to often trivial compile issues) are discovered as a result of portability problems. Much more bugs are discovered on the primary development system by the main developer. People opposing the changes are often more vocal that those who need the changes. The later category may not be using mc at all. Perhaps they tried mc and didn't like how it looked on the Unicode capable terminal. Or maybe they were affected by bugs caused by distribution patches. Those who don't want the changes can be usually satisfied by later changes that restore the old behavior or the resource consumption. Again, existing users could be asked to contribute portability fixes and optimization. It's an easier job than converting the code to the new concepts and untangling the mess of function interdependencies. And those who threaten to switch to different software or to fork the project are usually not very good contributors to begin with. The won't be missed. In more practical terms, I suggest that mc uses only ncurses or S-Lang for Unicode. Doing two ports would exhaust already limited resources. I think the preference should be given to ncurses because it's not trying to be an interpreted language or anything else other than a screen library. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
Hello! On Mon, 2007-01-08 at 10:01 +1100, Zdzislaw Sliwinski wrote: On the surface, it looks like you guys could use cvs watch. I don't see how it could be useful. The goal is to find out if there were any updates since a certain time in the past. How would you use cvs watch for that? It's also implied that the implementation show be completely transparent to the developers. For instance, they shouldn't have to use cvs edit just because somebody somewhere is making the snapshots. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 23:07 +0200, Pavel Tsekov wrote: On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote: On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. I see. I thought the snapshot was generated manually. At least it seemed to me that new versions appear after changes were commited :) Perhaps the process can be automated ? The script will need to find out if there are any updates in CVS. We don't want to post a snapshot without actual changes in CVS. Unfortunately, there is no single commit ID in CVS, so I'll need to implement an algorithm to calculate it (I think it could be SHA1 of the sorted list of all files with revisions). I'm placing the issue on my TODO list. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: file coloring
Hello! On Sun, 2006-08-13 at 19:01 +0300, Pavel Tsekov wrote: On Sun, 13 Aug 2006, Kisel Jan wrote: Good day! I suggest you mc patch to apply file-coloring scheme based on file name pattern. So far none of the file highlighting patches submitted to the list was accepted (considered). The reasons differ - incomplete patches, the author doesn't want to change his/her patch and finally the MC maintainer thinks that this feature is not worth adding. I think we should decide whether this is indeed an useful feature or whether patches addressing file highlighting should be rejected. I'm not against file highlighting. In fact, mc is already highlighting core files by their name. It would be better for this facility to be configurable rather than hardcoded. It's also important that the configuration file is not limited to DOS-style extensions. I think shell globs would be fine, so that one could define a color for core.* or *.tar.* or something like that. It would be nice to highlight directories as well. Perhaps CVS, .svn, .git and similar special directories should have a distinctive color. You might want to read the thread below: http://mail.gnome.org/archives/mc/2002-October/msg00110.html I'm a bit overreacted here about mp3's. I think the best approach would be not to try to highlight non-technical stuff by default, at least not until mc supports 256 colors. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc 4.6.1 : colon bug in file names
On Mon, 2006-08-07 at 16:42 +, Ludovic wrote: Hi ! Some Debian users have found an annoying bug on files which have a colon in their name: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380075 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381353 Is it Debian specific or not ? What is actually run? Can you check the command line by ps x? It may be a bug in the pdf viewer. I see that evince 0.5.4 has this problem (Fedora Core 6 Test 2). -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc-2006-07-12-22 bug report
On Sat, 2006-07-15 at 09:14 +0200, enrico wrote: 0x080be9e0 in vfs_s_generate_entry (me=0x81043c0, name=0x81b69f0 WA, parent=0x0, mode=493) at direntry.c:179 ││ 179 inode = vfs_s_new_inode (me, parent-super, st); See FIXME: check if vfs_s_find_inode returns NULL in direntry.c. Apparently, what's happening is exactly that. Of course, it's not hard to check the result and return, but it would be nice to actually make mc work rather than bail out. I cannot reproduce this error, so I guess you are doing something unusual with the FTP server. More details about that could be helpful. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: non ascii file sort
Hello! On Wed, 2006-07-05 at 21:38 +0300, ForestCreature wrote: Hello! I've recently noticed wrong file sort order in file list pannels. I use ru_RU.KOI8-R locale. There is no alphabetic symbol order (what strcmp implies?). Attached patch works for me. It's not so simple. strcoll() is not guaranteed to be case sensitive in all locales. I think the choice in Sort Order ... should be between case-sensitive, case-insensitive and locale-specific. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Snapshots availability
Hello, Leonard! On Wed, 2006-06-21 at 23:21 +0200, Leonard den Ottolander wrote: Hi, Who is the creator of the two weekly snapshots found at http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ ? Pavel? Miguel? I generate them using maint/mcsnap Could you please keep a couple of months worth of snapshots around? I couldn't find the May 30th snapshot when I wanted to compare it with mccolorer. Snapshots are not intended for developers. Developers should be using proper version control systems. Snapshots are for users who want to try the latest features and check if some bug has been fixed, but who don't intend to keep the sources up-to-date. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugzilla submits only against = 4.6.1
On Tue, 2006-06-20 at 01:02 +0200, Leonard den Ottolander wrote: I didn't mean old bugs should be removed from the bug list. I just feel it doesn't make much sense for people to file new bugs against anything older than 4.6.1. There is no added value to let people add bugs against older versions. Anyone who takes time to file a new bug is adding some value to the project. It may be more or less valuable, but we shouldn't give the impression that we don't want to hear about the problem. If the issue no longer exists it's just wasted time, and if it does still exist the reporter should make the effort to verify the issue indeed still exists in 4.6.1 or later. Ideally, yes. But not everyone can do it. It's better to have 10 reports for already fixed bugs and one for a bug that still exists than to have neither of them. If you have an example where time was wasted as a result of the availability of the older versions in the bug tracker, I may reconsider. None is hardcoded, All versions is not. I think all version is a valid value in some cases. Yes, but only if you keep all the other versions as valid options. If we'd drop anything but latest stable and CVS there's not much use leaving all versions around. I generally assume the bug reporters to be intelligent persons who can make there own judgment how to file a bug. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugzilla submits only against = 4.6.1
Hello! On Sat, 2006-06-17 at 14:52 +0200, Leonard den Ottolander wrote: Hello Pavel, IMO it doesn't make much sense for people to be able to report bugs against mc versions older than 4.6.1. I presume most developers will agree with me (please protest if not). Could you please update the Savannah bugs Release drop down menu to only contain the following elements? older than 4.6.1 (upgrade first!) 4.6.1 current (CVS or snapshot) I think that would be solving a social problem using technical means. If you check Red Hat's Bugzilla you'll see that it's possible to enter a bug e.g. for Fedora Core 1. Some bugs can be more long-lived than you may think. I believe the quality of the bug report should be judged not only by the version. Bugs against old versions should be discouraged, but not outright forbidden. Besides, there is only one bug filed for older than 4.5.55. I don't think we need the entries All versions and None but these might be hard coded default entries. None is hardcoded, All versions is not. I think all version is a valid value in some cases. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Problems with the mailing list ?
Hello! On Fri, 2006-06-16 at 18:57 +0300, Pavel Tsekov wrote: Hello, Does anyone miss messages from the mc-devel list ? It seems like some messages do not reach the mailing list at all while others don't reach the mailing list subcsribers. Can anyone confirm or deny this ? I have sent an email to the GNOME mailing list administrator. I don't see any delays or mail loss, but let's see what would happen to this message. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
Hello! On Thu, 2006-06-15 at 09:45 +1200, Bart Oldeman wrote: On Wed, 14 Jun 2006, Egmont Koblinger wrote: On Tue, Jun 13, 2006 at 07:14:41PM +0200, Tomasz K?oczko wrote: BTW: anyone is working on UFT-8 support for ncurses(w) backend ? I don't think so, and I don't think it is worth it. Maintaining two backends IMHO just causes headaches while it doesn't make mc better. I still can't see why developers do not decide which one to use and drop the other one. Maybe compatibility with older UN*Xes with curses but no slang? It's a bogus argument. UNIX curses was removed long ago, and it had never worked well anyway. I don't remember a single person complaining. Besides, S-Lang is included with mc and it's quite portable. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: SO_LINGER used when not HAVE_STRUCT_LINGER_L_LINGER
Hello! On Wed, 2006-05-24 at 14:37 +0200, Leonard den Ottolander wrote: Hi, Building mc on Minix-3.1.2 last weekend I stumbled over this piece of code: vfs/ftpfs.c:1346 #ifdef HAVE_STRUCT_LINGER_L_LINGER li.l_onoff = 1; li.l_linger = 120; setsockopt (sock, SOL_SOCKET, SO_LINGER, (char *) li, sizeof (li)); #else setsockopt (sock, SOL_SOCKET, SO_LINGER, flag_one, sizeof (flag_one)); #endif The build on Minix chokes on the fact that SO_LINGER is undefined. It seems a bit odd that constant is being used when HAVE_STRUCT_LINGER_L_LINGER is not defined. Nothing odd. HAVE_STRUCT_LINGER_L_LINGER means that there is structure linger with field l_linger. That field (and the whole structure) is not used if HAVE_STRUCT_LINGER_L_LINGER is not defined. Any ideas on how to fix this cleanly? Put #ifdef SO_LINGER ... #endif around the code you quoted. Also do the same for the declaration. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: SO_LINGER used when not HAVE_STRUCT_LINGER_L_LINGER
On Thu, 2006-05-25 at 18:35 +0200, Leonard den Ottolander wrote: Hello Pavel, On Thu, 2006-05-25 at 02:15 -0400, Pavel Roskin wrote: Nothing odd. HAVE_STRUCT_LINGER_L_LINGER means that there is structure linger with field l_linger. That field (and the whole structure) is not used if HAVE_STRUCT_LINGER_L_LINGER is not defined. So you mean SO_LINGER can be defined although HAVE_STRUCT_LINGER_L_LINGER is not? Yes. Why not? Many other socket options just use an integer as an option. I can imagine SO_LINGER was an on/off option in the past, without the timeout. Put #ifdef SO_LINGER ... #endif around the code you quoted. Also do the same for the declaration. And disable the call to setsockopt() altogether? Yes. To be pedantic, it would be nice to research whether this option is needed and why it's only needed for FTP but not for other VFS implementations. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [RFE][PATCH] Display free space on device in panels
Hello! I was originally inspired by the old czech m602 file manager: http://oldgame.legalne.net/big/images/Manazer-M602.00.120.jpg A bit more talky design was used in the DOS Navigator: http://www.dev0.de/pix/dn151lfnbeta3.png Can we avoid any highlighting? I think Far Manager does it right: http://red-bean.com/proski/mc/far.png -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: midnight commander reloaded (?)
On Thu, 2006-05-11 at 10:29 +0300, Pavel Tsekov wrote: On Wed, 10 May 2006, Pavel Roskin wrote: On Wed, 2006-05-10 at 14:53 +0200, Jozef Riha wrote: Summer of Code-like sponsorship would not probably work due to the complexity of the task, limited time and resources. There is one thing that may work. We could ask to rewrite mc in another programming language as proof of maturity of that language. I hope some For what purpose ? If someone wanted to have a file manager in language XYZ he would have done so already. Not necessarily. There are many great things that have never been written. Every now and then someone jumps in and starts complaining that he would want this and that added to MC and without those very IMPORTANT features MC is just crap. Then they start to speculate how rewriting MC would pave the way and so on and so on... That's not about me. Why don't these people just start contributing - either by suggesting ideas and ways to implement them or by actually writing code ?! I'm suggesting an idea how to use a Summer of Code like process and get an acceptable result. I'm not sure it will happen, but if it will, it shouldn't be a waste of resources. Maybe it should be permitted to modify an existing project (I believe there is a file manager in Python) to match all significant features of mc. Although non-Python programmers would be at disadvantage in this case. I've tried ZC (Zemljanka Commander) at one point and I wasn't very fascinated. It is written in Python if I remember correctly and uses GTK+/Gnome for the GUI. I am not sure but maybe one of the authors used to work on MC in the past. As far as I can see, only plugins are in Python. The code is in C. The project clearly needs some work. Some of the tarballs clearly didn't come from make distcheck. config.guess in avfs is from year 1996 and doesn't know about x86_64. The Copyright tag in *.spec files is obsolete. But the C code looks quite good. The functions are quite short and easy to understand. Now I'm quite sure that modification of the existing projects should be permitted. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: midnight commander reloaded (?)
Hello! On Wed, 2006-05-10 at 14:53 +0200, Jozef Riha wrote: Summer of Code-like sponsorship would not probably work due to the complexity of the task, limited time and resources. There is one thing that may work. We could ask to rewrite mc in another programming language as proof of maturity of that language. I hope some e.g. Ruby programmer would take the challenge of implementing mc in a few months. The result would be maintainable, because otherwise it would be a negative advertising for the language. Maybe it should be permitted to modify an existing project (I believe there is a file manager in Python) to match all significant features of mc. Although non-Python programmers would be at disadvantage in this case. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: tigetstr() usage in init_xterm_support()
Hello, Pavel! On Thu, 2006-05-04 at 16:41 +0200, Pavel Tsekov wrote: init_xterm_support() uses tigetstr() to retrieve the xterm mouse sequnce from the terminfo database. Unfortunately, the prototype for tigetstr() is missing which is fatal for 64-bit builds of MC as the compiler assumes that tigetstr() returns int (32 bits) instead of pointer to char (64 bits). Now, the obvious solution is to include term.h which holds the prototype for tigetstr(), but unfortunately this doesn't work very well as term.h defines a series of macros which pollute the namespace badly i.e. lines, buttons, etc... Please consider moving init_xterm_support() outside main.c, so that the namespace pollution doesn't affect other code. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
Hello! On Thu, 2006-03-09 at 23:14 +0100, Leonard den Ottolander wrote: Hi Jindrich, On Thu, 2006-03-09 at 13:48 +0100, Jindrich Novy wrote: 1. Ok sets the parameters only for the current session and won't touch the ini file. Ok is equivalent to save if auto save setup is set. ... and if you exit from mc rather than e.g. close the xterm window. And if you don't have another mc running that would overwrite those settings if you exit from it properly. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Inconsistent behaviour of Options
On Thu, 2006-03-09 at 23:40 +0100, Leonard den Ottolander wrote: Hello Pavel, On Thu, 2006-03-09 at 17:31 -0500, Pavel Roskin wrote: ... and if you exit from mc rather than e.g. close the xterm window. And if you don't have another mc running that would overwrite those settings if you exit from it properly. The latter would still be a problem with direct saves. I don't understand which scenario you have in mind. If you mean saving settings from two mc instances, that would be a problem, but it's a counter-intuitive thing for users to do. And that auto save setup only works on normal programme termination should be obvious. Remember, users can be distracted, and they are generally assumed to have a short attention span. You cannot expect a user to remember to exit from mc correctly to save settings. There may be thousands of things between changing the configuration and ending mc, and some of them can kill mc, e.g. as X crash due to some other software, closing a wrong window, reboot due to urgent security upgrade etc. I actually find it more natural that once the dialog has been dismissed by any button, I don't have to remember to do anything. I'm accustomed to software that doesn't use my memory too much. Also, programs that save anything on exit try to protect against killing until that data has been saved. That's why SIGKILL is the last resort. mc doesn't do anything like that, as it would lose the unsaved configuration even on SIGHUP. I think that auto save setup is something that cannot be implemented reliably in mc unless you make Ok work exactly like Save and save changes immediately. But then the option auto save setup would be redundant... Unless you mean that the behaviour of Ok should be changed based on the current auto save setting. I think auto save setup is redundant, but I never had time to remove it. Besides, it would open a huge can of worms. Some users rely on auto save setup to have mc remember the last directories. Sure, such users have a different mental model of mc, they try not to kill mc, and I guess they run one copy of mc at most (so it's more a DOS/Norton Commander like model). Another group of users likes to edit configuration files manually. If mc defaults not to save the configuration, the configuration files are not created first time mc is run. Somebody would complain. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #15412] gpmsupport on console doesn't work
On Fri, 2006-02-03 at 16:33 +0100, Leonard den Ottolander wrote: Hello Pavel, On Thu, 2006-02-02 at 16:48 +0200, Pavel Tsekov wrote: Please, close. Could Pavel get the right to close bugs please? Thanks. Done. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Bad permission highlighting
On Fri, 2006-01-06 at 13:32 +0100, Jindrich Novy wrote: Hello mc-devel, Andy Shevchenko reported a bug to me for bad permissions highlighting. I've written a patch for it and it's attached. It's not a big deal but it fixes the highlighting problem. Actually, your patch breaks permission highlighting for CVS mc. The highlight is shifted to the right. I tried both perm and mode. But mc distributed by Fedora (mc-4.6.1a-6) has this problem. It must be caused by Red Hat patches. So, the patch shouldn't be applied to the original mc sources. In any case, it would be better to adjust values of l and r rather than their meaning. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Proper names
Hello! On Tue, 2005-12-20 at 20:45 +0100, Marcin Garski wrote: Hello, Here is the patch that changes names to it proper version, like Red Hat, GNOME, GTK+. I think it's wrong to fix ChangeLog files in such way. I understand fixing spacing or obvious typos, but rewriting history of the project to use official names of software - it just smells like 1984. What if GNOME is renamed to EMONG tomorrow? Would we rewrite the project history again? @@ -1109,7 +1109,7 @@ 2002-10-08 Pavel Roskin [EMAIL PROTECTED] * configure.in: Rename RH_VERSION to RPM_VERSION - not every - rpm-based system is Red Hat. Replace all dashes, not just one. + rpm-based system is Red Hat Linux. Replace all dashes, not just one. This is just ridiculous. The text doesn't become more clear, but formatting becomes sloppy. I don't want such changes to be applied to the entries that bear my name. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re[3]: mcslang library for win32
On Mon, 2005-11-28 at 18:22 +0500, Pavel Shirshov (pchel) wrote: Hello Pavel, Monday, November 28, 2005, 3:00:40 PM, you wrote: LdO There was some speak of reviving win32 support LdO (http://mail.gnome.org/archives/mc-devel/2005-September/msg00076.html). LdO Also I don't know in what respect cygwin depends on these files. Cygwin uses ncurses win32 port. PT Cygwin MC uses the Cygwin port of ncurses. Even if it used slang it would PT use the Cygwin port of slang which does not need the files slvideo.c PT and slw32tty.c - those files are used by the native Win32 slang port. What is your opinion about removing mcslang PC port? I've removed it. Thank you for noticing. Those files should have been removed long ago. If the PC port is revived, those files will be restored as well. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] spec.syntax misses %check
On Wed, 2005-11-23 at 22:05 +0100, Jindrich Novy wrote: Hello mc-devel, spec.syntax ignores the %check macro. The following patch adds highlighting of it in spec files. Applied. Thank you! -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)
On Tue, 2005-11-15 at 18:30 +0100, Leonard den Ottolander wrote: Hi Pavel, I assume this is caused by one of the recent changes you've made. I haven't seen this ever before. Installing an rpm build from a distchecked tarball from a few days ago fails with the following error: $ sudo rpm -Fv /usr/src/redhat/RPMS/i386/mc-4.6.1a-1.lj.i386.rpm Password: error: Failed dependencies: ld-linux.so.2(GLIBC_PRIVATE) is needed by mc-4.6.1a-1.lj.i386 The same procedure with a tarball just a few days older doesn't give me this problem. nm mc shows that the only symbol from GLIBC_PRIVATE is __libc_enable_secure. Search for __libc_enable_secure finds it in two places: intl/dcigettext.c - it's only used if that file is compiled as part of libc, which is not the case. slang/slcommon.c - this one uses __libc_enable_secure when glibc 2.x and newer is used. So, I guess it's upgrading S-Lang that introduced this problem. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Depency on ld-linux.so.2(GLIBC_PRIVATE)
On Tue, 2005-11-15 at 21:05 +0100, Leonard den Ottolander wrote: He he. I see the same issue indeed exists with my 2005-11-10 CVS checkout + slang2. Any suggestions on how to fix this? You are going the right thing :-) Ask S-Lang developers. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stale link to download area
On Mon, 2005-11-14 at 18:29 +0100, Leonard den Ottolander wrote: Hi Pavel, The Filelist (Download area) link on the project page (http://savannah.gnu.org/projects/mc/) still points to http://savannah.gnu.org/files/?group=mc which redirects to http://ftp.gnu.org/gnu/mc/ . Could you please point that to http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/ ? Thanks. Fixed. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Gettext version bump [was Re: make distcheck warnings]
Quoting Leonard den Ottolander [EMAIL PROTECTED]: Hi Pavel, On Sat, 2005-11-12 at 19:51 -0500, Pavel Roskin wrote: What kind of breakage do you see or expect to see? Being unable to build mc on such legacy systems as the build requirements are not met. This version bump also bumps the version requirements for automake and autoconf. You are supposed to build from a tarball on such systems, not from CVS. Darwin support without that ugly kludge in configure.ac. Less warnings (there are still plenty of them in the gettext code if you run my mctest, but neither of them seems to indicate a real problem). I'd rather live with a few redundant warnings than without a more recent mc on such legacy systems. I'm yet to see any complaints from anyone who actually tried that. If you insist on building from CVS on legacy systems, I could write a wrapper or replacement for autopoint to ignore the version requirements for gettext. I could also ask gettext maintainers to allow support for the at least operator for gettext version - I think it should be safe for mc. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: make distcheck warnings
Quoting Leonard den Ottolander [EMAIL PROTECTED]: Hello Pavel, On Thu, 2005-11-10 at 20:55 -0500, Pavel Roskin wrote: I chose version 0.14.3 was chosen because Fedora Core 4 supplies it. It should be old enough for the core developers to have it, and new enough to have most bugs fixed. I'm not so sure it's such a good idea to have the build depend on such a recent version of gettext. You might fix a few bugs, but you break compatibility with a lot of legacy systems. What kind of breakage do you see or expect to see? Could you please provide more details? I actually think newer versions of gettext should work better with legacy systems, since the fixes are incorporated into gettext runtime over time. What exactly is it we need version 0.14.3 for? Darwin support without that ugly kludge in configure.ac. Less warnings (there are still plenty of them in the gettext code if you run my mctest, but neither of them seems to indicate a real problem). Actually, the CVS version of gettext supports message contexts, so it would be nice to switch to it soon after it's released. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: make distcheck warnings
Hello, Leonard! On Thu, 2005-11-10 at 22:42 +0100, Leonard den Ottolander wrote: Hi, make distcheck reports the following warnings: msgmerge: ta.po: warning: Charset TSCII is not a portable encoding name. /usr/bin/msgfmt: ta.po: warning: Charset TSCII is not a portable encoding name. We cannot fix it in mc. It was discussed many times. Google for mc TSCII. TSCII is not standard, but it's actually used. Either TSCII should be standardized, or Unicode should be used. If I remember correctly, there are some problems with Tamil support in Unicode. Maybe the consoles fonts is not so good. I don't think we should pressure Tamil users to follow standards if they don't have good Unicode fonts. configure: WARNING: Rejecting S-Lang with UTF-8 support, it's not fully supported yet ../../intl/intl-compat.c:24:1: warning: _INTL_REDIRECT_MACROS redefined ../config.h:644:1: warning: this is the location of the previous definition The redefinition of _INTL_REDIRECT_MACROS is fixed in 0.14.3 (it might have been fixed much earlier). The problem with redirection was reported on Darwin, where __USER_LABEL_PREFIX__ wasn't defined. The problem was fixed in gettext immediately after 0.11.5. Since mc supported older versions of gettext, a workaround was provided. I also noticed that the test used in mc was incorrect - it used nested functions instead of global functions used by gettext. I fixed that initially. But then I settled for a better approach - mc is using gettext 0.14.3 now, and MC_ASM_LABELS is gone. I chose version 0.14.3 was chosen because Fedora Core 4 supplies it. It should be old enough for the core developers to have it, and new enough to have most bugs fixed. ../config.h:641:1: warning: _GNU_SOURCE redefined ../../intl/loadmsgcat.c:23:1: warning: this is the location of the previous definition This is fixed by using AC_GNU_SOURCE. Since it appeared in Autoconf 2.54, configure.ac requires it now. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Version 4.6.1 in bugzilla
On Wed, 2005-10-19 at 13:40 +0200, Leonard den Ottolander wrote: Hi Pavel, Version 4.6.1 is missing in bugzilla. Could you please add it? Thanks. Done -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 10:09 +0200, Jindrich Novy wrote: On Wed, 2005-10-05 at 10:30 -0400, Pavel Roskin wrote: I think your translation of %s in %d file is incorrect. There are no bytes in the message. It's file that should be plural. When tested, I got 72 byty byte v 1 souborech, which doesn't look right. Yes, the string is definitely not right. It's for the first time I see the plural construct in the po file, as I'm not a translator actually ;) I assumed that: #, fuzzy, c-format msgid %s byte msgid_plural %s bytes msgstr[0] %s byt. msgstr[1] %s byt. msgstr[2] %s byt. is trying to reflect different translations for inflected languages such as Czech. Your assumption is correct. However, be careful - the numbers in brackets are values returned by the formula in the beginning of the *.po file on the Plural-Forms: line. These are not example numbers (0 bytes, 1 byte, 2 bytes etc). It would be great to improve gettext to show the lowest number to match the rule rather than some abstract rule number. We have three suffices for describing an amount: 1 - byte 2-4- byty (the last character is yacute;) I have fixed that. It was plain y in your patch. 5-infinity - bytu (the last character is uring;) You may need to fix Plural-Forms: if that's true. There is a disagreement between what gettext 0.14.4 manual says about Czech language (which is what you say) and the rules used in cs.po included with gettext, which treat e.g. 22 like 2. I took the rules from gettext's cs.po. so because of the number of indices of msgstr[] I assumed that it's this case. Apparently it's not. I don't understand what you mean. The attached patch translated another missing strings and fixes ButtonBar string to fit to 6 characters. Applied. I actually forgot to commit the previous patch, so I had to apply your changes manually, but now they are in CVS. You didn't reply about %s in %d file. I did some research using Google and came with reasonable translations, but I'm not sure I got the v/ve thing correct. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 11:03 +0200, Egmont Koblinger wrote: On Thu, Oct 06, 2005 at 10:09:26AM +0200, Jindrich Novy wrote: msgid ButtonBar|Quit msgstr Tla??tkov?Li?ta|Konec If I understand correctly how the Q_() function of glib works, the translated strings must not contain the prefix up to the | character, since glib's Q_() (perhaps due to performance issues) does not strip this prefix, except if gettext() returns the same pointer (i.e. the string has no translation available). You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. So I think it should be: msgid ButtonBar|Quit msgstr Konec but the best would be to test it with glib = 2.4. It's working fine with glib 2.6.6 because it doesn't include glib/gi18n.h when glib.h is included. If I include glib/gi18n.h, bad things do happen. I hope when glib/gi18n.h is included in glib.h, it will be mature enough to avoid such stupidities. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 20:50 +0200, Jindrich Novy wrote: I hope when glib/gi18n.h is included in glib.h, it will be mature enough to avoid such stupidities. So the preferred way is to omit everything before the pipe sign in the translated strings to keep compatibility with older glibs ? Yes, except that it's for compatibility with new glib. The bug is already filed: http://bugzilla.gnome.org/show_bug.cgi?id=164373 -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 20:46 +0200, Jindrich Novy wrote: 2-4- byty (the last character is yacute;) I have fixed that. It was plain y in your patch. I was correct in the original patch, sorry. Only plain y without any accents is suitable here. Fixed. Yes, the Plural-Forms expression isn't correct for Czech inflection (the rule in the cs.po file looks more like a rule definition for ordinal numeral suffices) and the correct rule should be like this: Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n=2 n=4 ? 1 : 2);\n what returns the correct result even for 0 (result=2). This should match perfectly messages like You have %llu bytes free on your drive. Fixed. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 19:52 +0200, Egmont Koblinger wrote: On Thu, Oct 06, 2005 at 01:08:46PM -0400, Pavel Roskin wrote: You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. I perfectly agree with you. Should we file a bugreport (enhancement request?) to Gnome Bugzilla? As I said, it's already there: http://bugzilla.gnome.org/show_bug.cgi?id=164373 But it looks like it will never be fixed. But even if they accept our arguments and fix it, if we want to allow ButtonBar|Konec style translations in mc, we'll have to use our own implementation of Q_() if glib is older than 2.X, so then a more complicated test will be needed, the simple #ifdef Q_ won't do it. There is only one glib (unlike e.g. libc), so checking for glib version would be adequate. H, maybe my idea of using glib's Q_() wasn't a good idea? It seems now that it would be easier to go our own way... Maybe. I still like the shorter name, and I don't want to change it back and forward. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
Hi, Jindrich! On Tue, 2005-10-04 at 14:35 +0200, Jindrich Novy wrote: Ok, just decided to translate the Czech po completely. The attached patch contains the complete Czech translation with the fixed duplicated keyboard shortcuts. Applied, merged, committed. Thank you! After merging with the current mc.pot, we have: 981 translated messages, 5 fuzzy translations, 3 untranslated messages. It would be great if you translate the new plural forms. Finally, the translation of M bytes in N files will be perfect in every language. It wasn't perfect even in English - you could have 1 bytes in 2 files. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Q_()
Hello! On Tue, 2005-10-04 at 15:36 +0200, Egmont Koblinger wrote: Hi, There's been a discussion here a few months ago how to make the same English text translated differently in different contexts. It was important e.g. for the texts of the bottom bar whose translations have to fit in 6 characters. It seems to me that this wasn't fully implemented. Agreed. I don't know how that thread ended and I cannot find it now, but I found the Q_() and g_strip_context() functions in glib (what already we use anyway) so it seems to me that they're the best (and most standard) choice we could stick to. mc uses gettext_ui(), which is equivalent to Q_. These functions/macros are only available from glib 2.4, so currently we would need to test for their presence and use an own implementation if older glib is being used, but this shouldn't be a problem, as implementing these functions is a trivial job, and as we know it from the flames of last week, there are some autoconf gurus also who can implement autodetection. :-) I don't think autodetection is needed. All that's needed is a replacement Q_() implementation in src/glibcompat.c. I think that using such a standard interface (even if it's a new one and we need temporary hacks to support older glib) is a perfect way to go, and will be even much better if one day in the far-far future we can drop support for glib 2.4. If you like this idea, I can send patch to mc to introduce this feature, except for the autoconf part. But maybe autoconf magic isn't needed at all, since Q_() is a macro, a simple #ifdef Q_ will do it in mc's source. Correct. I've committed the Q_() support. Fixing the translation is left for you. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: prOmpt on replace
On Tue, 2005-10-04 at 22:28 +0200, Leonard den Ottolander wrote: Hi, I'd like to fix the hotkey in the subject to Prompt on replace as the O is a duplicate with the O from Ok. If I do not fix the strings in the .po files as well will this lead to untranslated strings? Yes, it will. When changing an English message without changing its sense, please update the translations. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposal for simplification
Hello, Egmont! Thank you for your comments and your support. For ncurses vs S-Lang, your arguments are very helpful. It's hard for me to argue in more details, but I see that the actual UTF-8 work done is for S-Lang only. Perhaps ncurses Unicode support wasn't fully explored yet. Maybe we need to defer the decision until both options are explored. As for gettext, I have discovered that ngettext() in already used in src/info.c, so I added the requirement that ngettext() is supported and bumped the minimal supported gettext version to 0.11.5. I also added a ngettext() call in src/screen.c, where it was badly needed to display mini-status: M byte(s) in N file(s). If ngettext() is outlawed, only outlaws will use ngettext() :-) VFS simplification is waiting for another timeslice. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposal for simplification
On Tue, 2005-09-27 at 23:22 +0200, Roland Illig wrote: Pavel Roskin wrote: 3) Support only versions of gettext that have ngettext(), i.e. drop gettext 0.10.x. I see no objections, so I've committed this. There had been the suggestion that we don't use internal gettext at all. This would simplify at least the ./autogen.sh and the configure script. It would also reduce the size of the tarball by about 80k. I'm quite of ambivalent about 80k, and I don't see much simplification. In fact, AM_ICONV and AC_PROG_RANLIB would have to be added to configure.ac because they are not implied for external gettext. I'm more concerned that non-GNU systems will need to have GNU gettext and GNU iconv installed for i18n to work. It's harder to compile them than S-Lang (AFAIK), but on the other hand, not having i18n is more acceptable than not being able to run mc at all. I'm keeping internal gettext for now, but I'm open to arguments. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposal for simplification
On Wed, 2005-09-28 at 12:08 +0300, Pavel Tsekov wrote: Hello, On Tue, 27 Sep 2005, Pavel Roskin wrote: 1) Support only S-Lang 2 and only as an external library. Those who need mc will get S-Lang. I know, this is pretty harsh, but the next release is probably months away, and S-Lang 2 will be ubiquitous by then. Most *nix variants have curses implementation. Why all of a sudden curses support should be dropped in favour of S-Lang ? mc already prefers S-Lang on such systems. Old curses (not curses) support was already dropped and nobody complained. S-Lang and ncurses have different API, which necessitates compatibility layer. As we are moving to S-Lang 2, we get more libraries to test. Adding UTF-8 support would likely increase incompatibilities even further (although I would like to be proven wrong on this issue). Restricting screen libraries to S-Lang would likely simplify color management. I believe some color related code wasn't even written because of the need to support two libraries. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposal for simplification
On Fri, 2005-09-30 at 17:09 +0200, Bálint Kardos wrote: Hi Pavel, As we are moving to S-Lang 2, we get more libraries to test. Adding UTF-8 support would likely increase incompatibilities even further (although I would like to be proven wrong on this issue). as I understand ncurses has UTF-8 support, and it is widely used by developers. Is S-Lang2 stable enough to rely on it as an only choice? Time will show. I think S-Lang is better maintained than ncurses, so we'll submit patches if needed. As I understand, there is a UTF-8 patch for S-Lang but not for ncurses. You can ask the author of the patch about the motivation. I assume that it's just easier to support one library. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Proposal for simplification
Hello! I believe one thing that makes mc so hard to maintain is the amount of various compile time options. While it may be cool to have support for e.g. ncurses or for a 5 years old version of gettext, changes do break code, and the more options we try to support, the more likely is the breakage. In particular, writing correct configuration scripts is hard and not rewarding, i.e. no matter how much time you invest, things will break for someone a few months later. I believe mc is an established project that can dictate some dependencies to those who want to compile it. Since all the dependencies are free software, it's only matter of getting and installing them. I suggest that we do following: 1) Support only S-Lang 2 and only as an external library. Those who need mc will get S-Lang. I know, this is pretty harsh, but the next release is probably months away, and S-Lang 2 will be ubiquitous by then. 2) Drop support for non-VFS builds. When we have reports that VFS was ported to Win32, there is no point to keep it optional. VFS could also provide an intermediate layer for the local filesystem - that's something we cannot do when VFS is optional. 3) Support only versions of gettext that have ngettext(), i.e. drop gettext 0.10.x. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reconfigure bugzilla to only allow reports by logged in users
On Wed, 2005-08-03 at 16:00 +0200, Leonard den Ottolander wrote: Hi Pavel, On Tue, 2005-08-02 at 06:23, Pavel Roskin wrote: Would it be possible to reconfigure mc bugzilla so only logged in users can post (to) bug reports. I see it is now indeed impossible to report new bugs without being logged in. Thanks. Please report it to Savannah admins as a bug. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reconfigure bugzilla to only allow reports by logged in users
On Wed, 2005-08-03 at 20:59 +0200, Leonard den Ottolander wrote: Hi Pavel, On Wed, 2005-08-03 at 18:38, Pavel Roskin wrote: Please report it to Savannah admins as a bug. Sure. What would be their address? [EMAIL PROTECTED] See https://savannah.gnu.org/contact.php Where to post if your call. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reconfigure bugzilla to only allow reports by logged in users
Hi, Leonard! On Sat, 2005-07-30 at 12:40 +0200, Leonard den Ottolander wrote: Hi Pavel, Would it be possible to reconfigure mc bugzilla so only logged in users can post (to) bug reports. Done. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: access to the mc homepage
Hello, Roland! On Sat, 2005-07-23 at 00:11 +0200, Roland Illig wrote: When I'm translating, I'm in most cases happy with pregenerated .po and .pot files. Only in case of doubt I download the tarball. And I don't compile a package just for translating it. I only use the line number information in the .po file and open the editor on that file. Translators should have to do as little as possible for translating a file. Their job is translating, not installing a whole bunch of dependencies to generate the translation files. OK. The script is called maint/send-po, the po files are in http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/po/ -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: access to the mc homepage
Hello, Roland! On Thu, 2005-07-21 at 19:54 +0200, Roland Illig wrote: Hello Pavel, I would like it if all developers could have write access to mc's homepage at http://www.ibiblio.org/mc/. I don't think it's right. I don't see any need for every developer to have access to the homepage. Permissions should be minimal for security reasons. I am planning to publish the current translation files (from HEAD) on a regular basis, so that we have a point where translators can download them from. That's better, although I think that snapshots should be sufficient. I'm not doing them often because I'm running a 64-bit system (x86_64), but I want to provide a 32-bit binary for Intel architecture, so I have to do chroot as root, which is more time consuming than running a script. Maybe I should abandon the goal of providing a binary RPM. I don't know how popular they are. If you think the translators need something else, you can send me a script that would create the files you want to provide. I'll take care of the uploading part. If you give sufficient arguments why you need to do it yourself, I'll assist you in getting access to the homepage. I _could_ also put those files on my private web space, but I don't want to open yet another location for mc's files. It's much nicer to have all those things centralized. (That would also include pchels frequent prereleases, if he wants.) I think it would be confusing to have prereleases made by different people on the same site. But if it's needed, maybe this could be handled by another script? You give me the tag name, I run the script, and the snapshot is uploaded. How about that? How do you think about this? And if you think all developers (or at least those who want) may have access, how does it work technically? How to we get the accounts? The accounts should be requested on ibiblio.org. You may need my help to get access to the mc areas (ftp and web). -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Removal of 7-zip oipening support - accidental?
Hello, Leonard! I see that you have removed support for opening 7-Zip archives in revision 1.79 of lib/mc.ext.in. The commit comments don't mention 7-Zip explicitly and it doesn't seem you meant to remove it: revision 1.79 date: 2005/07/03 12:43:15; author: leonardjo; state: Exp; lines: +36 -31 lib/mc.ext.in: Move matches for plain compressed files down. I think it would be polite to you inform the author of the original patch if you are undoing it. Maybe you removed 7-zip opening support accidentally? CVS should prevent it, unless you do something gross. One possible scenario would be if you copy the file from the working directory, update from CVS and copy the file back to the working directory. If that was the case, please don't do it again. I'm restoring 7-zip opening support, and if you want to remove it again, I want to hear your arguments. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] add 'ualz' to MC extfs.
Hello! On Thu, 2005-07-14 at 19:41 +0900, SungHyun Nam wrote: Hello, I added 'ualz' extfs script. I tested this patch with unalz-0.50. It seems that your script would never report directories in the archive. What's the reason? Looking and the code of unalz (CUnAlz::IsFolder), it seems to me that the directories can be stored in the archive. Why don't you use the -d option to avoid cd in mcualz_copyout()? I have put the script to http://ibiblio.org/mc/contrib/unalz-extfs/ I don't think it should be added to the main distribution because the compression software (ALZip) is not free and not really popular, so mc would in effect advertise it. Also, unalz doesn't seem to be mature because it cannot extract files to stdout. Creating a temporary directory for every file would slow down copying large amounts of files in mc. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project
Hello! Sorry, I should have answered this long ago. On Sat, 2005-06-04 at 05:58 -0700, Fudoki wrote: Greetings All! My name is Terry Wilkinson and I am on the Docs Team and also am the Public Relations Coordinator for the Krusader File Manager Project (http://krusader.sourceforge.net/index.php). Our Team has been watching this list closely because most of us are regular MC users. I have also been talking to our leadership, and to Pavel Roskin, about offering to become the new Maintainer of the Midnight Commander Project, and Pavel has encouraged me to do so. This is not true. In fact, it tried to discourage you from attempts to take over the existing project. That's what I wrote you: Fresh start needs developers. If you have developers, you don't need to talk to me. Just start coding and show me your existing code if you want me in your team. From another message: By the way, I think the new project shouldn't be called Midnight Commander. Either you misunderstood me or you are misrepresenting my words. In either case, I don't think you should take over the existing project. If you want mc developers to join your project, show what you can offer them. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi, Leonard! On Mon, 2005-05-23 at 21:41 +0200, Leonard den Ottolander wrote: ?? Aren't you saying what I'm saying? MC_4_6_1_PRE should become mc-4.6.1 and HEAD should be used for the release of 4.7 (the viewer code is not well tested so I believe it shouldn't be used for 4.6.1). Where do we disagree? I misunderstood you as saying we should use MC_4_6_1_PRE branch for 5.0 and further releases. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: before committing translation files ...
On Mon, 2005-05-23 at 11:58 +0200, Roland Illig wrote: Pavel Roskin wrote: On Thu, 2005-05-19 at 13:24 +0200, Roland Illig wrote: please run the ./strip-location.sh script on all files you want to commit. The locations are only redundant information for the translator. To regenerate the locations, just run make po-update. Example: cd mc/po ./strip-location.sh de.po cvs commit ChangeLog de.po make update-po The effect is that cvs diff is more readable. I've added --no-location to all msgmerge invocations, so it should be automatic (the patch is in the HEAD branch for now). And how do the translators get their version with locations? ;) Command--Find File Or by doing this: msgmerge --update lang.po mc.pot -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #7872] Suggested changes in Python syntax bindings
On Mon, 2005-05-23 at 20:08 +, Leonard den Ottolander wrote: Follow-up Comment #7, bug #7872 (project mc): My question is why do we need the extra code to match '/usr/bin/env' if all we need to match is 'perl'? It seems redundant. Like trying to match '/usr/bin/perl', '/usr/local/bin/perl' etc. instead of just 'perl'. Good idea, let's do it for all interpreters. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hello, Leonard! On Mon, 2005-05-23 at 00:09 +0200, Leonard den Ottolander wrote: Hi Miguel, On Sun, 2005-05-22 at 23:46, Miguel de Icaza wrote: long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. I would suggest if such a step would be made we use the MC_4_6_1_PRE for this. HEAD is somewhat experimental. I disagree. We would confuse everybody. The 4.6.1 branch should be released as 4.6.1 if at all (maybe as 4.6.2 if there we unofficial 4.6.1 releases). It's the experimental code that should become 5.0 or 4.7 or whatever we choose. If it's too unstable, we could make some prereleases. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: GCC-4.0 warnings
Hello, Roland!
On Wed, 2005-05-18 at 21:46 +0200, Roland Illig wrote:
Leonard den Ottolander wrote:
Hi,
Here's a list of gcc-4.0 warnings against HEAD from 2005-05-04. Tarball
taken from the FC4t3 mc-4.6.1a-0.9.src.rpm. Removed all patches as not
to cause confusion between clean CVS and downstream patches. Grepped for
warning in the build log.
Thanks for the list.
If anyone wants to fix these warnings, please _think_ before committing.
Changing a variable from signed to unsigned or vice versa is not a
trivial thing.
Another thing. It turns out gcc 4.0.0 is smart enough to check logic in
the called function if it's available. This means that it may warn
about uninitialized variables if they were passed to a function that
doesn't always initialize them.
So you can get a warning in this situation:
int callee(int *out)
{
if (bad_things)
return -1;
*out = 1;
return 0;
}
void caller(void)
{
int val;
if (callee(val) 0)
return;
printf(%d\n, val);
}
The warning is shown only if callee() is defined in the same file, so
that gcc can check it. You may need use -O3 flag to get the warning (I
guess it tells gcc to use inlining more aggressively).
While the code is correct, it's not obvious for gcc. The knee-jerk
reaction could be to initialize val in caller(), but sometimes it may be
better to fix callee(), especially if it's used many times. Even more
so if it's not documented that the pointer won't be initialized if
callee() returns a failure code.
I have fixed all warnings in HEAD except one introduced by you. I guess
you can fix it better (I tried and it's not trivial, so you may want to
reverse some of your changes instead):
help.c: In function 'help_handle_key':
help.c:627: warning: passing argument 3 of 'check_movement_keys'
discards qualifiers from pointer target type
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: before committing translation files ...
On Thu, 2005-05-19 at 13:24 +0200, Roland Illig wrote: please run the ./strip-location.sh script on all files you want to commit. The locations are only redundant information for the translator. To regenerate the locations, just run make po-update. Example: cd mc/po ./strip-location.sh de.po cvs commit ChangeLog de.po make update-po The effect is that cvs diff is more readable. I've added --no-location to all msgmerge invocations, so it should be automatic (the patch is in the HEAD branch for now). -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: MC_ARG_ENABLE_DEVELOPER_MODE
Hi, Roland! Also, NDEBUG is documented in glibc.info - it disables assert(). I don't think it's a good idea. Failed assertions should terminate the program. In my opinion, the only exception is when they are placed by somebody with the purpose of understanding how the program works. Then other users wouldn't need those particular asserts to terminate the program. please (GNU) grep -wr assert mc and see what assert() is used for. Why don't you use g_assert* functions like the rest of the code does? Their behavior can be controlled by environment variables (if I remember correctly), which is much more convenient than a hardcoded choice. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [OT] Re: [bug #12223] shift keys should change function menu descriptions
On Thu, 2005-05-19 at 22:44 +0200, Leonard den Ottolander wrote: Hi, On Thu, 2005-05-19 at 09:53, Oswald Buddenhagen wrote: The best joke, IMO, is the fact that the release of MC 4.6.1 is going to happen real soon now for two and a half years. that's indeed a sad joke ... :( Yeah. I almost sent out an April fools prank mail announcing the release of 4.6.1 with Pavel Roskin's address as the sender. As I don't know him that well I wasn't sure if he'd appreciate the joke so I abandoned the idea. But that fake test mail still looks very nice in my mailbox ;-) . If I saw such joke, I would likely have asked GNU admins to close my account on GNU machines. I'm already getting much more spam to that address than valid e-mails, including all mailing lists I'm subscribed to. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: portability of mc
Hi, Roland! On Wed, 2005-05-18 at 07:13 +0200, Roland Illig wrote: Do we want mc to be able to run on platforms that have: - 16 bit ints - 16 bit size_t No. - other weird system limits? No. In particular, I don't think we need to support Win64, where long cannot hold a pointer. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: PATCH new OOo2 file extensions
Hello, Leonard! On Sat, 2005-05-14 at 12:00 +0200, Leonard den Ottolander wrote: On Sat, 2005-05-14 at 00:13, Pavel Roskin wrote: For example, the stable branch compiles with a significant amount of warnings by the latest gcc. This wasn't the case when 4.6.0 was released. I don't see *any* warning on the MC_4_6_1_PRE branch, which is the branch that should be used for a 4.6.1 release. What's your definition of latest gcc? According to gcc.gnu.org, it's 4.0.0. How about this warning: utilvfs.c: In function 'vfs_mkstemps': utilvfs.c:211: warning: pointer targets in assignment differ in signedness It doesn't even require -Wall. I'm sorry, but I don't have time to port every minor fix to the 4.6 branch. We have been applying these safe and minor fixes to MC_4_6_1_PRE for months as we - we being at least Pavel Shirshov, Roland Illig, Jindrich Novy and me - expect that branch to be used for a 4.6.1 release. I appreciate it. Instead of complaining about all the effort of back porting (which most of the active developers don't seem to mind), could you please release a rc for 4.6.1 from the MC_4_6_1_PRE branch? It depends on how stable it is. Last time I tried it didn't work well. P.P.S. If you still feel that the X11 error when running mc over ssh should be fixed before a release of 4.6.1 could you please give us an indication of how you think this issue should be fixed? I would expect the fix needs to be applied to init_key_x11() in src/key.c but I am not quite sure how to do this. Just closing the module, window and display as in done_key() and setting them to NULL or 0 does not suffice to fix this issue. Do we need an extra parameter to indicate we can't use X11 related functions? I believe an X error handler is needed. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: PATCH new OOo2 file extensions
Hi, Nerijus! On Fri, 2005-05-13 at 18:36 +0300, Nerijus Baliunas wrote: IMHO it's safe to apply to MC_4_6_1_PRE too. Most changes are safe to apply, but it takes additional time. I'm thinking of skipping 4.6.1 and going to 4.7.0 because the changes accumulated so far exceed by far what is expected from a x.x.1 release. We are behind time in terms of development. For example, the stable branch compiles with a significant amount of warnings by the latest gcc. This wasn't the case when 4.6.0 was released. The changes required to fix the warnings were potentially risky (removing unsigned in many places and adding it in functions from ctype.h). In other words, we need significant changes just to keep mc as good as it was. I'm not even talking about Unicode support. If we ever add it, we should release 5.0.0. And what should we do with Alt-O, which works differently in two branches? Should we release 4.6.1 and 4.7.0 with different behavior? I'm sorry, but I don't have time to port every minor fix to the 4.6 branch. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Changes in screen.c rev. 1.211 not merged on the MC_4_6_1_PRE branch
On Wed, 2005-05-11 at 16:56 +0300, Pavel Tsekov wrote: Hello, Pavel, is there a reason not to have this change in MC 4.6.1 ? I've merged it. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: CVS Ids in source files
Hi, Roland! On Tue, 2005-05-10 at 23:02 +0200, Roland Illig wrote: I would like to include a declaration like the following into every .c file. static const char mc_cvsid[] = $Id; Please don't do it. CVS doesn't handle it properly. It can cause conflicts when merging branches. Also, the Id in CVS is rather meaningless. Every file has its own revision. There is no single revision for the tree. There is no way to find the branch the the file Id. In fact, CVS doesn't seem to have any keyword that would indicate the branch. We need to move to a better versioning system some day. I just hope that Savannah will start supporting Subversion. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Updated Lithuanian translation
Hello, Nerijus! On Sat, 2005-04-23 at 03:36 +0300, Nerijus Baliunas wrote: I fixed all but one fuzzy - didn't touch one fuzzy and 4 untranslated as it's 1 sentence splitted into 5 parts, and it's very difficult to translate as the order of the words is different in my language. Please apply to MC_4_6_1_PRE. Applied. Thank you! -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: MC accessibility patch
Hi, Yannick! On Mon, 2005-04-11 at 14:14 +0200, Yannick PLASSIARD wrote: Hi All, I'd like to suggest a little patch for mc to be usable by blind users. You forgot to attach it. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Updated Lithuanian translation
On Wed, 2005-04-06 at 22:12 +0200, Vaidrius Petrauskas wrote: Hello, please commit updated lt translation. Applied. Thank you! -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Proposed patch: Alt-O on files to select current directory
On Fri, 2005-03-25 at 20:19 -0500, Miguel de Icaza wrote: Hello, Miguel, since you wanted the old behavior, I'd like you to see the patch so you don't complain again that I broke something you liked. Thanks for the patch. I think that this is a useful addition, I have no objections to it. Applied. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Issues to fix before 4.6.1?
On Sat, 2005-03-26 at 09:25 +0100, Leonard den Ottolander wrote: Hello Pavel, Could you please tell us which according to you are issues that still need to be fixed before a release of 4.6.1? Development on the 4.6.1-pre branch has been rather quiet for a few months now (since december essentially), so it would be nice to resolve these issues and have a release. I've just fixed the last issue, both in HEAD and MC_4_6_1_PRE. It was a bug in cpio handling that could cause a buffer overflow on broken cpio archives. Now the biggest issue is catching up with the development. There are hundreds of posts in the mailing list that I have never had a chance to read. I don't feel good about making any releases without having read them. Some messages could be about security issues. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Proposed patch: Alt-O on files to select current directory
Hello, Miguel and everybody!
I'm sorry, I was too busy to do anything about the issue with Alt-O,
even to argue about it. But I'd like to fix the current code a bit to
make it less annoying to me.
Alt-O on a file makes the inactive panel change to the parent directory
of the one in the active panel. It would be great to move selection on
the inactive panel to select the entry corresponding to the current
directory on the active panel.
This way, I could use Alt-O, Tab, Enter to emulate the behavior of Alt-O
in mc 4.6.0. Also, I could press Tab and use Alt-O or cursor keys to
navigate directories with similar names.
Miguel, since you wanted the old behavior, I'd like you to see the patch
so you don't complain again that I broke something you liked.
ChangeLog:
* screen.c (chdir_other_panel): When used on a file
entry, move selection on the inactive panel to select
the entry for the current directory on the active panel.
--
Regards,
Pavel Roskin
--- src/screen.c
+++ src/screen.c
@@ -2017,18 +2017,22 @@ static void
chdir_other_panel (WPanel *panel)
{
char *new_dir;
+char *sel_entry = NULL;
if (get_other_type () != view_listing) {
set_display_type (get_other_index (), view_listing);
}
-if (!S_ISDIR (panel-dir.list [panel-selected].st.st_mode))
+if (!S_ISDIR (panel-dir.list [panel-selected].st.st_mode)) {
new_dir = concat_dir_and_file (panel-cwd, ..);
-else
+ sel_entry = strrchr(panel-cwd, PATH_SEP);
+} else
new_dir = concat_dir_and_file (panel-cwd, panel-dir.list [panel-selected].fname);
change_panel ();
do_cd (new_dir, cd_exact);
+if (sel_entry)
+ try_to_select (current_panel, sel_entry);
change_panel ();
move_down (panel);
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Fixes committed
Hello! I have committed following fixed to HEAD: Shift-F4 was broken in the editor (blame: Roland Illig) Advanced Chown was broken (blame: Roland Illig) Alt-O would change current directory without updating the current panel (blame: Miguel de Icaza) I'm sorry, I'm still buried in unanswered e-mails, and I don't know when I'll be able to reply to all of them. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Fwd: Re: mc-4.6.1-pre2b
On Thu, 27 Jan 2005, Leonard den Ottolander wrote: Hi Pavel, Pavel, On Thu, 2005-01-27 at 06:50, Pavel Shirshov (pchel) wrote: mc exists when run remotely over ssh with X forwarding enabled: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 38 (X_QueryPointer) Resource id in failed request: 0x60 Serial number of failed request: 6 Current serial number in output stream: 6 This is an openssh issue. Please compare https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125838 . You need to use ssh with -Y instead of -X IIRC. I wouldn't call this an OpenSSH issue. From http://www.openssh.com/txt/release-3.8: * ssh(1) now uses untrusted cookies for X11-Forwarding. Some X11 applications might need full access to the X11 server, see ForwardX11Trusted in ssh(1) and xauth(1) for more information. So, mc needs full access, but it cannot get in certain cases. If that happens, mc should stop using X events without exiting. It's not like mc is completely useless without full access to the X server. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10
On Tue, 2 Sep 2003, Ali Akcaagac wrote: On Tue, 2003-09-02 at 16:59, Nerijus Baliunas wrote: Why did you send core file (800 KB !) without first asking if we need it and without gzipping it ? The question is, how can an 800kb file pass the 40kb filelimit of the mailinglist. It requires moderation to pass these files. Indeed. I'm sorry for that. As it stands now, mc-devel gets about 40 virus bounces and reports a day. They all are held in the moderation queue. It takes a lot of time to remove them. There are occasional legitimate messages from unsubscribed users. When Mailman (the mailing list software) shows them in the queue, it also gives a reason for rejection. It shows only one reason, not all of them. When a message comes from an unsubscribed user and it exceeds the allowed size, I only see the first reason. Mailman shows only the beginning of the message, so it's not immediately obvious that the message is huge. It can be seen from the headers, but my first concern is not to discard legitimate mail in the flood of garbage, so I'm not always paying attention to details. It happened in the past already. If I had control over the Mailman installation, this problem would have been fixed already. I have asked the gnome.org sysadmins to upgrade Mailmen to the latest version, which has a much superior moderation queue, but they don't want to do it. I'll try to be more careful in the future. Sorry for inconvenience. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Put character on screen
On Mon, 1 Sep 2003 [EMAIL PROTECTED] wrote: I want to put a character on screen, with your total attributes ( blinking, color, etc.), using C. What routine should I use? And what library? If you are talking about Midnight Commander, use attrset() to set the attributes and addch() to display a character. These functions are provided by the ncurses library. If S-Land is used instead, there is a compatibility layer in the Midnight Commander source that allows you to use the same functions. (Embedded image moved to file: pic05447.pcx) I don't know why you sent this image. It appears to be a picture of a signature. Please don't send this image to mailing lists, it used bandwidth but adds nothing to the discussion. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Please install filter for viruses
Hello, postmaster! I wrote you yesterday but got no reply. The problem with the Sobig.F virus is only getting worse. I'm getting hundreds of viruses sent to [EMAIL PROTECTED] - approximately one in two minutes. Mailman 2.0.x is not equipped to deal with this deluge. I had to turn off notifications to the moderator and to the sender about e-mail held for moderation. I have reduced the e-mail size to 10k to catch viruses. A filter has been added to Mailman to catch automated replies. Still, I have to deal with hundreds of messages in the moderation queue. Despite my efforts, three virus messages with stripped payload have slipped into the mailing list. As a result, I had to blacklist administrators of the list, whose addresses were used by the virus (including myself). Half of the junk in the queue are actual virus e-mails. They can be removed by installing a filter in front of Mailman. The rest are bounces and virus warnings. They can filtered out as well. I know, you don't plan to upgrade to Mailman 2.1.x, but that's something that could have relieved me from the tedious task of discarding hundreds of junk e-mails one-by-one. But if this issue is not be resolved one way or another, there will be no other solution but to move mailing lists to a site with better administration. I know, it would be a major inconvenience for the subscribers, but I cannot spend hours a day cleaning up junk from the moderation queue. I don't want it to sound as an attempt to put pressure on you, but the fact is that no project can be successful if the communication between its members doesn't work. It's a serious problem and it needs to be solved. The copy goes to the mailing list, whose members are entitled to know what is going on. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
[OT] Changes in mailing list configuration
Hello! The mailing list [EMAIL PROTECTED] has been attacked by the Sobig.F virus. I have removed more than 200 copies from the moderation queue. For each message held in the queue, Mailman (the mailing list software) sends a message saying that the post is awaiting moderators approval. Since the return address in the virus is picked in from the address book and the web cache, the messages from Mailman could have reached real people who didn't post anything to the list. To prevent this from happening, I have turned off the Mailman notification message both for [EMAIL PROTECTED] and [EMAIL PROTECTED] I'm sorry for possible inconvenience, but sending 200 bogus notifications a day is unacceptable. I hope that the mail administrators of gnome.org will deal with the situation by installing filters and/or a newer version of Mailman, but if nothing is done, moving the lists to gnu.org will be the only option. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Fix ESCDELAY check.
On Fri, 15 Aug 2003, Andrew V. Samoilov wrote: Hello, small patch to fix ESCDELAY check. This variable declared extern, so test case should be linked instead of compiling. This fix is usefull for Solaris2.7. Applied. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: FTP Passwords in Directory Hotlists
On Sun, 17 Aug 2003, Thomas Glanzmann wrote: It would be nice if mc would hide ftp passwords in directory hotlists. I think the right for FTP passwords is ~/.netrc, not ~/.mc/hotlist. If you allow the password to be saved outside .netrc, it should not be considered so secret that it needs to be hidden. Since you didn't mention your version of mc, I cannot tell you if it implements .netrc support correctly. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: MC_PWD_FILE in mc-wrapper
On Fri, 15 Aug 2003, Figura Peter wrote:
Mandrake 9.1, mc-4.6.0-1mdk.rpm
login: peterf
MC_PWD_FILE=/home/peterf/tmp/mc-peterf/mc.pwd.
$su root
MC_PWD_FILE=/root/tmp/mc-peterf/mc.pwd.
but mc created a directory /root/tmp/mc-root !
Yes, I was told already that $USER is not reliable.
1c1,2
MC_PWD_FILE=${TMPDIR-/tmp}/mc-$USER/mc.pwd.$$
---
# MC_PWD_FILE=${TMPDIR-/tmp}/mc-$USER/mc.pwd.$$
MC_PWD_FILE=${TMPDIR-/tmp}/mc-${USERNAME-$USER}/mc.pwd.$$
Why do you think that $USERNAME is better? I cannot apply this patch
without explanation. I think id is more portable than environment
variables, but it was told that the arguments to id are not portable.
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] bashism in sh script
On Fri, 1 Aug 2003, GoTaR wrote: There's no thing like $[..] to evaluate expressions in POSIX sh, it's bash feature. sh uses $((..)) instead (and bash understands it too). Here comes fix. Does the next line work for you? I mean this: if (( $A 10 )); then A=0$A; fi I think it's a much worse case of non-portable code. Have you tested your changes? -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] bashism in sh script
On Fri, 8 Aug 2003, Andrew V. Samoilov wrote: I think patch below make audio.in much more portable. Applied. BTW, I don't see reason to substitute audio from audio.in. There is @AWK@ in audiofs_copyout(), but it's hard to notice :-) -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch]: lib/cedit.menu: portability fixes
On Fri, 25 Jul 2003, Andrew V. Samoilov wrote:
Hello, Pavel!
One more fix for Solaris.
I think it's over-engineered. Isn't $USER standard? Does id -u work?
It may be more reliable to use the numeric user ID. I suggest one of the
following, sorted in the order of decreased preference:
awk -F: '$1 == ENVIRON[USER] {print $5}' /etc/passwd
awk -F: '$1 == '$USER' {print $5}' /etc/passwd
awk -F: '$3 == '`id -u`' {print $5}' /etc/passwd
awk -F: '$3 == '`id | sed 's/^.*uid=\([^(]*\).*$/\1/'`' {print $5}' /etc/passwd
BTW, it will be fine to rename
http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/binaries/SunOS/mc-4.6.0-SunOS.tar.Z
to mc-4.6.0-sol7-sparc-local.tar.Z and to place /usr/local/README from
this tarball near tarball.
I have no idea why more generic SunOS should be replaced with more
specific sol7 (what would Solaris 8 users think?), but I put README to
the same directory.
By the way, your mail program gives text attachments mime-type plain/text,
but it should be text/plain.
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
