Re: Highlighting trailing spaces
On Wed, 05 Feb 2003, Pavel Roskin wrote: On Sun, 2 Feb 2003 03:34:10 +0100 Arpi [EMAIL PROTECTED] wrote: Btw, the Makefile syntax ruleset also contains an ugly part, showing TABs with bright red backround. It's even worse, as TABs are correct there. I like it - I don't forget to add TABs when adding new lines to Makefiles the Maybe it should be made less ugly? I tried but could not find any better color. What about black? I found it better then bright red. Vlad Romanenko. -- Ukrainian Postnuke translator http://uanuke.sourceforge.net/ ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: contrib directory badly needed
Hello! Good idea. Moreover mc homepage should be more informative. If nobody protests, I could improve the mc homepage when I have more time, or even rebuild it from scratch. I develop some commercial sites (http://www.rpg-portal.pl http://www.nostromorpg.pl), so you could be sure I know how things work in web design. Both sites don't resolve, so I cannot see your work. I agree that the homepage needs to be improved. Please avoid Javascript and frames and make sure that the site remains useful with lynx. It would be great if you could show your preliminary design before you spend too much time on the new homepage. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: contrib directory badly needed
On Thu, Feb 06, 2003 at 07:52:49AM -0500, Pavel Roskin wrote: Both sites don't resolve, so I cannot see your work. Sorry, some network problems. I'll kill the server admin when I catch him. Please avoid Javascript and frames and make sure that the site remains useful with lynx. Don't worry, I prefer simple and useful design. -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Update TODO list
Hi, 1) It's about time to make ftp to sites like ftp.mcafee.com. If other programs can why do we not? As soon as we (mplayer team) are over the 0.90 release (should happen in a few days) i'll start my work on rewritting ftpfs. The current code is (sorry) a messy hack, with lots of bad assumptions and unhandled errors. It ay work with wu-ftpd, but for example it cannot chdir to homedir on proftpd, and i don't even want to imagine when it meets our hungarian language AIX server... I've already spent lots of time improving ftpfs in 4.1.35 in AMC, and i see the same problems still exists in 4.6.0. So, cound on me for ftpfs. Some more TODO entries: The fishfs is a little buggy, if you start transferring a big file and then aborts with ctrl+c, it gets into unusable state, and thanks to the vfs dir cache you have to quit mc and restart to get it working again... Maybe someone familiar with fishfs code could fix it? Another important issue i found is that patchfs doens't handle delete, so if you enter a 'patch', and edit a 'file' in it, it will append the edited version but don't remove the original part, rendering it unusably broken. Delete/edit support is (imho) required for patchfs to make it useful. Unfortunatelly it's written in perl, so i can't volunteer fixing it, unless i rewrite it in C or bash. The lslR-fs is cool, but it's extremly slow (try to enter a 80mb ls-lR file) and eats extremly high memory (aoround 200mb for that 80mb lslr file). I think we should write 'native' support for it, just like for tar and cpio. It could do an initial pass, searching for directories, and storing the position in the lslR file as 'inode', and when the user enters a directory, then jump to that position and parse that part only. A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu However, many people beg for its inclusion in Debian. Why? - Gabucino Because having new software in Debian is good. - Josselin Mouette Because having good software in Debian is new. - Gabucino ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Update TODO list
On Thu, 6 Feb 2003 14:29:42 +0100 Arpi [EMAIL PROTECTED] wrote: The fishfs is a little buggy, if you start transferring a big file and then aborts with ctrl+c, it gets into unusable state, and thanks to the vfs dir cache you have to quit mc and restart to get it working again... Command-Free VFSs now should probably help. Regards, Nerijus ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Update TODO list
Hi, David! Now that we have the 4.6.0 it's time to plain future work. Right. I think the development should stay on the 4.6 branch for a while. There are many rather simple things to be done, and having separate branches would increase the load on the developers and the time from a patch to the stable release that includes it. Once we need to do anything serious that may need more than a month for stabilization, the 4.6 branch will be created for stable releases, while the development will be done on the head. I hope to release at least 4.6.1 before we come to that point, although I'm getting increasingly busy with my job and personal life, which means that the project will be more dependent on contributions by other developers. I would propose a couple of things... 1) It's about time to make ftp to sites like ftp.mcafee.com. If other programs can why do we not? Which programs can do it? I looked at the output of the ls command, and it looks like that handling such a different format would require a very advanced parser. At least remote_is_amiga shouldn't be the only site specific flag. Also, the complexity of the code may require a testsuite, i.e. emulators of different sites, so that whoever changes the code could easily check it for regressions. 2) l10n is nearly there, which is great as this is like a huge puzzle. We should think of some way to have the user menu (the stock entries) translated. I've been thinking about this. If we make separate menu files and keep them on CVS, it will be hard to keep the default menu in sync. We could make the menu a script that would generate the actual menu at the runtime using its arguments (current file, current directory, presence of certain files). Python is already supported by gettext, but that would be an additional requirement for mc. Perl support is planned. The simplest solution would be to create a C file with all translatable texts used in the default menu. That file should be listed in po/POTFILES.in but not compiled. mc will translate menu entries on the fly when they are about to be displayed. Non-standard entries won't be translated, which is not good if there are users with different language preferences on the same machine. Another possibility would be to generate the menu files in all supported languages at the compile time. The source would have all the strings and would be listed in po/POTFILES.in. The menu file will be selected at the runtime based on the locale. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
