Re: Unwanted natural sorting of numbers
I have noticed, that when I have case in sensitive sorting set, MC uses this bad sorting: 00050.jpg 51.gif 00054.jpg When I set sorting to case sensitive, then these numbers are sorted correctly, but the sort is then case sensitive, which is something I don't want... I spotted this behavior in git some months ago As for locales, the only locale related env. vars I use are these: LC_COLLATE=C LC_CTYPE=en_US.UTF-8 Yes, it looks like this issue has to do with your specific setup. I'm not implying that it is NOT an mc problem, but at least for now we couldn't reproduce it. As I've found out in my setup, only case insensitive sort suffers from this problem, when MC is build with --enable-charset configuire option (though I think that option is now default since some time ago) Is there anything else I can do, try or post about my system that might help determine what's going on? Your best bet would be to open a ticket on the Trac with all relevant information as not all of the developers follow the list. Maybe someone will then come up with a test case to isolate the problem. There is already ticked for this I opened 4 months ago. http://www.midnight-commander.org/ticket/1536 Perhaps just put any additional information there. Since I also encounter this misbehavior on my system and in about 3 or 4 directories this sort order annoys me slightly, I think I'll look at this bug further. When I looked at the cause, I found out that some glib functions are called for sorting filenames (with my settings in ./configure), so there is no string sorting directly inside mc used for that - in my brief look before 4 months I found no trivial way to tell glib sort strings with number in them like any other strings (otherwise I would have sent a patch), so I guess I'll have to study glib documentation a bit further to find a way to fix it. Note: some newer unicode FAR releases have option to use/not use similar numeric sort. Perhaps we can have this in MC too. Martin Petricek ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
Enrico Weigelt wrote: * SZABÓ Gergely s...@subogero.com schrieb: Actually mc implements a lot of CUA standards, but you seem to forget about the Norton/Total/Far traditions. I think it's equally (or more) important to conform to those traditions. Anybody who ever used a two-pane file-manager knows by heart what the keys F1 to F10 mean. And they all expect to be able to edit the command line without any further complications. ACK. These keybindings should not change (at least not in the default installation). We could distribute multiple keybinding files aside of the default one - one in which MC will mimick Total commander keyboard shortcuts as close as possible, one mimicking FAR manager as close as possible, perhaps some other if someone will send us something reasonable :) Currently we have only the default and emacs keymap. Martin Petricek ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
I believe the idea is to be able to view parts of huge file without loading them to RAM first. (for really big files, they may not even fit in RAM.) Some really big files won't fit even in virtual memory. For example on 32bit architectures (like commonly used i386) you have 2gb usable virtul memory for each process (rest 2 gb is reserverd for kernelspace). Since some part of the 2gb space is already occupied by libraries, etc, you usually can get perhaps 1 gb of virtual memory in which you can mmap things (since the virtual memory range in which you will mmap the file have to be contiguous). And files larger than 4 Gb are quite common (large archives, apache logs from busy servers, etc ...). So mmap may be unavailable at compile time (due to platform issues ...) or at runtime (if you request block too large) We could have some get that file into memory call, that will try to use mmap if possible and store pointer to freeing the block (that would call munmap, free or some other method depending on how the block was acquired) But we need to cope with situations, where the file won't fit in RAM and won't fit in virtual memory either. For example 8gb file on i386 architecture with 2 gb of ram. Martin Petricek ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc sets process group differently from shell; forgets to close fd# 3
This reminds me of one odd behavior. When i debug a graphical program, outputting lots of debugging messaged under gdb and start it directly under bash, it works fine. But if I start it from mc (i.e. the shell in mc which I get after Ctrl-O), the gdb is stopped to background as soon as I run my program in it and it emits its first debugging message to the console (i.e. instantly). When I use fg to revive gdb, program continues till next debugging message in which gdb says the program received SIGTTOU - each command of continue will them move to next SIGTTOU (next debugging message). Maybe it is related to this one? Martin Petricek # mc # bash bash-3.2# kill -KILL $$ [1]+ Stopped mc # _ See? mc is backgrounded! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch] 7zip support + bug in viewer
Two bugs in mc from CVS, for one of them a patch is attached:
1. MC interpret .7z archives wrongly as manpages if you press F3 on them
(usually causes MC to hang while nroff is munching several megabytes of binary
trash...)
I have attached a patch to mc.ext.in that will show listing of archive for .7z
files instead (if you have p7zip installed) - like it is done for .zip, etc ...
(attached mc_mc.ext.patch)
2. If I try to view HTML and have not lynx installed (or basically anything
for which I do not have coresponding viewer from mc.ext installed), I think it
might be better to show the file directly, instead of something like lynx:
command not found followed by Empty output from child filter)
For files that are almost text like html it makes much more sense to display
them as-is instead of some error message
I think I may change the view_load in view.c that if the
view_load_command_output returns error (or at least error of type 'viewer not
found'), it will show the file directly and no error messages, but I am not
sure if this won't broke somethings ... should I try to make a patch for it,
or does it have some caveats that I don't see?
Martin Petricek
--- mc-original/ChangeLog 2005-05-13 15:09:55.0 +
+++ mc-modified/ChangeLog 2005-05-29 16:10:23.0 +
@@ -0,0 +1,5 @@
+2005-05-29 Martin Petricek [EMAIL PROTECTED]
+
+ * lib/mc.ext.in: Added support for .7z archives
+ (if p7zip is installed)
+
--- mc-original/lib/mc.ext.in 2005-05-13 15:09:55.0 +
+++ mc-modified/lib/mc.ext.in 2005-05-29 16:10:23.0 +
@@ -143,6 +143,10 @@
shell/.info
Open=info -f %f
+# 7zip archives (they are not man pages)
+shell/.7z
+ View=%view{ascii} 7za l %f 2/dev/null
+
# Manual page
# Exception - .so libraries are not manual pages
regex/\.(so|so\.[0-9\.]*)$
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
