Re: Makeing the subshell reliable
On Thu, 13 Jul 2006, Oswald Buddenhagen wrote: 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. Maybe we can even borrow the code directly from bash (or some other shell) and embed it into MC. * 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. Even without the subshell the command output doesn't get lost - just try it. It is taken care of. 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. Well, a fix was checked in which was supposed to fix the issue - that was almost 4 year ago. Some years laters a variation of the same bug hits again... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Fri, Jul 14, 2006 at 08:11:55AM +0300, Pavel Tsekov wrote: * 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. Even without the subshell the command output doesn't get lost - just try it. It is taken care of. you snipped way too much of my quote. ;-P without the subshell i can't operate mc while the command is executed, i can't use the shell's much better completion, history and line editing, aliases shell functions and whatever cool features a modern unix shell offers, and i can't execute a series of commands without switching off the panels after each command to verify the result (and don't suggest me the pause after run option - it's getting on my nerves very fast). point is, i tried several other managers (mostly shiny kde programs, because they have a much better vfs than mc), and always went back to mc, because the real shell is right at my fingertips and it's sort-of integrated with the panels (even if it's only one-way, but alt-enter, alt-a ctrl-shift-j are priceless). -- 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: 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.
Here's the patch to fix it. Thanks for pointing this out.
Jindrich
--- mc/syntax/spec.syntax.case 2006-07-13 13:59:28.0 +0200
+++ mc/syntax/spec.syntax 2006-07-13 17:02:41.0 +0200
@@ -2,19 +2,19 @@
keyword whole Auto\{Pp\}rov: green
keyword whole Auto\{Rr\}eq\{Pp\}rov: green
keyword whole Auto\{Rr\}eq: green
-keyword whole BuildArch: green
-keyword whole BuildPre\{Rr\}eq: green
+keyword whole Build\{Aa\}rch: green
+keyword whole Build\{Pp\}re\{Rr\}eq: green
keyword whole Build\{Rr\}oot: green
-keyword whole BuildRequires: green
+keyword whole Build\{Rr\}equires: green
keyword whole Conflicts: green
keyword whole Copyright: white
keyword whole Description: green
keyword whole Distribution: green
keyword whole Doc\{Dd\}ir: green
keyword whole Epoch: green
-keyword whole ExcludeArch: green
-keyword whole ExclusiveArch: green
-keyword whole ExclusiveOS: green
+keyword whole Exclude\{Aa\}rch: green
+keyword whole Exclusive\{Aa\}rch: green
+keyword whole Exclusive\{Oo\}\{Ss\}: green
keyword whole Group: green
keyword whole Group(\[abcdefghijklmnopqrstuvwxyz\]): green
keyword whole Group(\[abcdefghijklmnopqrstuvwxyz\]_\[ABCDEFGHIJKLMNOPQRSTUVWXYZ\]): green
@@ -38,8 +38,7 @@
keyword whole Summary(\[abcdefghijklmnopqrstuvwxyz\]_\[ABCDEFGHIJKLMNOPQRSTUVWXYZ\].\[ABCDEFGHIJKLMNOPQRSTUVWXYZ-1234567890\]): green
keyword whole Vendor: green
keyword whole Version: green
-keyword whole URL: green
-keyword whole Url: green
+keyword whole U\{Rr\}\{Ll\}: green
keyword whole linestart %build red
keyword whole linestart %changelog red
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Fri, 14 Jul 2006, Oswald Buddenhagen wrote: On Fri, Jul 14, 2006 at 08:11:55AM +0300, Pavel Tsekov wrote: * 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. Even without the subshell the command output doesn't get lost - just try it. It is taken care of. you snipped way too much of my quote. ;-P without the subshell i can't operate mc while the command is executed, i Ok. But it can be as simple as Ctrl-O, execute command, Ctrl-O. There is only an extra Ctrl-O. can't use the shell's much better completion, history and line editing, The subshell prompt widget doesn't perform these via the subshell. aliases shell functions and whatever cool features a modern unix shell Well yes - but see above. Again Ctrl-O followed by a command should do just fine. offers, and i can't execute a series of commands without switching off I dont understand this. point is, i tried several other managers (mostly shiny kde programs, because they have a much better vfs than mc), and always went back to mc, because the real shell is right at my fingertips and it's sort-of integrated with the panels (even if it's only one-way, but alt-enter, alt-a ctrl-shift-j are priceless). I am not advertising the removal of the subshell . I just want to remove the ability to execute commands typed at MC's prompt widget trough the subshell (if it isn't clear yet). However, if this functionality is to remain we have to define exactly how it is supposed to work and the subshell prompt should definitely go. My opinion is that if we start to impose restrictions on that feature there would alway be a group of confused users since it want behave exactly as they would expect to. But I am open to suggestions. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: obsolete RPM tags highlighting
On Fri, 14 Jul 2006, Jindrich Novy wrote: 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. Here's the patch to fix it. Thanks for pointing this out. Commited. Thanks! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Follow-up Comment #4, bug #15461 (project mc): ? First you commit Jindrich's patch that highlights obsolete tags differently, and now you commit this patch removing these tags?? I think removing these tags from trpm makes sense: trpm is for browsing installed rpms, so I do not expect many people to be affected by this (although even in this case you could leave the highlighting for obsolete tags around. If they are not used they are not highlighted). However, to browse legacy rpms Jindrich's approach to highlight obsolete tags differently makes more sense. ___ 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
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Follow-up Comment #5, bug #15461 (project mc): Sorry for the confusion: Browsing rpms of course has nothing to do with (syntax) highlighting, so please ignore my last paragraph. The fact remains that keeping these obsolete tags around to be able to browse legacy rpms doesn't hurt. (FYI I do maintain legacy RHL 7.3 systems that still feature the Copyright tag.) ___ 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
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. -- With best regards, Andy Shevchenko. mailto: [EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Follow-up Comment #6, bug #15461 (project mc): Well, that was my concern initially but since noone cared to share his opinion I figured that it doesn't really matter so much. If you feel that those tags are indeed needed - please feel free to revert parts of the patch. ___ 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
[bug #15461] vfs/extf for rpm/trpm query obsolete rpm tags
Update of bug #15461 (project mc): Status: Fixed = Postponed ___ Follow-up Comment #7: Ok. I will (revert). (Introduction of EPOCH was indeed overdue.) See also http://mail.gnome.org/archives/mc-devel/2004-August/msg00040.html . The fact that I left in the COPYRIGHT tag was the result of (off list) discussions concluding to leave these legacy keywords around for a while longer. As they hardly consume any resources I'd say we review this issue in a year or 10 ;-p . ___ 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
Hi,
On Fri, 2006-07-14 at 15:33 +0200, Leonard den Ottolander wrote:
Hi,
On Fri, 2006-07-14 at 09:24 +0200, Jindrich Novy wrote:
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.
Here's the patch to fix it. Thanks for pointing this out.
Andy's examples were just that: Examples. A complete patch should allow
any mixing of case for any spec keyword. For _example_:
\{Gg\}\{Rr\}\{Oo\}\{Uu\}\{Pp\}
Just fixing and committing a few arbitrary examples does not makes much
sense imo.
This is a joke, isn't it?
Just imagine a nice spec like this:
SuMmArY: Programs for backing up and restoring ext2/ext3 filesystems
nAMe: dump
veRSioN: 0.4b41
I really think that the highlighting rules for spec should be limited to
some set of commonly used tags. At least the first capital letter should
be mandatory upper-case and some case sensitivity fix-ups should be made
for tags composed from multiple words as Andy pointed out. Otherwise
specs written using mcedit would be a big mess IMO.
Jindrich
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: non ascii file sort
On Thu, 06 Jul 2006 14:35:27 +0300 Andy Shevchenko [EMAIL PROTECTED] wrote: ForestCreature пишет: Hello! I've recently noticed wrong file sort order in file list pannels. I use ru_RU.KOI8-R locale. There is no alphabetic symbol order (what strcmp implies?). Attached patch works for me. This is glibc related issue, not mc. strcoll would have pair case-(in)sensivity functions like strcmp/strcasecmp. In this case it would work on 8bit locales. In unicode locales we still have problem with third (fourth, ...) languages at the same time on FS. I (for example) don't know how to resolve this simple. -- With best regards, Andy Shevchenko. mailto: [EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel Maybe you would like mbtowc() = wcscmp()/wcscasecmp() ? Second function is a GNU ext. It would be easy implemented via towlower(). Should I try to implement it or it's a dirty hack? Thanks ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
