Re: patchfs, audio update
Pavel Roskin wrote:
Hello!
Well, but some quoting (and security) issues fixed in the CVS just now.
Patch attached. BTW, new incarnation reports wrong patch sizes for
gzipped patches.
Just for your information.
Size is not very critical after I disabled fast loading on non-local VFS
in the editor. You can open files with 0 length, e.g. INFO/DESCRIPTION in
rpm archives, and it will show properly. I'm not saying that reporting
the right size is not important, but it's not as important as it was.
Negative file size is illegal for vfs parser. Such entries are skipped.
I haven't analyzed the patchfs code, but if finding the file size needs a
lot of additional work (e.g. uncompressing the patch one more time), it's
better to report 0 and hope that copyout will do the right thing
nevertheless.
copyout is ok.
Adam Byrtek 'alpha' wrote:
On Wed, Dec 18, 2002 at 06:45:42PM -0500, Pavel Roskin wrote:
Sorry, I don't understand why an empty line is not a diff boundary.
It's not valid in diff, as far as I know.
Yes, it is not a valid diff.
Valid diff puts:
' \n' (space and a newline)
But Andrew gave me a link to a www mailing list archive, with a patch
inside pre tags. When one saves such webpage (or pastecopy it) the
space is stripped and it looks like this:
'\n' (only newline)
I think we should treat this as a diff contents even if it isn't
formaly valid.
Well, I resent this letter to Adam, it's valid diff.
Problems starts when you compress this patch by gzip or bzip2.
It seems perl's tell() works incorrect for pipes (I wonder), as far as
lseek() (I don't wonder).
Besides, Andrew has CVS access and uses it very responsibly.
Maybe, but his fix isn't necessary - at least for my system. See:
http://www.rpg-portal.pl/alpha/mc-patchfs.png
Lets wait for Andrew's reaction if you don't trust me.
We trust you, but sometimes you misunderstand us.
I think that @@\n$ should be replaced with @@ in both places.
Tested, works for me. I'm not applying it to avoid conflicts, but
keep it
in mind.
Good stuff. Also I want to replace all '^-{3}' with more readable '^---'.
--
Regards,
Andrew V. Samoilov
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: patchfs, audio update
On Thu, Dec 19, 2002 at 05:40:08PM +0200, Andrew V. Samoilov wrote: We trust you, but sometimes you misunderstand us. Sorry, maybe I used the wrong word once more. I apologize if it sounded that way. But the main problem was that everything works fine for me, so I was confused and did not know what Andrew wanted to fix. I thought maybe it was the 'empty line problem' (which in fact exists) and I've send a patch for this. Regards -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Panel_Mousewheel_Scroll.patch
Trivial Patch #10262:
This patch scrolls one line at at time instead of one page at a time
when spinning the mousewheel.
Does anyone like it or find it useful?
--- mc-cvs-4.6.0-pre1b-021217/src/screen.c Sun Dec 15 22:42:17 2002
+++ mc-draft-4.6.0-pre1b-021217/src/screen.cTue Dec 17 12:31:22 2002
@@ -2261,11 +2261,22 @@ panel_event (Gpm_Event *event, WPanel *p
/* Mouse wheel events */
if ((event-buttons GPM_B_UP) (event-type GPM_DOWN)) {
- prev_page (panel);
+ if ( panel_scroll_pages ) {
+ panel-top_file -= 1;
+ if (panel-top_file 0) panel-top_file = 0;
+ paint_dir (panel);
+}
return MOU_NORMAL;
}
if ((event-buttons GPM_B_DOWN) (event-type GPM_DOWN)) {
- next_page (panel);
+ if ( panel-count ITEMS (panel) panel_scroll_pages ){
+ panel-top_file += 1;
+ if (panel-top_file panel-count - ITEMS (panel))
+ panel-top_file = panel-count - ITEMS (panel);
+ paint_dir (panel);
+}
return MOU_NORMAL;
}
Re: [PATCH] xterm titlebar
Hello! I believe that some versions of xterm may be incompatible. Just check init_xterm_support() in main.c: #if 0 /* It works on xterm, but not on rxvt */ printf (ESC_STR ]0;GNU Midnight Commander\7); #endif That comment is probably outdated. Both the xterm_hintbar and xterm_titlebar features work in my rxvt 2.7.8. That's a development release, though. I don't think that the code would be commented out if it was harmless on older versions of rxvt. I wish I could check the old rxvt, but I don't have time. Please keep in mind that testing usually takes more time than coding. If you don't check the dark corners, somebody will have to do it for you, either now, or when somebody reports a problem a few months later. I tried what happens when the xterm_titlebar feature is used in an mc running in the linux console and it does nothing at all. Which I suppose is good. :) But maybe a check for getenv(DISPLAY) would be appropriate ? Of course not. The comment implies serious problems with rxvt, and you cannot distinguish between rxvt and xterm by checking the DISPLAY variable. Quoting is IMHO cumbersome in this case, a simpler and IMHO acceptable solution would be to remove all characters except some sane ones from the title. Agreed. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
