Re: Release out mc-4.7.0
Hello,
I did not install this update, but the previous version remapped Control-T
to be some sort of selector for encodings, and it used to be tag-current-file.
Tag current file is necessary for older terminals, and it is also the
binding used for other terminal applications.
Miguel.
On Dec 25, 2009, at 2:20 PM, Slava Zanko wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, folks.
Subj. Download page: http://www.midnight-commander.org/downloads
Major changes since 4.6.2:
Core:
* Native UTF-8 support;
* Scalable TUI;
* Added support for skins;
* Added support for key bindings;
* Added the ability to sort files by mouse click on column header;
* Added keybindings to change files sorting order via shortcuts
(PanelSelectSortOrder, PanelToggleSortOrderPrev,
PanelToggleSortOrderNext, PanelReverseSort, PanelSortOrderByName,
PanelSortOrderByExt, PanelSortOrderBySize, PanelSortOrderByMTime);
* Now the indicator of the sorting type and sorting direction is
always drawn on the panel header (sorting direction indicator is drawn
near the current column in the long file list mode only);
* Skin files: added new parameters 'sort-sign-up' and
'sort-sign-down' in the section '[widget-common]' to change the
indicator of the sorting order;
* Added option 'extensions_case' to the filehighlight.ini file;
* Menu engine was reimplemented: 1) now the menu is built
dynamically, 2) the shortcut displayed in the menu item is not a part of
the menu item text and it is synchronized with the keybindings defined
in mc.keymap file;
* Removed own popt stuff (command line options parser), now using
glib parser;
* Added filename highlighting in the panels;
* Copy/Move overwrite query dialog is more friendly to the long file
names;
* On the first run the find file dialog now contains latest item
from history;
* Charset support enabled by default (--enable-charset option);
* Added cyclic menu navigation;
* Changed the behavior of C-space: now it calculate size on ..,
and for selected dirs if there are any;
* New find file option: find only first hit in file (make search
faster);
* New find file option: whole words (find whole words only);
* Support for the filename charset selection in panels;
* Reworked 'Find File' dialog;
* New unified search/replace engine with multiple search types:
plain, wildcard, regexp and hex;
* Extended 'Learn Keys' capability;
* Locale-based codepage autodetection;
* Initial support for Doxygen generated docs;
* Build system updates (autoconf);
* Translation updates;
* Multiple x86_64 fixes.
VFS:
* Fixed viewing the *.tar files with a colon in the name;
* Now 'exit' command on non-local filesystems is allowed;
* Added partial support for Microsoft CAB archives;
* Added support for *.ico files;
* Added support for *.djvu files;
* Fixed segfaults in various cases while browsing various VFSs;
* Fixed warnings when file is copied inside the archive;
* Fixed the recognition of the *.tar.xz archives;
* Added the recognition of the lzma archives by extension;
* Added support for IPv6 protocol in FTPFS;
* Updated extfs/iso9660 to support Joliet UCS level 1.
Editor:
* Added scrolled percentage in status bar (only in simple
statusbar mode);
* Fixed misbehaving rectangular selection in the editor (when
selecting from right to left and/or bottom to top);
* Split editor menu 'Command' to 'Command' and 'Format';
* Added option 'Check POSIX new line' into 'Save mode...' dialog,
add notification before save when no newline at EOF;
* Added keybindings ('EditShiftBlockLeft', 'EditShiftBlockRight')
for shift block;
* Fixed incorrect drawing CJK (double width) characters;
* Enhanced 'Save as' dialog by allowing to select the line breaks
type: Windows/UNIX/Mac (CR LF/LF/CR);
* Updated syntax highlighting for VerilogHDL, Shell script, mail, html;
* Added syntax highlighting for yum *.repo files, pacman's PKGBUILD
and .install files, erlang, ebuild, named, strace, j;
* New search/replace flag added In selection;
* New hotkeys for bookmarks, now bookmark is displayed in status
line and editor;
* New cursor behavior: option Cursor beyond end of line allows
moving the cursor beyond the end of line.
* Various editor enhancements (mark/move/copy/paste vertical blocks);
* Source code navigation through ctags/etags TAGS files;
* New option: 'Persistent selection';
* Delete/Backspace deletes selected block if 'Persistent selection'
is off;
* Ability to shift blocks to the right with Tab key and to the left
with Complete key if 'Persistent selection' is off;
* Show line numbers (optional);
* Highlighting of tabs and trailing spaces (optional);
* Added some hotkeys.
Viewer:
* Fixed tabs alignment;
* Fixed view of next/prev file;
*
Re: Re[2]: Further Midnight Commander development
Hello, It was *YOU* destroyed that by climbing out of your deep dark tomb and behaving like the old king coming back which everyone has to submit to. It was you caused a lot of wasting resources (not just computer's but also human's) for your personal crusade against a lot of things we've done so far, without even listening to reasons why we did this, not because you had the slightest technical argument, but just because it didn't happen under your command. You are making a soap opera out of my only objection, which was the dropping of glib under poor rationale. I have not opposed any other patch, I have merely provided some feedback on some patches that required tuning. And that is exactly the reason why I abondened and created my own fork (*1) - as long as you are ruling here, I don't see the slightest bit of common ground. (and BTW, this was one of the major reasons why I've removed all my branches from mc.o git: I dont support dictators). Feel free to post the logs. You basically threw a tantrum when things did not go the way you wanted. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hello, You went light on the details, other than saying 'you totally' repeatedly. * you totally ignored recommendation for defering this decision until eglib becomes production-ready It is very simple. The majority of people to not have a problem with glib, and the size is not an issue. You claim this is a problem for embedded systems. So in your mind it is better to change all the code, introduce new bugs, introduce regressions, and introduce yet another poorly supported, debugged and documented API for this goal. So I proposed that you use eglib which is a lightweight version of glib. The rest of the community should not be held hostage to your single needs. Your reason for not accepting eglib over the production-ready does not hold any merits, considering that eglib has actually been used in various project in *production* compared to mhl which was merely an atrocious hack on a branch. production ready is and was merely an excuse to stall reverting the code. * you totally ignored that lots of my changes you enforced your servants to revert, have *NOTHING* to do with mhl at all. I have no problems with any of the other changes, and as far as we discussed, there is no problem in keeping that code around. I will be more than happy to keep this code. You even didn't listen to my arguments. When you came out of your deep dark tomb, your first action was to declare that mhl must die. That was an declaration of war. Don't be pissed when somebody shoots back. Well, some of us were not in a position to participate at the time. MHL was a poor decision, and there is really no point in debating that. I am interested in moving forward. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re[2]: Further Midnight Commander development
*1) git://git.metux.de/free-mc.git Thanks for the link. I guess we can go and pick any good changes from there and merge them into mc now. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Cocoa front end
Hello, Looking at the code, it appears as though there may be some refactoring required to abstract the UI a bit more before trying to slap an objective-c gui on there (I write C++ almost exclusively nowadays and haven't been in the pure C world for quite some time :D). Does that seem like a reasonable statement to most? A engine/GUI split was done at one point and we used to have a number of front-ends, one for GNOME, and one that used Tk. The results were not pretty. The code became a mess, and the GUI model vs the terminal model just did not blend well. It might be much better to start an effort from scratch in that case, you will end up with something that is better integrated into the core OS than trying to build a UI on top. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hello, It is very common in every project I participate to use different mailing list for these different goals: users, developer discussion, bug tracking and commits. It makes it easier to filter, and it allows for people that care about one particular area to focus on that area. If you want all the mail mixed up, you have the choice of doing that in your email program, but there is no need to force other people into your development model. Having multiple lists, one per task makes it so that people can opt-in into what they want instead of having to opt-out with complicated rules that they have to updated every once in a while. Miguel. On Feb 14, 2009, at 11:53 AM, Oswald Buddenhagen wrote: On Sat, Feb 14, 2009 at 05:43:55PM +0100, Patrick Winnertz wrote: Well.. I would like to have some place to discuss everything. of course. If this is too much it would be worth to move this to a separate mailinglist. yes - *if*. but that's not going to be the case. i cannot imagine that the additional effort resulting from fragmenting the communication channels even more would be in any way justified. but that's not my decision anyway ... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re[2]: Further Midnight Commander development
Hello, I am not really unavailable. In fact if someone bothered to ping me personally I would have noticed immediately. The list traffic was stalled for quite some time and I haven't been reading it on a regular basis for a while so I missed the interesting part. I agree with Pavel here. mc-dev has been for the most part dormant, and some terrible decisions (like that whole mhl fiasco) could have been avoided. Anyway, I am making making my way trough the mailing list volume for the last two months. I would not like to comment before I have gone trough all threads but some threads caught my attention already - search for mhl Does it feel familiar, is it what MC really needs ? Is this someone's excercise ? Luckily that mhl thing got nuked. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Disable cvs/savannah
Hello, 2.) cvs is in my eyes not very optimal for working together. git is better for such an task in my eyes. Probably the most interesting feature of using GIT is that everyone can have a full check out of the code, and it would be easier to maintain branches and maintain changes that are not officially blessed until that time comes. I am lame enough that I still have trouble using GIT myself, but progress requires learning, and it is worth taking this step. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hello, I agree with the sentiments expressed by Pavel Tsekov. If you guys have collected a new set of patches to Midnight Commander, let us get those patches posted to the tracking software in midnight-commander.org and discuss those changes as a community. Pavel is right that many forks have been created over the years, probably about a dozen, and either the efforts have died in the worst cases, or in the better cases, we managed to integrate the code back into the main repository. The Midnight Commander development community is small and it is in my opinion a step backwards to fragment it at this point. Miguel. Hello Slava, You might not be aware but I am (still) one of the two official MC maintainers. Thursday, December 18, 2008, 2:23:07 AM, you wrote: Hello, dear developers! It is no secret that the recent console manager Midnight Commander stopped in its development. We do not know the reasons why this is happening, but we badly want to see its further development. In fact, the Midnight Commander is developing further, but distributions in the form of patches, for each distribution its own set of patches. In fact, there are many versions of modern MS for each distribution. Please, cool down a bit. The various distributions usually have a set of patches to MC but the most important one is the UTF-8 patch. The rest are usually of much lesser interest. Our team was formed recently, we have only just begun working on Midnight Commander, we have yet to be established, the relationship within the team have formed. But we are striving to become a team, which will be beneficial to all fans MC (a lot of them). Already, we have created assembly, which could satisfy both users of Debian/Ubuntu, FreeBSD and Gentoo, and users of Red Hat Linux distributions, Open Suse, MandRiva etc. You may have to apologize already issued release mc-4.6.3 (actually, we do not have the right to publish under that name). It is better to ask forgiveness than permission.. :) You should have done it the proper way by trying to communicate your changes with official MC instead of making a yet another fork. You team has just formed and no one knows for how long it will last, nor what your aims are. Many like you have appeared in the past and soon lost interest in their own creation. If you are unaware of that fact you might want to check the archives. We are a young team, we ask that you permit the continued development of Midnight Commander it was under this name. Also, please refer to us the files CVS repository for the preservation of history and development of the names of all people, ever participated in the development mc. We understand that this may be shocking request, but nevertheless, we hope to receive any response - if the answer is we simply will Forque, which we hope will develop further. We want to see MC very comfortable and pleasant, not as it is now. Please, try to follow the traditional way of doing things. If you really want to become a MC developer, be so kind, to do it the proper way which means post your changes to the mailing list, discuss issues and so on. You don't become a project member and developer by just waiting for the right moment, appearing on the scene and taking over of everything. Best regards, Pavel Tsekov ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Abstracting away glib?
Hello, a) memory requirements - as you probably know glib is being used for a lot of projects, to the point that it's hard to avoid at all, even on embedded; on platforms with really constrained memory (easy to OOM) glib is probably not ideal, but to be honest, I can't imagine running mc on those either; We're actually using only a *very* small percentage of glib - all we need easily fits in a bunch of .h files. Glib is just a fat blob which makes more hassle than it's worth it, IMHO ;-p Not really; It makes the code cleaner, and it makes the code more maintainable as people that already have experience with glib are able to pick up easily and start contributing effectively from the get-go as opposed to learning a new internal API for basic stuff. But if memory consumption is that much of a concern to you, you are free to pull the Embedded GLIB which is an MIT X11 licensed version of the glib API designed for embedded systems. It is part of Mono's source code. For a project that does not get a lot of contributors: maintenance always comes first. b) performance - Enrico Weigelt mentioned some ways in which glib is underperforming or adding unnecessary abstractions. I'd argue that if it's just the implementation, it should be fixed in glib itself; In theory you're right. But from my own experience I can tell you that this won't happen (unless we're doing our own fork ;-o). Are you guys being serious? A file manager spends most of its time doing file I/O and any glib abstraction over g_malloc or whatever else is negligible. c) possible interface breaks - I think every library has those, but I also think glib has been better than most in maintaining the compatibility since their last major API break 7 years ago. In recent years, I've experienced enough glib trouble (not just interface breaks) for disliking it, especially when it's not really needed. Which interface breaks? That is nonsense. Glib has been API stable since Gnome 2.0 came out. If you have had problems document them. I for one doubt your statement very much. But I'd expected you to start using more of glib, instead of less. For what ? Where exactly is the benefit ? Open Source Development 101: * Someone else maintains the code * Someone else fixes the bugs. * We benefit from both. * Less work on our plate. * Easier for newcomers with previous experience to pick it up. * Minimize number of bugs. * Reduce maintenance cost. * Shared development cost. * Shared code in memory with other processes. * Improvements in glib, improve mc directly (better hashtables, we benefit, better allocation, we benefit). Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
mc and embedded lib.
Hello guys,
As we discussed on the mc-devel channel today, here is a patch that
allows Midnight Commander to be built with the lightweight Embedded glib
implementation, the patch is against the mc-4.6.2-pre1 release.
It is a proof of concept, as I hardcoded the location in my disk
where I have installed eglib, but the result is a fully functional mc:
mono$ ldd /tmp/eglib/bin/mc
linux-gate.so.1 = (0xe000)
libSM.so.6 = /usr/lib/libSM.so.6 (0xb7fd4000)
libICE.so.6 = /usr/lib/libICE.so.6 (0xb7fba000)
libX11.so.6 = /usr/lib/libX11.so.6 (0xb7e99000)
libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7e74000)
libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7e7)
libgpm.so.1 = /usr/lib/libgpm.so.1 (0xb7e68000)
libc.so.6 = /lib/libc.so.6 (0xb7d25000)
libm.so.6 = /lib/libm.so.6 (0xb7cff000)
libxcb-xlib.so.0 = /usr/lib/libxcb-xlib.so.0 (0xb7cfc000)
libxcb.so.1 = /usr/lib/libxcb.so.1 (0xb7ce3000)
libdl.so.2 = /lib/libdl.so.2 (0xb7cdf000)
/lib/ld-linux.so.2 (0xb7fff000)
libncurses.so.5 = /lib/libncurses.so.5 (0xb7ca7000)
libXau.so.6 = /usr/lib/libXau.so.6 (0xb7ca3000)
mono$ ls -l /tmp/eglib/bin/mc
-rwxr-xr-x 1 miguel users 2203175 2009-02-05 17:45 /tmp/eglib/bin/mc*
It is also necessary to bundle gtree.c and gnode.c for the mc/editor in
that case.
Miguel.
diff -ru mc-4.6.2-pre1/configure.ac eglib-mc-4.6.2//configure.ac
--- mc-4.6.2-pre1/configure.ac 2007-09-10 10:25:30.0 -0400
+++ eglib-mc-4.6.2//configure.ac 2009-02-05 15:54:51.0 -0500
@@ -33,9 +33,18 @@
AC_ARG_WITH([glib_static],
[ --with-glib-static Link glib statically [[no]]])
-glib_found=no
-if test x$with_glib12 != xyes; then
- PKG_CHECK_MODULES(GLIB, [glib-2.0], [glib_found=yes], [:])
+AC_ARG_WITH([eglib],
+ [ --with-eglib Uses embedded glib (eglib) [[no]]])
+
+if test x$with_eglib = xyes; then
+ glib_found=yes
+ GLIB_CFLAGS=-I/cvs/mono/eglib/src
+ GLIB_LIBS=-L/cvs/mono/eglib/src -leglib
+else
+ glib_found=no
+ if test x$with_glib12 != xyes; then
+ PKG_CHECK_MODULES(GLIB, [glib-2.0], [glib_found=yes], [:])
+ fi
fi
dnl Fall back to glib-1.2, don't use pkgconfig to find it.
@@ -65,14 +74,6 @@
dnl Used in src/glibcompat.c
AC_CHECK_FUNCS([strlcpy])
-else
- PKG_CHECK_MODULES(GMODULE, [gmodule-2.0], [gmodule_found=yes])
- GLIB_LIBDIR=`$PKG_CONFIG --variable=libdir glib-2.0`
-fi
-
-if test x$gmodule_found = xyes ; then
- dnl Check if the gmodule functionality supported on this system.
- AC_G_MODULE_SUPPORTED
fi
AC_HEADER_MAJOR
diff -ru mc-4.6.2-pre1/edit/edit.c eglib-mc-4.6.2//edit/edit.c
--- mc-4.6.2-pre1/edit/edit.c 2007-01-04 10:37:23.0 -0500
+++ eglib-mc-4.6.2//edit/edit.c 2009-02-05 17:44:02.0 -0500
@@ -149,7 +149,7 @@
if ((file = mc_open (filename, O_RDONLY | O_BINARY)) == -1) {
GString *errmsg = g_string_new(NULL);
- g_string_sprintf(errmsg, _( Cannot open %s for reading ), filename);
+ g_string_printf(errmsg, _( Cannot open %s for reading ), filename);
edit_error_dialog (_(Error), get_sys_error (errmsg-str));
g_string_free (errmsg, TRUE);
return 1;
@@ -271,7 +271,7 @@
edit_cursor_move (edit, current - edit-curs1);
if (pclose (f) 0) {
GString *errmsg = g_string_new (NULL);
- g_string_sprintf (errmsg, _( Error reading from pipe: %s ), p);
+ g_string_printf (errmsg, _( Error reading from pipe: %s ), p);
edit_error_dialog (_(Error), errmsg-str);
g_string_free (errmsg, TRUE);
g_free (p);
@@ -279,7 +279,7 @@
}
} else {
GString *errmsg = g_string_new (NULL);
- g_string_sprintf (errmsg, _( Cannot open pipe for reading: %s ), p);
+ g_string_printf (errmsg, _( Cannot open pipe for reading: %s ), p);
edit_error_dialog (_(Error), errmsg-str);
g_string_free (errmsg, TRUE);
g_free (p);
@@ -326,7 +326,7 @@
O_NONBLOCK | O_RDONLY | O_BINARY | O_CREAT | O_EXCL,
0666);
if (file 0) {
- g_string_sprintf (errmsg = g_string_new (NULL),
+ g_string_printf (errmsg = g_string_new (NULL),
_( Cannot open %s for reading ), filename);
goto cleanup;
} else {
@@ -337,14 +337,14 @@
/* Check what we have opened */
if (mc_fstat (file, st) 0) {
- g_string_sprintf (errmsg = g_string_new (NULL),
+ g_string_printf (errmsg = g_string_new (NULL),
_( Cannot get size/permissions for %s ), filename);
goto cleanup;
}
/* We want to open regular files only */
if (!S_ISREG (st-st_mode)) {
- g_string_sprintf (errmsg = g_string_new (NULL),
+ g_string_printf (errmsg = g_string_new (NULL),
_( %s is not a regular file ), filename);
goto cleanup;
}
@@ -358,7 +358,7 @@
}
if (st-st_size = SIZE_LIMIT) {
-g_string_sprintf (errmsg = g_string_new (NULL),
+g_string_printf (errmsg = g_string_new (NULL),
_( File %s is too large ), filename);
goto cleanup;
}
diff -ru mc-4.6.2-pre1/edit/edit-widget.h
Re: [bug #25438] Crash when editing a file with a nonexistent syntax file included by ~/.mc/cedit/Syntax
Hello, I've asked Miguel and Pavel several times to lock the bugtracker and to add a hint on the project page that the development has moved to www.midnight- commander.org but nothing happened. I would be happy if finally the bugtracker on savannah could be closed. Oops. I am sorry, I could use some help here: * I tried registering an account `miguel', but I guess someone must have created it for me before. Could I get the credentials for it? I will look into the tickets this week and provide some feedback. Furthermore it would be cool if somone could give me (and maybe someone else from the new team access to the savannah stuff so that we are able to continue to upload the new source tarball to the gnu servers. I finally found my login/password for Savanah, what needs changing on that site? MIguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hellom IMHO we should start with the latest stable release (4.6.1 ?) and apply all the vendor/distro patches floating around step by step (*1). Once that's done, we should make a new official release very soon. I agree with this approach, we should start by reviewing those patches as well, as not every distro patch in packages is suitable for upstream inclusion. I suggest that the patches are posted to the list, in a way similar to other projects so the patches can be peer-reviewed and discussed before they go into the tree. Miguel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] segfault-on-invalid-mtime fix
Hello, This patch looks good, but there are two uses of strftime as well, it might make sense to wrap the use of strftime in a new routine that always make this check (when localtime returns NULL). mc-4.6.1/src/util.c ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] some bash support fixups
Hello, This patch looks pretty dubious, specially considering that MC is used on system other than latest Linux distro with the latest bash. Do we have more information as to what this patch is trying to fix? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] ebuild syntax file
This patch looks like an extension, it looks harmless and should go into the tree. http://patches.metux.de/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] cons.saver: non-blocking console
Hello, Opening the console in non-blocking mode is a bad idea, as it means that every call that is done later on the console_fd needs to check for EWOULDBLOCK. Most of the time, it would be not return that, it would only return that under unique situations which means that testing this patch would not only be non-trivial, but someone would have to audit all the code paths. Also, this is lacking a ChangeLog explaining why this is needed. But I think that this patch should not be applied, it seems like a workaround that has not been properly implemented. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] find file fixups
This patch looks OK to go in. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] largefile fixups
This patch looks OK to go in. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
a) cmd.c: compare_files() - it uses the mmap() call directly (w/o going over mcvfs), and it seems to work on local files only. wouldn't it make sense to let it run via mcvfs ? b) view.c: it tries to mmap() in the file, obviously to let the kernel do all the loading. BUT: do we *really* want mmap() here, or just some get me that file into memory()-call (same in cmd.c) ? mmap is more efficient, because the kernel can throw those pages out at any time (as it knows what the backing store for the file is), so under memory pressure it can alleviate the system load easily. Loading the file ourselves means that we load it into dirty pages, effectively taking memory, and forcing the kernel to write the data to swap under load, or to keep the data in memory even when not needed. I do not like the idea of dropping mmap. In case we just want to have an faster way for loading files into memory (in case it's supported), I suggest some new vfs operation for that, let's call it loadFile() - it returns some FILE_DATA structure, containing size, buffer ptr and a callback vector for free'ing. Everyone who wants the whole file (or large blocks) just uses this call instead of ugly #ifdef's, and it's up to vfs to decide what to do behind the scenes. You are trying to invent a bloated replacement for something that the kernel can do really well. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hello, My suggestion would be to have at first a look who wants to help to develop mc further and then where to do this. Agreed, this initial post is light on the details as to what the changes are, ChangeLog entries and the documentation. The site is in Russian which does not help very much in terms of getting our international crowd to talk to everyone else * What the patches are (with ChangeLog entries) * What the changes are (with documentation) 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. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: GNU Midnight Commander 4.6.2-pre1
Hello Pavel, Do you have a list of changes in this release? Hello, I've prepared the fist pre-release of GNU Midnight Commander 4.6.2 . Please, download it and give it a try. I've been waiting for several days to get access to ftp.gnu.org so that I can upload the pre-release there, but it seems like it's going to take a while. I am not willing to hold this pre-release any longer so I've uploaded it to my private web space - you can get it from there: http://ptsekov.fixity.net/mc/mc-4.6.2-pre1.tar.gz http://ptsekov.fixity.net/mc/mc-4.6.2-pre1.tar.gz.asc Once I have access to ftp.gnu.org I'll upload there too. Alternatively, you can fetch it from cvs - use the MC_4_6_2_pre1 tag. Thanks! P.S. The public key fingerprint is: 611B 04F9 776E E02B 4AA3 5192 140E C4C2 85DA C198 The public key id is: 85DAC198 ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Midnight Commander 4.6.1 has been released.
Hello, A new version of Midnight Commander, an easy to use console-based file manager for Unix systems has been released, it is available from: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/mc-4.6.1.tar.gz md5sum: 18b20db6e40480a53bac2870c56fc3c4 mc-4.6.1.tar.gz The changes since the last public release (4.6.0) are as follows: - Core functionality. - Fix double free in mc_maybe_editor_or_viewer(). - Do not blindly cleanup in exit_subshell(). - Fix blocking of panel cd-ing with white space command. - Fix mini status after first Ctrl-O. - Fix dynamic loading of Photon library for shift keys. - Fix X11 connection handling. - Improve support for tcsh. - Use 8bit input as default. - Better support for '@' in FTP usernames. - Better large file support (int - off_t) - Add gnome, rxvt and xterm-new terminals (keyword copy for mc.lib). - Make the find dialog more responsive while scanning through large files. - Add implementation to cons.handler for FreeBSD 4.x and 5.x. - Screen saving is now supported on FreeBSD console. - Hide temporary commands from history. - Add --with-glib12 option to configure to force using glib 1.2.x. - Add --disable-background option to disable background support. - Background support now uses pipes instead of UNIX sockets. - libX11 is loaded dynamically using gmodule if possible. - User is warned if one mc is run from another. - In red dialog boxes draw the hotkey characters with a color different than the one used to paint the dialog. - Security. - Fix CAN-2004-0226 (buffer overflows). - Fix CAN-2004-0231 (unsafe temporary file and directory creation). - Fix CAN-2004-0232 (format string vulnerablities). - cons.saver does not need to be setuid-root on Linux. - Hiding of FTP passwords. - Portability. - Added configuration files for Sun Solaris pkgmk(1). - PC port has been removed. - Support for SCO UNIX has been removed. - Improve support for QNX Neutrino. - Editor. - Fix position save bug. - Improve c.syntax. - Improve makefile.syntax. - Improve python.syntax. - Improve eiffel.syntax. - Improve syntax.syntax. - Add syntax file for the x86 assembler. - Add syntax file for the Vision(tm) Ray Tracer. - Add syntax file for the CORBA IDL. - Add syntax file for the LUA programming language. - Fix bugs for mcedit compiled with ncurses. - New status string format in mcedit. - Support for large syntax files. - Temporarily disable safe save and backups on remote VFS because it doesn't work. - Enable user menu in mcedit. - Add syntax file for the ASP.NET technology. - Add syntax file for the Eiffel programming language. - Add syntax file for the Ruby programming language. - Add syntax file for the C# programming language. - Upgrade php.syntax file. - Improve sql.syntax file. - Improve perl.syntax. - Improve diff.syntax. - Improve makefile.syntax. - Add define keyword for syntax files. - Viewer. - Add .7z archives extensions to mc.ext.in. - Add OpenOffice.org 2 extensions to mc.ext.in. - Recognize both .udeb and .deb as Debian packages. - VFS. - Extensive samba cleanup. - Fix possible crash on broken cpio archives. - Quote fixes in urar.in. - Full audit of quoting of parameters in vfs scripts (CAN-2004-0494). - Fixed CAN-2003-1023 (stack overflow in vfs_s_resolve_symlink). - Various fixes in tar.c. - VFS supports iso9660 images. - extfs/rpm: Don't show the package's contents directly in the root directory, but only as an archive called contents.cpio. - Screen libraries. Backport S-Lang fixes from HEAD. - Add many boundary check into internal slang library. - Internal slang upgrade to 1.4.9. - Increased maximum screen size to 512 x 512. - Add support for qansi-m terminals. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Let's have a release!
Hello, I think it is time to finally have a release of 4.6.1. I'm satisfied with having had an official pre release and a few weeks time for testing. Afaict all the other developers are anxious for a release as well. Let's have it! If Pavel does not beat me to it, I will do the release on the weekend. Miguel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: To release or not to release ...
Hello, Is a release going to happen anytime soon ? What are we waiting for ? I did a release which got posted here. Then a kind developer told me that I skipped one number (I do not think its a major issue, and he re-released) and posted here. The only issue is that I need to get an account on ibiblio to make it completely official. I will ask for one. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc release schedule?
Hello, Both you and pchel have put out tarballs, and we're nearing the time in which you wanted to see a release. After talking to Leonard den Ottolander off list, the question was asked where we're at with that process? Specifically, has anyone reconsiled your tarball with pchel's, and do we know the current state of the existing bugs that remain outstanding? I would take the tarball that was posted as the release. The only downside is that I do not have access to ibiblio.org to upload it. As for bugs pending: we should fix those on the next iteration. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, Please use MC_4_6_1_PRE for the release of 4.6.1. Then we can use HEAD for 4.6.2 and onwards. I second that. Sounds good. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? What did you fix? Make distcheck was broken, look at the dist-hook target, it would not build with VPATH/different prefixes. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz I can rename this to 4.6.1 if people want. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, Roland, I like your proposal, for a major release version. But I got the feeling that we could go back to bi-weekly releases, so with a quick release schedule, translators just need to make sure they can catch the next train if their translations are not available. I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? We continue to use the 4.6.xx family name. I think it might be time to change one of those numbers to identify the changes done since the 4.6.0 release in a more significant way. Once we agree on that, I can upload the tarball. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Hello, Thanks for offering to become the new maintainer for Midnight Commander. I do not want you to become the Project Manager for a number of reasons: * In open source, maintainers are chosen by their merits, before today I have never heard of you.It is a meritocracy, you have shown none so far. * In open source, I have never seen a project manager, this is an invention of the standard software industry. There is no project manager for Linux, Samba, x-Windows. * Maintainers are people with deep understanding of the codebase and the language the code is written in, so they can make decisions as to what is best for the project on technical grounds. * You exhibit the behavior of many people who have no ideas whatsoever about the project but like big titles. Public Relations Coordinator, the leadership, and Project Manager. * MC should not be part of the Krusader family, it is an independent project, not part of a suite. * I dislike people who misspell: Krusader and Krew. * Tell the Leadership that thanks, but no thanks. As I stated previously, if we have problems in Midnight Commander, I will step in as its maintainer or suggest someone actively involved (or which has been actively involved in the past) to do so. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Greetings, Your last email proved my point. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] Synchronization of the panels (fwd)
Hello, This is an updated version of the dnotify patch from Andrey Siver. The patch still needs a lot of work, for example, why do we have an include file at all with the code? (The core of the code lives in sync.inc). Configure patches, fall back patches are missing as well. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] Synchronization of the panels
Hello, Please consider my patch to synchronize the panels with hard drives state. note that dnotify prevents a watched directory from being unmounted (one of the reasons why it is being replaced). that means one has to leave the dir in question in both panels. no problem as such, but it might lead to surprises ... It could be argued that if mc is watching a directory, mc is in that directory so unmounting should not be an issue at this point, but adopting something like inotify in the long run seems like a better option. The other problem with the patch is that it lacks the configure magic to work on non-dnotify systems, and also lacks support for not aborting if the code is not available in the current kernel. The patch is a nice one, but it needs to be productized. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Restoring the functionality of Alt-o
Hello, Let me propose some possibilities: 1) Revert Alt-o - annoyed users because Alt-o suddenly changes. 2) Create an alternate keyboard shortcut such as Alt-i that acts like the old Alt-o. 3) Keep Alt-o shortcut and switch between old/new Alt-o in Options/Configuration. Personally I vote for 2) because mc won't lose any of its functionality and it won't need too much work IMHO. May be 2) and 3) both? To avoid discrimination of old-style (or new-style) users... You guys raise good points. I will make it a configuration feature, and restore the old behavior by default. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: start time
Hey, I have applied this patch to the CVS repository with a few changes (configure.in checks, plus made sure that the style matched the rest of the code). I think this patch is reasonable. BTW, I did not add ChangeLog entries for these getgrouplist() patches. This patch looks good, could you commit? Miguel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: start time
Hello, I have applied this patch to the CVS repository with a few changes (configure.in checks, plus made sure that the style matched the rest of the code). To which branches? Only to HEAD or also to mc-4.6.1-PREsomething? Only to HEAD, I did not want to step on an already tagged tree. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Restoring the functionality of Alt-o
Hello, A long time ago I added Alt-o as a binding that would help in navigating directories. The idea is that in one panel you press Alt-o, and if the selection is on a directory, it will load the contents of the highlighted directory into the other panel. If no directory was selected, this was a no-op. At some point this behavior was removed from mc, and now instead it just loads the current directory on the other panel, which is not very useful for navigating anything. I remember having this discussion with Pavel but I forget the rationale for it. I would like to get this change reverted in CVS. Any objections? Miguel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Properly dispaying log files from /var/log
Hello, This patch prevent displaying log files (like log.1) from /var/log directory as a man pages. It's just a workaround, I'm working on the better solutions but it will take me some more time. Maybe a more solid path would be to use the `type' functionality in mc.ext.in to flag troff files. Or extend the script to use `file' and if it matches `English Text' or does not match `troff' not treat it as a man page. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Valgrind vs. MAD
Hello, Although Valgrind is currently limited to one OS and one architecture, it does such a great job, that we should consider removing MAD (memory allocation debugger) from the MC sources. This is a very good idea. In the past very few developers used MAD if any, mostly those debugging the system. Given the wild distribution of Linux, it might make sense to just drop support for MAD. Less code to maintain is always good. As for distinguishing between g_malloc() and malloc(), it can be done with Valgrind by redirecting malloc() and free() to some alternative memory manager while keeping g_* functions intact. I don't think it's worth the trouble to distinguish between g_malloc() and malloc(), as long as we stay with glib-1.2. yep. Miguel ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New website and ftp server
If anyone needs access to ftp.gnome.org, please send me your public ssh key and we will have the account open. Miguel. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Moving from ~/.cedit to ~/.mc
I suggest that MC doesn't use the .cedit directory and uses .mc for the files that it currently looks for in .cedit. The main reason is that the Syntax file conflicts with Cooledit. Do we have any words from Paul on integrating maybe the new cooledit with MC? Miguel. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
