From stking at bway.net Mon Sep 1 00:26:17 2003 From: stking at bway.net (Sean King) Date: Sun, 31 Aug 2003 20:26:17 -0400 Subject: patch: C-PGUP/DN will work in GNU screen in xterm Message-ID: <20030901002617.GA13492@bway.net> Hi all, I wanted to get C-PGUP and C-PGDN working with screen in an xterm. I'm no C coder (mostly bash and REXX) but below's a patch for key.h and key.c in 4.6.0 which seems to do the trick.... I hope it's OK as it stands -- but something on these lines ought to be in there, it seems to me. best, S. =====patch below================ --- key.h.orig Mon Dec 23 04:46:28 2002 +++ key.h Sun Aug 31 20:03:27 2003 @@ -60,4 +60,9 @@ int define_sequence (int code, char *seq, int action); +/* xterm_key_defines for GNU screen running in xterm -- +defined in key.c, called by init_key() */ + +int screen_under_xterm(); + /* internally used in key.c, defined in keyxtra.c */ void load_xtra_key_defines (void); --- key.c.orig Mon Jan 27 17:37:56 2003 +++ key.c Sun Aug 31 20:03:32 2003 @@ -252,4 +252,32 @@ #endif /* HAVE_TEXTMODE_X11_SUPPORT */ +/* C-PGUP and C-PGDN will work fine in GNU screen running in */ +/* an xterm -- but xterm_key_defines are needed for that. */ +/* */ +/* screen doesn't like TERM to be anything other than */ +/* 'screen*' (or maybe 'vt100'), and init_key has been doing */ +/* */ +/* define_sequences (xterm_key_defines); */ +/* */ +/* only for TERM=xterm* or TERM=iris-ansi*.... So we want to */ +/* say 'Yes, TERM=screen*, but I'm running in an xterm -- */ +/* define those sequences.' */ +/* */ +/* So we create this function and add a test to init_key. */ +/* */ +/* I don't think WINDOWID is infallible, but I don't know */ +/* another way. (XGetCommand(), perhaps??) */ + +int +screen_under_xterm (void) +{ + static int s_xterm = -1; + + if (s_xterm == -1) + s_xterm = !!getenv ("WINDOWID"); + + return s_xterm; +} + /* This has to be called before slang_init or whatever routine calls any define_sequence */ @@ -263,5 +291,5 @@ /* Terminfo on irix does not have some keys */ - if ((!strncmp (term, "iris-ansi", 9)) || (!strncmp (term, "xterm", 5))) + if ((!strncmp (term, "iris-ansi", 9)) || (!strncmp (term, "xterm", 5)) || (!strncmp (term, "screen", 6) && screen_under_xterm())) define_sequences (xterm_key_defines); From stking at bway.net Mon Sep 1 08:24:55 2003 From: stking at bway.net (Sean King) Date: Mon, 1 Sep 2003 04:24:55 -0400 Subject: patch: C-PGUP/DN will work in GNU screen in xterm In-Reply-To: References: <20030901002617.GA13492@bway.net> Message-ID: <20030901082455.GA24842@bway.net> On Mon, Sep 01, 2003 at 02:15:13AM -0400, Pavel Roskin wrote: > > > I think it's a pretty dirty hack. yeah, but it's not the _only_ 'is_an_xterm' type function relying on WINDOWID.... ;-) > WINDOWID doesn't mean that you are running xterm. ....as you see, I express some doubts in the comment.... > It may be another terminal emulator. Absolutely -- IIRC, konsole _doesn't_ use WINDOWID, but I'll bet some of 'em do (I think they *all* _should_, actually...) Well, maybe one could test, what.... Eterm? rxvt? There's three possibilities, I guess: Something bad happens under rxvt or what-have-you with define_sequences (xterm_key_defines); (Already known perhaps?) Nothing in particular happens. Or --- perhaps --- it actually gets C-PGDN/UP working with screen-under-rxvt-or-whatever TOO! ;-) > > It would be much better if screen just emulated xterm and used TERM=xterm. Nah, screen is locked into vt100-ishness AFAICT... What happens if you use TERM=xterm-*anything* with screen (*even if* the terminfo db is simply the actual screen db *named* to xterm-anything....) is, that the screen painting with mc's Ctrl-O feature gets fouled up.... (the subshell works, but the screen is blank -- you have to hit enter to get the prompt back. This is even _with_ 'set altscreen on'). That's probably because screen's using strncmp( , "xterm", 5 ) _too_.... > I don't know, maybe it's supported already. Well, one could write a patch for _screen_ I guess.... ;-) Here's the thing: even if it is only screen-under-xterm that this patch helps, it's worth doing _somehow_ if it can be done -- If the _only_ thing standing between screen's being able to use this (important) bit of functionality is the _string_ "xterm" (and AFAICS that's the case) then surely something other than, or in addition to strncmp() should be used.... In other words, if a screen_under_xterm function _can_ be produced, it should be. AFAICT this works _perfectly_ with xterm, and that's not insignificant -- a lot of people use xterm, after all. ;-) There's gotta be a way to test for running-under-xterm-when-TERM= something else (doesn't there? ;-).... Maybe someone who knows more about this kind of coding (I generally run to shellscripts and editor macros....) could come up with something.... I mentioned XGetCommand -- I don't know how easy it is to get at the info, but WM_COMMAND will always contain the command and arguments used to invoke a terminal.... I certainly agree that if the function breaks something, or risks breaking something, it needs to be extended -- but I think such a function should _exist_. Heck, if worst came to worst, one could just extend the function with a few strncmp(termvalues,,) i.e. NOT eterm, NOT rxvt.... whatever it takes. I certainly think it's worth doing! Thanks for your reply! best, Sean From proski at gnu.org Mon Sep 1 06:15:13 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 01 Sep 2003 02:15:13 -0400 (EDT) Subject: patch: C-PGUP/DN will work in GNU screen in xterm In-Reply-To: <20030901002617.GA13492@bway.net> Message-ID: On Sun, 31 Aug 2003, Sean King wrote: > I wanted to get C-PGUP and C-PGDN working with screen in an xterm. > > I'm no C coder (mostly bash and REXX) but below's a patch for key.h and > key.c in 4.6.0 which seems to do the trick.... > > I hope it's OK as it stands -- but something on these lines ought to be > in there, it seems to me. I think it's a pretty dirty hack. WINDOWID doesn't mean that you are running xterm. It may be another terminal emulator. It would be much better if screen just emulated xterm and used TERM=xterm. I don't know, maybe it's supported already. -- Regards, Pavel Roskin From tux at centrum.cz Mon Sep 1 09:20:57 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 01 Sep 2003 11:20:57 +0200 Subject: [BUG] bug in internal cd command. Message-ID: <20030901092112Z116574-12888+69846@mail.centrum.cz> I found a buf in internal cd command How to reproduce: make a directory with space in its name, like "cpu info" Type "cd ", then press alt-enter on that directory name with space in it, the command line will read "cd cpu\ info". Now press enter. Mc will complain the directory does not exist -> seems it can't handle backslashes in internal cd command. The same apply for *, ?, ", \ and probably other characters in directory names although they are not so common as space character. Also when testing this bug I encountered another one (possibly more fatal): I make directory with name "a:b" (yes, it countain colon) in /tmp and put some files in it, but when I press enter while standing on the file in active panel, i get usually two results, most of the time the current directory in the active panel changes to "/#a" and empty directory is shown, sometimes I get also this message (only at first time accessing that dir and also after freeing VFS): Error: Can't exec "mdir": No such file or directory at /usr/local/share/mc/extfs/a line 66. readline() on closed filehandle FILE at /usr/local/share/mc/extfs/a line 67. Martin Petricek From tux at centrum.cz Mon Sep 1 09:23:29 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 01 Sep 2003 11:23:29 +0200 Subject: [BUG] copy/move - error dialog should include "ignore" button Message-ID: <20030901092342Z106464-12886+69815@mail.centrum.cz> The state of the checkbox "preserve attributes" in copy/move dialog should be preserved (or make an option whether to be preserve or not by default) at least in current mc session -> if I forget to untick it and I copy/move from ext2 to fat32 partition, I get dialog box saying "Cannot chown target file ... Operation not permitted (1)" with Skip/retry/abort options. I am really missing "ignore" or even better also "ignore all" button, which will silently continue as if the chown succeeded (since chown on fat is really impossible...) If i press "skip" while moving, the file is copied BUT it remains at the location from where it should be moved. This is why I think there should be also "ignore"/"ignore all" button (or both of them). Also "skip all" might be useful on some other operations too. Martin Petricek From tux at centrum.cz Mon Sep 1 09:24:14 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 01 Sep 2003 11:24:14 +0200 Subject: [BUG] colors in red dialog boxes Message-ID: <20030901092416Z119427-12889+70023@mail.centrum.cz> In normal gray dialog box the shortcut key to activate a button is blue, while the remaining text of button is black. In red dialog boxes, the shortcut key is white and the text is also white, so I don't see the shortcut for all but the current button (which is blue on black). This is especially annoying in "overwrite file?" dialog, since it have eight buttons and i don't remember all the shortcuts. I think the keyboard shortcut to activate the button in red dialog boxes should have any color, but not white. Also when I press "down" key while on "yes", i expect the button "all" to be active, not "no" button. (seems that up/down just move left/right, nt up/down in the rows of buttons as I would expect) Martin Petricek From tux at centrum.cz Mon Sep 1 09:25:39 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 01 Sep 2003 11:25:39 +0200 Subject: [BUG] unpacking zip archives horribly slow Message-ID: <20030901092553Z119775-12888+69944@mail.centrum.cz> When I press enter in zip archive, mark some files and press f5 (copy) to extract them, it takes about 3 second for each file (well, on a 486DX4/100, but running "unzip archive.zip" is much faster, so it's not caused just by slow cpu) I think the reason is in extfs/uzip - when I try to run it alone, it takes about 2 seconds to compile the script with perl and execute it. And since it is executed and terminated repeadedly for each extracted file, it's horribly slow (I read numbers like 200 bytes/second on the progress indicator) This is especially annoying for archives containing lot of small files, running unzip takes few seconds, unpacking them with mc via F5(copy) takes usually few minutes Proposed solutions: rewrite uzip in C, not i perl (should be quite easy, just use z-lib). This will be faster and I think someone have already done it (i can look on the web for it) but for extracting lot of small files this will fix the things only partially. So I think that in addition to copyin/copyout in extfs protocol there should be added something like multicopyin/multicopyout, allowing to supply a list of files to be extracted, instead of calling the binary in extfs once for each file. Or, even better, integrate .zip file support directly into mc (like it seems to be done with .tgz files) since .zip is quite popular format ... Which solution would be the most preferable? I might help with coding it ... Martin Petricek From tux at centrum.cz Mon Sep 1 09:26:21 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 01 Sep 2003 11:26:21 +0200 Subject: [BUG, minor] display garbled when resizing window while copying files Message-ID: <20030901092627Z116542-12888+69963@mail.centrum.cz> When I start to copy files and resize the terminal window while the copy progress dialog is displayed, the display become garbled - dialog is moved, but the values (percentages, kb/s information, etc ...) are written somewhere else (outside the dialog). It's minor bug, since when the copy finishes, mc restores to normal (and resizes itself to terminal dimensions) Martin Petricek From stking at bway.net Mon Sep 1 10:02:21 2003 From: stking at bway.net (Sean King) Date: Mon, 1 Sep 2003 06:02:21 -0400 Subject: patch: C-PGUP/DN will work in GNU screen in xterm In-Reply-To: <20030901082455.GA24842@bway.net> References: <20030901002617.GA13492@bway.net> <20030901082455.GA24842@bway.net> Message-ID: <20030901100221.GA25148@bway.net> replying to myself.... > I mentioned XGetCommand -- I don't know how easy it is to get at the > info, but WM_COMMAND Been looking around, and looking at man pages -- if we _must_ uniquely identify an xterm, it looks like *XGetClassHint* is the real deal -- perhaps I can cobble something together or find a sample function.... or maybe somebody who actually knows C wants to step forward.... ;-) From gpaiva at chesf.gov.br Mon Sep 1 15:18:09 2003 From: gpaiva at chesf.gov.br (gpaiva at chesf.gov.br) Date: Mon, 1 Sep 2003 12:18:09 -0300 Subject: Put character on screen Message-ID: 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? Regards, (Embedded image moved to file: pic05447.pcx) Guilherme Paiva Santos Analista de Sistemas - DSA C?lula: Gest?o Recursos de TI Telefone: (081) 229 2758 -------------- next part -------------- A non-text attachment was scrubbed... Name: pic05447.pcx Type: application/octet-stream Size: 26067 bytes Desc: not available URL: From proski at gnu.org Mon Sep 1 18:29:50 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 01 Sep 2003 14:29:50 -0400 (EDT) Subject: Put character on screen In-Reply-To: Message-ID: On Mon, 1 Sep 2003 gpaiva at chesf.gov.br 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 From stking at bway.net Mon Sep 1 22:17:17 2003 From: stking at bway.net (Sean King) Date: Mon, 1 Sep 2003 18:17:17 -0400 Subject: patch: C-PGUP/DN will work in GNU screen in xterm In-Reply-To: References: <20030901002617.GA13492@bway.net> Message-ID: <20030901221717.GA17367@bway.net> > I think it's a pretty dirty hack. WINDOWID doesn't mean that you are > running xterm. It may be another terminal emulator. > OK, I've been mulling this over, and have installed some extra terminals and been doing some testing.... First point: on any showing we should add something like || (!strncmp (term, "rxvt", 4)) to init_key. because, after all, those /* rxvt keys with modifiers */ are part of xterm_key_defines.... ....and, without *that* patch C-PGDN/UP *don't work* in rxvt, aterm, and wterm; but with it, they *do*.... ;-) And if we made it something like || (!strncmp (term, "rxvt", 4)) || (!strncmp (term, "Eterm", 5)) then C-PGDN/UP -- which currently don't work in Eterm -- *will* work in Eterm. (And, in rxvt, aterm, wterm....) They all define WINDOWID, yes indeed.... but, with the patch above, and the WINDOWID-testing function I submitted yesterday, C-PGDN/UP will work under _screen_ running in any of those terminals _too_. I think there's a case to be made for that little function (which should be renamed to is_capable_term() or something like that) and for today's little patch, too. That's a lot of things working, that weren't working before. And no downside -- at least as far as my testing today has shown. If there _is_ a terminal that defines WINDOWID and that's going to blow up or something if the xterm_key_defines are added, I say we just add a strncmp() test for it to is_capable_term().... I haven't tested konsole (don't feel like dealing with all that KDE cruft ;-) but then, konsole defines TERM=xterm, doesn't it? So there's already something slipping through the net. Now, as for an _infallible_ test -- This Really Is An Xterm, No Fooling.... -- with the help of Usenet and manpages, I'm "this close" to having a function, in spite of my ignorance of C and Xlib. I daresay I can finish it. But is it needed? -- that's the question. ...and AFAICT it wouldn't be available unless HAVE_TEXTMODE_X11_SUPPORT were defined, unless one did a pretty big rewrite. And, it probably ought to be somewhere else than in key.c / key.h if it _were_ needed -- which it hasn't been so far. I say, unless there's some downside I'm not aware of -- a downside that can't be handled with a simple test -- that something like these suggestions should be adopted; why *not* have this functionality available in rxvt, aterm, wterm, Eterm, (etc.?) (NTM screen-under-rxvt/aterm/wterm/Eterm.... and xterm too, of course!) It seems eminently worth doing, and it only takes a half-dozen lines of code. That's how it looks to me. best, S. From ralph.schenn at zurich.com Tue Sep 2 09:15:59 2003 From: ralph.schenn at zurich.com (Ralph Schenn) Date: Tue, 2 Sep 2003 11:15:59 +0200 Subject: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10 Message-ID: When i select "Left" -> "Listing Mode" and check "User Mini Status" and then try to edit the line below the Checkbox the program crashes with the following codedump: (See attached file: mc-4.6.0.core) Thank you. Best regards Schenn -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.0.core Type: application/octet-stream Size: 583340 bytes Desc: not available URL: From nerijus at users.sourceforge.net Tue Sep 2 14:59:28 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 2 Sep 2003 17:59:28 +0300 (EEST) Subject: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10 In-Reply-To: References: Message-ID: <20030902150004.805C25DBA5@mx.ktv.lt> On Tue, 2 Sep 2003 11:15:59 +0200 Ralph Schenn wrote: > When i select "Left" -> "Listing Mode" and check "User Mini Status" and > then try to edit the line below the Checkbox the program crashes with the > following codedump: > > (See attached file: mc-4.6.0.core) Why did you send core file (800 KB!) without first asking if we need it and without gzipping it? Why didn't you use gdb and send us backtrace instead? Regards, Nerijus From andrew at email.zp.ua Tue Sep 2 16:03:25 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 2 Sep 2003 19:03:25 +0300 (EEST) Subject: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10 In-Reply-To: <20030902150004.805C25DBA5@mx.ktv.lt> Message-ID: <200309021603.h82G3PRv033849@email.zp.ua> Hello, > Why did you send core file (800 KB!) without first asking if we need it > and without gzipping it? > Why didn't you use gdb and send us backtrace instead? Is it possible to set moderator approval for messages greater than 30 KB? -- Regards, Andrew V. Samoilov. From aliakc at web.de Tue Sep 2 16:06:08 2003 From: aliakc at web.de (Ali Akcaagac) Date: Tue, 02 Sep 2003 18:06:08 +0200 Subject: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10 In-Reply-To: <20030902150004.805C25DBA5@mx.ktv.lt> References: <20030902150004.805C25DBA5@mx.ktv.lt> Message-ID: <1062518767.725.7.camel@localhost> 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. From proski at gnu.org Tue Sep 2 18:17:50 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 2 Sep 2003 14:17:50 -0400 (EDT) Subject: Version 4.6.0 crashing on HP-UX 11i with glib 1.2.10 In-Reply-To: <1062518767.725.7.camel@localhost> References: <20030902150004.805C25DBA5@mx.ktv.lt> <1062518767.725.7.camel@localhost> Message-ID: 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 From lists at pervalidus.tk Wed Sep 3 05:18:44 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Wed, 3 Sep 2003 02:18:44 -0300 (BRT) Subject: Bug using 'Background': file_progress_real_query_replace Message-ID: I got the following downloading a file which was already there (same name, just older). No prompt, nothing. The file was automatically overwritten. I also tried with 2 and both were. You can do nothing else until the download is complete. filegui.c: line 685 (file_progress_real_query_replace): assertion `ctx->ui != NULL' failed Using CVS just checked out. -- How to contact me - http://www.pervalidus.net/contact.html From lists at pervalidus.tk Wed Sep 3 05:24:43 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Wed, 3 Sep 2003 02:24:43 -0300 (BRT) Subject: Bug using 'Background': file_progress_real_query_replace In-Reply-To: References: Message-ID: Sorry. I noticed it was reported some time ago by David Sterba - http://mail.gnome.org/archives/mc-devel/2003-July/msg00002.html On Wed, 3 Sep 2003, Fr?d?ric L. W. Meunier wrote: > I got the following downloading a file which was already there > (same name, just older). > > No prompt, nothing. The file was automatically overwritten. I > also tried with 2 and both were. You can do nothing else until > the download is complete. > > filegui.c: line 685 (file_progress_real_query_replace): assertion `ctx->ui != NULL' failed > > Using CVS just checked out. -- How to contact me - http://www.pervalidus.net/contact.html From andrew at email.zp.ua Thu Sep 4 12:33:05 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 4 Sep 2003 15:33:05 +0300 (EEST) Subject: %view macro in the user menu implemented Message-ID: <200309041233.h84CX5rt019994@email.zp.ua> Hello, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: user.c.patch URL: From proski at gnu.org Thu Sep 4 17:17:28 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 4 Sep 2003 13:17:28 -0400 (EDT) Subject: %view macro in the user menu implemented In-Reply-To: <200309041233.h84CX5rt019994@email.zp.ua> References: <200309041233.h84CX5rt019994@email.zp.ua> Message-ID: On Thu, 4 Sep 2003, Andrew V. Samoilov wrote: > Hello, :-) Applied. I also have added an item for viewing manual pages to the menu, which uses this patch. By the way, the menu needs to be reorganized and cleaned up. I don't think many people need to "Strip headers from current newsarticle" very often. -- Regards, Pavel Roskin From ptsekov at gmx.net Fri Sep 5 22:46:22 2003 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sat, 6 Sep 2003 00:46:22 +0200 (MEST) Subject: [BUG] unpacking zip archives horribly slow Message-ID: <25938.1062801982@www9.gmx.net> >When I press enter in zip archive, mark some files and press f5 (copy) >to extract them, it takes about 3 second for each file (well, on a >486DX4/100, but running "unzip archive.zip" is much faster, so it's not >caused just by slow cpu) >I think the reason is in extfs/uzip - when I try to run it alone, it takes about 2 seconds to compile the >script with perl and execute it. And since it is executed and terminated repeadedly for each extracted >file, it's horribly slow (I read numbers like 200 bytes/second on the progress indicator) >This is especially annoying for archives containing lot of small files, >running unzip takes few seconds, unpacking them with mc via F5(copy) >takes usually few minutes There reason is that MC fork()s for every single file in the archive when performing the copyin/copyout thing. >Proposed solutions: > >rewrite uzip in C, not i perl (should be quite easy, just use z-lib). This will be faster and I think >someone have already done it (i can look on the web for it) but for extracting lot of small files this will >fix the things only partially. >So I think that in addition to copyin/copyout in extfs protocol there should be added something like >multicopyin/multicopyout, allowing to supply a list of files to be extracted, instead of calling the binary >in extfs once for each file. > >Or, even better, integrate .zip file support directly into mc (like it seems to be done with .tgz files) >since .zip is quite popular format ... Well, you know - it takes someone to implement this things. It looks like most people are find the current implementation decent enough and do not bother. But on really old machines I guess it is quite evident that the implementation is wrong. Fixing this will also relieve to the Cygwin users, since the fork () is quite slow there. I tried different workarounds to get it working faster on Cygwin but none was good enough. So if time allows I can look into this problem too. If you start coding something please keep me posted. Pavel Which solution would be the most preferable? I might help with coding it ... Martin Petricek -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post From gotar at poczta.onet.pl Sat Sep 6 10:30:39 2003 From: gotar at poczta.onet.pl (GoTaR) Date: Sat, 6 Sep 2003 12:30:39 +0200 Subject: more xterm.ad sequences Message-ID: <20030906103039.GA5283@os> Hi! These are for directories history, find file and filtered view. -- Tom Pala http://vfmg.sourceforge.net/ http://www.pld-linux.org/Members/gotar/ -------------- next part -------------- --- /home/gotar/cvs/mc.orig/lib/xterm.ad 1998-02-27 05:54:45.000000000 +0100 +++ /home/gotar/cvs/mc/lib/xterm.ad 2003-09-06 12:12:56.000000000 +0200 @@ -61,6 +61,7 @@ ae: string(0x1b) string("e") \n\ af: string(0x1b) string("f") \n\ ag: string(0x1b) string("g") \n\ + a sh: string(0x1b) string("H")\n\ ah: string(0x1b) string("h") \n\ ai: string(0x1b) string("i") \n\ aj: string(0x1b) string("j") \n\ @@ -79,4 +80,6 @@ aw: string(0x1b) string("w") \n\ ax: string(0x1b) string("x") \n\ ay: string(0x1b) string("y") \n\ - az: string(0x1b) string("z") + az: string(0x1b) string("z") \n\ + a s/: string(0x1b) string("?")\n\ + a s1: string(0x1b) string("!") From stking at bway.net Sat Sep 6 22:47:14 2003 From: stking at bway.net (Sean King) Date: Sat, 6 Sep 2003 18:47:14 -0400 Subject: more xterm.ad sequences In-Reply-To: <20030906103039.GA5283@os> References: <20030906103039.GA5283@os> Message-ID: <20030906224714.GA28619@bway.net> I was just looking over xterm.ad the other day -- is there any advantage to ... aw: string(0x1b) string("w") \n\ ax: string(0x1b) string("x") \n\ ay: string(0x1b) string("y") \n\ ... over the simple Alt : string(0x1b) insert() which seems to take care of everything? best, S. From stking at bway.net Sat Sep 6 23:45:07 2003 From: stking at bway.net (Sean King) Date: Sat, 6 Sep 2003 19:45:07 -0400 Subject: more xterm.ad sequences In-Reply-To: References: <20030906103039.GA5283@os> <20030906224714.GA28619@bway.net> Message-ID: <20030906234507.GA29008@bway.net> > > It may be fine for mc, but it would be a wrong thing to do. It would > break sequences for other keys. For example, Alt-Up should be "\e[1;3A" > and it's implemented by the latest xterm-179. Innaressin'.... if anything bites me, I'll change over; or maybe do it anyway on general principle -- > > Of course, the users of the latest xterm are not likely to need xterm.ad > at all, I'll have to pay Dickey a visit.... I'm at 165. > but it's better to be careful. Yup. Thanks for your response. best, S. From proski at gnu.org Sat Sep 6 23:19:36 2003 From: proski at gnu.org (Pavel Roskin) Date: Sat, 06 Sep 2003 19:19:36 -0400 (EDT) Subject: more xterm.ad sequences In-Reply-To: <20030906224714.GA28619@bway.net> References: <20030906103039.GA5283@os> <20030906224714.GA28619@bway.net> Message-ID: On Sat, 6 Sep 2003, Sean King wrote: > I was just looking over xterm.ad the other day -- is there any advantage > to > ... > aw: string(0x1b) string("w") \n\ > ax: string(0x1b) string("x") \n\ > ay: string(0x1b) string("y") \n\ > ... > > over the simple > > Alt : string(0x1b) insert() > > which seems to take care of everything? It may be fine for mc, but it would be a wrong thing to do. It would break sequences for other keys. For example, Alt-Up should be "\e[1;3A" and it's implemented by the latest xterm-179. Even though mc doesn't sequences for Alt with control characters, other software may use them. Of course, the users of the latest xterm are not likely to need xterm.ad at all, but it's better to be careful. -- Regards, Pavel Roskin From proski at gnu.org Sun Sep 7 01:56:36 2003 From: proski at gnu.org (Pavel Roskin) Date: Sat, 06 Sep 2003 21:56:36 -0400 (EDT) Subject: more xterm.ad sequences In-Reply-To: <20030906103039.GA5283@os> References: <20030906103039.GA5283@os> Message-ID: On Sat, 6 Sep 2003, GoTaR wrote: > Hi! > > These are for directories history, find file and filtered view. Have you tested it? When I tried to follow the instructions in README.xterm and ran "xrdb xterm.ad", xterm forgot the settings from ~/.Xresources, such as font size and background color. Just in case, I'm using Debian unstable and xterm-179. The only way I found to install xterm.ad without affecting the existing settings was to use the "-merge" switch to xrdb. Even then, some of the working keys stopped working. For example, Shift-Ins would not insert text from the clipboard anymore. I had to change xterm.ad and replace #override with #augment to fix this problem. Strange thing is, xterm.ad has been unchanged since 1998 and I don't remember seeing any complaints about it. Either nobody used it or those who tried gave up and took some other approach. Also, I'm not sure that redefining Alt-Shift-1 is correct. This makes an assumption about keyboard layout, namely that Shift-1 is "!". This may be wrong for some keyboards. After I loaded the original xterm.ad I noticed that Alt-Shift-1 would insert the exclamation sigh upside down, which is used in Spanish. I'm afraid not everybody will be happy with the "improved" xterm.ad. I'm more inclined to remove xterm.ad, xterm.ti and xterm.tcap from the sources. They don't belong here. GNU Midnight Commander started as a shell for hackers who would gladly reconfigure everything they are told to work around deficiencies of their terminals. The times have changed since then. Terminals are more capable and users don't want to tweak everything. There are other means to make keys work, such as the "Learn Keys" dialog. I don't want users to be confused by something they most likely don't need. I haven't seen bug reports about xterm.ad, but I have seen and even heard complaints from people who could not find "Learn Keys" because our documentation is still oriented to the hackers of the past times. -- Regards, Pavel Roskin From stking at bway.net Sun Sep 7 03:20:19 2003 From: stking at bway.net (Sean King) Date: Sat, 6 Sep 2003 23:20:19 -0400 Subject: more xterm.ad sequences In-Reply-To: References: <20030906103039.GA5283@os> Message-ID: <20030907032019.GA31057@bway.net> On Sat, Sep 06, 2003 at 09:56:36PM -0400, Pavel Roskin wrote: > > Also, I'm not sure that redefining Alt-Shift-1 is correct. One could use 'exclam' and 'question' -- i.e. the names seen with 'xmodmap -pke'.... So a question: string(0x1b) string("?")\n\ a exclam: string(0x1b) string("!") not a s/: string(0x1b) string("?")\n\ a s1: string(0x1b) string("!") best, S. From pavel at ucw.cz Sun Sep 7 16:19:59 2003 From: pavel at ucw.cz (Pavel Machek) Date: Sun, 7 Sep 2003 18:19:59 +0200 Subject: [BUG] unpacking zip archives horribly slow In-Reply-To: <20030901092553Z119775-12888+69944@mail.centrum.cz> References: <20030901092553Z119775-12888+69944@mail.centrum.cz> Message-ID: <20030907161958.GA743@elf.ucw.cz> Hi! > When I press enter in zip archive, mark some files and press f5 (copy) > to extract them, it takes about 3 second for each file (well, on a > 486DX4/100, but running "unzip archive.zip" is much faster, so it's not > caused just by slow cpu) > I think the reason is in extfs/uzip - when I try to run it alone, it takes about 2 seconds to compile the script with perl and execute it. And since it is executed and terminated repeadedly for each extracted file, it's horribly slow (I read numbers like 200 bytes/second on the progress indicator) > This is especially annoying for archives containing lot of small files, > running unzip takes few seconds, unpacking them with mc via F5(copy) > takes usually few minutes > > Proposed solutions: > > rewrite uzip in C, not i perl (should be quite easy, just use z-lib). This will be faster and I think someone have already done it (i can look on the web for it) but for extracting lot of small files this will fix the things only partially. > So I think that in addition to copyin/copyout in extfs protocol there should be added something like multicopyin/multicopyout, allowing to supply a list of files to be extracted, instead of calling the binary in extfs once for each file. > > Or, even better, integrate .zip file support directly into mc (like it seems to be done with .tgz files) since .zip is quite popular format ... > > Which solution would be the most preferable? I might help with > coding it ... multicopyout will have ugly issues with error handling (if single file fails, it will be "interesting" to return that info back from the shell script... Integrating zip into mc is certainly doable. Completely different protocol for extfs would be probably best. Something like "run extfs, then tell it over pipe what to do". You may reuse some parts of fish. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] From gotar at poczta.onet.pl Sun Sep 7 20:17:42 2003 From: gotar at poczta.onet.pl (GoTaR) Date: Sun, 7 Sep 2003 22:17:42 +0200 Subject: more xterm.ad sequences In-Reply-To: References: <20030906103039.GA5283@os> Message-ID: <20030907201742.GA27300@os> On Sat, Sep 06, 2003 at 21:56:36 -0400, Pavel Roskin wrote: > > These are for directories history, find file and filtered view. > > Have you tested it? I use much more extended version, but all the lines are included. > When I tried to follow the instructions in > README.xterm and ran "xrdb xterm.ad", xterm forgot the settings from > ~/.Xresources, such as font size and background color. Just in case, I'm > using Debian unstable and xterm-179. > > The only way I found to install xterm.ad without affecting the existing > settings was to use the "-merge" switch to xrdb. Yes, that information should go into the file. BTW there are two typos: 2nd line: "IS you are using enclosed" should be "if" 12th line: "modifier in FRON of some" shoud be "front" > Strange thing is, xterm.ad has been unchanged since 1998 and I don't > remember seeing any complaints about it. Either nobody used it or those > who tried gave up and took some other approach. Or used it as a simple example/template. For example it was probably used as a template in PLD Linux Distribution. > Also, I'm not sure that redefining Alt-Shift-1 is correct. This makes an > assumption about keyboard layout, namely that Shift-1 is "!". This may be > wrong for some keyboards. After I loaded the original xterm.ad I noticed > that Alt-Shift-1 would insert the exclamation sigh upside down, which is > used in Spanish. Indeed. But as you noticed - nobody uses this file alone and this is good example. > I'm afraid not everybody will be happy with the "improved" xterm.ad. I'm > more inclined to remove xterm.ad, xterm.ti and xterm.tcap from the > sources. They don't belong here. xterm.ti and xterm.tcap are redundant, but xterm.ad should be moved to examples or docs. Without it many would never know how to change xterm resources. E.g. I'm using: MetaRight: string(0x1b) string(0x09) to have 'tab' completion on alt-right_arrow. > GNU Midnight Commander started as a shell for hackers who would gladly > reconfigure everything they are told to work around deficiencies of their > terminals. Well, maybe you would like to include this to key.c: { KEY_M_CTRL | KEY_UP, ESC_STR "[1;5A", MCKEY_NOACTION }, { KEY_M_CTRL | KEY_DOWN, ESC_STR "[1;5B", MCKEY_NOACTION }, { KEY_M_CTRL | KEY_RIGHT, ESC_STR "[1;5C", MCKEY_NOACTION }, { KEY_M_CTRL | KEY_LEFT, ESC_STR "[1;5D", MCKEY_NOACTION }, ctrl-left/right moves by words, ctrl-up/down scrolls screen w/o moving cursor. And this one too: { KEY_M_SHIFT | KEY_IC, ESC_STR "[2;2~", MCKEY_NOACTION }, if someone wants to override paste from X clipboard to paste from mc clipboard (ctrl-ins and shift-del: to clipboard, shift-ins: from clipboard). > The times have changed since then. Terminals are more capable > and users don't want to tweak everything. There are other means to make > keys work, such as the "Learn Keys" dialog. > > I don't want users to be confused by something they most likely don't > need. I haven't seen bug reports about xterm.ad, but I have seen and even > heard complaints from people who could not find "Learn Keys" because our > documentation is still oriented to the hackers of the past times. Hey, lusers don't use mc at all, they use konqueror. mc is tool for hackers and power users and that's the way it should remain. Oh, by the way: have you heard about Midnight Commander MP: http://mc.linuxinside.com/cgi-bin/dir.cgi it has many nice features, like clock, different colors for differet file types, panel resplitter (Ctrl+LEFT|RIGHT|END as F9-o-l-[<>e]-o), checkbox for recursive search in find file (one must use grep if wants to search non-recursively with current mc implementation), and very useful thing - bookmarks in editor (Alt-Ctrl-Ins: set bookmark, Alt-Ctrl-UP|DOWN: move through them). And many others - please read README.40, but the ones I mentioned, are the most usefull. I'll be happy to see them in mc. -- Tom Pala http://vfmg.sourceforge.net/ http://www.pld-linux.org/Members/gotar/ From andrew at email.zp.ua Mon Sep 8 09:30:20 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 8 Sep 2003 12:30:20 +0300 (EEST) Subject: %view macro in the user menu implemented In-Reply-To: Message-ID: <200309080930.h889UKkl073224@email.zp.ua> Hello! > Applied. I also have added an item for viewing manual pages to the menu, > which uses this patch. Thanks! > By the way, the menu needs to be reorganized and cleaned up. I don't > think many people need to "Strip headers from current newsarticle" very > often. Yes, as far as "Inspect gzip'ed newsbatch file" and "Uudecode marked news articles (needs work)". It seems it will be too hot month for me to participate in this deal ;-( -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Mon Sep 8 11:00:48 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 8 Sep 2003 14:00:48 +0300 (EEST) Subject: [patch]: rare segmentation violation in user menu Message-ID: <200309081100.h88B0mj6076801@email.zp.ua> Hello, Pavel! Apply these patches, please. Thanks! -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: user.c.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: view.patch URL: From stking at bway.net Mon Sep 8 20:32:37 2003 From: stking at bway.net (Sean King) Date: Mon, 8 Sep 2003 16:32:37 -0400 Subject: %view macro in the user menu implemented In-Reply-To: References: <200309041233.h84CX5rt019994@email.zp.ua> Message-ID: <20030908203237.GA13524@bway.net> On Thu, Sep 04, 2003 at 01:17:28PM -0400, Pavel Roskin wrote: > By the way, the menu needs to be reorganized and cleaned up. I don't > think many people need to "Strip headers from current newsarticle" very > often. Funny, that -- and the two mentioned by Andrew -- are the very ones I deleted long ago.... ;-) I don't know if the below are worth including in the dist; some may like to see them, however -- I use the heck out of 'em myself. + t t | T t e Edit tagged files TMPFILE=`mktemp -q -t 2B-ed.XXXXXXXXXX` || exit 1 set %u while [ -n "$1" ]; do echo "%d/$1" >>$TMPFILE shift done set %U while [ -n "$1" ]; do echo "%D/$1" >>$TMPFILE shift done ${EDITOR-vi} `cat $TMPFILE` rm -f $TMPFILE + ! t dcbfs & ! T dcbfs f diff file with file in the other directory TMPFILE=`mktemp -q -t mcdif.XXXXXXXXXX` || exit 1 echo "< %d/%f" >> $TMPFILE echo "> %D/%F" >> $TMPFILE echo "------" >> $TMPFILE diff %f %D/%F >> $TMPFILE if [ "$?" -eq 1 ]; then mc -v $TMPFILE fi rm -f $TMPFILE + t t F diff tagged files in current directory set %t [ $# -eq 2 ] && c=1 || exit 1 TMPFILE=`mktemp -q -t mcdif.XXXXXXXXXX` || exit 1 while [ -n "$1" ]; do if [ $c -lt 2 ]; then echo "< %d/$1" >> $TMPFILE else echo "> %d/$1" >> $TMPFILE fi eval ARG$c="%d/$1" c=2 shift done echo "------" >> $TMPFILE diff "$ARG1" "$ARG2" >> $TMPFILE if [ "$?" -eq 1 ]; then mc -v $TMPFILE fi rm -f $TMPFILE I suppose one would use the %view macro now, with that new patch applied. I use two more -- identical to the last two, except that they are invoked with 'g' and 'G', and call diff with the '-b' switch. best, S. From proski at gnu.org Tue Sep 9 05:20:15 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 09 Sep 2003 01:20:15 -0400 (EDT) Subject: [patch]: rare segmentation violation in user menu In-Reply-To: <200309081100.h88B0mj6076801@email.zp.ua> References: <200309081100.h88B0mj6076801@email.zp.ua> Message-ID: On Mon, 8 Sep 2003, Andrew V. Samoilov wrote: > Hello, Pavel! > > Apply these patches, please. Applied. Thank you! -- Regards, Pavel Roskin From juancri at TAGnet.org Tue Sep 9 05:31:15 2003 From: juancri at TAGnet.org (=?iso-8859-1?Q?Juan_Crist=F3bal_Olivares_C.?=) Date: Tue, 9 Sep 2003 01:31:15 -0400 Subject: c# segmentation fault Message-ID: <001e01c37693$9b82b350$0200a8c0@juancri> Hi: I sent you the cs.syntax file, a c# syntax highlight file, but it produces a segmentation fault in newer versions of mc. I don't know how is this but it can be fixed deleting (or commenting with a #) the line 95. Juan C. Olivares From juancri at TAGnet.org Tue Sep 9 05:35:48 2003 From: juancri at TAGnet.org (=?iso-8859-1?Q?Juan_Crist=F3bal_Olivares_C.?=) Date: Tue, 9 Sep 2003 01:35:48 -0400 Subject: c# segmentation fault [with file] Message-ID: <002a01c37694$3971c2e0$0200a8c0@juancri> File attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: cs.syntax Type: application/octet-stream Size: 4378 bytes Desc: not available URL: From makovick at kmlinux.fjfi.cvut.cz Tue Sep 9 13:55:55 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Tue, 09 Sep 2003 15:55:55 +0200 Subject: [PATCH] remove global vars in fish.c Message-ID: <3F5DDBEB.7050401@kmlinux.fjfi.cvut.cz> Hi, this patch removes the two remaining static globals in vfs/fish.c: 1) force_expiration is unused anyway; 2) reply_str is replaced by an additional parameter in command(). Regards, -- Jindrich Makovicka -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fish.c.diff URL: From makovick at kmlinux.fjfi.cvut.cz Tue Sep 9 18:54:03 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Tue, 09 Sep 2003 20:54:03 +0200 Subject: [PATCH] repaint other panel after Alt-O Message-ID: <3F5E21CB.80801@kmlinux.fjfi.cvut.cz> Hi, With current CVS, when a directory contains more files than fit on the screen, and the cursor is on the files "below the bottom edge", Alt-O selects this file in the other panel, but it still displays the entries beginning with the first one. The attached patch fixes this iissue by explicitly redrawing the panel when do_select sets top_file to something higher than zero. Regards, -- Jindrich Makovicka -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: screen.c.diff URL: From proski at gnu.org Tue Sep 9 21:08:47 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 9 Sep 2003 17:08:47 -0400 (EDT) Subject: Be careful with latest CVS Message-ID: Hello! I'm trying to make the widget library in the mc sources easier to use and debug. Many fixes depend on straightening it out. Unfortunately, it can affect stability. It appears that some changes applied this weekend broke quick widgets. The code in quick_callback() used an undocumented trick to close the dialog on Enter (the default is to move focus to the next widget), but allow the current button to set the return value of the dialog. As a result, selecting a non-default button and pressing Enter would activate the default button. In particular, the search/replace in the editor was affected. I have restored the old code in quick_callback() but added a comment. If you are using a CVS version from the last three days, please upgrade. Sorry for inconvenience. -- Regards, Pavel Roskin From andrew at email.zp.ua Tue Sep 9 22:34:08 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 10 Sep 2003 01:34:08 +0300 (EEST) Subject: Warning fix in smbfs Message-ID: <200309092234.h89MY8m4054257@email.zp.ua> Hello, Pavel! You did great work to remove unused code from smbfs!!! This patch comments out one more function to fix warning about declared but unused _interpret_node_status(). -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: namequery.c.patch URL: From proski at gnu.org Tue Sep 9 22:15:35 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 9 Sep 2003 18:15:35 -0400 (EDT) Subject: [PATCH] repaint other panel after Alt-O In-Reply-To: <3F5E21CB.80801@kmlinux.fjfi.cvut.cz> References: <3F5E21CB.80801@kmlinux.fjfi.cvut.cz> Message-ID: On Tue, 9 Sep 2003, Jindrich Makovicka wrote: > With current CVS, when a directory contains more files than fit on the > screen, and the cursor is on the files "below the bottom edge", Alt-O > selects this file in the other panel, but it still displays the entries > beginning with the first one. The attached patch fixes this iissue by > explicitly redrawing the panel when do_select sets top_file to something > higher than zero. The real problem is that the "dirty" flag on panels is now ignored, which is obviously wrong. The reason for this flag is to repaint the panel only once per event, and do it without the frame. I see that I was wrong when I removed make_panels_dirty(). The function was obviously misnamed, because it actually does the opposite. Also, the problem was masked by the fact that panel_update_contents() or paint_panel() is often called where setting panel->dirty would be sufficient. I'll try to fix this functionality. Thank you for your report! -- Regards, Pavel Roskin From proski at gnu.org Tue Sep 9 22:30:11 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 9 Sep 2003 18:30:11 -0400 (EDT) Subject: [PATCH] remove global vars in fish.c In-Reply-To: <3F5DDBEB.7050401@kmlinux.fjfi.cvut.cz> References: <3F5DDBEB.7050401@kmlinux.fjfi.cvut.cz> Message-ID: On Tue, 9 Sep 2003, Jindrich Makovicka wrote: > Hi, > > this patch removes the two remaining static globals in vfs/fish.c: > > 1) force_expiration is unused anyway; Yes, but please look beyond that piece of code. There is also force_expiration in ftpfs.c, and it's used in ftpfs_flushdir(). This function is called by update_one_panel_widget(). See FIXME in that code: /* FIXME: Should supply flushdir method */ I think mc_ctl() could be used to access this method outside VFS. > 2) reply_str is replaced by an additional parameter in command(). Please avoid random constants like 80. Either allocate enough memory for any reply, or set a limit as a preprocessor define, e.g. #define MAX_REPLY_LEN 80 -- Regards, Pavel Roskin From proski at gnu.org Tue Sep 9 22:55:25 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 9 Sep 2003 18:55:25 -0400 (EDT) Subject: c# segmentation fault [with file] In-Reply-To: <002a01c37694$3971c2e0$0200a8c0@juancri> References: <002a01c37694$3971c2e0$0200a8c0@juancri> Message-ID: On Tue, 9 Sep 2003, [iso-8859-1] Juan Crist?bal Olivares C. wrote: > File attached. OK, I cannot reproduce the segmentation fault, but the text in single quotes becomes black. The reason is a space inside the curly braces instead of \0x7F. Actually, \0x7F shouldn't be there because it's a control character, so I'm removing it. Also, I have noticed some changes between CVS and your version. I don't know which changes are intentional. That's why patches are preferred over whole files - at least I know what your base version was and I can assume that you have checked your changes. Keyword "interface" is yellow in CVS, white in your version. "typeoff" becomes "typeof". That's a good change, I'm applying it. New keyword "value". According to http://www.codeproject.com/useritems/ModifierKeywords.asp, it's not a keyword of the language, but IDE highlights it. I'm applying it. You version removes highlighting for %lx and similar constructs in double quotes. I don't think you wanted to make this change. It's more likely you are not using the CVS version as your base. I'm not applying this part. -- Regards, Pavel Roskin From juancri at TAGnet.org Tue Sep 9 23:32:29 2003 From: juancri at TAGnet.org (=?iso-8859-1?Q?Juan_Crist=F3bal_Olivares_C.?=) Date: Tue, 9 Sep 2003 19:32:29 -0400 Subject: c# segmentation fault [with file] References: <002a01c37694$3971c2e0$0200a8c0@juancri> Message-ID: <00cc01c3772a$a4e504b0$0200a8c0@juancri> I changed some highlight words. There was only one version before this one, so you can make a patch from the CVS. Juan C. Olivares ----- Original Message ----- From: "Pavel Roskin" To: "Juan Crist?bal Olivares C." Cc: Sent: Tuesday, September 09, 2003 6:55 PM Subject: Re: c# segmentation fault [with file] > On Tue, 9 Sep 2003, [iso-8859-1] Juan Crist?bal Olivares C. wrote: > > > File attached. > > OK, I cannot reproduce the segmentation fault, but the text in single > quotes becomes black. The reason is a space inside the curly braces > instead of \0x7F. Actually, \0x7F shouldn't be there because it's a > control character, so I'm removing it. > > Also, I have noticed some changes between CVS and your version. I don't > know which changes are intentional. That's why patches are preferred over > whole files - at least I know what your base version was and I can assume > that you have checked your changes. > > Keyword "interface" is yellow in CVS, white in your version. > > "typeoff" becomes "typeof". That's a good change, I'm applying it. > > New keyword "value". According to > http://www.codeproject.com/useritems/ModifierKeywords.asp, it's not a > keyword of the language, but IDE highlights it. I'm applying it. > > You version removes highlighting for %lx and similar constructs in double > quotes. I don't think you wanted to make this change. It's more likely > you are not using the CVS version as your base. I'm not applying this > part. > > -- > Regards, > Pavel Roskin > From proski at gnu.org Wed Sep 10 06:42:06 2003 From: proski at gnu.org (Pavel Roskin) Date: Wed, 10 Sep 2003 02:42:06 -0400 (EDT) Subject: [PATCH] repaint other panel after Alt-O In-Reply-To: References: <3F5E21CB.80801@kmlinux.fjfi.cvut.cz> Message-ID: On Tue, 9 Sep 2003, Pavel Roskin wrote: > On Tue, 9 Sep 2003, Jindrich Makovicka wrote: > > > With current CVS, when a directory contains more files than fit on the > > screen, and the cursor is on the files "below the bottom edge", Alt-O > > selects this file in the other panel, but it still displays the entries > > beginning with the first one. The attached patch fixes this issue by > > explicitly redrawing the panel when do_select sets top_file to something > > higher than zero. > > The real problem is that the "dirty" flag on panels is now ignored, which > is obviously wrong. The reason for this flag is to repaint the panel only > once per event, and do it without the frame. I have fixed the problem you reported by taking exactly the opposite approach compared to what you were trying to do. paint_panel() and panel_update_contents() are static now to discourage their excessive use where marking the panel dirty is enough. screen.c is still a mess. paint_dir(), repaint_file() and even paint_panel() are still used outside the WIDGET_DRAW and DLG_POST_KEY handlers. However, the problem you described has been solved. > I see that I was wrong when I removed make_panels_dirty(). It's now called update_dirty_panels() and resides in screen.c. It's also much simpler. -- Regards, Pavel Roskin From lists at pervalidus.tk Wed Sep 10 19:47:55 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Wed, 10 Sep 2003 16:47:55 -0300 (BRT) Subject: fish: zombies ? Message-ID: I don't know if it's a known (minor) issue, but when I use fish each connection leaves an ssh zombie until I exit mc. "Active VFS list" doesn't remove it. Example: root 17870 0.0 0.0 0 0 pts/1 Z 16:38 0:00 [ssh] Using CVS from a week ago with OpenSSH 3.6.1p2. -- How to contact me - http://www.pervalidus.net/contact.html From aliakc at web.de Thu Sep 11 19:50:46 2003 From: aliakc at web.de (Ali Akcaagac) Date: Thu, 11 Sep 2003 21:50:46 +0200 Subject: Be careful with latest CVS In-Reply-To: References: Message-ID: <1063309846.3596.1.camel@localhost> On Tue, 2003-09-09 at 23:08, Pavel Roskin wrote: > I have restored the old code in quick_callback() but added a > comment. If you are using a CVS version from the last three days, > please upgrade. Sorry for inconvenience. CVS HEAD from this morning C-x s (symlink) Still in quickmode, no OK/Cancel function only switching from one field to another. I hope that you don't keep that behavior because I expect to have it do an OK when pressing return and switching from one field to another with pressing TAB. (Basically the old way). From proski at gnu.org Thu Sep 11 22:32:58 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 11 Sep 2003 18:32:58 -0400 (EDT) Subject: Be careful with latest CVS In-Reply-To: <1063309846.3596.1.camel@localhost> References: <1063309846.3596.1.camel@localhost> Message-ID: On Thu, 11 Sep 2003, Ali Akcaagac wrote: > On Tue, 2003-09-09 at 23:08, Pavel Roskin wrote: > > I have restored the old code in quick_callback() but added a > > comment. If you are using a CVS version from the last three days, > > please upgrade. Sorry for inconvenience. > > CVS HEAD from this morning > > C-x s (symlink) > > Still in quickmode, no OK/Cancel function only switching from one field > to another. I hope that you don't keep that behavior because I expect to > have it do an OK when pressing return and switching from one field to > another with pressing TAB. (Basically the old way). Thanks for report. The problem is that the existing code is very inconsistent in treating Enter on focusable widgets other than buttons. Sometimes Enter would move focus to the next widget, sometimes it would be equivalent to the "OK" button, even if there is no such button in the dialog. Normal dialogs move focus on Enter. Quick dialogs had a callback to intercept Enter and close the dialog. The problem is that the user doesn't know if the dialog is implemented as quick dialog or not. I decided that if there is a default button (marked by "[<" and ">]"), Enter would activate it. Otherwise, the focus moves to the next field. I think that's a logical behavior. The "Find File" dialog was moving the focus despite having the default button. Now it turns out that the "Symbolic link" dialog doesn't have a default button, but expects to be closed by Enter. I have added "OK" and "Cancel". This also makes it possible to close the dialog by the mouse. We can close all dialogs on Enter. It's not hard to do, but I'm not sure if everybody would approve. -- Regards, Pavel Roskin From aliakc at web.de Fri Sep 12 03:46:22 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 12 Sep 2003 05:46:22 +0200 Subject: Be careful with latest CVS In-Reply-To: References: <1063309846.3596.1.camel@localhost> Message-ID: <1063338382.3800.8.camel@localhost> On Fri, 2003-09-12 at 00:32, Pavel Roskin wrote: > ... is a default button (marked by "[<" and ">]"), Enter would > activate it. Otherwise, the focus moves to the next field. > I think that's a logical behavior. I think comparing from the way normal graphical Toolkits work (Motif, GTK+, QT, ...) that switching the focus to another 'widget' (or field as in this case) is the right way to go and that 'Return' should be explicit used in the "[<" and ">]" scenarios. Having Return go to the next field is highly irritating because you don't always think about wether to be in a FORM where you can press 'Return' to close it and where you can go from Field to Field. > I have added "OK" and "Cancel". This also makes it possible to > close the dialog by the mouse. Yes this sound good. > We can close all dialogs on Enter. It's not hard to do, but I'm > not sure if everybody would approve. Well the way it was it around * <= 4.6.x was quite ok imo. From aliakc at web.de Fri Sep 12 03:49:35 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 12 Sep 2003 05:49:35 +0200 Subject: Be careful with latest CVS In-Reply-To: <1063338382.3800.8.camel@localhost> References: <1063309846.3596.1.camel@localhost> <1063338382.3800.8.camel@localhost> Message-ID: <1063338575.3798.11.camel@localhost> On Fri, 2003-09-12 at 05:46, Ali Akcaagac wrote: > I think comparing from the way normal graphical Toolkits work (Motif, > GTK+, QT, ...) that switching the focus to another 'widget' or field > as in this case ....? is the right way to go and that 'Return' should > be explicit used in the "[<" and ">]" scenarios. ? ... using the Tabulator Key ... Sorry, the sentence was half. From proski at gnu.org Fri Sep 12 07:27:58 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 12 Sep 2003 03:27:58 -0400 (EDT) Subject: Be careful with latest CVS In-Reply-To: <1063338382.3800.8.camel@localhost> References: <1063309846.3596.1.camel@localhost> <1063338382.3800.8.camel@localhost> Message-ID: On Fri, 12 Sep 2003, Ali Akcaagac wrote: > On Fri, 2003-09-12 at 00:32, Pavel Roskin wrote: > > ... is a default button (marked by "[<" and ">]"), Enter would > > activate it. Otherwise, the focus moves to the next field. > > I think that's a logical behavior. > > I think comparing from the way normal graphical Toolkits work (Motif, > GTK+, QT, ...) that switching the focus to another 'widget' (or field as > in this case) is the right way to go and that 'Return' should be > explicit used in the "[<" and ">]" scenarios. Having Return go to the > next field is highly irritating because you don't always think about > wether to be in a FORM where you can press 'Return' to close it and > where you can go from Field to Field. I see. I was unclear, Enter goes to the next widget only in the input widget (see input_callback). This code is prehistoric. It's present in revision 1.1 of widget.c. Perhaps it's time to remove it. > > We can close all dialogs on Enter. It's not hard to do, but I'm not > > sure if everybody would approve. > > Well the way it was it around * <= 4.6.x was quite ok imo. Just to clear misunderstanding, I'm not trying to change any user visible behavior. I'm trying to make the internals easier to understand so that it's easier to develop more code. I'm trying to make it unnecessary to use workarounds to achieve standard functionality. I'm trying to make it easier to write and change user interface. Ideally, the behavior should not change. But it should also be consistent. As I said, Enter in the Find File dialog would go to the next field. That's what you don't like, and that's what it was in 4.6.0. In fact, it has been the standard feature of the input widget at least since February 1998. It was just masked in some dialogs, but not in others. -- Regards, Pavel Roskin From tux at centrum.cz Thu Sep 18 11:33:06 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Thu, 18 Sep 2003 13:33:06 +0200 Subject: [PATCH] 3 patches for MC-2003-09-15-04 Message-ID: <20030918113306Z99073-26953+388255@mail.centrum.cz> I am sending three patches for latest development version of MC In attached archive patches.tgz (6KB) are three files: kilobyte.patch : Allow to specify whether you want to use 1024 based kilobyte units (as is now default) or 1000 based kilobyte when showing file sizes - settable in mc.ini. (i found it difficult to compare values like 695M and 728000123 bytes, I don't know waht is more or less without taking a calculator, so after applying this patch, anyone can set one_kilobyte=1000 in mc.ini and values like 695M will change to 728m or so. Thousand based units are IMHO more human-readable) sort_order.patch : change sort order by keyboard shortcuts, I modified this patch for this mc version and corrected one bug that was there (indicator not repainting) datefromat.patch : change datetime format, modified to apply to current development version each of these patches is independent of others and can be applied separately and in any order. All the patches include changelog entry and updated documentation. Please apply them to current MC. Just do `patch -p 1 From hubert at feyrer.de Fri Sep 19 02:27:41 2003 From: hubert at feyrer.de (Hubert Feyrer) Date: Fri, 19 Sep 2003 04:27:41 +0200 (MEST) Subject: Patches for mc-4.5.51 Message-ID: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Hi! below you will find some patches against mc-4.5.51 that are currently part of the NetBSD Packages Collection, pkgsrc, to get your software build properly on NetBSD and maybe some other platforms. We'd be pleased if you could include as much of these patches into your next release as possible, thanks! FWIW, your software has a webpage at the NetBSD site, see http://www.NetBSD.org/packages/sysutils/mc/README.html See http://www.NetBSD.org/Documentation/software/packages.html to learn more about the NetBSD Packages Collection, to find out more about the NetBSD operating system, see http://www.NetBSD.org/. --- 8X --- 8X --- 8X --- 8X --- 8X --- 8X --- 8X --- 8X --- 8X --- 8X --- $NetBSD: patch-aa,v 1.11 2002/10/08 17:27:20 wiz Exp $ --- configure.orig Mon Jul 3 10:31:57 2000 +++ configure @@ -3543,6 +3543,11 @@ +# Set DATADIRNAME to "${PKGLOCALEDIR}" +DATADIRNAME="${PKGLOCALEDIR}" +INTLDEPS= +INTLLIBS="-lintl" + cc_uses_g=yes if test x$GCC = xyes; then if test x$ac_cv_prog_gcc_g = xyes; then @@ -9409,11 +9414,15 @@ # Check whether --with-gnome or --without-gnome was given. +gnomecodedirs= +gnomeunixdirs= if test "${with_gnome+set}" = set; then withval="$with_gnome" if test x$withval = xyes; then want_gnome=yes + gnomecodedirs='gnome idl' + gnomeunixdirs='doc-gnome' mx=mx gmcdep=gmcdep libgtkedit="libgtkedit.a" @@ -11891,6 +11900,7 @@ s/@@/%@/; s/@@/@%/; s/@g\$/%g/' > conftest.subs <<\\CEOF $ac_vpsub $extrasub +s%@LOCALBASE@%$LOCALBASE%g s%@SHELL@%$SHELL%g s%@CFLAGS@%$CFLAGS%g s%@CPPFLAGS@%$CPPFLAGS%g @@ -12019,6 +12029,8 @@ s%@GNOME_DOCKLETS_LIBS@%$GNOME_DOCKLETS_LIBS%g s%@GNOME_CAPPLET_LIBS@%$GNOME_CAPPLET_LIBS%g s%@gnomeicondir@%$gnomeicondir%g +s%@gnomecodedirs@%$gnomecodedirs%g +s%@gnomeunixdirs@%$gnomeunixdirs%g s%@mx@%$mx%g s%@gmcdep@%$gmcdep%g s%@libgtkedit@%$libgtkedit%g $NetBSD: patch-ab,v 1.10 2000/10/19 23:31:18 jlam Exp $ --- vfs/Make-mc.in.orig Mon Jul 3 10:31:58 2000 +++ vfs/Make-mc.in @@ -16,6 +16,7 @@ INSTALL = @INSTALL@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ -m 755 INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ AR = @AR@ # @@ -342,11 +343,11 @@ $(DESTDIR)$(extfsdir)/$$I; \ done for I in $(EXTFS_CONST) ; do \ - $(INSTALL_PROGRAM) $(srcdir)/extfs/$$I \ + $(INSTALL_SCRIPT) $(srcdir)/extfs/$$I \ $(DESTDIR)$(extfsdir)/$$I; \ done for I in $(EXTFS_OUT) ; do \ - $(INSTALL_PROGRAM) $(builddir)/vfs/extfs/$$I \ + $(INSTALL_SCRIPT) $(builddir)/vfs/extfs/$$I \ $(DESTDIR)$(extfsdir)/$$I; \ done $NetBSD: patch-ac,v 1.7 1999/10/23 11:54:35 tron Exp $ --- lib/Makefile.in.orig Wed Sep 29 22:39:38 1999 +++ lib/Makefile.in Sat Oct 23 13:29:19 1999 @@ -7,6 +7,7 @@ INSTALL = @INSTALL@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ # # Distribution variables @@ -62,7 +63,7 @@ for I in $(LIBFILES_OUT); \ do $(INSTALL_DATA) $(builddir)/lib/$$I $(DESTDIR)$(mclibdir)/$$I; done for I in $(SUPPBIN_OUT); \ - do $(INSTALL_PROGRAM) -m 755 $(builddir)/lib/$$I $(DESTDIR)$(suppbindir)//$$I; done + do $(INSTALL_SCRIPT) -m 755 $(builddir)/lib/$$I $(DESTDIR)$(suppbindir)//$$I; done for I in $(TIFILES); \ do $(INSTALL_DATA) $(srcdir)/$$I $(DESTDIR)$(tidir)/$$I; done $(MKINSTALLDIRS) $(DESTDIR)$(confdir) $NetBSD: patch-ad,v 1.7 2002/10/23 08:49:07 bouyer Exp $ --- vfs/smbfs.c.orig Mon Jul 3 16:31:59 2000 +++ vfs/smbfs.c Tue Oct 22 22:29:12 2002 @@ -29,7 +29,9 @@ confilcts with definitions in other includes */ #undef HAVE_LIBREADLINE #define NO_CONFIG_H +#ifndef SunOS #define BOOL_DEFINED +#endif #include "samba/include/includes.h" #include @@ -375,7 +377,8 @@ static int smbfs_init(vfs *me) { - char *servicesf = "/etc/smb.conf"; + /* This must match what net/samba uses. */ + char *servicesf = "/etc/samba/smb.conf"; /* DEBUGLEVEL = 4; */ $NetBSD: patch-af,v 1.11 2000/10/19 23:31:18 jlam Exp $ --- Makefile.in.orig Mon Jul 3 10:31:57 2000 +++ Makefile.in @@ -5,14 +5,15 @@ @MCFGR@@MCF@ foreigndirs=pc -codedirs=vfs lib doc slang gtkedit edit src gnome new_icons icons idl syntax -unixdirs=intl $(codedirs) doc-gnome @POSUB@ +codedirs=vfs lib doc slang gtkedit edit src new_icons icons syntax @gnomecodedirs@ +unixdirs=intl $(codedirs) @gnomeunixdirs@ @POSUB@ alldirs=$(unixdirs) $(foreigndirs) subdirs=$(alldirs) INSTALL = @INSTALL@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_DATA = @INSTALL_DATA@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ DISTMAIN = configure configure.in NEWS README INSTALL INSTALL.FAST \ Makefile.in FAQ COPYING create_vcs install-sh \ @@ -45,7 +46,7 @@ install: installdirs @for I in $(unixdirs); do cd $$I; $(MAKE) DESTDIR=$(DESTDIR) $@ || exit 1; cd ..; done $(INSTALL_DATA) $(srcdir)/FAQ $(DESTDIR)$(mclibdir)/FAQ - $(INSTALL_PROGRAM) mcfn_install $(DESTDIR)$(suppbindir)/mcfn_install + $(INSTALL_SCRIPT) mcfn_install $(DESTDIR)$(suppbindir)/mcfn_install chmod +x $(DESTDIR)$(suppbindir)/mcfn_install @echo "Please verify that the configuration values are correctly" @echo "set in the mc.ext file in $(mclibdir)" $NetBSD: patch-ag,v 1.9 2002/07/24 04:30:16 hubertf Exp $ --- vfs/extfs/uzip.in.orig Mon Jul 3 10:32:00 2000 +++ vfs/extfs/uzip.in @@ -7,7 +7,7 @@ # # -DZIP=/usr/bin +DZIP=@LOCALBASE@/bin XZIP="$DZIP/zip -g" XDZIP="$DZIP/zip -d" XUNZIP="$DZIP/unzip" $NetBSD: patch-ah,v 1.4 2002/07/24 04:30:16 hubertf Exp $ --- vfs/extfs/urar.in.orig Mon Jul 3 10:32:00 2000 +++ vfs/extfs/urar.in @@ -5,7 +5,7 @@ # Updated by christian.gennerat at alcatel.fr 1999 # beta version 2.0 # -DRAR=/usr/bin +DRAR=@LOCALBASE@/bin RAR=$DRAR/rar UNRAR=$DRAR/unrar # Prefer unrar (freeware) # $NetBSD: patch-ae,v 1.7 2002/07/24 05:06:00 hubertf Exp $ --- vfs/extfs/ulha.in.orig Wed Jul 24 06:52:24 2002 +++ vfs/extfs/ulha.in @@ -34,11 +34,16 @@ # Define your awk AWK=@AWK@ -if ls -de . >& /dev/null; +if ls -de . >/dev/null 2>&1 ; then LS_COMMAND="ls -le" else - LS_COMMAND="ls -l --full-time" + if ls -dT . >/dev/null 2>&1; # BSD::ls -T == Linux::ls -e + then + LS_COMMAND="ls -lT" + else + LS_COMMAND="ls -l --full-time" + fi fi # Define which archiver you are using with appropriate options $NetBSD: patch-ai,v 1.1 2002/10/08 17:27:20 wiz Exp $ --- vfs/samba/Makefile.in.orig Tue Oct 8 19:13:16 2002 +++ vfs/samba/Makefile.in @@ -518,8 +518,6 @@ $(srcdir)/include/config.h.in: $(srcdir) @: $(srcdir)/include/stamp-h.in: @MAINT@ $(srcdir)/acconfig.h $(srcdir)/configure.in - cd $(srcdir) && $(AUTOHEADER) - @date -u > $@ # automatic dependency tracking rules .deps/.dummy: $NetBSD: patch-aj,v 1.1 2003/05/22 17:02:54 salo Exp $ --- slang/slang-mc.h.orig 2000-07-03 16:32:03.000000000 +0200 +++ slang/slang-mc.h 2003-05-22 18:43:06.000000000 +0200 @@ -25,6 +25,11 @@ # endif #endif /* __watcomc__ */ +#ifdef __NetBSD__ +#undef unix +#define unix 1 +#endif + #ifdef unix # ifndef __unix__ # define __unix__ 1 From proski at gnu.org Fri Sep 19 05:24:02 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 19 Sep 2003 01:24:02 -0400 (EDT) Subject: Patches for mc-4.5.51 In-Reply-To: <200309190227.h8J2Rfo09460@miyu.feyrer.net> References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: On Fri, 19 Sep 2003, Hubert Feyrer wrote: > Hi! > > below you will find some patches against mc-4.5.51 that are > currently part of the NetBSD Packages Collection, pkgsrc, to get your > software build properly on NetBSD and maybe some other platforms. We'd > be pleased if you could include as much of these patches into your next > release as possible, thanks! I remember reviewing and applying something similar before 4.5.55 release. I don't see anything in this patch that wasn't addressed in some form. Current stable version is 4.6.0. I'm surprised that you are still using version 4.5.51, which is more than 3 years old. What would you do with a patch for NetBSD 1.4 kernel if I sent it to you today? If you mistrust development that happened after 4.5.51, then I'll appreciate if you explain the reasons. Stability and portability has been the focus of the recent releases. Version 4.6.0 was tested by Valgrind for memory errors, and several of them have been found and fixed. This tool didn't even exist when 4.5.51 was released. If you believe in rumors that the new mc requires GNOME 2 and XFree86 as some posters here implied, please adjust your reality :-) -- Regards, Pavel Roskin From hubert.feyrer at informatik.fh-regensburg.de Fri Sep 19 10:25:57 2003 From: hubert.feyrer at informatik.fh-regensburg.de (Hubert Feyrer) Date: Fri, 19 Sep 2003 12:25:57 +0200 (MEST) Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: On Fri, 19 Sep 2003, Pavel Roskin wrote: > If you mistrust development that happened after 4.5.51, then I'll > appreciate if you explain the reasons. Stability and portability has been > the focus of the recent releases. Version 4.6.0 was tested by Valgrind > for memory errors, and several of them have been found and fixed. This > tool didn't even exist when 4.5.51 was released. We don't distrust you, don't worry. It's just most likely that everyone was happy with 4.5.51 so far, and didn't feel a real urge to upgrade. Which is unfortunate on it's own, admittedly. > If you believe in rumors that the new mc requires GNOME 2 and XFree86 as > some posters here implied, please adjust your reality :-) No. :) - Hubert -- ___ _ _ _ _ * Harddisk Image Cloning * / __| | || | | | www.feyrer.de/g4u/ | (_ |_ _| |_| | \___| |_| \___/ v1.12 out now, including partition support! From gotar at poczta.onet.pl Fri Sep 19 10:19:00 2003 From: gotar at poczta.onet.pl (GoTaR) Date: Fri, 19 Sep 2003 12:19:00 +0200 Subject: more xterm.ad sequences In-Reply-To: <20030907201742.GA27300@os> References: <20030906103039.GA5283@os> <20030907201742.GA27300@os> Message-ID: <20030919101900.GA23671@os> On Sun, Sep 07, 2003 at 22:17:42 +0200, GoTaR wrote: I see no answer or comment on this, so here is the most important part once more: > Well, maybe you would like to include this to [src/]key.c: > > { KEY_M_CTRL | KEY_UP, ESC_STR "[1;5A", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_DOWN, ESC_STR "[1;5B", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_RIGHT, ESC_STR "[1;5C", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_LEFT, ESC_STR "[1;5D", MCKEY_NOACTION }, > > ctrl-left/right moves by words, ctrl-up/down scrolls screen w/o moving > cursor. And this one too: > > { KEY_M_SHIFT | KEY_IC, ESC_STR "[2;2~", MCKEY_NOACTION }, > > if someone wants to override paste from X clipboard to paste from mc > clipboard (ctrl-ins and shift-del: to clipboard, shift-ins: from > clipboard). These are vital for the combos to work, at least when compiled w/o X. -- Tom Pala http://vfmg.sourceforge.net/ http://www.pld-linux.org/Members/gotar/ From mr700 at globalnet.bg Fri Sep 19 15:12:59 2003 From: mr700 at globalnet.bg (Doncho Gunchev) Date: Fri, 19 Sep 2003 18:12:59 +0300 Subject: mc /some/dir/\~/ bug... Message-ID: <200309191812.59668.mr700@globalnet.bg> I've tryed to enter a directory named \~ / '~' and I got into my home :) ex: cd mkdir tmp cd tmp mkdir '~' then try to go in tmp an then to '~' with mc... I use GNU Midnight Commander 4.6.0 build from source rpm... someone ideas? I could not decide where, so I'm sending bouth to mc users & mc developers... -- Regards, Doncho N. Gunchev From andrew at email.zp.ua Fri Sep 19 19:40:13 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 19 Sep 2003 22:40:13 +0300 (EEST) Subject: c# segmentation fault [with file] In-Reply-To: <00cc01c3772a$a4e504b0$0200a8c0@juancri> Message-ID: <200309191940.h8JJeDOS093908@email.zp.ua> > I changed some highlight words. There was only one version before this one, > so you can make a patch from the CVS. > > Juan C. Olivares > > ----- Original Message ----- > From: "Pavel Roskin" > To: "Juan Crist?bal Olivares C." > Cc: > Sent: Tuesday, September 09, 2003 6:55 PM > Subject: Re: c# segmentation fault [with file] > > > > On Tue, 9 Sep 2003, [iso-8859-1] Juan Crist?bal Olivares C. wrote: > > > > > File attached. > > > > OK, I cannot reproduce the segmentation fault, but the text in single > > quotes becomes black. The reason is a space inside the curly braces > > instead of \0x7F. Actually, \0x7F shouldn't be there because it's a > > control character, so I'm removing it. This space divided your keyword and second part was treated as foreground color. This part was too long to fit in stack allocated buffer, so we had classic buffer overflow. This bug fixed in CVS since 2003-02-25. Patch attached. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: syntax.c.patch URL: From lists at pervalidus.tk Fri Sep 19 23:37:50 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Fri, 19 Sep 2003 20:37:50 -0300 (E. South America Standard Time) Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: On Fri, 19 Sep 2003, Pavel Roskin wrote: > If you believe in rumors that the new mc requires GNOME 2 and > XFree86 as some posters here implied, please adjust your > reality :-) And it's a shame people still fork it, like with Midnight Commander MP. I was going to try it but was surprised by the following on http://mc.linuxinside.com/ : "there is no possibilities to compile it without some X parts, like Glib." Not to mention the third paragraph makes you wonder if the developers (mainly Pavel) are the worse :-) Well, a nice feature I miss is the MultiScreen support from Walery, which seems to be in MP. Others from Arpi were nice too. Anyway, if I was a programmer I'd contribute to HEAD, not fork and have my ideas used by a few people. -- How to contact me - http://www.pervalidus.net/contact.html From lists at pervalidus.tk Sat Sep 20 05:29:04 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Sat, 20 Sep 2003 02:29:04 -0300 (E. South America Standard Time) Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: On Fri, 19 Sep 2003, Fr?d?ric L. W. Meunier wrote: > On Fri, 19 Sep 2003, Pavel Roskin wrote: > > > If you believe in rumors that the new mc requires GNOME 2 and > > XFree86 as some posters here implied, please adjust your > > reality :-) The following makes me wonder if some distribution requires the XFree86 libraries. From src/ChangeLog: 2003-02-22 Pavel Tsekov * acinclude.m4 [AC_G_MODULE_SUPPORTED]: New macro. * configure.in: Test for gmodule. Don't link mc with libX11 if gmodule is supported. 2002-12-23 Pavel Roskin * configure.in: Enable X11 support by default, use --without-x to disable. So, does 4.6.0 by default require it ? 2003-02-22 is after the release. http://lists.suse.com/archive/suse-linux-e/2003-Jul/1031.html Well, it's up to the distribution maintainers. I don't know what SuSE did. -- How to contact me - http://www.pervalidus.net/contact.html From makovick at kmlinux.fjfi.cvut.cz Sat Sep 20 09:15:49 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Sat, 20 Sep 2003 11:15:49 +0200 Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: <3F6C1AC5.1040503@kmlinux.fjfi.cvut.cz> Fr?d?ric L. W. Meunier wrote: > Anyway, if I was a programmer I'd contribute to HEAD, not fork > and have my ideas used by a few people. Here is my favourite one, resume support for ftp (& others), I am using it for about a year, and don't think anymore that this feature will ever get into "official" mc :) I appreciate the efforts regarding the code cleanups, but maybe the mc development should be a _bit_ more liberal. It's nice that the current mc has a much cleaner codebase, but the things which pissed me off (ftp resume, operations which sometimes have to be cancelled by ctrl-z kill -9 mc - mainly Viewer and Find File) three years ago are still there and there's no sign they'll go away anytime soon. And yes, I sent patches addressing these issues, with no reply. Maybe they are crappy, because I don't know the mc code much, but at least "your patch sucks because of this and that" would be appreciated. Regards, -- Jindrich Makovicka -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ftp_resume.patch URL: From dave at jikos.cz Sat Sep 20 17:30:27 2003 From: dave at jikos.cz (David Sterba) Date: Sat, 20 Sep 2003 19:30:27 +0200 Subject: mc /some/dir/\~/ bug... In-Reply-To: <200309191812.59668.mr700@globalnet.bg> References: <200309191812.59668.mr700@globalnet.bg> Message-ID: <200309201930.27307.dave@jikos.cz> Hi, this is known bug (see src/TODO). Dave From tux at centrum.cz Sat Sep 20 19:35:07 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Sat, 20 Sep 2003 21:35:07 +0200 Subject: Patches for mc-4.5.51 Message-ID: <20030920193515Z100529-26955+446453@mail.centrum.cz> > And yes, I sent patches addressing these issues, with no reply. Maybe > they are crappy, because I don't know the mc code much, but at least > "your patch sucks because of this and that" would be appreciated. I sent three patches too, but neither I saw them applied, neither I received email like "the patches sucks because ..." or at least "your patch sucks". Also the bug "when I edit file and change directory in subshell, the file is saved elsewhere" - I saw a patch on it on https://savannah.gnu.org/patch/?group=mc about 6 months ago and the problem is still there (or at least was in the 2003/08 development snapshot, I haven't checked the 2003/09/15 for this bug yet) In the past I saw some MC versions where someone fixed few annoying issues, gave out some better version of MC, but he was unable to maintain it and apply changes from the official mc, so in few months that version was osoleted by mc with some new features but still with old bugs. So there exist some versions that are 4.5.X (or older) with some good improvements, but on the other hand they for example don't remember positions in editor, etc... Maybe it's a good idea to fork MC into stable and unstable branch, like there is 2.4.x (stable) and 2.5.x (testing) linux kernel, and to port features from the testing branch to the stable once they are found bug free or whatever... I will use the testing branch anyway :o) And, of course, the unstable should be more liberal in accepting patches.... Martin Petricek -------------------- Svezte se a vyhrajte s nov?m Ford Focus C-MAX. http://ad2.bbmedia.cz/please/redirect/124/6/1/7/?param=3149/3823_1 From stking at bway.net Sat Sep 20 22:27:30 2003 From: stking at bway.net (Sean King) Date: Sat, 20 Sep 2003 18:27:30 -0400 Subject: Patches for mc-4.5.51 In-Reply-To: <20030920193515Z100529-26955+446453@mail.centrum.cz> References: <20030920193515Z100529-26955+446453@mail.centrum.cz> Message-ID: <20030920222730.GA28919@bway.net> On Sat, Sep 20, 2003 at 09:35:07PM +0200, tux at centrum.cz wrote: > > And yes, I sent patches addressing these issues, with no reply. Maybe > > they are crappy, because I don't know the mc code much, but at least > > "your patch sucks because of this and that" would be appreciated. > > I sent three patches too, but neither I saw them applied, neither > I received email like "the patches sucks because ..." or at least > "your patch sucks". Say, you beat me to the punch -- I was going to say the exact same thing! ;-) ...In key.c, we have 'xterm_key_defines' -- one group there is actually commented as '/* rxvt keys with modifiers */'.... AFAICS, those sequences are defined (in init_key()) _only_ if TERM=xterm* or TERM=iris-ansi* . I suggested that || (!strncmp (term, "rxvt", 4)) be added (takes care of rxvt _and_ derivatives) (or even, || (!strncmp (term, "rxvt", 4)) || (!strncmp (term, "Eterm", 5)) ) Not alone that nobody says, Great idea, thanks. (Maybe it _isn't_ a good idea -- maybe I missed something.) But nobody says: bad idea, because.... No one says: bad idea, and I'm not going to tell you why.... No one even says, Go jump in the lake.... Well, that's one way to run a project! S. From dooligan at intergate.ca Mon Sep 22 04:58:38 2003 From: dooligan at intergate.ca (Miven Dooligan) Date: Sun, 21 Sep 2003 21:58:38 -0700 Subject: Patches for mc-4.5.51 References: <20030920193515Z100529-26955+446453@mail.centrum.cz> Message-ID: <3F6E817E.1040809@intergate.ca> > > Maybe it's a good idea to fork MC into stable and unstable branch, like there is 2.4.x (stable) and 2.5.x (testing) > linux kernel, and to port features from the testing branch to the stable once they are found bug free or > whatever... I will use the testing branch anyway :o) > > And, of course, the unstable should be more liberal in accepting patches.... > I agree. It's a good idea. 4.6 and 4.7. From andrew at email.zp.ua Mon Sep 22 13:54:46 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 22 Sep 2003 16:54:46 +0300 (EEST) Subject: Patches for mc-4.5.51 In-Reply-To: <20030920193515Z100529-26955+446453@mail.centrum.cz> Message-ID: <200309221354.h8MDskx6098260@email.zp.ua> > > And yes, I sent patches addressing these issues, with no reply. Maybe > > they are crappy, because I don't know the mc code much, but at least > > "your patch sucks because of this and that" would be appreciated. > > I sent three patches too, but neither I saw them applied, neither I received email like "the patches sucks because ..." or at least "your patch sucks". > > Also the bug "when I edit file and change directory in subshell, the file is saved elsewhere" - I saw a patch on it on https://savannah.gnu.org/patch/?group=mc about 6 months ago and the problem is still there (or at least was in the 2003/08 development snapshot, I haven't checked the 2003/09/15 for this bug yet) Please check this bug again: 2003-07-31 Andrew V. Samoilov * edit-widget.h: Resurrect "dir" field in WEdit to store directory for relative filenames. * edit.c (edit_clean): Release edit->dir. * editcmd.c (edit_save_file): Use absolute filename. Temporarily disable safe save and backups on remote VFS because it doesn't work - again. -- Regards, Andrew V. Samoilov. From proski at gnu.org Mon Sep 22 22:32:18 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 22 Sep 2003 18:32:18 -0400 (EDT) Subject: c# segmentation fault [with file] In-Reply-To: <200309191940.h8JJeDOS093908@email.zp.ua> References: <200309191940.h8JJeDOS093908@email.zp.ua> Message-ID: On Fri, 19 Sep 2003, Andrew V. Samoilov wrote: > This space divided your keyword and second part was treated as > foreground color. This part was too long to fit in stack allocated > buffer, so we had classic buffer overflow. This bug fixed in CVS since > 2003-02-25. It wasn't sufficient. An additional patch has been applied to CVS: 2003-09-22 Pavel Roskin * syntax.c (compare_word_to_right): Add checks that we don't go beyond text length for certain invalid rules. Reported by Juan C. Olivares -- Regards, Pavel Roskin From proski at gnu.org Tue Sep 23 05:28:33 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 23 Sep 2003 01:28:33 -0400 (EDT) Subject: mc /some/dir/\~/ bug... In-Reply-To: <200309201930.27307.dave@jikos.cz> References: <200309191812.59668.mr700@globalnet.bg> <200309201930.27307.dave@jikos.cz> Message-ID: On Sat, 20 Sep 2003, David Sterba wrote: > Hi, > > this is known bug (see src/TODO). Fixed. I've removed tilde expansion from the generic VFS code. It doesn't belong there. mc_chdir() should be equivalent to chdir() on localfs, and chdir() doesn't expand tilde. If tilde expansion on some VFSes (e.g. ftpfs) is still desired, it should be implemented there, not in the generic VFS code. -- Regards, Pavel Roskin From proski at gnu.org Tue Sep 23 07:16:55 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 23 Sep 2003 03:16:55 -0400 (EDT) Subject: more xterm.ad sequences In-Reply-To: <20030907201742.GA27300@os> References: <20030906103039.GA5283@os> <20030907201742.GA27300@os> Message-ID: On Sun, 7 Sep 2003, GoTaR wrote: > Yes, that information should go into the file. BTW there are two typos: > > 2nd line: "IS you are using enclosed" should be "if" > 12th line: "modifier in FRON of some" shoud be "front" Fixed. > > Strange thing is, xterm.ad has been unchanged since 1998 and I don't > > remember seeing any complaints about it. Either nobody used it or > > those who tried gave up and took some other approach. > > Or used it as a simple example/template. For example it was probably > used as a template in PLD Linux Distribution. Ideally, new distributions should have terminals that don't need any workarounds. xterm.ad and other files are primarily for old systems. > > I'm afraid not everybody will be happy with the "improved" xterm.ad. I'm > > more inclined to remove xterm.ad, xterm.ti and xterm.tcap from the > > sources. They don't belong here. > > xterm.ti and xterm.tcap are redundant, but xterm.ad should be moved to > examples or docs. Done. > Without it many would never know how to change xterm resources. E.g. I'm > using: > > MetaRight: string(0x1b) string(0x09) > > to have 'tab' completion on alt-right_arrow. OK, this file is staying in the sources. > Well, maybe you would like to include this to key.c: > > { KEY_M_CTRL | KEY_UP, ESC_STR "[1;5A", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_DOWN, ESC_STR "[1;5B", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_RIGHT, ESC_STR "[1;5C", MCKEY_NOACTION }, > { KEY_M_CTRL | KEY_LEFT, ESC_STR "[1;5D", MCKEY_NOACTION }, > ctrl-left/right moves by words, ctrl-up/down scrolls screen w/o moving > cursor. And this one too: > > { KEY_M_SHIFT | KEY_IC, ESC_STR "[2;2~", MCKEY_NOACTION }, > > if someone wants to override paste from X clipboard to paste from mc > clipboard (ctrl-ins and shift-del: to clipboard, shift-ins: from > clipboard). Done. > > The times have changed since then. Terminals are more capable and > > users don't want to tweak everything. There are other means to make > > keys work, such as the "Learn Keys" dialog. > > > > I don't want users to be confused by something they most likely don't > > need. I haven't seen bug reports about xterm.ad, but I have seen and > > even heard complaints from people who could not find "Learn Keys" > > because our documentation is still oriented to the hackers of the past > > times. > > Hey, lusers don't use mc at all, they use konqueror. mc is tool for > hackers and power users and that's the way it should remain. Anyway, today's hackers may not have time to tweak everything. Things should work by default if possible. > Oh, by the way: have you heard about Midnight Commander MP: > http://mc.linuxinside.com/cgi-bin/dir.cgi I remember seeing that link. > it has many nice features, like clock, different colors for differet > file types, panel resplitter (Ctrl+LEFT|RIGHT|END as F9-o-l-[<>e]-o), > checkbox for recursive search in find file (one must use grep if wants > to search non-recursively with current mc implementation), and very > useful thing - bookmarks in editor (Alt-Ctrl-Ins: set bookmark, > Alt-Ctrl-UP|DOWN: move through them). And many others - please read > README.40, but the ones I mentioned, are the most usefull. I'll be happy > to see them in mc. As it stands now, there is not enough manpower to apply already existing patches fast, so I don't expect it to happen unless somebody ports the changes and pushes them very actively. It's quite hard to write new GUI now. We don't even have a generic function to spread buttons in dialogs (their length is different in different languages). Until recently, widgets had to be inserted from bottom to top, and it's still true for "quick" widgets. The listmode editor sits in the code unfinished for years. Things are improving, but it's still too fragile and inconvenient. -- Regards, Pavel Roskin From thomas.jarosch at intra2net.com Tue Sep 23 13:19:46 2003 From: thomas.jarosch at intra2net.com (Thomas Jarosch) Date: Tue, 23 Sep 2003 15:19:46 +0200 Subject: Fwd: uninitialized buffer in midnight commander Message-ID: <200309231519.46936.thomas.jarosch@intra2net.com> Hello! I've seen this posting on bugtraq, but it looks like Ilya Teterin didn't care to contact the authors of mc. Forgive me if I'm wrong :-) Please CC: reply as I'm not on the list. Cheers, Thomas ---------- Forwarded Message ---------- Subject: uninitialized buffer in midnight commander Date: Friday 19 September 2003 15:47 From: "Ilya Teterin" To: bugtraq at securityfocus.com Midnight Commander is using uninitialized buffer for handling symlinks in VFS (tar, cpio). See vfs/direntry.c, handling of buf[] at vfs_s_resolve_symlink(). I wonder but it works almost properly ;-) On linux-i386 I can reach stack buffer overflow using specially crafted archive. Open http://buggzy.narod.ru/exp.tgz in mc's VFS to test (mc will crash). Affected systems/vendors/archs: at least linux-i386, mc-4.5.52 to mc-4.6.0, too lazy to test others ;-) P.S. Greetings to iDEFENSE VCP. I'm tired and hungry ;) ------------------------------------------------------- From proski at gnu.org Wed Sep 24 08:04:41 2003 From: proski at gnu.org (Pavel Roskin) Date: Wed, 24 Sep 2003 04:04:41 -0400 (EDT) Subject: Fwd: uninitialized buffer in midnight commander In-Reply-To: <200309231519.46936.thomas.jarosch@intra2net.com> References: <200309231519.46936.thomas.jarosch@intra2net.com> Message-ID: On Tue, 23 Sep 2003, Thomas Jarosch wrote: > Hello! > > I've seen this posting on bugtraq, but it looks like Ilya Teterin didn't > care to contact the authors of mc. Forgive me if I'm wrong :-) Thank you for your report. I confirm that the bug is still present in the CVS version. Indeed, vfs_s_resolve_symlink() uses buffer of fixed size but never checks if its size is sufficient. There are still places in the VFS code that were written without any thought of security. -- Regards, Pavel Roskin From proski at gnu.org Fri Sep 26 22:09:01 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 26 Sep 2003 18:09:01 -0400 (EDT) Subject: [PATCH] 3 patches for MC-2003-09-15-04 In-Reply-To: <20030918113306Z99073-26953+388255@mail.centrum.cz> References: <20030918113306Z99073-26953+388255@mail.centrum.cz> Message-ID: On Thu, 18 Sep 2003 tux at centrum.cz wrote: > I am sending three patches for latest development version of MC > In attached archive patches.tgz (6KB) are three files: > kilobyte.patch : Allow to specify whether you want to use 1024 based > kilobyte units (as is now default) or 1000 based > kilobyte when showing file sizes - settable in > mc.ini. > (i found it difficult to compare values like 695M > and 728000123 bytes, I don't know waht is more or > less without taking a calculator, so after applying > this patch, anyone can set one_kilobyte=1000 in > mc.ini and values like 695M will change to 728m or > so. Thousand based units are IMHO more > human-readable) I don't think we should accept any new options for which there is no user interface. There are too many of them already. How many people actually edit the configuration files manually? We probably need an additional dialog for advanced options. > sort_order.patch : change sort order by keyboard shortcuts, I > modified this patch for this mc version and > corrected one bug that was there > (indicator not repainting) Same thing. If the user interface is so hard to modify to add new options, then we should not ignore this problem. However, I like the idea of using shortcuts compatible with Norton Commander. > datefromat.patch : change datetime format, modified to apply to > current development version Again, options without interface to set them. Also, I don't think it's a good idea to override locale settings without serious reasons. -- Regards, Pavel Roskin From proski at gnu.org Fri Sep 26 22:28:45 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 26 Sep 2003 18:28:45 -0400 (EDT) Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> Message-ID: On Sat, 20 Sep 2003, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > On Fri, 19 Sep 2003, Fr?d?ric L. W. Meunier wrote: > > > On Fri, 19 Sep 2003, Pavel Roskin wrote: > > > > > If you believe in rumors that the new mc requires GNOME 2 and > > > XFree86 as some posters here implied, please adjust your > > > reality :-) > > The following makes me wonder if some distribution requires the > XFree86 libraries. > > 2002-12-23 Pavel Roskin > > * configure.in: Enable X11 support by default, use --without-x > to disable. [snip] > So, does 4.6.0 by default require it ? 2003-02-22 is after > the release. Let's not confuse requirements for compilation and requirements for running a precompiled executable. If you don't have X11, you compile without X11. If you have X11, it's used. If you compile with X11 and distribute the executable, then the resulting package depends on X11. The claim on http://mc.linuxinside.com/ that it's impossible to _compile_ mc without X11 is outright wrong. I guess the author of that text didn't know what glib doesn't depend on X11. In fact, it's glib that allowed us to remove the runtime dependency in the CVS version. > http://lists.suse.com/archive/suse-linux-e/2003-Jul/1031.html > > Well, it's up to the distribution maintainers. I don't know what SuSE > did. This is fixed in CVS by using gmodule. -- Regards, Pavel Roskin From proski at gnu.org Fri Sep 26 23:20:47 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 26 Sep 2003 19:20:47 -0400 (EDT) Subject: Patches for mc-4.5.51 In-Reply-To: <3F6C1AC5.1040503@kmlinux.fjfi.cvut.cz> References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> <3F6C1AC5.1040503@kmlinux.fjfi.cvut.cz> Message-ID: On Sat, 20 Sep 2003, Jindrich Makovicka wrote: > Fr?d?ric L. W. Meunier wrote: > > Anyway, if I was a programmer I'd contribute to HEAD, not fork > > and have my ideas used by a few people. > > Here is my favourite one, resume support for ftp (& others), I am using > it for about a year, and don't think anymore that this feature will ever > get into "official" mc :) I don't see any comments about this code. I don't understand the changes in vfs/local.c. Why do we seek the file only if it's in the linear mode? I think there are no limitations for seek on local files. I understand setting O_LINEAR by the caller of mc_open means certain limitations of what the caller can do. I don't think it has means that VFS may not seek the file. I would expect you to change to comment in vfs.h if you change the semantic of that flag. Oh, I see it now. You arranged the code so that offset will be 0 if O_LINEAR is not set. Looks like a trap for those who will work on this code after you. Also, there is a warning in vfs.c: vfs.c: In function `mc_open': vfs.c:388: warning: `mode' might be used uninitialized in this function As far as I can see, the warning is genuine. "mode" and "offset" are used in the same call. Can it be happen that the file you are going to reget disappears at this point, and VFS creates a world writable file? mc_open() is supposed to be a VFS equivalent of open(). I don't feel good about adding the fourth argument to it. What could you cay about following comment from vfs.h? * c) lseek() immediately after open(), giving ftpfs chance to * reget. Be warned that this lseek() can fail, and you _have_ * to handle that gratefully. If that doesn't work, let's create new function mc_open_linear() with 4 arguments and get rid of O_LINEAR. I'll appreciate comments from others who understand VFS. > I appreciate the efforts regarding the code cleanups, but maybe the mc > development should be a _bit_ more liberal. It's nice that the current > mc has a much cleaner codebase, but the things which pissed me off (ftp > resume, operations which sometimes have to be cancelled by ctrl-z kill > -9 mc - mainly Viewer and Find File) three years ago are still there and > there's no sign they'll go away anytime soon. The problem is, if the patch is not explained, there is a good chance that it's not worth looking at, at least not as the first priority. Often it turns out that those who don't comment their changes don't understand them. There may be great patches that get lost because there is no manpower to review them. That's too bad, but there is nothing to be done about it unless more people start reviewing code. It's not the same as testing in some obvious situations. A bad patch can withstand testing but make the code break later. Liberal development doesn't mean that patches that make the code more fragile are welcome. > And yes, I sent patches addressing these issues, with no reply. Maybe > they are crappy, because I don't know the mc code much, but at least > "your patch sucks because of this and that" would be appreciated. I agree. Everybody who understands the code is welcome to comment on patches. There is no way I can do it alone. -- Regards, Pavel Roskin From lists at pervalidus.tk Sun Sep 28 19:45:27 2003 From: lists at pervalidus.tk (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Sun, 28 Sep 2003 16:45:27 -0300 (BRT) Subject: [PATCH] edit.indent.rc (updated 3 URLs) Message-ID: Attached. -- How to contact me - http://www.pervalidus.net/contact.html -------------- next part -------------- --- edit.indent.rc.old 2003-06-09 16:52:48.000000000 -0300 +++ edit.indent.rc 2003-09-28 16:36:59.000000000 -0300 @@ -8,7 +8,7 @@ case `echo $1 |sed 's/^.*\.//'` in c|h) - # ftp://ftp.gnu.org/pub/gnu/indent/ + # ftp://ftp.gnu.org/gnu/indent/ # Please add options to your ~/.indent.pro, not here. indent "$2" ;; @@ -21,11 +21,11 @@ astyle --style=java --mode=java "$2" ;; htm|html|HTM|HTML) - # http://www.w3.org/People/Raggett/tidy/ + # http://tidy.sourceforge.net/ tidy -q -m -ascii -wrap 80 "$2" ;; *) - #ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.tar.gz + # ftp://ftp.gnu.org/gnu/coreutils/ fmt "$2" >"$2.tmp" && rm -f "$2" && mv -f "$2.tmp" "$2" ;; esac From proski at gnu.org Sun Sep 28 21:04:23 2003 From: proski at gnu.org (Pavel Roskin) Date: Sun, 28 Sep 2003 17:04:23 -0400 (EDT) Subject: [PATCH] edit.indent.rc (updated 3 URLs) In-Reply-To: References: Message-ID: On Sun, 28 Sep 2003, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > Attached. Thank you. I've applied it with little changes. -- Regards, Pavel Roskin From andrew at email.zp.ua Mon Sep 29 11:27:48 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 29 Sep 2003 14:27:48 +0300 (EEST) Subject: find.c cleanups Message-ID: <200309291127.h8TBRmXd004719@email.zp.ua> Hello, Pavel! -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: find.c.patch URL: From proski at gnu.org Mon Sep 29 15:59:43 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 29 Sep 2003 11:59:43 -0400 (EDT) Subject: find.c cleanups In-Reply-To: <200309291127.h8TBRmXd004719@email.zp.ua> References: <200309291127.h8TBRmXd004719@email.zp.ua> Message-ID: On Mon, 29 Sep 2003, Andrew V. Samoilov wrote: > Hello, Pavel! Applied. -- Regards, Pavel Roskin From egmont at uhulinux.hu Mon Sep 29 16:09:18 2003 From: egmont at uhulinux.hu (Koblinger Egmont) Date: Mon, 29 Sep 2003 18:09:18 +0200 (CEST) Subject: ^X^P sometimes doesn't put trailing slash (fwd) Message-ID: Hi, This mail, sent a month ago, somehow got forgotten. Please fix this bug... ---------- Forwarded message ---------- Date: Sat, 23 Aug 2003 23:57:08 +0200 (CEST) From: Koblinger Egmont To: mc-devel at gnome.org Subject: ^X^P sometimes doesn't put trailing slash Hi, ^X^P doesn't put a trailing slash under certain circumstances, e.g. if you're in /tmp/asdf/x while the other panel is /tmp/foo/x. The bug is in main.c copy_other_pathname(): command_insert (cmdline, opanel->cwd, 0); if (cpanel->cwd[strlen (opanel->cwd) - 1] != PATH_SEP) ^^^^^^ command_insert (cmdline, PATH_SEP_STR, 0); that one should be opanel, too. bye, Egmont _______________________________________________ Mc-devel mailing list Mc-devel at gnome.org http://mail.gnome.org/mailman/listinfo/mc-devel From tux at centrum.cz Mon Sep 29 16:35:58 2003 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 29 Sep 2003 18:35:58 +0200 Subject: [PATCH] 3 patches for MC-2003-09-15-04 Message-ID: <20030929163605Z104508-26952+685062@mail.centrum.cz> ... > I don't think we should accept any new options for which there is no user > interface. There are too many of them already. How many people actually > edit the configuration files manually? > > We probably need an additional dialog for advanced options. Yes, It will be useful, maybe add some dialog that will accept some structure which will be an array like: setting advanced_settings={ {"Time format - old",&timeformat,STRING}, {"Time format - recent",&timeformat_recent,STRING}, {"Torben FJ mode",&torben_fj_mode,BOOL}, {"Show Sort Mode indicator",&show_indicator,BOOL}, {"1 kilobyte is (1000/1024):",&one_kilobyte,INT), ... }; If anyone else won't do that, I might do it after things calm a bit down in school .... in a week or two (semester just started) Also, in future, it there would be too many options, this might allow for moving those options in tabs of some sort or whatever (multiple pages in advanced settings...) - just modify the dialog code and move the fields in two or more structures. Or make even the standard dialog this way .... And add the ":advanced settings" in Main menu -> settings The dialog may be a bit tougher (like scrolling the dialog if too many options are shown on small terminal window, etc...) but not impossible. Do you think this is a good idea? I don't want to code anything that won't have chance of being accepted into MC at end .... > > > sort_order.patch : change sort order by keyboard shortcuts, I > > modified this patch for this mc version and > > corrected one bug that was there > > (indicator not repainting) > > Same thing. If the user interface is so hard to modify to add new > options, then we should not ignore this problem. > > However, I like the idea of using shortcuts compatible with Norton > Commander. > > > datefromat.patch : change datetime format, modified to apply to > > current development version > > Again, options without interface to set them. Also, I don't think it's a > good idea to override locale settings without serious reasons. Well, this one does not modify locale, only the format in which MC displays things. The reason I made this patch is that I hate having different time format for old (6+ monts cca) and new files, so having two different formats in one column is quite disorienting IMHO. Martin Petricek From proski at gnu.org Mon Sep 29 16:39:49 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 29 Sep 2003 12:39:49 -0400 (EDT) Subject: ^X^P sometimes doesn't put trailing slash (fwd) In-Reply-To: References: Message-ID: On Mon, 29 Sep 2003, Koblinger Egmont wrote: > Hi, > > This mail, sent a month ago, somehow got forgotten. > Please fix this bug... Applied, thank you! -- Regards, Pavel Roskin From makovick at kmlinux.fjfi.cvut.cz Mon Sep 29 16:39:55 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Mon, 29 Sep 2003 18:39:55 +0200 Subject: Patches for mc-4.5.51 In-Reply-To: References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> <3F6C1AC5.1040503@kmlinux.fjfi.cvut.cz> Message-ID: <3F78605B.3070705@kmlinux.fjfi.cvut.cz> Pavel Roskin wrote: > On Sat, 20 Sep 2003, Jindrich Makovicka wrote: > > >>Fr?d?ric L. W. Meunier wrote: >> >>>Anyway, if I was a programmer I'd contribute to HEAD, not fork >>>and have my ideas used by a few people. >> >>Here is my favourite one, resume support for ftp (& others), I am using >>it for about a year, and don't think anymore that this feature will ever >>get into "official" mc :) > > > I don't see any comments about this code. I don't understand the changes > in vfs/local.c. Why do we seek the file only if it's in the linear mode? Just to make sure the patch won't break the functionality of mc and to make the vfs open functions behave the same way as direntry.c:vfs_s_open. > I think there are no limitations for seek on local files. I understand > setting O_LINEAR by the caller of mc_open means certain limitations of > what the caller can do. I don't think it has means that VFS may not seek > the file. I would expect you to change to comment in vfs.h if you change > the semantic of that flag. > > Oh, I see it now. You arranged the code so that offset will be 0 if > O_LINEAR is not set. Looks like a trap for those who will work on this > code after you. I don't understand. It doesn't change any semantics, except that with O_LINEAR, an argument for offset is read. That's all. > > Also, there is a warning in vfs.c: > > vfs.c: In function `mc_open': > vfs.c:388: warning: `mode' might be used uninitialized in this function > > As far as I can see, the warning is genuine. "mode" and "offset" are used > in the same call. Can it be happen that the file you are going to reget > disappears at this point, and VFS creates a world writable file? Yes, they are, but only with O_CREAT. The if condition can be eventually left out, if you don't like it, but you'll have to supply a dummy mode argument when opening an existing file with O_LINEAR. > mc_open() is supposed to be a VFS equivalent of open(). I don't feel good > about adding the fourth argument to it. > > What could you cay about following comment from vfs.h? > > * c) lseek() immediately after open(), giving ftpfs chance to > * reget. Be warned that this lseek() can fail, and you _have_ > * to handle that gratefully. > > If that doesn't work, let's create new function mc_open_linear() with 4 > arguments and get rid of O_LINEAR. Sounds easier. moreover, most of the functionality is already implemented in vfs_s_open, there's just no way to pass the offset argument. Actually, I just changed the remaining vfs open functions to match vfs_s_open. > Liberal development doesn't mean that patches that make the code more > fragile are welcome. Once more: This patch shouldn't change any mc_open semantics, except when using O_LINEAR, which is used only in one place. Regards, -- Jindrich Makovicka From makovick at kmlinux.fjfi.cvut.cz Tue Sep 30 06:48:40 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Tue, 30 Sep 2003 08:48:40 +0200 Subject: Patches for mc-4.5.51 In-Reply-To: <3F78605B.3070705@kmlinux.fjfi.cvut.cz> References: <200309190227.h8J2Rfo09460@miyu.feyrer.net> <3F6C1AC5.1040503@kmlinux.fjfi.cvut.cz> <3F78605B.3070705@kmlinux.fjfi.cvut.cz> Message-ID: <3F792748.7010901@kmlinux.fjfi.cvut.cz> Jindrich Makovicka wrote: > to make the vfs open functions behave the same way as direntry.c:vfs_s_open. Sorry, this one was complete bullshit, I should have reviewed the patch twice, didn't realize I modified vfs_s_open too. But the main reason to do the seek only for O_LINEAR was that I wanted to affect only this one case, and making sure that mc_open will behave the same way as before when O_LINEAR is not used. -- Jindrich Makovicka