From roland.illig at gmx.de Wed Mar 2 18:40:19 2005 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 02 Mar 2005 19:40:19 +0100 Subject: Big patch for mcview Message-ID: <42260893.9020300@gmx.de> Hi all, I must have had too much time, as I have partly rewritten mcview. The patch is quite large and changes many things. However, I have tested it with all available types of data sources (see the code for explanation), and it seems to work. http://www.roland-illig.de/tmp/viewer.patch Here are the major improvements: * Dropped mmap support. * Don't load large files completely into memory. * Grouped all variables that have to do with the data source management. * Made every variable have only one purpose. (Before, you could never be sure what the view->data field contained, as it was used for keeping the error message as well as the mmapped file and the data of the non-mmapped file.) * Provided a clean interface for the get_byte() function, as well as four different implementations of it. * Added assertions to guarantee that the code is only used in situations where it is meant to be used. * First steps to supporting 64-bit files. (Mainly through consistent use of the appropriate data types.) Perhaps you may worry about the fact that my patch makes the file 119 lines longer, but I hope the code becomes more readable and maintainable. Of course, there are many things that don't work yet or that can be improved. I will work on them, perhaps by first marking the relevant places with FIXMEs. Things that don't work nicely at the moment are: * Initialization of a WView object. (I'd like to have a function that initializes _every_ field to a sensible default value; "constructor".) * Destruction of a WView object. (The counterpart to the constructor. Cleans up the object and frees it.) * Cursor movement in all display modes (textview, textwrap, hexview, hexedit, rawmode, nroffmode, ...) should be rewritten in cleaner code. * Support for 64-bit files still needs much work. Roland From dmi_a at qnx.org.ru Thu Mar 3 16:48:15 2005 From: dmi_a at qnx.org.ru (Dmitry Alexeyev) Date: Thu, 3 Mar 2005 19:48:15 +0300 Subject: Big patch for mcview In-Reply-To: <42260893.9020300@gmx.de> References: <42260893.9020300@gmx.de> Message-ID: <200503031948.15646.dmi_a@qnx.org.ru> On Wednesday 02 March 2005 21:40, Roland Illig wrote: > Hi all, > > I must have had too much time, as I have partly rewritten mcview. The > patch is quite large and changes many things. However, I have tested > it with all available types of data sources (see the code for > explanation), and it seems to work. > Gives "Broken pipe" warning when closing tarball WBR Dmitry From zscherni at rz.uni-potsdam.de Fri Mar 4 10:05:41 2005 From: zscherni at rz.uni-potsdam.de (zscherni at rz.uni-potsdam.de) Date: Fri, 4 Mar 2005 11:05:41 +0100 (CET) Subject: request concerning confirmations (and selecting) Message-ID: Imho one thing in mc is a little bit dangerous: If there is (are) (a) selected file(s) somewhere in the filelist in the activ mc-window (e.g. marked before pressing the insert-key while the cursor-bar stood on that file) and the cursor-bar stands on another file now and one presses F8 and one doesn't read exactly the confirmation-message asking if one really wants to delete that (these) (the earlier selected) file(s) and one clicks ok, so the earlier selected file(s) is (are) lost and not the file selected in that moment, which one could have expected... That's why i would like another message in that case which warns, that there are other files selected than the one on which the cursor-bar stands in that moment... Sebastian PS: To manage files and directories sometimes (but because of the mentioned problem not always...) using GNU Midnight Commander 4.6.0 [ perhaps see also http://mail.gnome.org/archives/mc/2004-April/msg00010.html http://mail.gnome.org/archives/mc/2004-April/msg00011.html http://mail.gnome.org/archives/mc/2004-April/msg00017.html ] From leonard at den.ottolander.nl Fri Mar 4 15:52:33 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 04 Mar 2005 16:52:33 +0100 Subject: request concerning confirmations (and selecting) In-Reply-To: References: Message-ID: <1109951552.4807.13.camel@athlon.localdomain> Hello Sebastian, On Fri, 2005-03-04 at 11:05, zscherni at rz.uni-potsdam.de wrote: > Imho one thing in mc is a little bit dangerous: > one doesn't read exactly the > confirmation-message asking if one really wants to delete that (these) This is really a usage issue. I don't think a different message will make much difference here. If the user doesn't read one message why could we expect him to do read another message? If you select files by pressing "insert" the current file will never be the selected one. The user should know this. If you have only 1 file selected the message clearly states the name of the file mc is about to delete. How could the message be clearer? And if you are deleting more than one file the message also makes that clear, so it should be obvious you are not deleting the current (single) file under the "cursor". Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Mon Mar 7 13:01:08 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 7 Mar 2005 15:01:08 +0200 Subject: Big patch for mcview In-Reply-To: <42260893.9020300@gmx.de> References: <42260893.9020300@gmx.de> Message-ID: Hello, On Wed, 2 Mar 2005, Roland Illig wrote: > Hi all, > > I must have had too much time, as I have partly rewritten mcview. The > patch is quite large and changes many things. However, I have tested it > with all available types of data sources (see the code for explanation), > and it seems to work. > > http://www.roland-illig.de/tmp/viewer.patch First of all - this patch could have been much smaller and thus easier to review/understand. 25 % (line 666 to the end) of the patch are hunks which do the following: get_byte => view->get_byte Well, simply keeping get_byte () and calling view->get_byte from within would have been much nicer. Also you could have made our lives easier if you have moved most of the "new" functions that you have introduced to the end of the file - this way it would be much easier to read the patch. > Here are the major improvements: > > * Dropped mmap support. Ok. > * Don't load large files completely into memory. Nice. > * Grouped all variables that have to do with the data source management. Good - also you've doubled the number of variables (7 vs 12). Not that it matters so much but I'd expect something much cleaner to represent the so called data source. In my imagination it is something like a struct with common methods exported much like, say, the vfs. Then you have several datasource objects and a pointer in the WView being set to point the one that is currently necessary. > * Made every variable have only one purpose. (Before, you could never be > sure what the view->data field contained, as it was used for keeping > the error message as well as the mmapped file and the data of the > non-mmapped file.) Good but see above. Also, I always have to think what was the difference between `ds_file_size' and `ds_file_datasize'. > * Provided a clean interface for the get_byte() function, as well as > four different implementations of it. It makes sense in the light of what you're trying to accomplish. One note though: view_set_datasource_none () view_set_datasource_string () view_set_datasource_file () init_growing_view () It was not so easy for me to derive the name of the function initializing the view to work with pipes. > Perhaps you may worry about the fact that my patch makes the file 119 > lines longer, but I hope the code becomes more readable and maintainable. Personally, I don't worry so much about the number of lines in the file. I think in the past you were the one complaining that view.c was too large. My major concern is that this code although announced as something quite new consists mainly of cosmetic changes (IMHO). I'd like others to comment too though. From roland.illig at gmx.de Tue Mar 8 19:54:32 2005 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 08 Mar 2005 20:54:32 +0100 Subject: Big patch for mcview In-Reply-To: References: <42260893.9020300@gmx.de> Message-ID: <422E02F8.9040308@gmx.de> Pavel Tsekov wrote: > First of all - this patch could have been much smaller and thus easier to > review/understand. 25 % (line 666 to the end) of the patch are hunks which > do the following: > > get_byte => view->get_byte > > Well, simply keeping get_byte () and calling view->get_byte from within > would have been much nicer. Also you could have made our lives easier if > you have moved most of the "new" functions that you have introduced to > the end of the file - this way it would be much easier to read the patch. Sorry for these. I had uploaded an old version of the patch. An improved patch is available: http://www.roland-illig.de/tmp/viewer-try2.patch >>* Grouped all variables that have to do with the data source management. > > Good - also you've doubled the number of variables (7 vs 12). Not that it > matters so much but I'd expect something much cleaner to represent the so > called data source. In my imagination it is something like a struct with > common methods exported much like, say, the vfs. Then you have several > datasource objects and a pointer in the WView being set to point the one > that is currently necessary. That would have made the source code even larger. I could invent a union viewer_datasource for this. I already explained the increase in the number of variables because there's no double-triple-use of them, like it was before. See below. Also, this is not the final patch for mcview. It's just something that makes it more understandable---in my opinion and at least to me. >>* Made every variable have only one purpose. (Before, you could never be >> sure what the view->data field contained, as it was used for keeping >> the error message as well as the mmapped file and the data of the >> non-mmapped file.) > > Good but see above. Also, I always have to think what was the difference > between `ds_file_size' and `ds_file_datasize'. Would it help to name them ds_file_filesize and ds_file_datasize? Or do you want even other names? >>* Provided a clean interface for the get_byte() function, as well as >> four different implementations of it. > > > It makes sense in the light of what you're trying to accomplish. One note > though: > > view_set_datasource_none () > view_set_datasource_string () > view_set_datasource_file () > init_growing_view () > > It was not so easy for me to derive the name of the function initializing > the view to work with pipes. The init_growing_view is the legacy interface to WView. I'm planning to remove it soon. But the patch had been big enough for now. :) >>Perhaps you may worry about the fact that my patch makes the file 119 >>lines longer, but I hope the code becomes more readable and maintainable. > > Personally, I don't worry so much about the number of lines in the file. I > think in the past you were the one complaining that view.c was too large. > My major concern is that this code although announced as something quite > new consists mainly of cosmetic changes (IMHO). I'd like others to comment > too though. These "cosmetic changes" do not add much functionality, but they bring in some common structure to all datasources, which helps to understand the concept of the datasource (interface, and implementation). That's all I want. It also makes it easier to re-add the mmap datasource, if we should ever need to do so. Roland From roland.illig at gmx.de Tue Mar 8 20:26:20 2005 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 08 Mar 2005 21:26:20 +0100 Subject: request concerning confirmations (and selecting) In-Reply-To: References: Message-ID: <422E0A6C.7060900@gmx.de> zscherni at rz.uni-potsdam.de wrote: > Imho one thing in mc is a little bit dangerous: > > If there is (are) (a) selected file(s) somewhere in the filelist in the > activ mc-window (e.g. marked before pressing the insert-key while the > cursor-bar stood on that file) and the cursor-bar stands on another > file now and one presses F8 and one doesn't read exactly the > confirmation-message asking if one really wants to delete that (these) > (the earlier selected) file(s) and one clicks ok, so the earlier > selected file(s) is (are) lost and not the file selected in that > moment, which one could have expected... > > That's why i would like another message in that case which warns, that > there are other files selected than the one on which the cursor-bar > stands in that moment... What about changing the default button to [No] in that case? Would that help or are you using the mouse for deletion? Roland From zscherni at rz.uni-potsdam.de Wed Mar 9 12:54:57 2005 From: zscherni at rz.uni-potsdam.de (Sebastian Zschernig) Date: Wed, 9 Mar 2005 13:54:57 +0100 (CET) Subject: request concerning confirmations (and selecting) In-Reply-To: <422E0A6C.7060900@gmx.de> References: <422E0A6C.7060900@gmx.de> Message-ID: Hello. On Tue, 8 Mar 2005, Roland Illig wrote: > zscherni at rz.uni-potsdam.de wrote: > > Imho one thing in mc is a little bit dangerous: > > > > If there is (are) (a) selected file(s) somewhere in the filelist in the > > activ mc-window (e.g. marked before pressing the insert-key while the > > cursor-bar stood on that file) and the cursor-bar stands on another > > file now and one presses F8 and one doesn't read exactly the > > confirmation-message asking if one really wants to delete that (these) > > (the earlier selected) file(s) and one clicks ok, so the earlier > > selected file(s) is (are) lost and not the file selected in that > > moment, which one could have expected... > > > > That's why i would like another message in that case which warns, that > > there are other files selected than the one on which the cursor-bar > > stands in that moment... > > What about changing the default button to [No] in that case? Would that > help or are you using the mouse for deletion? (I usually don't use the mouse.) What means "in that case"? Really only in the case discribed above (the case that the cursor bar stands on a file which isn't selected but another file is selected so that this other file would be deleted and not the one on which the cursor bar stands)? Then I think it would help. (But another (warning about the fact of divergence of selecting) message in addition to the exceptionally preset [No] button would be great too.) regards Sebastian > > Roland > From roland.illig at gmx.de Thu Mar 10 19:02:13 2005 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 10 Mar 2005 20:02:13 +0100 Subject: Support for extended character sets Message-ID: <423099B5.9060702@gmx.de> Hi all, I have written some code to unify single-byte character sets and extended character sets. With this code, it should be easier to enable extended character set support not only for UTF-8, but also for any other character set. Especially, this code tries to reduce the amount of #ifdef's that is needed to support both kinds of character sets. It only makes use of features that appeared in the ANSI C89 standard library, so it should work nearly everywhere. This is my first try, so don't expect it to be perfect. Another big question is how to interpret filenames. Consider a setup where the root filesystem is encoded in iso8859-1, but there's a Samba filesystem mounted somewhere with utf-8 encoding. I would like mc to be able to handle this, but I know it will take some time and many thoughts to properly implement it. Roland -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mc-ecs.patch URL: From leonard at den.ottolander.nl Sun Mar 13 10:51:52 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 13 Mar 2005 11:51:52 +0100 Subject: [PATCH] Patch comment readability Message-ID: <1110711112.4826.38.camel@athlon.localdomain> Hi, The comments at the top of a patch are rather unreadable in the current gray. Yellow seems a more appropriate colour. Or just anything a little brighter. --- diff.syntax.000 2004-11-10 16:17:27.000000000 +0100 +++ diff.syntax 2005-03-13 11:46:01.000000000 +0100 @@ -1,6 +1,6 @@ # Highlighting for various diffs including those generated by CVS # Comments to Pavel Roskin -context default gray +context default yellow keyword linestart @@*@@ cyan keyword linestart Index:\s brown keyword linestart \s black white Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Mon Mar 14 00:16:15 2005 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 14 Mar 2005 01:16:15 +0100 Subject: [PATCH] Patch comment readability In-Reply-To: <1110711112.4826.38.camel@athlon.localdomain> References: <1110711112.4826.38.camel@athlon.localdomain> Message-ID: <4234D7CF.1020306@gmx.de> Leonard den Ottolander wrote: > Hi, > > The comments at the top of a patch are rather unreadable in the current > gray. Yellow seems a more appropriate colour. Or just anything a little > brighter. > > --- diff.syntax.000 2004-11-10 16:17:27.000000000 +0100 > +++ diff.syntax 2005-03-13 11:46:01.000000000 +0100 > @@ -1,6 +1,6 @@ > # Highlighting for various diffs including those generated by CVS > # Comments to Pavel Roskin > -context default gray > +context default yellow > keyword linestart @@*@@ cyan > keyword linestart Index:\s brown > keyword linestart \s black white That's great. Committed. Roland From ptsekov at gmx.net Wed Mar 9 11:42:15 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 9 Mar 2005 13:42:15 +0200 Subject: [PING] Re: Complete: Show All In-Reply-To: References: <20050126081040.GG1995@disclosure.fdns.net> Message-ID: Hello, On Fri, 18 Feb 2005, Pavel Tsekov wrote: > Hello, > > On Wed, 26 Jan 2005, Thomas Zajic wrote: > > > Hi, > > > > I just stumbled across another long-standing bug in mc again. > > > > With "Complete: Show All" enabled in F9->Options->Configuration, mc does > > not autocomplete paths or filenames when there's only one alternative. > > > > Eg. given a directory structure like "x/y/z" (with "y" being the only dir > > entry in "x", and "z" being the only dir entry in "y"), having "x" in one > > panel and some other directory in the other panel, mc stops autocompletion > > in "y" (or even "x", if "x" is the only file/directory in that panel) when > > trying to copy/move a file to "z". > > > > This works fine with "Complete: Show All" disabled. > > Attached is a patch which solves the issue. Please, test. Does anybody care to take a look at this ? At least the original reporter could provide some feedback. It seems the list is pretty dead again :( From zlatko at gmx.at Wed Mar 16 07:44:16 2005 From: zlatko at gmx.at (Thomas Zajic) Date: Wed, 16 Mar 2005 08:44:16 +0100 Subject: [PING] Re: Complete: Show All In-Reply-To: References: <20050126081040.GG1995@disclosure.fdns.net> Message-ID: <20050316074416.GF3408@disclosure.fdns.net> * Pavel Tsekov , 09/03/2005, 13:42 > > On Wed, 26 Jan 2005, Thomas Zajic wrote: > > > > > I just stumbled across another long-standing bug in mc again. > > > > > > With "Complete: Show All" enabled in F9->Options->Configuration, mc > > > does not autocomplete paths or filenames when there's only one > > > alternative. [...] > > > > Attached is a patch which solves the issue. Please, test. > > Does anybody care to take a look at this ? At least the original reporter > could provide some feedback. It seems the list is pretty dead again :( Sorry, I seem to have missed/lost the original mail with the patch somehow - I'll fetch it from the list archive and try to report back here as soon as possible. Thomas -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.29 & Mutt-1.4.2.1i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= From zlatko at gmx.at Wed Mar 16 08:25:23 2005 From: zlatko at gmx.at (Thomas Zajic) Date: Wed, 16 Mar 2005 09:25:23 +0100 Subject: [PING] Re: Complete: Show All In-Reply-To: <20050316074416.GF3408@disclosure.fdns.net> References: <20050126081040.GG1995@disclosure.fdns.net> <20050316074416.GF3408@disclosure.fdns.net> Message-ID: <20050316082523.GG3408@disclosure.fdns.net> * Thomas Zajic , 16/03/2005, 08:44 > Sorry, I seem to have missed/lost the original mail with the patch > somehow - I'll fetch it from the list archive and try to report back > here as soon as possible. Seems to work fine here - I applied the patch against the semi-official 4.6.1-pre3 tarball that's been posted here a while ago. Thanks! :-) Thomas -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.29 & Mutt-1.4.2.1i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= From siver at sirius.ihep.su Wed Mar 16 10:26:56 2005 From: siver at sirius.ihep.su (Siver Andrey) Date: Wed, 16 Mar 2005 13:26:56 +0300 Subject: Fw: [patch] Synchronization of the panels (fwd) Message-ID: <040b01c52a12$ae2f71d0$f3a1bec2@hermes> Sorry, I e-mailed a message not to the main list: ----- Original Message ----- From: "Siver Andrey" To: "Miguel de Icaza" Sent: Sunday, February 27, 2005 3:33 PM Subject: Re: [patch] Synchronization of the panels (fwd) > Hi All, > > ----- Original Message ----- > From: "Miguel de Icaza" > To: "Pavel Tsekov" > Cc: "MC dev" > Sent: Saturday, February 26, 2005 7:40 PM > Subject: Re: [patch] Synchronization of the panels (fwd) > > > > Hello, > > > > The patch still needs a lot of work, for example, why do we have an > > include file at all with the code? (The core of the code lives in > > sync.inc). > > It's not a problem if it's the last problem (it's easy to embed sync.inc > straight into main.c). > > > Configure patches, fall back patches are missing as well. > > I would like to ask somebody to update configure scripts (WITH_SYNC need to > be defined if kernel version >= 2.4. If it's not defined - the patch gives > nothing new, so I do not understand what do you mean by "fall back > patches"). > > Is anybody ready to do it? > > > > > Miguel. > > _______________________________________________ > > Mc-devel mailing list > > http://mail.gnome.org/mailman/listinfo/mc-devel > > > > ----- Original Message ----- > From: "Miguel de Icaza" > To: "Oswald Buddenhagen" ; "Siver Andrey" > > Cc: > Sent: Saturday, February 26, 2005 7:38 PM > Subject: Re: [patch] Synchronization of the panels > > > > Hello, > > > > It could be argued that if mc is watching a directory, mc is in that > > directory so unmounting should not be an issue at this point, > > >but > > adopting something like inotify in the long run seems like a better > > option. > > What do you mean ("the long run" ?) ? > > > The other problem with the patch is that it lacks the configure magic to > > work on non-dnotify systems, and also lacks support for not aborting if > > the code is not available in the current kernel. > > I added error processing for 'fcntl' function: if it returns error signal - > nothing bad will happen (as I guess). > > > > > The patch is a nice one, but it needs to be productized. > > > > > Best regards, > > Andrey > From roland.illig at gmx.de Wed Mar 16 10:37:04 2005 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 16 Mar 2005 11:37:04 +0100 Subject: AFK from Mar 17 until Mar 31 Message-ID: <42380C50.1000502@gmx.de> I'll be away for these two weeks plusminus some days. Roland From ptsekov at gmx.net Wed Mar 9 15:48:06 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 9 Mar 2005 17:48:06 +0200 Subject: Fw: [patch] Synchronization of the panels (fwd) In-Reply-To: <040b01c52a12$ae2f71d0$f3a1bec2@hermes> References: <040b01c52a12$ae2f71d0$f3a1bec2@hermes> Message-ID: Hello Andrey, On Wed, 16 Mar 2005, Siver Andrey wrote: > > ----- Original Message ----- > > From: "Miguel de Icaza" > > To: "Pavel Tsekov" > > Cc: "MC dev" > > Sent: Saturday, February 26, 2005 7:40 PM > > Subject: Re: [patch] Synchronization of the panels (fwd) > > > > > > > Hello, > > > > > > The patch still needs a lot of work, for example, why do we have an > > > include file at all with the code? (The core of the code lives in > > > sync.inc). > > > > It's not a problem if it's the last problem (it's easy to embed sync.inc > > straight into main.c). Well, it is even easier to create a new set of files (.h and .c) devoted to this new feature and then patch the Makefile.am files to include the new module in the build. > > > Configure patches, fall back patches are missing as well. > > > > I would like to ask somebody to update configure scripts (WITH_SYNC need > to > > be defined if kernel version >= 2.4. If it's not defined - the patch gives > > nothing new, so I do not understand what do you mean by "fall back > > patches"). > > > > Is anybody ready to do it? It must be you . You can get some help/advice in the process of reviewing your patch - but do not expect others to do your job. From lestat at i.com.ua Wed Mar 16 05:45:45 2005 From: lestat at i.com.ua (Mike V. Gorchak) Date: Wed, 16 Mar 2005 07:45:45 +0200 Subject: New syntax highlight files, please add it to the distro Message-ID: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua> Hello all ! I've did x86 assembler syntax file for highlighting (I can't believe that I'm first who did it :-| ) and POVRay syntax highlight. Both syntax files are complete near 80%, because assembler keywords different in the each product (WASM, MASM, TASM, GAS, NASM, etc) and I have tryied to add as much as possible keywords, which I know and NASM and TASM manuals provided. As for POVRay syntax - they adding new keywords with each version, so maybe it is outdated a bit. But I will add patches to these syntax files later, when I've find a missing keywords. Need to add the following to the Syntax file too: file ..\*\\.(asm|ASM|Asm|s|S)$ ASM\sProgram include assembler.syntax file ..\*\\.(pov|POV|Pov)$ POV\sScript include povray.syntax Have a nice day ! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: povray.syntax Type: application/octet-stream Size: 8548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: assembler.syntax Type: application/octet-stream Size: 9922 bytes Desc: not available URL: From ossi at kde.org Wed Mar 16 16:10:10 2005 From: ossi at kde.org (Oswald Buddenhagen) Date: Wed, 16 Mar 2005 17:10:10 +0100 Subject: New syntax highlight files, please add it to the distro In-Reply-To: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua> References: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua> Message-ID: <20050316161010.GA8807@ugly.local> On Wed, Mar 16, 2005 at 07:45:45AM +0200, Mike V. Gorchak wrote: > because assembler keywords different in the each product (WASM, MASM, > TASM, GAS, NASM, etc) and I have tryied to add as much as possible > keywords, > i'm strictly against putting all the asm syntaxes in one file. it is annoying enough for c vs. c++; for asm (with completely different syntax of gas compared to the rest) it would be a nightmare. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From lestat at i.com.ua Thu Mar 17 05:29:27 2005 From: lestat at i.com.ua (Mike V. Gorchak) Date: Thu, 17 Mar 2005 07:29:27 +0200 Subject: New syntax highlight files, please add it to the distro References: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua> <20050316161010.GA8807@ugly.local> Message-ID: <027301c52ab2$4b082f20$0d00200a@zero.priv.malva.com.ua> Hello, Oswald! OB> On Wed, Mar 16, 2005 at 07:45:45AM +0200, Mike V. Gorchak wrote: ??>> because assembler keywords different in the each product (WASM, MASM, ??>> TASM, GAS, NASM, etc) and I have tryied to add as much as possible ??>> keywords, OB> i'm strictly against putting all the asm syntaxes in one file. it is OB> annoying enough for c vs. c++; for asm (with completely different OB> syntax of gas compared to the rest) it would be a nightmare. Did you tried it ? It's works fine for me with GAS, NASM and TASM. And anyway it's much better than the plain gray text without any highlight anyway. And how you planning to split NASM sources with GAS for example, both can contain .s and .asm extension. With best regards, Mike V. Gorchak. E-mail: lestat at i.com.ua From ossi at kde.org Thu Mar 17 06:05:22 2005 From: ossi at kde.org (Oswald Buddenhagen) Date: Thu, 17 Mar 2005 07:05:22 +0100 Subject: New syntax highlight files, please add it to the distro In-Reply-To: <027301c52ab2$4b082f20$0d00200a@zero.priv.malva.com.ua> References: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua> <20050316161010.GA8807@ugly.local> <027301c52ab2$4b082f20$0d00200a@zero.priv.malva.com.ua> Message-ID: <20050317060521.GA1622@ugly.local> On Thu, Mar 17, 2005 at 07:29:27AM +0200, Mike V. Gorchak wrote: > It's works fine for me with GAS, NASM and TASM. > oh, sure it "works". with my variable ah in gas being highlighted, etc. just as useful as "new" and "class", etc. all over my c sources. > And how you planning to split NASM sources with GAS for example, both > can contain .s and .asm extension. > that's indeed a problem - the same as with c vs. c++ header files. see my last post on this topic some days ago. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From lestat at i.com.ua Thu Mar 17 06:23:17 2005 From: lestat at i.com.ua (Mike V. Gorchak) Date: Thu, 17 Mar 2005 08:23:17 +0200 Subject: New syntax highlight files, please add it to the distro References: <01ce01c529eb$66bbbc40$0d00200a@zero.priv.malva.com.ua><20050316161010.GA8807@ugly.local><027301c52ab2$4b082f20$0d00200a@zero.priv.malva.com.ua> <20050317060521.GA1622@ugly.local> Message-ID: <027e01c52ab9$cf8121b0$0d00200a@zero.priv.malva.com.ua> Hello, Oswald! OB> oh, sure it "works". with my variable ah in gas being highlighted, etc. OB> just as useful as "new" and "class", etc. all over my c sources. That's bad style :) Write hundred times "Do not name variables as registers names". The same as in linux 2.4.x kernels was numerous variables 'new', 'list', etc which has been highlighted, but ... these headers failed to be compiled when was included in the c++ application, because of reserved names. So it's another side of bad style. With best regards, Mike V. Gorchak. E-mail: lestat at i.com.ua From leonard at den.ottolander.nl Thu Mar 17 11:13:53 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 17 Mar 2005 12:13:53 +0100 Subject: [PATCH] php syntax single quote fix Message-ID: <1111058033.4822.1.camel@athlon.localdomain> Hi, A small fix for single quoted strings that contain escaped single quotes themselves. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: php.singlequote_fix.patch Type: text/x-patch Size: 488 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Mar 17 11:18:14 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 17 Mar 2005 12:18:14 +0100 Subject: [PATCH] php syntax single quote fix In-Reply-To: <1111058033.4822.1.camel@athlon.localdomain> References: <1111058033.4822.1.camel@athlon.localdomain> Message-ID: <1111058293.4822.6.camel@athlon.localdomain> Hi, + keyword \\\' brightgreen Can read + keyword \\' brightgreen instead. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Mar 17 11:25:42 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 17 Mar 2005 12:25:42 +0100 Subject: [PATCH] php syntax single quote fix In-Reply-To: <1111058293.4822.6.camel@athlon.localdomain> References: <1111058033.4822.1.camel@athlon.localdomain> <1111058293.4822.6.camel@athlon.localdomain> Message-ID: <1111058741.4822.8.camel@athlon.localdomain> Hi, Please ignore this patch. I'll have to come up with a better version as I now see issues with the double quotes containing a single quote. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Mar 17 11:57:04 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 17 Mar 2005 12:57:04 +0100 Subject: [PATCH] php syntax single quote fix In-Reply-To: <1111058033.4822.1.camel@athlon.localdomain> References: <1111058033.4822.1.camel@athlon.localdomain> Message-ID: <1111060624.4822.12.camel@athlon.localdomain> Hi, Adding a keyword " for context ' ' causes a context change for '"', but not for ' "' nor '" '. Should that be considered a bug? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From siver at sirius.ihep.su Thu Mar 17 14:56:49 2005 From: siver at sirius.ihep.su (Siver Andrey) Date: Thu, 17 Mar 2005 17:56:49 +0300 Subject: Fw: [patch] Synchronization of the panels (fwd) References: <040b01c52a12$ae2f71d0$f3a1bec2@hermes> Message-ID: <004001c52b01$8c635950$f3a1bec2@hermes> Hello Pavel, ----- Original Message ----- From: "Pavel Tsekov" To: "Siver Andrey" Cc: Sent: Wednesday, March 09, 2005 6:48 PM Subject: Re: Fw: [patch] Synchronization of the panels (fwd) > Hello Andrey, > > On Wed, 16 Mar 2005, Siver Andrey wrote: > > > > ----- Original Message ----- > > > From: "Miguel de Icaza" > > > To: "Pavel Tsekov" > > > Cc: "MC dev" > > > Sent: Saturday, February 26, 2005 7:40 PM > > > Subject: Re: [patch] Synchronization of the panels (fwd) > > > > > > > Hello, > > > > > > > > Configure patches, fall back patches are missing as well. > > > > > > I would like to ask somebody to update configure scripts (WITH_SYNC need > > to > > > be defined if kernel version >= 2.4. If it's not defined - the patch gives > > > nothing new, so I do not understand what do you mean by "fall back > > > patches"). > > > > > > Is anybody ready to do it? > It must be you . You can get some help/advice in the process of reviewing > your patch - but do not expect others to do your job. Do you know how to detect kernel version >= 2.4 at configure time and how to add corresponding parameter to gcc? Andrey From proski at gnu.org Thu Mar 17 22:45:03 2005 From: proski at gnu.org (Pavel Roskin) Date: Thu, 17 Mar 2005 17:45:03 -0500 Subject: Fixes committed Message-ID: <1111099503.30842.4.camel@dv> Hello! I have committed following fixed to HEAD: Shift-F4 was broken in the editor (blame: Roland Illig) Advanced Chown was broken (blame: Roland Illig) Alt-O would change current directory without updating the current panel (blame: Miguel de Icaza) I'm sorry, I'm still buried in unanswered e-mails, and I don't know when I'll be able to reply to all of them. -- Regards, Pavel Roskin From ptsekov at gmx.net Fri Mar 11 13:34:43 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 11 Mar 2005 15:34:43 +0200 Subject: Fixes committed In-Reply-To: <1111099503.30842.4.camel@dv> References: <1111099503.30842.4.camel@dv> Message-ID: Hello Pavel, On Thu, 17 Mar 2005, Pavel Roskin wrote: > Hello! > > I have committed following fixed to HEAD: > > Shift-F4 was broken in the editor (blame: Roland Illig) > Advanced Chown was broken (blame: Roland Illig) > Alt-O would change current directory without updating the current panel > (blame: Miguel de Icaza) > > I'm sorry, I'm still buried in unanswered e-mails, and I don't know when > I'll be able to reply to all of them. Good to hear from you! Do you plan to work on MC again ? From plamen at bluetone.cz Fri Mar 18 15:15:11 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Fri, 18 Mar 2005 16:15:11 +0100 Subject: Xterm window title enhancement to hostname:/path Message-ID: <20050318161511.7694936f.plamen@bluetone.cz> Hi developers, I've found a feature in last version of mc. It is really nice to change xterm window title to current path. One can check Window List in its Window Manager and find the right window there. It is really nice. But it is not enough if one is logged on another machines via ssh. Then Window list can look like: mc - /etc mc - /etc mc - /etc mc - /usr/src Well, but what is the right window what I am looking for? I want to switch to configuration window of my firewall. I need a bit different list: mc - debi:/etc mc - Firewall:/etc mc - Planet:/etc mc - workstation:/usr/src or better (not coded now) mc - root at debi:/etc mc - root at Firewall:/etc mc - root at Planet:/etc mc - plamen at workstation:/usr/src This patch adds hostname to current path in x-terminal window with minimal source code changes into existing code. It works for me and I hope it will be useful for many network administrators too. I hope this patch is safe. It is restricted to hostnames up to 63 bytes long. Please include it into upstream if you'll find it useful. It is possible that during some days I'll add username to make information more complete and if it will be welcomed I'll sent it too. The best way is - of course - to make this feature configurable, but I am not experienced C programmer so I cannot do it :-( Regards, Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main.c.diff URL: From plamen at bluetone.cz Fri Mar 18 15:55:16 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Fri, 18 Mar 2005 16:55:16 +0100 Subject: Xterm window title enhancement to hostname:/path II. Message-ID: <20050318165516.50d96aae.plamen@bluetone.cz> Sorry - I've attached wrong file so now it has to be a bit better. Hi developers, I've found a feature in last version of mc. It is really nice to change xterm window title to current path. One can check Window List in its Window Manager and find the right window there. It is really nice. But it is not enough if one is logged on another machines via ssh. Then Window list can look like: mc - /etc mc - /etc mc - /etc mc - /usr/src Well, but what is the right window what I am looking for? I want to switch to configuration window of my firewall. I need a bit different list: mc - debi:/etc mc - Firewall:/etc mc - Planet:/etc mc - workstation:/usr/src or better (not coded now) mc - root at debi:/etc mc - root at Firewall:/etc mc - root at Planet:/etc mc - plamen at workstation:/usr/src This patch adds hostname to current path in x-terminal window with minimal source code changes into existing code. It works for me and I hope it will be useful for many network administrators too. I hope this patch is safe. It is restricted to hostnames up to 63 bytes long. Please include it into upstream if you'll find it useful. It is possible that during some days I'll add username to make information more complete and if it will be welcomed I'll sent it too. The best way is - of course - to make this feature configurable, but I am not experienced C programmer so I cannot do it :-( Regards, Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c.patch Type: application/octet-stream Size: 1196 bytes Desc: not available URL: From plamen at bluetone.cz Sat Mar 19 12:10:19 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Sat, 19 Mar 2005 13:10:19 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050319084751.GA3489@SteX> References: <20050318165516.50d96aae.plamen@bluetone.cz> <20050319084751.GA3489@SteX> Message-ID: <20050319131019.10b4fac3.plamen@bluetone.cz> On Sat, 19 Mar 2005 09:47:51 +0100 Stefano Melchior wrote: > > In the patch file you should have put: > > --- src/main.c Fri Nov 14 21:43:12 2003 > +++ src/main.c Fri Mar 18 15:36:41 2005 > > instead of: > > --- main.c Fri Nov 14 21:43:12 2003 > +++ main.c Fri Mar 18 15:36:41 2005 > > otherwise the patch application can not understand what file to patch. > This is a simple correction (look at the attachment) > Bye > > SteX OK, I will keep it in my mind and next time it will be better :-) Thank you for this info. Pavel From stefano.melchior at fastwebnet.it Sat Mar 19 08:47:51 2005 From: stefano.melchior at fastwebnet.it (Stefano Melchior) Date: Sat, 19 Mar 2005 09:47:51 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050318165516.50d96aae.plamen@bluetone.cz> References: <20050318165516.50d96aae.plamen@bluetone.cz> Message-ID: <20050319084751.GA3489@SteX> On Fri, Mar 18, 2005 at 04:55:16PM +0100, Pavel V?vra wrote: Hi Pavel, > > mc - root at debi:/etc > mc - root at Firewall:/etc > mc - root at Planet:/etc > mc - plamen at workstation:/usr/src > > This patch adds hostname to current path in x-terminal window with minimal source code changes into existing code. It works for me and I hope it will be useful for many network administrators too. I hope this patch is safe. It is restricted to hostnames up to 63 bytes long. Please include it into upstream if you'll find it useful. It is possible that during some days I'll add username to make information more complete and if it will be welcomed I'll sent it too. The best way is - of course - to make this feature configurable, but I am not experienced C programmer so I cannot do it :-( In the patch file you should have put: --- src/main.c Fri Nov 14 21:43:12 2003 +++ src/main.c Fri Mar 18 15:36:41 2005 instead of: --- main.c Fri Nov 14 21:43:12 2003 +++ main.c Fri Mar 18 15:36:41 2005 otherwise the patch application can not understand what file to patch. This is a simple correction (look at the attachment) Bye SteX -- GPG key = D52DF829 -- SteX -- Keyserver: http://keyserver.kjsl.com, User#324592, http://counter.li.org http://www.openlabs.it/~stex -- http://www.stex.name -------------- next part -------------- --- src/main.c.orig Fri Nov 14 21:43:12 2003 +++ src/main.c Fri Mar 18 15:36:41 2005 @@ -1597,21 +1597,45 @@ #define xtoolkit_panel_setup() -/* Show current directory in the xterm title */ +/* Show hostname and current directory in the xterm title */ void update_xterm_title_path (void) { unsigned char *p, *s; + char *pvp; + size_t pvlen; + int pvresult; if (xterm_flag && xterm_title) { + // currrent path p = s = g_strdup (strip_home_and_password (current_panel->cwd)); + // hostname + pvlen = strlen(p); + pvp = g_malloc (pvlen + 64); //approach - max hostname length + pvresult = gethostname(pvp, 63); + if (pvresult) { // print just current path + g_free (pvp); + pvp = p; + } else { + s = pvp; + do { // merge hostname with path + if (!is_printable (*s)) + *s = '?'; + } while (*++s!=0x00); + *s++=':'; + strcpy (s, p); + g_free (p); + } + do { if (!is_printable (*s)) *s = '?'; } while (*++s); - fprintf (stdout, "\33]0;mc - %s\7", p); +// fprintf (stdout, "\33]0;mc - %s\7", p); + fprintf (stdout, "\33]0;mc - %s\7", pvp); fflush (stdout); - g_free (p); +// g_free (p); + g_free (pvp); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From proski at gnu.org Sat Mar 19 19:54:30 2005 From: proski at gnu.org (Pavel Roskin) Date: Sat, 19 Mar 2005 14:54:30 -0500 Subject: Fixes committed In-Reply-To: References: <1111099503.30842.4.camel@dv> Message-ID: <1111262070.5609.4.camel@portland.hansa.lan> On Fri, 2005-03-11 at 15:34 +0200, Pavel Tsekov wrote: > Hello Pavel, > > Good to hear from you! Do you plan to work on MC again ? No definite plans, sorry. On the positive side, I have fixed compilation od Debian unstable. It' turns out Debian strips private symbols like _SLsys_getkey(), so mc should use the public interface. I'm sorry, I wrongly blamed other mc developers for breaking mc, but it was a Debian update that broke compilation. I've just made another snapshot (yes, as strange as it sounds, I compile RPMs on Debian). -- Regards, Pavel Roskin From proski at gnu.org Sat Mar 19 19:54:30 2005 From: proski at gnu.org (Pavel Roskin) Date: Sat, 19 Mar 2005 14:54:30 -0500 Subject: Fixes committed In-Reply-To: References: <1111099503.30842.4.camel@dv> Message-ID: <1111262070.5609.4.camel@portland.hansa.lan> On Fri, 2005-03-11 at 15:34 +0200, Pavel Tsekov wrote: > Hello Pavel, > > Good to hear from you! Do you plan to work on MC again ? No definite plans, sorry. On the positive side, I have fixed compilation od Debian unstable. It' turns out Debian strips private symbols like _SLsys_getkey(), so mc should use the public interface. I'm sorry, I wrongly blamed other mc developers for breaking mc, but it was a Debian update that broke compilation. I've just made another snapshot (yes, as strange as it sounds, I compile RPMs on Debian). -- Regards, Pavel Roskin From leonard at den.ottolander.nl Sun Mar 20 10:20:48 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 20 Mar 2005 11:20:48 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050319131019.10b4fac3.plamen@bluetone.cz> References: <20050318165516.50d96aae.plamen@bluetone.cz> <20050319084751.GA3489@SteX> <20050319131019.10b4fac3.plamen@bluetone.cz> Message-ID: <1111314048.4793.1.camel@athlon.localdomain> Hello Pavel, On Sat, 2005-03-19 at 13:10, Pavel V?vra wrote: > On Sat, 19 Mar 2005 09:47:51 +0100 > Stefano Melchior wrote: > > In the patch file you should have put: > > > > --- src/main.c Fri Nov 14 21:43:12 2003 > > +++ src/main.c Fri Mar 18 15:36:41 2005 And most people prefer a unified diff (diff -up). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From krics at linuxforum.hu Sun Mar 20 11:35:58 2005 From: krics at linuxforum.hu (Christian Hamar) Date: Sun, 20 Mar 2005 12:35:58 +0100 Subject: mcedit position remember bug Message-ID: <1111318558.7002.4.camel@localhost> Hello there! I found maybe a bug (or just a bad configuration) in mcedit postition remember option. I got mc 4.6.1pre4a version. I go and mcedit some file example /home/krics/README Then in /home/krics/.mc/filepos i got this line: /home/krics/README 7;5 ^^ So that is The editor remembers where i was in the file. The line number (first) and the column number (second) But there is the bug. If i hit F4 again to README then my cursor is in 7;0 position and not in 7;5 which was in the filepos !! So mcedit miss to set the cursor to the right column. Just i misconfigure or compiled bad mc or is this an mcedit bug in 4.6.1pre4a ? Regards Christian Hamar alias krix Hungary From jnovy at redhat.com Mon Mar 21 08:19:34 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 21 Mar 2005 09:19:34 +0100 Subject: [PATCH] space on prompt bugfix Message-ID: <1111393174.21856.32.camel@obelix.redhat.usu> Hi mc-devel! There's a bug I've been annoyed with for some time so I finally decided to fix it. To reproduce: 1. start mc 2. go to some directory where you see some further subdirectories 3. press space once or for more times -> spaces will appear in the command prompt 4. try to go to some subdirectory by pressing enter on it or press enter on any *.c, *.mp3 file. Results: You're unable to change a directory until you delete all spaces typed on command prompt and mc does nothing while you're pressing Enter. Furthermore you're unable to launch any application by tapping enter on *.c, *.mp3 files, etc. I did two patches to fix it so that you can decide which one is better commit candidate. Patch1: Allows an user to type leading spaces on the command prompt, but when enter is pressed, it tests whether the user typed at least something except spaces. In case it finds only spaces, it deletes them from the command prompt and let the enter be further processed. Patch2: Doesn't let the user to type leading spaces if he didn't write a non- space letter already. Note that both the patches also contain fix for a redundant strlen () call. Cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-spaceprompt1.patch Type: text/x-patch Size: 1051 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-spaceprompt2.patch Type: text/x-patch Size: 765 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Mon Mar 21 11:47:38 2005 From: buc at odusz.so-cdu.ru (buc) Date: Mon, 21 Mar 2005 14:47:38 +0300 Subject: [PATCH] space on prompt bugfix In-Reply-To: <1111393174.21856.32.camel@obelix.redhat.usu> References: <1111393174.21856.32.camel@obelix.redhat.usu> Message-ID: <423EB45A.3090801@odu.neva.ru> Jindrich Novy wrote: >I did two patches to fix it so that you can decide which one is better >commit candidate. > >Patch1: >Allows an user to type leading spaces on the command prompt, but when >enter is pressed, it tests whether the user typed at least something >except spaces. In case it finds only spaces, it deletes them from the >command prompt and let the enter be further processed. > >Patch2: >Doesn't let the user to type leading spaces if he didn't write a non- >space letter already. > > > IMHO, patch1 is better way. Else "end user" can decide "the space key is not working" ... -- Dmitry Butskoj Saint-Petersburg, Russia From krics at linuxforum.hu Mon Mar 21 11:51:37 2005 From: krics at linuxforum.hu (Christian Hamar) Date: Mon, 21 Mar 2005 12:51:37 +0100 Subject: mcedit position remember bug In-Reply-To: <1111318558.7002.4.camel@localhost> References: <1111318558.7002.4.camel@localhost> Message-ID: <1111405897.7001.10.camel@localhost> > I found maybe a bug (or just a bad configuration) in mcedit postition > remember option. I create a small patch for this (just change one line and one little value). The main problem is in the src/util.c code. I viewed mc4.6.1pre1 which contains a segfaultable code with atol. That was fixed in 4.6.1pre4 to use strtoll and check if The old code in 4.6.1pre1: *line = atol(p); p = strchr (buf, ';'); *column = atol (&p[1]); The new code in 4.6.1pre4: *line = strtol(p, const_cast(char **, &p), 10); if (*p == ';') { *column = strtol(p, const_cast(char **, &p), 10); if (*p != '\n') *column = 0; } else *line = 1; We see that there is a check for ; . If found then go and strtol p to column. But. With this code the column got something like this as value : (if in filepos : /xx.txt 12;20) ;20 So the bad ; stays there and column goes to 0 and editor can not set cursor to ';20' The fix is included. Need *column = strtol(p+1, const_cast(char **, &p), 10); I attached this small patch against 4.6.1pre4 I hope this is good way to fix this problem, if not, please someone correct out that :) Regards Christian Hamar alias krix Hungary -------------- next part -------------- A non-text attachment was scrubbed... Name: mc_filepos_bugfix_461pre4a.patch Type: text/x-patch Size: 464 bytes Desc: not available URL: From jnovy at redhat.com Mon Mar 21 14:17:43 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 21 Mar 2005 15:17:43 +0100 Subject: [PATCH] space on prompt bugfix In-Reply-To: <423EB45A.3090801@odu.neva.ru> References: <1111393174.21856.32.camel@obelix.redhat.usu> <423EB45A.3090801@odu.neva.ru> Message-ID: <1111414663.13496.24.camel@obelix.redhat.usu> Hello Dmitry, On Mon, 2005-03-21 at 14:47 +0300, buc wrote: > Jindrich Novy wrote: > > >I did two patches to fix it so that you can decide which one is better > >commit candidate. > > > >Patch1: > >Allows an user to type leading spaces on the command prompt, but when > >enter is pressed, it tests whether the user typed at least something > >except spaces. In case it finds only spaces, it deletes them from the > >command prompt and let the enter be further processed. > > > >Patch2: > >Doesn't let the user to type leading spaces if he didn't write a non- > >space letter already. > > > > > > > IMHO, patch1 is better way. Else "end user" can decide "the space key is > not working" ... Yes, the spacebar won't be working for leading spaces. However, typing the leading spaces in the command prompt IMHO doesn't make too much sense to me so maybe after patch2 is applied we may use the spacebar as an equivalent of "Ins" for selecting files/dirs as usual in other filemanagers when nothing is actually typed in the command prompt. That is a slight advantage of the second patch so please let me know if you like/dislike the idea so that I can do another patch for this or simply be happy with the patch1. Thanks, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From buc at odusz.so-cdu.ru Mon Mar 21 14:44:46 2005 From: buc at odusz.so-cdu.ru (buc) Date: Mon, 21 Mar 2005 17:44:46 +0300 Subject: [PATCH] space on prompt bugfix In-Reply-To: <1111414663.13496.24.camel@obelix.redhat.usu> References: <1111393174.21856.32.camel@obelix.redhat.usu> <423EB45A.3090801@odu.neva.ru> <1111414663.13496.24.camel@obelix.redhat.usu> Message-ID: <423EDDDE.5080201@odu.neva.ru> Jindrich Novy wrote: >>IMHO, patch1 is better way. Else "end user" can decide "the space key is >>not working" ... >> >> > >Yes, the spacebar won't be working for leading spaces. However, typing >the leading spaces in the command prompt IMHO doesn't make too much >sense to me so maybe after patch2 is applied we may use the spacebar as >an equivalent of "Ins" for selecting files/dirs as usual in other >filemanagers when nothing is actually typed in the command prompt. > >That is a slight advantage of the second patch so please let me know if >you like/dislike the idea so that I can do another patch for this or >simply be happy with the patch1. > > Intuitively, the MC can be perceived as a screen extension to shell (which became possible due to ncurses/slang lib and Ctr/Fn/Alt/Meta keyboard features). Therefore, MC`s cmdline should be closer to a shell command line, rather than a screen application input field. Currently, we have only one printable character -- Tab -- which behaves unser MC and a shell differently (and it is reasonable). But don`t add space to this list! There are a lot of keyboard buttons, modifier keys etc. to do things easy -- let MC cmdline be a "true command line". -- Dmitry Butskoj Saint-Petersburg, Russia From tux at centrum.cz Mon Mar 21 16:42:00 2005 From: tux at centrum.cz (tux at centrum.cz) Date: Mon, 21 Mar 2005 17:42:00 +0100 Subject: [PATCH] space on prompt bugfix Message-ID: > Patch2: > Doesn't let the user to type leading spaces if he didn't write a non- > space letter already. Not a good idea, since I think if you prepend a space to any command, the command is not saved in bash history - a feature. Sometimes it may be thus desirable to be able to type leading space if you do not want to save the command in history - your patch would disallow this Martin Petricek From jnovy at redhat.com Mon Mar 21 17:25:34 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 21 Mar 2005 18:25:34 +0100 Subject: [PATCH] space on prompt bugfix In-Reply-To: References: Message-ID: <1111425934.13496.66.camel@obelix.redhat.usu> Hello Martin, On Mon, 2005-03-21 at 17:42 +0100, tux at centrum.cz wrote: > > Patch2: > > Doesn't let the user to type leading spaces if he didn't write a non- > > space letter already. > > Not a good idea, since I think if you prepend a space to any command, the command is not saved in bash history - a feature. > Sometimes it may be thus desirable to be able to type leading space if you do not want to save the command in history - your patch would disallow this Ok, I forgot about this feature, thanks for noticing this. So maybe Patch1 would be the best solution for the issue. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Mon Mar 21 21:23:10 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 21 Mar 2005 22:23:10 +0100 Subject: [PATCH] space on prompt bugfix In-Reply-To: <1111425934.13496.66.camel@obelix.redhat.usu> References: <1111425934.13496.66.camel@obelix.redhat.usu> Message-ID: <1111440190.4793.11.camel@athlon.localdomain> Hi Jindrich, On Mon, 2005-03-21 at 18:25, Jindrich Novy wrote: > On Mon, 2005-03-21 at 17:42 +0100, tux at centrum.cz wrote: > > Not a good idea, since I think if you prepend a space to any command, the command is not saved in bash history - a feature. > > Sometimes it may be thus desirable to be able to type leading space if you do not want to save the command in history - your patch would disallow this > > Ok, I forgot about this feature, thanks for noticing this. HISTCONTROL=ignorespace is actually used actively by mc itself to hide mc commands from the history in subshell.c ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Tue Mar 22 07:31:56 2005 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 22 Mar 2005 12:31:56 +0500 Subject: [PATCH] space on prompt bugfix In-Reply-To: <423EDDDE.5080201@odu.neva.ru> References: <1111393174.21856.32.camel@obelix.redhat.usu> <423EB45A.3090801@odu.neva.ru> <1111414663.13496.24.camel@obelix.redhat.usu> <423EDDDE.5080201@odu.neva.ru> Message-ID: <79484495.20050322123156@pavelsh.pp.ru> Hello buc, Monday, March 21, 2005, 7:44:46 PM, you wrote: b> Intuitively, the MC can be perceived as a screen extension to shell b> (which became possible due to ncurses/slang lib and Ctr/Fn/Alt/Meta b> keyboard features). Therefore, MC`s cmdline should be closer to a shell b> command line, rather than a screen application input field. b> Currently, we have only one printable character -- Tab -- which b> behaves unser MC and a shell differently (and it is reasonable). But b> don`t add space to this list! b> There are a lot of keyboard buttons, modifier keys etc. to do things b> easy -- let MC cmdline be a "true command line". MC cmdline isn't a "true command line". Please. Read man mc. Macro Substitution When accessing a user menu, or executing an extension dependent com- mand, or running a command from the command line input, a simple macro substitution takes place. ................... and so on. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From buc at odusz.so-cdu.ru Tue Mar 22 11:15:22 2005 From: buc at odusz.so-cdu.ru (buc) Date: Tue, 22 Mar 2005 14:15:22 +0300 Subject: [PATCH] space on prompt bugfix In-Reply-To: <79484495.20050322123156@pavelsh.pp.ru> References: <1111393174.21856.32.camel@obelix.redhat.usu> <423EB45A.3090801@odu.neva.ru> <1111414663.13496.24.camel@obelix.redhat.usu> <423EDDDE.5080201@odu.neva.ru> <79484495.20050322123156@pavelsh.pp.ru> Message-ID: <423FFE4A.1050306@odu.neva.ru> Pavel Shirshov (pchel) wrote: >Hello buc, > >Monday, March 21, 2005, 7:44:46 PM, you wrote: > >b> Intuitively, the MC can be perceived as a screen extension to shell >b> (which became possible due to ncurses/slang lib and Ctr/Fn/Alt/Meta >b> keyboard features). Therefore, MC`s cmdline should be closer to a shell >b> command line, rather than a screen application input field. >b> Currently, we have only one printable character -- Tab -- which >b> behaves unser MC and a shell differently (and it is reasonable). But >b> don`t add space to this list! >b> There are a lot of keyboard buttons, modifier keys etc. to do things >b> easy -- let MC cmdline be a "true command line". > >MC cmdline isn't a "true command line". > >Please. Read man mc. > > Macro Substitution > When accessing a user menu, or executing an extension dependent com- > mand, or running a command from the command line input, a simple macro > substitution takes place. > >................... > > and so on. > > > I know. I meant it should be closer to a "true" command line (note quotedbl). Of couse, bash has no "%d"-like macro substitution and other features (as an old bourne shell has no "$((...))" etc. ;-)) From me at pavelsh.pp.ru Wed Mar 23 05:31:05 2005 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 23 Mar 2005 10:31:05 +0500 Subject: mcedit position remember bug In-Reply-To: <1111405897.7001.10.camel@localhost> References: <1111318558.7002.4.camel@localhost> <1111405897.7001.10.camel@localhost> Message-ID: <1517210883.20050323103105@pavelsh.pp.ru> Hello Christian, Monday, March 21, 2005, 4:51:37 PM, you wrote: CH> The fix is included. Need *column = strtol(p+1, const_cast(char **, &p), CH> 10); CH> I attached this small patch against 4.6.1pre4 CH> I hope this is good way to fix this problem, if not, please someone CH> correct out that :) Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Wed Mar 23 13:28:48 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 23 Mar 2005 14:28:48 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050318165516.50d96aae.plamen@bluetone.cz> References: <20050318165516.50d96aae.plamen@bluetone.cz> Message-ID: <1111584528.1242.40.camel@obelix.redhat.usu> Hello Pavel, On Fri, 2005-03-18 at 16:55 +0100, Pavel V?vra wrote: > Sorry - I've attached wrong file so now it has to be a bit better. > > Hi developers, > I've found a feature in last version of mc. It is really nice to change xterm window title to current path. One can check Window List in its Window Manager and find the right window there. It is really nice. But it is not enough if one is logged on another machines via ssh. Then Window list can look like: > mc - /etc > mc - /etc > mc - /etc > mc - /usr/src > > Well, but what is the right window what I am looking for? I want to switch to configuration window of my firewall. I need a bit different list: > > mc - debi:/etc > mc - Firewall:/etc > mc - Planet:/etc > mc - workstation:/usr/src > I like the idea you presented, so I reimplemented the hostname addition to xterm window title so that it can be committed. Please avoid using C++ comments in patches for the next time. Cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-hostname.patch Type: text/x-patch Size: 545 bytes Desc: not available URL: From plamen at bluetone.cz Wed Mar 23 14:02:03 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Wed, 23 Mar 2005 15:02:03 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <1111584528.1242.40.camel@obelix.redhat.usu> References: <20050318165516.50d96aae.plamen@bluetone.cz> <1111584528.1242.40.camel@obelix.redhat.usu> Message-ID: <20050323150203.4b8b942a.plamen@bluetone.cz> Hi Jindrich, now 2nd part of this patch is done so xterminal window can display user at hostname:/path. I think it will be better implement both parts of this patch just once. My code is now a bit cleaner but I am testing now this feature so patch is not prepared just now. I'll send it during today. Thank you Pavel On Wed, 23 Mar 2005 14:28:48 +0100 Jindrich Novy wrote: > Hello Pavel, > > On Fri, 2005-03-18 at 16:55 +0100, Pavel V?vra wrote: > > Sorry - I've attached wrong file so now it has to be a bit better. > > > > Hi developers, > > I've found a feature in last version of mc. It is really nice to change xterm window title to current path. One can check Window List in its Window Manager and find the right window there. It is really nice. But it is not enough if one is logged on another machines via ssh. Then Window list can look like: > > mc - /etc > > mc - /etc > > mc - /etc > > mc - /usr/src > > > > Well, but what is the right window what I am looking for? I want to switch to configuration window of my firewall. I need a bit different list: > > > > mc - debi:/etc > > mc - Firewall:/etc > > mc - Planet:/etc > > mc - workstation:/usr/src > > > > I like the idea you presented, so I reimplemented the hostname addition > to xterm window title so that it can be committed. > > Please avoid using C++ comments in patches for the next time. > > Cheers, > Jindrich > > -- > Jindrich Novy , http://people.redhat.com/jnovy/ > From plamen at bluetone.cz Wed Mar 23 14:19:10 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Wed, 23 Mar 2005 15:19:10 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <1111584528.1242.40.camel@obelix.redhat.usu> References: <20050318165516.50d96aae.plamen@bluetone.cz> <1111584528.1242.40.camel@obelix.redhat.usu> Message-ID: <20050323151910.33b1b67d.plamen@bluetone.cz> Well, I look to your patch and I decide that it has no sense to send my patch. this one is really nice and I cannot write it better. Just an idea how to get username (sorry if you know better solution): ---------------- register struct passwd *pw; register uid_t uid; uid = getuid(); pw = getpwuid(uid); /* OK, you'll write pw = getpwuid(getuid()) */ /* now pw->pw_name contains user name */ ------------------ On Wed, 23 Mar 2005 14:28:48 +0100 Jindrich Novy wrote: > Hello Pavel, > > On Fri, 2005-03-18 at 16:55 +0100, Pavel V?vra wrote: > > Sorry - I've attached wrong file so now it has to be a bit better. > > > > Hi developers, > > I've found a feature in last version of mc. It is really nice to change xterm window title to current path. One can check Window List in its Window Manager and find the right window there. It is really nice. But it is not enough if one is logged on another machines via ssh. Then Window list can look like: > > mc - /etc > > mc - /etc > > mc - /etc > > mc - /usr/src > > > > Well, but what is the right window what I am looking for? I want to switch to configuration window of my firewall. I need a bit different list: > > > > mc - debi:/etc > > mc - Firewall:/etc > > mc - Planet:/etc > > mc - workstation:/usr/src > > > > I like the idea you presented, so I reimplemented the hostname addition > to xterm window title so that it can be committed. > > Please avoid using C++ comments in patches for the next time. > > Cheers, > Jindrich > > -- > Jindrich Novy , http://people.redhat.com/jnovy/ > From jnovy at redhat.com Wed Mar 23 15:10:01 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 23 Mar 2005 16:10:01 +0100 Subject: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050323151910.33b1b67d.plamen@bluetone.cz> References: <20050318165516.50d96aae.plamen@bluetone.cz> <1111584528.1242.40.camel@obelix.redhat.usu> <20050323151910.33b1b67d.plamen@bluetone.cz> Message-ID: <1111590606.17922.7.camel@obelix.redhat.usu> Hello Pavel, here is the patch where both hostname and username are printed in the xterm window title. Cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-hostname.patch Type: text/x-patch Size: 833 bytes Desc: not available URL: From plamen at bluetone.cz Wed Mar 23 16:06:21 2005 From: plamen at bluetone.cz (Pavel =?ISO-8859-2?Q?V=E1vra?=) Date: Wed, 23 Mar 2005 17:06:21 +0100 Subject: Fw: Re: Xterm window title enhancement to hostname:/path II. Message-ID: <20050323170621.14aeaa3e.plamen@bluetone.cz> Yes, it is. My patch is quite long when I compare it with your one. I am not able to write compact C code :-(. Next time I'll add item into wishlist and I'll save a lot of time. What do you think about restoring of original title when mc ends? I usually open xterm with some title, then I run ssh client and then I run commander. When I run mc, title of window is changed, but when I exit mc last used title is still displayed as permanent title. This title is wrong - in Window List I see that mc is running but only (ba)sh prompt is present there. I have no suggestion how to do it but it is possible that you can do it during 5 minutes and your patch will be about 10 lines long. Regards, Pavel .... and next item into wishlist will be to configure xterm title, e.g. "mc - $USER@$HOSTNAME:%d" :-) P. Dne Wed, 23 Mar 2005 16:10:01 +0100 Jindrich Novy p??e: > Hello Pavel, > > here is the patch where both hostname and username are printed in the > xterm window title. > > Cheers, > Jindrich > > -- > Jindrich Novy , http://people.redhat.com/jnovy/ > From proski at gnu.org Wed Mar 23 21:25:48 2005 From: proski at gnu.org (Pavel Roskin) Date: Wed, 23 Mar 2005 16:25:48 -0500 Subject: Proposed patch: Alt-O on files to select current directory Message-ID: <1111613148.8853.13.camel@dv> Hello, Miguel and everybody! I'm sorry, I was too busy to do anything about the issue with Alt-O, even to argue about it. But I'd like to fix the current code a bit to make it less annoying to me. Alt-O on a file makes the inactive panel change to the parent directory of the one in the active panel. It would be great to move selection on the inactive panel to select the entry corresponding to the current directory on the active panel. This way, I could use Alt-O, Tab, Enter to emulate the behavior of Alt-O in mc 4.6.0. Also, I could press Tab and use Alt-O or cursor keys to navigate directories with similar names. Miguel, since you wanted the old behavior, I'd like you to see the patch so you don't complain again that I broke something you liked. ChangeLog: * screen.c (chdir_other_panel): When used on a file entry, move selection on the inactive panel to select the entry for the current directory on the active panel. -- Regards, Pavel Roskin -------------- next part -------------- A non-text attachment was scrubbed... Name: alt_o_select.diff Type: text/x-patch Size: 823 bytes Desc: not available URL: From proski at gnu.org Wed Mar 23 21:25:48 2005 From: proski at gnu.org (Pavel Roskin) Date: Wed, 23 Mar 2005 16:25:48 -0500 Subject: Proposed patch: Alt-O on files to select current directory Message-ID: <1111613148.8853.13.camel@dv> Hello, Miguel and everybody! I'm sorry, I was too busy to do anything about the issue with Alt-O, even to argue about it. But I'd like to fix the current code a bit to make it less annoying to me. Alt-O on a file makes the inactive panel change to the parent directory of the one in the active panel. It would be great to move selection on the inactive panel to select the entry corresponding to the current directory on the active panel. This way, I could use Alt-O, Tab, Enter to emulate the behavior of Alt-O in mc 4.6.0. Also, I could press Tab and use Alt-O or cursor keys to navigate directories with similar names. Miguel, since you wanted the old behavior, I'd like you to see the patch so you don't complain again that I broke something you liked. ChangeLog: * screen.c (chdir_other_panel): When used on a file entry, move selection on the inactive panel to select the entry for the current directory on the active panel. -- Regards, Pavel Roskin -------------- next part -------------- A non-text attachment was scrubbed... Name: alt_o_select.diff Type: text/x-patch Size: 823 bytes Desc: not available URL: From makovick at kmlinux.fjfi.cvut.cz Thu Mar 24 11:53:40 2005 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Thu, 24 Mar 2005 12:53:40 +0100 Subject: Big patch for mcview In-Reply-To: <422E02F8.9040308@gmx.de> References: <42260893.9020300@gmx.de> <422E02F8.9040308@gmx.de> Message-ID: <4242AA44.9020903@kmlinux.fjfi.cvut.cz> Roland Illig wrote: > Pavel Tsekov wrote: > >> First of all - this patch could have been much smaller and thus easier to >> review/understand. 25 % (line 666 to the end) of the patch are hunks >> which >> do the following: >> >> get_byte => view->get_byte >> >> Well, simply keeping get_byte () and calling view->get_byte from within >> would have been much nicer. Also you could have made our lives easier if >> you have moved most of the "new" functions that you have introduced to >> the end of the file - this way it would be much easier to read the patch. > > > Sorry for these. I had uploaded an old version of the patch. An improved > patch is available: http://www.roland-illig.de/tmp/viewer-try2.patch Crashes when switching between viewer modes. To reproduce, use F3 on a jpg/mp3/whatever (assuming you have mpg123, ImageMagick or other corresponding viewer), press F8 to display raw, then press F4 => sig11. Regards, -- Jindrich Makovicka From miguel at novell.com Sat Mar 26 01:19:40 2005 From: miguel at novell.com (Miguel de Icaza) Date: Fri, 25 Mar 2005 20:19:40 -0500 Subject: Proposed patch: Alt-O on files to select current directory In-Reply-To: <1111613148.8853.13.camel@dv> References: <1111613148.8853.13.camel@dv> Message-ID: <1111799980.3551.173.camel@linux.site> Hello, > Miguel, since you wanted the old behavior, I'd like you to see the patch > so you don't complain again that I broke something you liked. Thanks for the patch. I think that this is a useful addition, I have no objections to it. Miguel From leonard at den.ottolander.nl Sat Mar 26 08:25:28 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 26 Mar 2005 09:25:28 +0100 Subject: Issues to fix before 4.6.1? Message-ID: <1111825528.4824.4.camel@athlon.localdomain> Hello Pavel, Could you please tell us which according to you are issues that still need to be fixed before a release of 4.6.1? Development on the 4.6.1-pre branch has been rather quiet for a few months now (since december essentially), so it would be nice to resolve these issues and have a release. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From proski at gnu.org Tue Mar 29 04:47:22 2005 From: proski at gnu.org (Pavel Roskin) Date: Mon, 28 Mar 2005 23:47:22 -0500 Subject: Proposed patch: Alt-O on files to select current directory In-Reply-To: <1111799980.3551.173.camel@linux.site> References: <1111613148.8853.13.camel@dv> <1111799980.3551.173.camel@linux.site> Message-ID: <1112071642.14308.2.camel@dv> On Fri, 2005-03-25 at 20:19 -0500, Miguel de Icaza wrote: > Hello, > > > Miguel, since you wanted the old behavior, I'd like you to see the patch > > so you don't complain again that I broke something you liked. > > Thanks for the patch. I think that this is a useful addition, I have no > objections to it. Applied. -- Regards, Pavel Roskin From proski at gnu.org Tue Mar 29 05:34:03 2005 From: proski at gnu.org (Pavel Roskin) Date: Tue, 29 Mar 2005 00:34:03 -0500 Subject: Issues to fix before 4.6.1? In-Reply-To: <1111825528.4824.4.camel@athlon.localdomain> References: <1111825528.4824.4.camel@athlon.localdomain> Message-ID: <1112074443.14308.12.camel@dv> On Sat, 2005-03-26 at 09:25 +0100, Leonard den Ottolander wrote: > Hello Pavel, > > Could you please tell us which according to you are issues that still > need to be fixed before a release of 4.6.1? Development on the 4.6.1-pre > branch has been rather quiet for a few months now (since december > essentially), so it would be nice to resolve these issues and have a > release. > I've just fixed the last issue, both in HEAD and MC_4_6_1_PRE. It was a bug in cpio handling that could cause a buffer overflow on broken cpio archives. Now the biggest issue is catching up with the development. There are hundreds of posts in the mailing list that I have never had a chance to read. I don't feel good about making any releases without having read them. Some messages could be about security issues. -- Regards, Pavel Roskin From andrew at email.zp.ua Tue Mar 29 08:07:39 2005 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 29 Mar 2005 11:07:39 +0300 (EEST) Subject: Issues to fix before 4.6.1? In-Reply-To: <1112074443.14308.12.camel@dv> Message-ID: <200503290807.j2T87dJT013482@email.zp.ua> Hello, > On Sat, 2005-03-26 at 09:25 +0100, Leonard den Ottolander wrote: > > Hello Pavel, > > > > Could you please tell us which according to you are issues that still > > need to be fixed before a release of 4.6.1? Development on the 4.6.1-pre > > branch has been rather quiet for a few months now (since december > > essentially), so it would be nice to resolve these issues and have a > > release. > > > I've just fixed the last issue, both in HEAD and MC_4_6_1_PRE. It was a > bug in cpio handling that could cause a buffer overflow on broken cpio > archives. > > Now the biggest issue is catching up with the development. There are > hundreds of posts in the mailing list that I have never had a chance to > read. I don't feel good about making any releases without having read > them. Some messages could be about security issues. There is a data loss possible if file is edited with external editor over VFS. -- Regards, Andrew V. Samoilov ________________________________________________________________ GET INTERNET ACCESS FROM BCS! http://www.bcs.zp.ua Join BCS today! For your FREE webmail, visit: http://email.zp.ua/ From jnovy at redhat.com Tue Mar 29 15:46:33 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 29 Mar 2005 17:46:33 +0200 Subject: Issues to fix before 4.6.1? In-Reply-To: <200503290807.j2T87dJT013482@email.zp.ua> References: <200503290807.j2T87dJT013482@email.zp.ua> Message-ID: <1112111193.15204.29.camel@obelix.redhat.usu> Hello Andrew, Pavel, On Tue, 2005-03-29 at 11:07 +0300, Andrew V. Samoilov wrote: > There is a data loss possible if file is edited with external editor over VFS. I have similar experience even with mcedit without VFS -> data loss when disk quota is exceeded, the edited file is truncated to zero size. I had these problems with mc-4.5.51 so I'm not sure if it's still a problem with recent mc. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From ldrolez at debian.org Tue Mar 29 18:44:09 2005 From: ldrolez at debian.org (Ludovic Drolez) Date: Tue, 29 Mar 2005 20:44:09 +0200 Subject: Issues to fix before 4.6.1? In-Reply-To: <20050329170129.A85A93B0CA8@menubar.gnome.org> References: <20050329170129.A85A93B0CA8@menubar.gnome.org> Message-ID: <4249A1F9.6000001@debian.org> Hi ! There's a small annoying bug in mc: If you 'ssh' to a box, and then 'su', the Xauthority token is not valid anymore, and instead of ignoring the X11 connection problem, mc exits and displays the following error message: X11 connection rejected because of wrong authentication. X connection to XXXXX:10.0 broken (explicit kill or server shutdown). (see also http://bugs.debian.org/301174) Is there an easy fix for this bug, or unsetting $DISPLAY is the only solution ? Cheers, PS: You can also find a trivial fix, for a .jar vfs problem, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299932, but I don't know if the next mc will be affected since we added a patch to uzip... -- Ludovic Drolez. http://www.palmopensource.com - The PalmOS Open Source Portal http://www.drolez.com - Personal site - Linux and PalmOS stuff From ossi at kde.org Tue Mar 29 20:37:26 2005 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 29 Mar 2005 22:37:26 +0200 Subject: Issues to fix before 4.6.1? In-Reply-To: <1112111193.15204.29.camel@obelix.redhat.usu> References: <200503290807.j2T87dJT013482@email.zp.ua> <1112111193.15204.29.camel@obelix.redhat.usu> Message-ID: <20050329203726.GA28924@ugly.local> On Tue, Mar 29, 2005 at 05:46:33PM +0200, Jindrich Novy wrote: > On Tue, 2005-03-29 at 11:07 +0300, Andrew V. Samoilov wrote: > > There is a data loss possible if file is edited with external editor over VFS. > > I have similar experience even with mcedit without VFS -> data loss when > disk quota is exceeded, the edited file is truncated to zero size. I had > these problems with mc-4.5.51 so I'm not sure if it's still a problem > with recent mc. > i've had this just yesterday ... good luck it was no important file. this happens with the quick save mode ... it must, given the way it works. not sure it can be fixed properly at all without just switching to another mode. oh, well, it could be fixed to not lose data, but the resulting file would be a bit inconsistent. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From jnovy at redhat.com Wed Mar 30 08:11:19 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 30 Mar 2005 10:11:19 +0200 Subject: [PATCH] Re: Issues to fix before 4.6.1? In-Reply-To: <20050329203726.GA28924@ugly.local> References: <200503290807.j2T87dJT013482@email.zp.ua> <1112111193.15204.29.camel@obelix.redhat.usu> <20050329203726.GA28924@ugly.local> Message-ID: <1112170279.15204.77.camel@obelix.redhat.usu> Hello Oswald, On Tue, 2005-03-29 at 22:37 +0200, Oswald Buddenhagen wrote: > On Tue, Mar 29, 2005 at 05:46:33PM +0200, Jindrich Novy wrote: > > On Tue, 2005-03-29 at 11:07 +0300, Andrew V. Samoilov wrote: > > > There is a data loss possible if file is edited with external editor over VFS. > > > > I have similar experience even with mcedit without VFS -> data loss when > > disk quota is exceeded, the edited file is truncated to zero size. I had > > these problems with mc-4.5.51 so I'm not sure if it's still a problem > > with recent mc. > > > i've had this just yesterday ... good luck it was no important file. > this happens with the quick save mode ... it must, given the way it > works. not sure it can be fixed properly at all without just switching > to another mode. oh, well, it could be fixed to not lose data, but the > resulting file would be a bit inconsistent. > Seems like mc still tests presence of a file on local filesystem in rather brutal way when quick-saving: if (!vfs_file_is_local (filename) || (fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1) what actually truncates the filename to zero size. The proposed patch modifies the opening mode to O_RDONLY so that we shouldn't lose any data at this point. Furthermore I noticed ctype.h is #included redundantly twice in edit_cmd.c. This fixes the second patch. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-dontrewrite.patch Type: text/x-patch Size: 442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-ctype.patch Type: text/x-patch Size: 274 bytes Desc: not available URL: From jnovy at redhat.com Wed Mar 30 09:27:28 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 30 Mar 2005 11:27:28 +0200 Subject: Fw: Re: Xterm window title enhancement to hostname:/path II. In-Reply-To: <20050323170621.14aeaa3e.plamen@bluetone.cz> References: <20050323170621.14aeaa3e.plamen@bluetone.cz> Message-ID: <1112174848.15204.102.camel@obelix.redhat.usu> Hello Pavel, On Wed, 2005-03-23 at 17:06 +0100, Pavel V?vra wrote: > What do you think about restoring of original title when mc ends? I > usually open xterm with some title, then I run ssh client and then I run > commander. When I run mc, title of window is changed, but when I exit mc > last used title is still displayed as permanent title. Unfortunately I cannot reproduce your case. I see the xterm title correctly restored after I quit mc even if I ssh somewhere and launch mc there. Did I miss something? (using the latest CVS mc) Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From ossi at kde.org Wed Mar 30 11:16:54 2005 From: ossi at kde.org (Oswald Buddenhagen) Date: Wed, 30 Mar 2005 13:16:54 +0200 Subject: [PATCH] Re: Issues to fix before 4.6.1? In-Reply-To: <1112170279.15204.77.camel@obelix.redhat.usu> References: <200503290807.j2T87dJT013482@email.zp.ua> <1112111193.15204.29.camel@obelix.redhat.usu> <20050329203726.GA28924@ugly.local> <1112170279.15204.77.camel@obelix.redhat.usu> Message-ID: <20050330111654.GB4533@ugly.local> On Wed, Mar 30, 2005 at 10:11:19AM +0200, Jindrich Novy wrote: > if (!vfs_file_is_local (filename) || > (fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1) > > what actually truncates the filename to zero size. > it does not, unless mc_open has totally misleading semantics - there is no O_TRUNCATE. the truncation comes during the actual write ... which leaves us with a truncated/empty file, if we run out-of-space in the middle. the "solution" would be not to use O_TRUNCATE at all. instead, first write the part that extends beyond the end of the old file. if that fails to complete, truncate to the old length. if we crash now, the old file will have garbage appended, but at least it's not clobbered alltogether. note that we cannot just seek to the new end and write one byte because of sparse files. after the "extension" was written, overwrite the start of the file with the new content and possibly truncate the file to the new length. this is all sooo ugly ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From browaeys.alban at wanadoo.fr Wed Mar 30 11:57:34 2005 From: browaeys.alban at wanadoo.fr (Alban browaeys) Date: Wed, 30 Mar 2005 13:57:34 +0200 Subject: Debian bug list (#241891) Message-ID: <1112183854.20260.6.camel@argos.server.maison> > Yes but if you read the end of the bug report, Dmitry Rutsky says that if > you replace 'posix_openpt' by 'getpt' it works. > > So couldn't we change the order of preference ? A warning for BSD pseudo terminal users http://lwn.net/Articles/70487/#Comments http://www.ussg.iu.edu/hypermail/linux/kernel/0402.1/0655.html I really do not know if bsd pty will be removed or not but it is a point against moving to bsd first. http://www.ussg.iu.edu/hypermail/linux/kernel/0402.1/0552.html Using BSD ptys is a security hazard. They should *definitely* not be usef preferentially. On my system (RH9) they aren't used by telnet even though they exist. -hpa I suggest one keep posix first. Ciao Alban From ptsekov at gmx.net Wed Mar 23 18:43:05 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 23 Mar 2005 20:43:05 +0200 Subject: Savannah bug #12406: /usr/share/mc/extfs/uarj bug Message-ID: Hello, The original reporter describes what could be a possible fix for this issue. Any extfs guru caring to check that one ? From ptsekov at gmx.net Wed Mar 23 19:29:46 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 23 Mar 2005 21:29:46 +0200 Subject: Savannah bug #12406: /usr/share/mc/extfs/uarj bug In-Reply-To: References: Message-ID: Sorry, forgot the direct link :( http://savannah.gnu.org/bugs/?func=detailitem&item_id=12406 On Wed, 23 Mar 2005, Pavel Tsekov wrote: > Hello, > > The original reporter describes what could be a possible fix for this > issue. Any extfs guru caring to check that one ? From leonard at den.ottolander.nl Wed Mar 30 22:03:58 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 31 Mar 2005 00:03:58 +0200 Subject: Savannah bug #12406: /usr/share/mc/extfs/uarj bug In-Reply-To: References: Message-ID: <1112220238.4790.21.camel@athlon.localdomain> Hi Pavel, On Wed, 2005-03-23 at 20:29, Pavel Tsekov wrote: > Sorry, forgot the direct link :( > > http://savannah.gnu.org/bugs/?func=detailitem&item_id=12406 Looks like an easy fix. Anybody who uses uarj cares to verify this one line fix? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Thu Mar 24 12:15:24 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 24 Mar 2005 14:15:24 +0200 Subject: Savannah bug #12406: /usr/share/mc/extfs/uarj bug In-Reply-To: <1112220238.4790.21.camel@athlon.localdomain> References: <1112220238.4790.21.camel@athlon.localdomain> Message-ID: Hello, On Thu, 31 Mar 2005, Leonard den Ottolander wrote: > Hi Pavel, > > On Wed, 2005-03-23 at 20:29, Pavel Tsekov wrote: > > Sorry, forgot the direct link :( > > > > http://savannah.gnu.org/bugs/?func=detailitem&item_id=12406 > > Looks like an easy fix. Anybody who uses uarj cares to verify this one > line fix? pchel, commited the fix. From me at pavelsh.pp.ru Thu Mar 31 09:52:32 2005 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 31 Mar 2005 15:52:32 +0600 Subject: Savannah bug #12406: /usr/share/mc/extfs/uarj bug In-Reply-To: References: <1112220238.4790.21.camel@athlon.localdomain> Message-ID: <125641284.20050331155232@pavelsh.pp.ru> Hello Pavel, Thursday, March 24, 2005, 6:15:24 PM, you wrote: >> On Wed, 2005-03-23 at 20:29, Pavel Tsekov wrote: >> > Sorry, forgot the direct link :( >> > >> > http://savannah.gnu.org/bugs/?func=detailitem&item_id=12406 >> >> Looks like an easy fix. Anybody who uses uarj cares to verify this one >> line fix? PT> pchel, commited the fix. Committed. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Mon Mar 28 15:39:13 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 28 Mar 2005 18:39:13 +0300 Subject: Terminology concerning strings In-Reply-To: <42510A70.3030200@gmx.de> References: <42510A70.3030200@gmx.de> Message-ID: Hello, On Mon, 4 Apr 2005, Roland Illig wrote: > Hi all, > > in the last time I have programmed a bit with strings, and I have found > four properties of them which need to be distinguished and which should > be named consistently throughout the whole Midnight Commander. > > * the _size_ of a string (as well as for other objects) is the number of > bytes that is allocated for it. For arrays, it is the number of > entries of the array. For strings it is at least _length_ + 1. > > * the _length_ of a string is the number of characters in it, excluding > the terminating '\0'. Wow! Btw you speak of null terminated strings here. The length of the string is always the number of characters in it no matter how do you represent a string. As about the size it depends on the string implementation. > Currently these differences are not recognized by most of the code. > Therefore I'd like to rename all matching variables according to this > scheme: For the string variable s, the _size_ is called ssize, the > _length_ is called slen, the _width_ is called swidth, and the _height_ > is called sheight. > > Example: > char *fname = g_strdup (s); > size_t fnamewidth, fnameheight, fnamesize, fnamelen; My personal preference is to prepend an underscore to the property tag i.e: `fname_width' instead of `fnamewidth' From ptsekov at gmx.net Mon Mar 28 16:42:07 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 28 Mar 2005 19:42:07 +0300 Subject: [PATCH] Re: Parent directory's permissions in mini-status In-Reply-To: <1112444383.4803.35.camel@athlon.localdomain> References: <1112442861.4803.34.camel@athlon.localdomain> <1112444383.4803.35.camel@athlon.localdomain> Message-ID: Hello, On Sat, 2 Apr 2005, Leonard den Ottolander wrote: > Hi Roland, pchel, > > On Sat, 2005-04-02 at 13:54, Leonard den Ottolander wrote: > > Just discussed this with Roland Illig who came up with a patch that > > seems to work correctly. I further fixed his patch to not need Well, he should have done some testing too. Not just hacking. > > add_dotdot_to_list() anymore by moving the relevant parts to > > set_zero_dir(). > > If either of you commits this, please *remove* the now commented out > parts. We don't need that junk around :) . > > O, and please also commit to PRE. Please, don't commit neither to HEAD nor to PRE. This patch sucks. It actually prevents the user from going to the parent directory for at least the following filesystems: FISH, cpio, tar I guess this is related to the following hunk: @@ -481,7 +492,7 @@ do_load_dir (const char *path, dir_list while ((dp = mc_readdir (dirp))) { status = handle_dirent (list, filter, dp, &st, next_free, &link_to_dir, - &stale_link); + &stale_link, strcmp(path, "/") != 0); if (status == 0) continue; if (status == -1) { Finding that MC will misbehave was relatively easy by just reading the source. It should have been much easier to find out by simply testing. I am seriously starting to worry about the quality of the code. From ptsekov at gmx.net Mon Mar 28 16:51:39 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 28 Mar 2005 19:51:39 +0300 Subject: Parent directory's permissions in mini-status In-Reply-To: <1112531103.4811.3.camel@athlon.localdomain> References: <1112531103.4811.3.camel@athlon.localdomain> Message-ID: http://mail.gnome.org/archives/mc-devel/2002-July/msg00076.html Hello, On Sun, 3 Apr 2005, Leonard den Ottolander wrote: > Hi Pavel, > > On Fri, 2005-03-25 at 15:27, Pavel Tsekov wrote: > > On Thu, 31 Mar 2005, Sergey Ilyevsky wrote: > > > It seems that mc shows wrong permission for parent dir in mini-status, > > > or in long-file (or user-defined) listing mode. > > > Yep - the '..' (parent dir) entry is bogus. If i remember right this was > > made on purpose because if you are using remote vfs (ssh, ftp) it can take > > a long time to stat the parent dir. You can check the mc-devel archives > > for further info. > > Totally missed this post as Sergey misdated his. That makes Roland and > my patch rather redundant. Do you happen to have a pointer to any of the > messages you are referring to? Yep! It seems that I started a thread about this issue back in July, 2002: http://mail.gnome.org/archives/mc-devel/2002-July/msg00076.html But this message sheds more light about the speedup I was talking about: http://mail.gnome.org/archives/mc-devel/2002-June/msg00016.html From ptsekov at gmx.net Mon Mar 28 17:48:19 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 28 Mar 2005 20:48:19 +0300 Subject: Big patch for mcview In-Reply-To: <424D105C.4050009@gmx.de> References: <42260893.9020300@gmx.de> <422E02F8.9040308@gmx.de> <4242AA44.9020903@kmlinux.fjfi.cvut.cz> <424D105C.4050009@gmx.de> Message-ID: Hello, On Fri, 1 Apr 2005, Roland Illig wrote: > Jindrich Makovicka wrote: > > Crashes when switching between viewer modes. To reproduce, use F3 on a > > jpg/mp3/whatever (assuming you have mpg123, ImageMagick or other > > corresponding viewer), press F8 to display raw, then press F4 => sig11. > > I cannot reproduce this. Can you be more specific where mc crashes? (a > backtrace of an mc with CFLAGS=-ggdb would be most helpful) [ptsekov at baba-meca ~]$ gdb /home/ptsekov/mc-test/usr/bin/mc 6379 GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Attaching to program: /home/ptsekov/mc-test/usr/bin/mc, process 6379 Reading symbols from /usr/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/lib/libgmodule-2.0.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/lib/libglib-2.0.so.0 Reading symbols from /usr/lib/libgpm.so.1...done. Loaded symbols for /usr/lib/libgpm.so.1 Reading symbols from /usr/lib/libslang-utf8.so.1...done. Loaded symbols for /usr/lib/libslang-utf8.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/X11R6/lib/libX11.so...done. Loaded symbols for /usr/X11R6/lib/libX11.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so 0x00eb57a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) c Continuing. Detaching after fork from child process 6388. Detaching after fork from child process 6389. Program received signal SIGSEGV, Segmentation fault. 0x080b68ba in mc_read (handle=0, buffer=0x8633219 "", count=7671) at ../../mc/vfs/vfs.c:392 392 MC_HANDLEOP(read, (int handle, char *buffer, int count), (vfs_info (handle), buffer, count) ) (gdb) bt #0 0x080b68ba in mc_read (handle=0, buffer=0x8633219 "", count=7671) at ../../mc/vfs/vfs.c:392 #1 0x080906bc in view_growbuf_read_until (view=0x861d430, ofs=4294967295) at ../../mc/src/view.c:309 #2 0x08092cf0 in get_bottom_first (view=0x861d430, do_not_cache=1, really=1) at ../../mc/src/view.c:1296 #3 0x08094145 in toggle_hex_mode (view=0x861d430) at ../../mc/src/view.c:1930 #4 0x0809a733 in buttonbar_callback (bb=0x8632eb0, msg=5, parm=1004) at ../../mc/src/widget.c:2244 #5 0x0806053a in dlg_try_hotkey (h=0x861d598, d_key=1004) at ../../mc/src/dialog.c:626 #6 0x08060618 in dlg_key_event (h=0x861d598, d_key=1004) at ../../mc/src/dialog.c:664 #7 0x08060946 in dlg_process_event (h=0x861d598, key=1004, event=0xbfef3e50) at ../../mc/src/dialog.c:765 #8 0x08060b40 in frontend_run_dlg (h=0x861d598) at ../../mc/src/dialog.c:797 #9 0x08060a54 in run_dlg (h=0x861d598) at ../../mc/src/dialog.c:812 #10 0x0809583d in view (_command=0x861d5d8 "/bin/sh /tmp/mc-ptsekov/mcextJBI8Ca", _file=0x861d370 "OggPlay-S60-MMF-1.5.1.zip", move_dir_p=0xbfef454c, start_line=0) at ../../mc/src/view.c:2574 #11 0x080638c5 in exec_extension (filename=0x861d370 "OggPlay-S60-MMF-1.5.1.zip", data=0x8631763 "\n\n# zoo\nregex/\\.(zoo|ZOO)$\n\tOpen=%cd %p#uzoo\n\tView=%view{ascii} zoo l %f\n\t\n# lha\ntype/^LHa\\ .*archive\n\tOpen=%cd %p#ulha\n\tView=%view{ascii} lha l %f\n\n# arj\nregex/\\.a(rj|[0-9][0-9])$\n\tOpen=%cd %p#uarj\n\t"..., move_dir=0xbfef454c, start_line=0) at ../../mc/src/ext.c:238 #12 0x0806447a in regex_command (filename=0x861dab0 "OggPlay-S60-MMF-1.5.1.zip", action=0xbfef4500 "View", move_dir=0xbfef454c) at ../../mc/src/ext.c:594 #13 0x08059b02 in view_file_at_line (filename=0x861dab0 "OggPlay-S60-MMF-1.5.1.zip", plain_view=0, internal=1, start_line=0) at ../../mc/src/cmd.c:124 #14 0x08059b8a in view_file (filename=0x861dab0 "OggPlay-S60-MMF-1.5.1.zip", plain_view=0, internal=1) at ../../mc/src/cmd.c:150 #15 0x08059d8c in do_view_cmd (normal=0) at ../../mc/src/cmd.c:208 #16 0x08059dc5 in view_cmd () at ../../mc/src/cmd.c:219 #17 0x0809a733 in buttonbar_callback (bb=0x861ae30, msg=5, parm=1003) at ../../mc/src/widget.c:2244 #18 0x0806053a in dlg_try_hotkey (h=0x8600460, d_key=1003) at ../../mc/src/dialog.c:626 #19 0x08060618 in dlg_key_event (h=0x8600460, d_key=1003) at ../../mc/src/dialog.c:664 #20 0x08060946 in dlg_process_event (h=0x8600460, key=1003, event=0xbfef46a0) at ../../mc/src/dialog.c:765 #21 0x08060b40 in frontend_run_dlg (h=0x8600460) at ../../mc/src/dialog.c:797 #22 0x08060a54 in run_dlg (h=0x8600460) at ../../mc/src/dialog.c:812 #23 0x0807809f in setup_panels_and_run_mc () at ../../mc/src/main.c:1679 #24 0x080782e6 in do_nc () at ../../mc/src/main.c:1753 #25 0x08078c27 in main (argc=1, argv=0xbfef4804) at ../../mc/src/main.c:2254 (gdb) From ptsekov at gmx.net Mon Mar 28 18:48:47 2005 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 28 Mar 2005 21:48:47 +0300 Subject: [PATCH] Re: Parent directory's permissions in mini-status In-Reply-To: References: <1112442861.4803.34.camel@athlon.localdomain> <1112444383.4803.35.camel@athlon.localdomain> Message-ID: Hello, On Mon, 28 Mar 2005, Pavel Tsekov wrote: > I guess this is related to the following hunk: > > @@ -481,7 +492,7 @@ do_load_dir (const char *path, dir_list > while ((dp = mc_readdir (dirp))) { > status = > handle_dirent (list, filter, dp, &st, next_free, &link_to_dir, > - &stale_link); > + &stale_link, strcmp(path, "/") != 0); > if (status == 0) > continue; > if (status == -1) { > > Finding that MC will misbehave was relatively easy by just reading the > source. It should have been much easier to find out by simply testing. Please, disregard this part. The patch doesn't work but that is because some filesystems (like those mentioned in the original message) do not have `.' and `..' entries.