Re: find in viewer
Any news on it? Or at least please fix the regression, if not add new feature. On Tue, 23 May 2006 15:44:30 +0300 (EEST) Pavel Tsekov [EMAIL PROTECTED] wrote: Hello, On Thu, 18 May 2006, Oswald Buddenhagen wrote: On Thu, May 18, 2006 at 05:42:45PM +0300, Pavel Tsekov wrote: I guess in the long term the last seach string should be remembered onto persistent storage as for example the file positions. yes. How about the following patch ? This is not a final version - I am just posting it to see whether you like the idea. The patch uses the input field's ability to automatically retrieve the last entered text from the history. The last search expression would be loaded in the input field even after you've exited MC and then launch it again - this differs from the old behaviour where the search expression would be lost on MC exit. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
On Thu, 13 Jul 2006, Nerijus Baliunas wrote: Any news on it? Or at least please fix the regression, if not add new feature. Oops. Sorry, I forgot about that. I'll try to commit a fix in the weekend. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
On Thu, 2006-07-13 at 14:08 +0200, Jindrich Novy wrote:
Hi mc-devel,
attaching a simple patch that highlights obsolete RPM tags with white
color so that it helps the spec file editor to be better aware of the
fact they are obsolete for several years and shouldn't be used.
The patch was in the reversed order, attaching the correct one...
Jindrich
--- mc/syntax/spec.syntax.obsolete 2006-06-21 17:22:55.0 +0200
+++ mc/syntax/spec.syntax 2006-07-13 13:59:28.0 +0200
@@ -7,7 +7,7 @@
keyword whole Build\{Rr\}oot: green
keyword whole BuildRequires: green
keyword whole Conflicts: green
-keyword whole Copyright: green
+keyword whole Copyright: white
keyword whole Description: green
keyword whole Distribution: green
keyword whole Doc\{Dd\}ir: green
@@ -30,6 +30,7 @@
keyword whole Release: green
keyword whole Requires: green
keyword whole Root: green
+keyword whole Serial: white
keyword whole Source\[0123456789\]: green
keyword whole Summary: green
keyword whole Summary(\[abcdefghijklmnopqrstuvwxyz\]): green
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Makeing the subshell reliable
Hello, The MC subshell while being a nice feature has been the source of many problems as well. I've been following this list and the MC development for a while and I can tell that the problems caused by the subshell are the hardest to track down and eliminate. Trough the years many fixes were applied and it still remains unreliable and its behaviour is somewhat undefined. This post is inspired by a recent discussion I had with Pavel Shirshov regarding a subshell misbehaviour on FreeBSD. While tracing the problem and trying to find a solution I realized several things: * the subshell behaviour is not clearly defined for that specific case thus fixing the problem would most likely case more undefined behaviour * there is no good way to solve the problem I also realized that the shell is too complicated and it tries to do more things that it really should do. Well, I was aware of this already but I kind of hoped that it just won't hit us. So, I think that instead of spending time in continuosly fixing the subshell we should spent some time in simplifying it and making it rock-solid. There are several features which are consistent source of problems: * the subshell prompt retrieval - this one is widely known to be unreliable. * execution of commands typed at MC's prompt widget trough the subshell My opinion is that we should remove both features from the subshell. Without those features the subshell shall have a single simple task. Interactive command execution when the panels are off. The current directory retrieval remains but it has not been a major source of problems though improvements won't harm. Especially if the directory retrieval could be made independent of the shell type. Please, feel free to share your opinion on this matter. I hope that at the end of this discussion we would have a better subshell. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Update of bug #15461 (project mc): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15461 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
On Thu, 13 Jul 2006, Jindrich Novy wrote: attaching a simple patch that highlights obsolete RPM tags with white color so that it helps the spec file editor to be better aware of the fact they are obsolete for several years and shouldn't be used. The patch was in the reversed order, attaching the correct one... Commited. P.S. what happend to your patch which changed the location of the configuration files to /etc ? Would you mind modifying it as suggested ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
Hi Andy, On Thu, 2006-07-13 at 17:22 +0300, Andy Shevchenko wrote: Jindrich Novy пишет: My $0.02 to specfile highliting. The mc shipped with FC4 doesn't handle correctly the case-insensivity tags. For example, BuildArch and Buildarch are highliting differently, but rpm recognize both. I guess the mainstream also has this issue. Yes, I noticed that and it also needs to be fixed. I'm going to write a patch for it as well. Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
Hi Pavel, On Thu, 2006-07-13 at 17:33 +0300, Pavel Tsekov wrote: On Thu, 13 Jul 2006, Jindrich Novy wrote: attaching a simple patch that highlights obsolete RPM tags with white color so that it helps the spec file editor to be better aware of the fact they are obsolete for several years and shouldn't be used. The patch was in the reversed order, attaching the correct one... Commited. Thanks. P.S. what happend to your patch which changed the location of the configuration files to /etc ? Would you mind modifying it as suggested ? Ah, almost forgot about that one. I need to reread the thread again so that I can modify the patch. Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote: There are several features which are consistent source of problems: My opinion is that we should remove both features from the subshell. * the subshell prompt retrieval - this one is widely known to be unreliable. could you be more precise about that? do you mean the shell's cwd or the actual prompt string? * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other nice file managers. it's just a pity that it does not work in the other direction as well. the only problem i have is mc permanently mis-detecting that the shell is busy, but that is worked around by ctrl-o enter ctrl-o alt-p enter. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, 13 Jul 2006, Oswald Buddenhagen wrote: On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote: There are several features which are consistent source of problems: My opinion is that we should remove both features from the subshell. * the subshell prompt retrieval - this one is widely known to be unreliable. could you be more precise about that? do you mean the shell's cwd or the actual prompt string? The shell prompt string itself. The current implementation is flawed. Some weeks ago I posted a patch witch tries to improve it. The patch would make the things better but still not perfect. At least not until commands typed at the prompt can be executed trough the subshell. If you want me to go into details - I'll do. * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other The prompt widget or the fact that if the subshell is enabled commands are executed trough the subshell ? Don't get me wrong - I want to keep the prompt widget. What I propose is to handle commands typed at it just as if the subshell is disabled. I cannot see how commands typed at the prompt and executed trough the subshell give MC an advantage over the other file managers. Could you elaborate ? nice file managers. it's just a pity that it does not work in the other direction as well. the only problem i have is mc permanently mis-detecting that the shell is busy, but that is worked around by ctrl-o enter ctrl-o alt-p enter. The problem that I was debugging - it was related to this feature. In short: 1) Start MC 2) Type a command that will take some time to execute at MC's prompt: for example - ls -lR / 3) While the command is running hit Enter This causes the following problem: 1) The subshell remains stopped 2) The subshell prompt isn't retrieved properly This happens on FreeBSD consistently but it could happen on other systems too. It is caused by the fact that before the command execution completes the newline character gets to the subshell and it is interpreted normally. This causes two things - first the subshell remains stopped because MC doesn't revive it after the subshell SIGSTOPs itself, and second the prompt gets mixed with the newline character which in turn causes the code which reads the prompt to misbehave. I can explain in further details if it doesn't become very clear (i am a bit tired right now). Thinking about a solution for this problem I realized that there is no way to solve this unless MC could read peoples (the subshell behaviour in this case lacks clear definition). Even if it had I am sure that there would be a group of people who wouldn't be satisfied. The problem described is the result of lack of clear definition of MC's behaviour in this case, different implementations of pty's on different OSes, bad interaction between features and (maybe) programming errors. It's just too complicated. I want to get rid of this complicated behaviour - I have debugged many of the subshell problems and I really want to put and end to it. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, Jul 13, 2006 at 09:58:08PM +0300, Pavel Tsekov wrote: On Thu, 13 Jul 2006, Oswald Buddenhagen wrote: On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote: There are several features which are consistent source of problems: My opinion is that we should remove both features from the subshell. * the subshell prompt retrieval - this one is widely known to be unreliable. could you be more precise about that? do you mean the shell's cwd or the actual prompt string? The shell prompt string itself. ok. maybe it would make sense to implement an own bash-compatible PS1 interpreter. trying to make sense of almost arbitrary program output sort of has to fail. * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other The prompt widget or the fact that if the subshell is enabled commands are executed trough the subshell ? Don't get me wrong - I want to keep the prompt widget. What I propose is to handle commands typed at it just as if the subshell is disabled. I cannot see how commands typed at the prompt and executed trough the subshell give MC an advantage over the other file managers. the fact that i can switch the panels on and off at any time - without losing the command's output. what would be really perfect would be what we had in norton commander, where the nc prompt just pretended to be the shell prompt, giving the possibility to freely toggle the panels while constructing a command, having the same history, etc. - however, emulating a typical unix shell's interactive command set is unrealistic, and embedding the real shell's prompt into the panel view seems outright impossible, esp. given the current problems. the only problem i have is mc permanently mis-detecting that the shell is busy, but that is worked around by ctrl-o enter ctrl-o alt-p enter. The problem that I was debugging - it was related to this feature. In short: [...] yes, i remember that discussion pretty well. it's, indeed, no simple problem. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
