From nerijus at users.sourceforge.net Wed Aug 1 01:01:05 2001 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 1 Aug 2001 03:01:05 +0200 (EET) Subject: segfault when ulimit for file size is set Message-ID: <200108010102.DAA1471849@mail.takas.lt> Hello, ulimit -a shows: file size (blocks) 40000 If I copy file larger than 40 MB, only these 40 MB are copied, and then mc segfaults. cp gives me "File size limit exceeded". Should be easy to reproduce I think. mc version 4.5.54. Regards, Nerijus From despair at sama.ru Wed Aug 1 04:00:05 2001 From: despair at sama.ru (Walery Studennikov) Date: Wed, 1 Aug 2001 09:00:05 +0500 Subject: Copy full filename to command line (Ctrl-F) patch Message-ID: <20010801090005.A12379@localhost.localdomain> Here is slightly purified and adapted to CVS version of MC patch from Max Schedriviy. It allows to copy full filename (with path) by pressing Ctrl-F. It is certainly more quick and convenient than using Alt-A + Ctrl-Enter. Regards, Walery -------------- next part -------------- --- main.c.orig Wed Aug 1 08:43:56 2001 +++ main.c Wed Aug 1 08:53:16 2001 @@ -1574,6 +1574,7 @@ } #endif + #ifndef HAVE_GNOME static void copy_current_pathname (void) { @@ -1645,6 +1646,13 @@ g_free (tmp); } +/* copy filename with full path to command line - mAX */ +void copy_full_prog_name (void) +{ + copy_current_pathname (); + copy_prog_name (); +} + static void copy_tagged (WPanel *panel) { int i; @@ -1817,6 +1825,7 @@ { ESC_CHAR, nothing }, { XCTRL('c'), nothing }, { XCTRL('g'), nothing }, + { XCTRL('f'), copy_full_prog_name }, { 0, 0 }, }; @@ -2007,7 +2016,11 @@ send_message_to (h, (Widget *) cmdline, WIDGET_KEY, id); return MSG_HANDLED; } - + if (id == XCTRL('f')){ + copy_full_prog_name (); + return MSG_HANDLED; + } + if ((!alternate_plus_minus || !(console_flag || xterm_flag)) && !quote && !cpanel->searching) { if(!only_leading_plus_minus) { From proski at gnu.org Wed Aug 1 04:58:49 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 00:58:49 -0400 (EDT) Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: <20010801090005.A12379@localhost.localdomain> Message-ID: On Wed, 1 Aug 2001, Walery Studennikov wrote: > Here is slightly purified and adapted to CVS version of MC patch > from Max Schedriviy. > > It allows to copy full filename (with path) by pressing Ctrl-F. > It is certainly more quick and convenient than using Alt-A + Ctrl-Enter. Please always comment the code if you are sending the patch. Don't expect everybody to understand it. Few questions/remarks: Why are you using copy_full_prog_name() in two places - once in the table and then by calling it explicitly? Cannot we just do it is one place? If not, then I would like to fix the existing code first. Why is copy_full_prog_name() global? It should be static. It's nitpicking, but when I analyze an impact of a change in a global function I have to scan the whole project for possible calls. MC traditionally has symmetric shortcuts for the current and the other panel, like "Atl-a" and "Alt-A" and even "Ctrl-x r" and "Ctrl-x Ctrl-r" (I've never used the later - copy readlink from the other panel). There is no shortcut to copy the filename on the other panel. Shouldn't we have counterparts for Ctrl-Enter and the proposed Ctrl-F to work with the other panel? Where does Ctrl-F come from? It's better that every shortcut is already used somewhere, so that at least some people don't have to re-learn. This patch adds a new user-visible feature. It should be documented. I know that mc.1.in is an unpleasant file to work with, but nobody has converted it to SGML yet. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 05:25:27 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 01:25:27 -0400 (EDT) Subject: segfault when ulimit for file size is set In-Reply-To: <200108010102.DAA1471849@mail.takas.lt> Message-ID: Hi, Nerijus! > ulimit -a shows: > file size (blocks) 40000 > > If I copy file larger than 40 MB, only these 40 MB are copied, and then mc > segfaults. cp gives me "File size limit exceeded". Should be easy to > reproduce I think. mc version 4.5.54. I could reproduce the crash with the current version of MC on RedHat Linux 7.1 with glibc-2.2.2 and kernel 2.4.7-ac2. However, cp also crashes. It comes from fileutils-4.0.36. I think that dumping the core on SIGXFSZ is a bug in glibc since mc never changes the handler for that signal. However, I don't know what POSIX says about the default handler. It should be possible to intersept SIGXFSZ in MC, but I doubt that many users need it. -- Regards, Pavel Roskin From despair at sama.ru Wed Aug 1 05:25:08 2001 From: despair at sama.ru (Walery Studennikov) Date: Wed, 1 Aug 2001 10:25:08 +0500 Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: ; from proski@gnu.org on Wed, Aug 01, 2001 at 12:58:49AM -0400 References: <20010801090005.A12379@localhost.localdomain> Message-ID: <20010801102508.A3149@localhost.localdomain> On Wed, Aug 01, 2001 at 12:58:49AM -0400, Pavel Roskin wrote: > On Wed, 1 Aug 2001, Walery Studennikov wrote: > > > Here is slightly purified and adapted to CVS version of MC patch > > from Max Schedriviy. > > > > It allows to copy full filename (with path) by pressing Ctrl-F. > > It is certainly more quick and convenient than using Alt-A + Ctrl-Enter. > > Please always comment the code if you are sending the patch. Don't expect > everybody to understand it. > > Few questions/remarks: > > Why are you using copy_full_prog_name() in two places - once in the table > and then by calling it explicitly? Cannot we just do it is one place? If > not, then I would like to fix the existing code first. Done. > Why is copy_full_prog_name() global? It should be static. It's > nitpicking, but when I analyze an impact of a change in a global function > I have to scan the whole project for possible calls. Yes, it should be static. The new version of patch is attached. > MC traditionally has symmetric shortcuts for the current and the other > panel, like "Atl-a" and "Alt-A" and even "Ctrl-x r" and "Ctrl-x Ctrl-r" > (I've never used the later - copy readlink from the other panel). There > is no shortcut to copy the filename on the other panel. Shouldn't we have > counterparts for Ctrl-Enter and the proposed Ctrl-F to work with the other > panel? IMHO commands for other panel is not so useful. > Where does Ctrl-F come from? It's better that every shortcut is already > used somewhere, so that at least some people don't have to re-learn. . From the FAR manager. Just the other way about many people having experience with FAR manager expects this functionality. > This patch adds a new user-visible feature. It should be documented. I > know that mc.1.in is an unpleasant file to work with, but nobody has > converted it to SGML yet. mc.1.in.diff is attached. Strage, but I have't found description for Meta-A there. > -- > Regards, > Pavel Roskin Regards, Walery -------------- next part -------------- --- mc.1.in.orig Wed Aug 1 10:13:48 2001 +++ mc.1.in Wed Aug 1 10:14:27 2001 @@ -451,6 +451,9 @@ .B C-Enter. Same a M-Enter, this one only works on the Linux console. .PP +.B C-F. +Copy the currently selected file name with full path to the command line. +.PP .B M-Tab. Does the filename, command, variable, username and hostname .\"LINK2" -------------- next part -------------- --- main.c.orig Wed Aug 1 08:43:56 2001 +++ main.c Wed Aug 1 10:23:52 2001 @@ -1574,6 +1574,7 @@ } #endif + #ifndef HAVE_GNOME static void copy_current_pathname (void) { @@ -1645,6 +1646,13 @@ g_free (tmp); } +/* copy filename with full path to command line - mAX */ +static void copy_full_prog_name (void) +{ + copy_current_pathname (); + copy_prog_name (); +} + static void copy_tagged (WPanel *panel) { int i; @@ -1817,6 +1825,7 @@ { ESC_CHAR, nothing }, { XCTRL('c'), nothing }, { XCTRL('g'), nothing }, + { XCTRL('f'), copy_full_prog_name }, { 0, 0 }, }; @@ -2007,7 +2016,7 @@ send_message_to (h, (Widget *) cmdline, WIDGET_KEY, id); return MSG_HANDLED; } - + if ((!alternate_plus_minus || !(console_flag || xterm_flag)) && !quote && !cpanel->searching) { if(!only_leading_plus_minus) { From hvv at hippo.ru Wed Aug 1 11:21:43 2001 From: hvv at hippo.ru (Vlad Harchev) Date: Wed, 1 Aug 2001 16:21:43 +0500 (SAMST) Subject: Ctrl-Shift-Arrows in mcedit again In-Reply-To: <20010731190941.A18254@localhost.localdomain> Message-ID: On Tue, 31 Jul 2001, Walery Studennikov wrote: Hi, It's very nice that you've found solution for that problem! Could you please send patches to authors of russian keyboard layout tables (and maintainer of that package) so that those tables had correct support for Ctrl-Shift-Arrows? Thanks. Best regards, -Vlad > On Tue, Jul 31, 2001 at 10:09:48PM +0500, Vlad Harchev wrote: > > On Tue, 31 Jul 2001, Walery Studennikov wrote: > > > Does anybody knows how to make work Ctrl-Shift-Arrows > > > in mcedit if it doesn't work? > > > Maybe some terminal setting needs adjusting (which?) > > > or maybe I have broken version of slang and/or ncurses? > > > > > > I have standard LINUX terminal. > > > Distribution: RedHat Linux 7.1 > > > > Hi, > > Did you ever have Ctrl-Shift-Arrows in any version of MC on your RH7.1? > > With 2.4 kernel - no. > > > Already solved. > The problem was in the keymap. > Im my 2.4 kernel with very many standard keymaps > (including ALL russian keymaps) > when you pressing Ctrl-Shift ALL keys are ignored > until you release Ctrl or Shift. > I have solved this adding the following > in my russian keymap: > > keycode 105 = Left > shift keycode 105 = Left > control keycode 105 = Left > shift control keycode 105 = Left > keycode 106 = Right > shift keycode 106 = Right > control keycode 106 = Right > shift control keycode 106 = Right > > > Regards, Walery From despair at sama.ru Wed Aug 1 12:20:08 2001 From: despair at sama.ru (Walery Studennikov) Date: Wed, 1 Aug 2001 17:20:08 +0500 Subject: --with-gpm-mouse problems Message-ID: <20010801172008.A8945@localhost.localdomain> Strange. Now CVS version of MC doesn't support mouse if this is specified with --with-gpm-mouse switch of configure. But it worked a few days ago. Regards, Walery From sxmboer at sci.kun.nl Wed Aug 1 15:02:56 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Wed, 01 Aug 2001 17:02:56 +0200 Subject: Updated mc.hint References: <20010731040502.M135@pervalidus> Message-ID: <3B681A20.1C4476B9@sci.kun.nl> Fr?d?ric L. W. Meunier wrote: > > Steef Boerrigter wrote: > > > I added a dutch translation while I was at it ;-) > > BTW, what about not installing mc.hint and mc.hlp > translations with --disable-nls ? The option --disable-nls doesn't completely disable nls on other occasions as well. On my installation, where nls is in a separate library from the libc, I have to include -lintl in the final linking command to compile mc. From sxmboer at sci.kun.nl Wed Aug 1 15:43:35 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Wed, 01 Aug 2001 17:43:35 +0200 Subject: Updated mc.hint References: Message-ID: <3B6823A7.E29F5754@sci.kun.nl> Hi, Pavel. Thanks for the warning about the too long lines in hint-files. I didn't think it was a problem, since I checked for the 80 column limit in the other languages and found many lines that are too long! I redid the dutch version. > I suggest that we remove the ftp site from the hint files. Another reason > is that we may have MC both in "stable" and "unstable" directories some > day. I think we shouldn't encourage people too much to use unstable releases. It will cause an avalanche of emails from unexperienced users. > Your translation is also too long. Note that other translations use > abbreviations - it not nice, but it's better than if MC strips the end. > 80x25 is still the default that many people use. The other languages should also be checked/changed. I only know english and dutch... new mc.hint.nl: ok mc.hint: ok mc.hint.cs: 1 line too long (is only a period) mc.hint.es: ok mc.hint.it: 1 line too long (is only a period) mc.hint.pl: 2 lines too long mc.hint.ru: 4 lines too long Steef -------------- next part -------------- diff -uN mc-4.5.54/lib/mc.hint mc-4.5.54a/lib/mc.hint --- mc-4.5.54/lib/mc.hint Sat May 19 04:44:48 2001 +++ mc-4.5.54a/lib/mc.hint Wed Aug 1 17:36:00 2001 @@ -1,4 +1,4 @@ -Midnight Commander (c) 1995-1997 The Free Software Foundation +Midnight Commander (c) 1995-2001 The Free Software Foundation Hint: Use C-x t to copy tagged file names to the command line. Hint: Use C-x p to copy the current pathname to the command line. Hint: Completion: use M-Tab (or Esc+Tab). Type it twice to get a list. @@ -8,7 +8,7 @@ Hint: Selecting directories: add a slash to the end of the matching pattern. Hint: If your terminal lacks functions keys, use the ESC+number sequence. Hint: There is a Midnight Commander URL: http://www.gnome.org/mc/ -Hint: The latest version of the Commander is in: ftp://ftp.gnome.org/pub/GNOME/sources/mc +Hint: The latest version of mc: ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ Hint: Please send any bug reports to mc-devel at gnome.org Hint: Midnight Commander home site: http://www.gnome.org/mc Hint: Tab changes your current panel. diff -uN mc-4.5.54/lib/mc.hint.nl mc-4.5.54a/lib/mc.hint.nl --- mc-4.5.54/lib/mc.hint.nl +++ mc-4.5.54a/lib/mc.hint.nl Wed Aug 1 17:29:07 2001 @@ -0,0 +1,49 @@ +Midnight Commander (c) 1995-2001 The Free Software Foundation +Hint: C-x t zet de geselecteerde filenamen in de commando lijn. +Hint: Gebruik C-x p om de huidige padnaam naar de commando lijn te kopieren. +Hint: Completeren: gebruik M-Tab (of Esc+Tab). Herhaal voor een lijst. +Hint: Gebruik M-p en M-n voor de commando lijn historie. +Hint: Een character quoten? Gebruik Control-q en dan het character. +Hint: Moe van deze hints? Zet ze uit in het Opties/Vormgeving menu. +Hint: Directories selecteren: zet een slash aan het eind van het zoekpatroon. +Hint: Als je terminal geen functietoetsen ondersteunt, gebruik dan ESC+nummer. +Hint: Er is een Midnight Commander URL: http://www.gnome.org/mc/ +Hint: De laatste versie van mc: ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ +Hint: Stuur bug rapporten naar mc-devel at gnome.org +Hint: Midnight Commander home page: http://www.gnome.org/mc +Hint: Tab verandert huidig paneel. +Hint: VFS coolheid: druk op enter op een tar file om zijn inhoud te onderzoeken. +Hint: We hebben ook een aardige handleiding. +Hint: Wil je lynx-achtige navigatie? Stel het in in de Configuratie dialoog. +Hint: % macros werken zelf op de commando lijn. +Hint: Met M-! kun je programmas draaien en de uitvoer in de viewer bekijken. +Hint: Het bestandslijst formaat kan aangepast worden; doe "man mc" voor details. +Hint: %D/%T expandeert naar de geselcterde bestanden in de andere directory. +Hint: Wil je een gewone shell? Druk C-o, en ga terug naar MC met nogmaals C-o. +Hint: De CDPATH variabele kan je een hoop typewerk met cd commandos besparen. +Hint: Als je .* bestanden wilt zien, stel dat dan in in het Configuratie scherm. +Hint: Wil je *~ backup bestanden zien? Ga naar het Configuratie scherm. +Hint: Heb je genoeg RAM/Virtueel RAM? Zet de tar VFS geheugenlimiet dan op -1. +Hint: Completering met M-Tab werkt op alle invoer regels in alle dialogen. +Hint: Op trage terminals zou de -s vlag weleens kunnen helpen. +Hint: Vind bestanden: gebruik de gevonden bestanden met de Extern Venster optie. +Hint: Wil je complexe zoekopdrachten? Gebruik het Externe Venster commando. +Hint: M-c (snelle cd) is om middenin een commando van directorie te wisselen. +NB: Shell commandos werken niet in niet-locale bestandssystemen. +Hint: Laat tekst herleven met C-y. +Hint: Werken sommige toetsen niet? Kijk naar Opties/Leer toetsen. +Hint: Om naar de uitvoer van een commando in d viewer te kijken, drukke men M-! +Hint: F13 (of Shift-F3) roept de viewer aan in ruwe modus. +Hint: Werken toetsen in xterms niet? Gebruik onze xterm.ad, .ti en .tcap! +Hint: Je kunt een editor onder F4 specificeren met de shell variabele EDITOR. +Hint: Je kunt een externe viewer specificeren met de shell variabele PAGER. +Hint: Je kunt alle aanvragen voor bevestiging instellen in Opties/Bevestiging. +Hint: Spring naar veel gebruikte directories in een keer met C-\. +Hint: Je kunt anonieme FTP draaien met mc door middel van 'cd /#ftp:machine.edu' +Hint: FTP is in de Midnight Commander gebouwd, check het Bestand/FTP link menu. +Hint: M-t verandert snel van lijst modus. +Hint: Geef als volgt je gebruikersnaam op met ftps: 'cd /#ftp:naam at machine.edu' +Hint: Je kunt RPM bestanden bekijken door er op te enteren. +Hint: Om directories toe te voegen aan de selectie, moet je een slash toevoegen. +Hint: Voor de normale cut and paste muisfuncties moet je de shift key inhouden. +Hint: Voer frequent bezochte ftp sites toe aan je hotlist: type C-\. From proski at gnu.org Wed Aug 1 16:22:44 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 12:22:44 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B681A20.1C4476B9@sci.kun.nl> Message-ID: Hi, Steef! > The option --disable-nls doesn't completely disable nls on other > occasions as well. On my installation, where nls is in a separate > library from the libc, I have to include -lintl in the final linking > command to compile mc. You should not have to to anything by hand. Autoconf should be able to do it for you. It's a big problem that some users don't know what the software is supposed to do and blame themselves and their installations. Please give me more details about your system (OS, libc, gettext) and the MC version (I hope it's the one from CVS, but it's better that you state it expicitly instead or relying on others guessing it). Also please quote the error message. I tried --disable-nls on RedHat 7.1 with gettext-0.10.39 and the CVS version of MC and it worked fine. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 17:07:48 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 13:07:48 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B6823A7.E29F5754@sci.kun.nl> Message-ID: Hi, Steef! > I redid the dutch version. I've applied it. Thank you. > > I suggest that we remove the ftp site from the hint files. Another reason > > is that we may have MC both in "stable" and "unstable" directories some > > day. > I think we shouldn't encourage people too much to use unstable releases. > It will cause an avalanche of emails from unexperienced users. No, the point was to avoid any variable data (such as download locations) in the translatable text if it's translated without assistance of gettext. Otherwise you may find yourself editing e.g. Chinese text to update that data. > mc.hint.ru: 4 lines too long I have fixed it. It's funny that the original translator interpreted "ESC+number sequence" as "ESC+(number sequence)", instead of the assumed "(ESC+number) sequence" :-) -- Regards, Pavel Roskin From sxmboer at sci.kun.nl Wed Aug 1 17:05:26 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Wed, 01 Aug 2001 19:05:26 +0200 Subject: Updated mc.hint References: Message-ID: <3B6836D6.1471FC40@sci.kun.nl> Hi Pavel, > You should not have to to anything by hand. Autoconf should be able to do > it for you. hmm, ok, if you say so..... > Please give me more details about your system (OS, libc, gettext) and the > MC version (I hope it's the one from CVS, but it's better that you state > it expicitly instead or relying on others guessing it). Also please quote > the error message. Ok, here goes: MC from CVS: 29 July rev.14 Platform: Silicon Graphics Indy workstation OS: Irix 6.2 libc: standard Irix c libraries: libc.so.1 (note that that version number does not relate to the GNU libc version!) gettext: 0.10.35 The exact error message is at the bottom of this mail. I think the only important bit is this: ld: ERROR 33: Unresolved text symbol "gettext" -- 1st referenced by dir.o. ld: ERROR 33: Unresolved text symbol "bindtextdomain" -- 1st referenced by main.o. ld: ERROR 33: Unresolved text symbol "textdomain" -- 1st referenced by main.o. These missing functions are in /usr/local/lib/libintl.a which was produced by gettext 0.10.35 > I tried --disable-nls on RedHat 7.1 with gettext-0.10.39 and the CVS > version of MC and it worked fine. !!!!! But I was wondering. Should gettext be used at all with the --disable-nls? I would guess that gettext is only necessary for NLS. Or am I mistaking? !!!!! Steef. ld: WARNING 84: /usr/lib/libsun.a is not used for resolving any symbol. ld: WARNING 84: /usr/lib/libgen.so is not used for resolving any symbol. ld: WARNING 85: definition of attrset in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 85: definition of getch in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 85: definition of hline in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 85: definition of vline in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 85: definition of has_colors in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 85: definition of init_pair in slint.o preempts that definition in /usr/lib/libcurses.so. ld: WARNING 84: /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/libgcc.a is not used for resolving any symbol. ld: WARNING 85: definition of _ffs in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of ffs in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_create in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _clnt_create_vers in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_create_vers in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_sperror in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_perror in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_sperrno in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_perrno in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _clnt_perrno in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_spcreateerror in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_pcreateerror in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clntraw_create in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _clntraw_create in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 85: definition of _callrpc in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of callrpc in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnttcp_create in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clntudp_bufcreate in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clntudp_create in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of netname2user in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _netname2user in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of netname2host in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _netname2host in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of getnetname in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _getnetname in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of user2netname in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of host2netname in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of pmap_set in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of pmap_unset in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of pmap_getmaps in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _pmap_getmaps in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of pmap_getport in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of xdr_pmap in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of xdr_pmaplist in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of pmap_rmtcall in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _pmap_rmtcall in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of xdr_rmtcall_args in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of xdr_rmtcallres in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 85: definition of _clnt_broadcast in /usr/lib/libnsl.so preempts that definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of clnt_broadcast in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: WARNING 134: weak definition of xdr_callmsg in /usr/lib/libnsl.so preempts that weak definition in /usr/lib/libc.so. ld: Giving up after printing 50 warnings. Use -wall to print all warnings. ld: ERROR 33: Unresolved text symbol "gettext" -- 1st referenced by dir.o. ld: ERROR 33: Unresolved text symbol "bindtextdomain" -- 1st referenced by main.o. ld: ERROR 33: Unresolved text symbol "textdomain" -- 1st referenced by main.o. ld: INFO 60: Output file removed because of error. make[2]: *** [mc] Error 1 make[2]: Leaving directory `/usr/people/sxmboer/mc-4.5.54a/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/people/sxmboer/mc-4.5.54a' make: *** [all] Error 2 Exit 2 From proski at gnu.org Wed Aug 1 18:35:13 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 14:35:13 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B6836D6.1471FC40@sci.kun.nl> Message-ID: My only idea is that you should run "make clean" before > ld: ERROR 33: Unresolved text symbol "bindtextdomain" -- 1st referenced > by main.o. My first idea is that you should run "make clean" before recompiling. You should always do it after you reconfigure the source. It is doesn't help please apply this patch to i18n.h, then remove main.o, run make and show me the result. ---------------------------------- --- i18n.h +++ i18n.h @@ -22,6 +22,7 @@ # define dgettext(Domain,Message) (Message) # define dcgettext(Domain,Message,Type) (Message) # define bindtextdomain(Domain,Directory) (Domain) +#error 1 # define _(String) (String) # define N_(String) (String) # endif ---------------------------------- > But I was wondering. Should gettext be used at all with the > --disable-nls? > I would guess that gettext is only necessary for NLS. Or am I mistaking? You are right. I was just showing you an example that reporting extra data doesn't hurt if you are not sure whether this data is relevant or not. It's better to add extra info than to send e-mails back and forth. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 19:03:07 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 15:03:07 -0400 (EDT) Subject: --with-gpm-mouse problems In-Reply-To: <20010801172008.A8945@localhost.localdomain> Message-ID: Hi, Walery! > Strange. Now CVS version of MC doesn't support mouse > if this is specified with --with-gpm-mouse switch of configure. > But it worked a few days ago. Please give the details. You are saving your time by not posting the details that you already know, while other people spend their time guessing those details. My suspicion is that you have recently upgraged your Linux kernel or you have replaced your mouse or you have switched to using devfs. Try mc-4.5.54. What does "mc -V" show? Does it say that the Linux console is supported? Actually, did the mouse stop working on the console or on xterm as well? Another advice. When reporting _strange_ things, the version of your compiler can be very helpful. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 20:17:49 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 16:17:49 -0400 (EDT) Subject: --with-gpm-mouse problems In-Reply-To: Message-ID: Hi, Walery! I could reprodice your problem on Linux 2.4.7-ac3 with devfs (devfsd-2.4.3-12 from RedHat 7.1) There are two problems: 1) /dev/gpmctl should be readable and writeable by users. It is not. 2) libgpm wants the tty to be in the form "/dev/ttyN" and doesn't understand "/dev/vc/N" Here's the patch against gpm-1.19.3. I don't guarantee that it's secure. -------------------------------- --- gpm.c +++ gpm.c @@ -1029,7 +1029,7 @@ int main(int argc, char **argv) maxfd=max(maxfd,ctlfd); /* only allow the console user to access. */ - chmod(GPM_NODE_CTL,0700); + chmod(GPM_NODE_CTL,0777); /*....................................... get screen dimensions */ --- liblow.c +++ liblow.c @@ -235,7 +235,7 @@ int Gpm_Open(Gpm_Connect *conn, int flag if (!t && isatty(2)) t = ttyname(2); /* stderr */ if (!t) goto err; strcpy(tty,t); - if (strncmp(tty,"/dev/tty",8) || !isdigit(tty[8])) + if ((strncmp(tty,"/dev/tty",8) && strncmp(tty,"/dev/vc/",8)) || !isdigit(tty[8])) goto err; conn->vc=atoi(tty+8); } -------------------------------- The problem is not in MC. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 20:32:23 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 16:32:23 -0400 (EDT) Subject: --with-gpm-mouse problems In-Reply-To: Message-ID: > Here's the patch against gpm-1.19.3. I don't guarantee that it's secure. Sorry, it's a patch against gpm-1.19.3 patched by RedHat. > - chmod(GPM_NODE_CTL,0700); > + chmod(GPM_NODE_CTL,0777); This part is not needed in the official gpm. This part comes from gpm-1.19.1-secenhance.patch If we want to use gpm on RedHat it may be needed to add another suid wrapper, like cons.saver. But I don't think using suid wrappers in applications is a good idea. I you are not allowed to read mouse events, then don't read them. The same applies to cons.saver and the console contents. > - if (strncmp(tty,"/dev/tty",8) || !isdigit(tty[8])) > + if ((strncmp(tty,"/dev/tty",8) && strncmp(tty,"/dev/vc/",8)) || !isdigit(tty[8])) This still applies, but checking major and minor numbers would be a better idea than checking the names. It's not the only place where /dev/tty is hardcoded. I have no time to make a complete patch for gpm. My priority is to release MC as soon as possible. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 1 21:56:51 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 1 Aug 2001 17:56:51 -0400 (EDT) Subject: Fix for another dala loss bug Message-ID: Hello! "Safe save" and "Do backups" don't work on the remote VFS. Fixing it properly is quite hard, because it requires on implementation of rename() on VFS. Editing files on VFS with those options on can cause loss of data. Such bugs should have a very high priority for us. I also replaced a tempnam() call with a call to mc_mkstemps(), so that the last annoying linker warning on GNU/Linux is going away. ChangeLog: * editcmd.c (edit_save_file): Temporarily disable safe save and backups on remote VFS because it doesn't work. Use mc_mkstemps() instead of tempnam(). --------------------------------------------- --- editcmd.c +++ editcmd.c @@ -261,15 +261,27 @@ int edit_save_file (WEdit * edit, const savename = (char *) strdup ((char *) filename); - if ((fd = open (savename, O_WRONLY)) == -1) { - this_save_mode = 0; /* the file does not exists yet, so no safe save or backup necessary */ + if (vfs_file_is_local (filename)) { + if ((fd = open (savename, O_WRONLY)) == -1) { + /* + * The file does not exists yet, so no safe save or + * backup are necessary. + */ + this_save_mode = 0; + } else { + close (fd); + this_save_mode = option_save_mode; + } } else { - close (fd); - this_save_mode = option_save_mode; + /* + * FIXME - rename is not impemented in VFS, so only + * quick save is possible. + */ + this_save_mode = 0; } if (this_save_mode > 0) { - char *savedir, *slashpos; + char *savedir, *slashpos, *saveprefix; savedir = (char *) strdup ("."); slashpos = strrchr (filename, '/'); if (slashpos) { @@ -279,10 +291,17 @@ int edit_save_file (WEdit * edit, const } if (savename) free (savename); - savename = (char *) tempnam (savedir, "cooledit"); + saveprefix = concat_dir_and_file (savedir, "cooledit"); + fd = mc_mkstemps(&savename, saveprefix, NULL); + g_free (saveprefix); free (savedir); if (!savename) return 0; + /* + * Close for now because it needs to be reopened by + * VFS-aware mc_open() and MY_O_TEXT should be used. + */ + close (fd); } if ((fd = open (savename, O_CREAT | O_WRONLY | O_TRUNC | MY_O_TEXT, --------------------------------------------- -- Regards, Pavel Roskin From polyama at yahoo.com Thu Aug 2 00:04:26 2001 From: polyama at yahoo.com (Maksym Polyakov) Date: Wed, 01 Aug 2001 19:04:26 -0500 Subject: Updated mc.hint References: <3B6823A7.E29F5754@sci.kun.nl> Message-ID: <3B68990A.94E7326D@yahoo.com> Here is Ukrainian version of mc.hint. -- Best regards, Maksym Polyakov -------------- next part -------------- Midnight Commander (c) 1995-2001, Free Software Foundation. ??????: ???????????? C-x t ??? ?????????? ?????????? ?????? ? ????????? ?????. ??????: ???????????? C-x p ??? ?????????? ????????? ????? ? ????????? ?????. ??????: ??????????????: M-Tab (Esc+Tab). ??? ????????? ?????? ????????? ?????. ??????: ???????????? M-p ? M-n ??? ??????? ?? ??????? ??????. ??????: ???????? ???????? ???????? ????????? Control-q ?? ???????. ??????: ???????? ?? ??????? ?????????? ?? ? ???? Options|Layout. ??????: ???????? ?????????: ??????? ?????? ????? ? ?????? ???????????? ???????. ??????: ???? ?????? ????????? ?????? ?????. ??????, ?????????????? ESC+?????. ??????: ???? Midnight Commander ? ?????????: http://www.gnome.org/mc ??????: ??????? ?????? MC: ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc ??????: ???? ?????, ????? ???????????? ??? ??????? ?? mc-devel at gnome.org ??????: ??????? ???????? Midnight Commander: http://www.gnome.org/mc ??????: Tab ?????? ??????? ??????. ??????: ????????? ???: ????????? Enter ?? ????? TAR ??? ????????? ???? ??????. ??????: ? ??? ????? ? ???????? ???????? ??????????. ??????: ?? ?????? ????????? ? ????? lynx? ?????????? ?? ? Options|Configuration. ??????: ??????? % ???????? ?????? ? ?????????? ?????. ??????: M-! ????????? ???????? ???????? ? ?????? ????????? ? ????? ?????????. ??????: ?????? ?????? ?????? ???? ???? ????????; ???????? "man mc" ??? ???????. ??????: %D/%T ??????? ????????? ????? ?? ??????????? ??????. ??????: ??????? ????????? shell? ????????? C-o, ? ????? C-o ??? ?????????? ? ??. ??????: ??????????? ?????? CDPATH, ?? ????????? ??????? ??? ?????? ??????? cd. ??????: ??? ?????? ????????? ????? .*, ?????????? ????? ? Options|Configuration. ??????: ??? ?????? ???????? ????? .*~, ?????????? ????? ? Options|Configuration. ??????: ????? ?????? RAM/????.RAM? ?????????? ????????? ???'??? ??? tar ? -1. ??????: ?????????????? ?????? ? ???? ?????? ????????. ?????? ????????? M-Tab. ??????: ?? ????????? ?????????? ???? ????????? ????? -s. ??????: ????? ?????: ??? ????????? ?? ?????????? ???????, ????????? Panelize. ??????: ??????? ???????? ???????? ?????? ????????????? Extermal Panelize. ??????: ??? ????? ???????? ??? ??? ?????? ???????, ????????? M-c (?????? ?????). ??????: ??????? shell ?? ???????????, ???? ?? ?? ? ????????? ???????? ???????. ??????: ????????? ????? ????? ????????? ?? ????????? C-u. ??????: ????? ??????? ?? ????????? ????????????? ???? Options|Learn keys. ??????: ??? ????????? ?????????? ??????? ? ????? ?????????, ???????? M-! ??????: F13 (??? Shift-F3) ?????????? ?????????? ? ?????? ???????????? ?????. ??????: ?? ???????? ??????? ? xterm? ????????? ???? ????? xterm.ad,.ti ? .tcap. ??????: ?? ?????? ??????? ???????? ??? F4 ?? ????????? ??????? ???????? EDITOR. ??????: ????????? ?????????? ????? ??????? ?? ????????? ??????? ???????? PAGER. ??????: ?? ?????? ????????? ?????? ?? ????????????? ? Options|Confirmation. ??????: ?????????? ?? ????? ???????????????? ????????? ???????? C-\. ??????: ????????? FTP ????? ???????? ? mc ???????? 'cd /#ftp:machine.edu' ??????: FTP ?????????? ? Midnight Commander, ???? ??????/FTP-?'???????. ??????: M-t ?????? ?????? ?????? ?????? ??????. ??????: ?? ?????? ?????? ??'? ??????????? ftpfs: 'cd /#ftp:user at machine.edu'. ??????: ????? RPM ????? ??????????? ?????????? Enter ?? ????? RPM. ??????: ??? ???????? ????????? ? ??????????? ????? ??????, ??????? ?????? ?????. ??????: ??? ????????? ? ??????? ?? ????????? ???? ???????? ??????? Shift. ??????: ?????????? ????? ??????????? FTP ? ?????? ?????????: ????????? C-\. From proski at gnu.org Thu Aug 2 14:34:50 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 2 Aug 2001 10:34:50 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B68990A.94E7326D@yahoo.com> Message-ID: On Wed, 1 Aug 2001, Maksym Polyakov wrote: > Here is Ukrainian version of mc.hint. Applied. Thank you! -- Regards, Pavel Roskin From sxmboer at sci.kun.nl Thu Aug 2 16:43:20 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Thu, 02 Aug 2001 18:43:20 +0200 Subject: Updated mc.hint References: Message-ID: <3B698328.FD76C55B@sci.kun.nl> Hi Pavel, > My only idea is that you should run "make clean" before Right! I forgot that. mc compiles&runs fine. However, after ./configure --disable-nls make I get: vstofchem18[115]~/mc-4.5.54a>./gnome/plain-gmc 5135:./gnome/plain-gmc: rld: Fatal Error: attempted access to unresolvable symbol in /usr/local/lib/libgnome.so.33: bindtextdomain Exit 1 I guess a similar problem is at hand here. Should there also be a i18n.h in gnome? Other spurious warnings I get (in order of appearance): I don't know which errors are caused by the old age of my gcc (2.7.2) and glib (libglib-1.2.so.1.6a) nd gnome (libgnome.so.33.11) and which are truly caused by the IRIX platform. The only thing that really worry me are the "statement with no effect" warnings Remember, I'm the guy with the IRIX 6.2 workstation. using recent CVS version. direntry.c: In function `vfs_s_dump': direntry.c:1013: warning: int format, long int arg (arg 4) screen.c: In function `string_file_perm_octal': screen.c:312: warning: unsigned int format, mode_t arg (arg 4) screen.c: In function `string_file_nlinks': screen.c:322: warning: int format, long int arg (arg 4) screen.c: In function `string_file_nuid': screen.c:342: warning: int format, uid_t arg (arg 4) screen.c: In function `string_file_ngid': screen.c:352: warning: int format, gid_t arg (arg 4) In file included from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/limits.h:112, from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/syslimits.h:7, from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/limits.h:11, from /usr/local/lib/glib/include/glibconfig.h:13, from /usr/local/include/glib.h:66, from global.h:6, from file.c:84: /usr/include/limits.h:185: warning: `RE_DUP_MAX' redefined eregex.h:212: warning: this is the location of the previous definition subshell.c: In function `init_subshell': subshell.c:438: warning: int format, pid_t arg (arg 4) subshell.c: In function `exit_subshell': subshell.c:782: warning: int format, pid_t arg (arg 4) main.c: In function `OS_Setup': main.c:2389: warning: int format, pid_t arg (arg 4) main.c: In function `main': main.c:2974: warning: statement with no effect main.c:2975: warning: statement with no effect learn.c: In function `init_learn': learn.c:235: warning: unused variable `i18n_flag' In file included from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/limits.h:112, from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/syslimits.h:7, from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2/include/limits.h:11, from /usr/local/lib/glib/include/glibconfig.h:13, from /usr/local/include/glib.h:66, from global.h:6, from filegui.c:86: /usr/include/limits.h:185: warning: `RE_DUP_MAX' redefined eregex.h:212: warning: this is the location of the previous definition filegui.c: In function `fmd_init_i18n': filegui.c:817: warning: unused variable `len' filegui.c:816: warning: unused variable `i' gcc -c -I.. -I.. -I../slang -I../vfs -I../slang -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/local/include -DNEED_GNOMESUPPORT_H -I/usr/local/lib/gnome-libs/include -I/usr/local/lib/glib/include -I.. -DHAVE_CONFIG_H -g -O2 -Wall -DHAVE_X -DHAVE_GNOME -DGTK edit.c In file included from ../src/fs.h:10, from ../src/util.h:52, from edit.h:170, from edit.c:33: /usr/include/sys/param.h:348: warning: `MIN' redefined /usr/local/include/glib.h:126: warning: this is the location of the previous definition /usr/include/sys/param.h:349: warning: `MAX' redefined /usr/local/include/glib.h:123: warning: this is the location of the previous definition gcc -c -I.. -I.. -I../slang -I../vfs -I../slang -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/local/include -DNEED_GNOMESUPPORT_H -I/usr/local/lib/gnome-libs/include -I/usr/local/lib/glib/include -I.. -DHAVE_CONFIG_H -g -O2 -Wall -DHAVE_X -DHAVE_GNOME -DGTK editcmd.c In file included from ../src/fs.h:10, from ../src/util.h:52, from edit.h:170, from editcmd.c:34: /usr/include/sys/param.h:348: warning: `MIN' redefined /usr/local/include/glib.h:126: warning: this is the location of the previous definition /usr/include/sys/param.h:349: warning: `MAX' redefined /usr/local/include/glib.h:123: warning: this is the location of the previous definition editcmd.c:1408: warning: `B_ENTER' redefined ../src/dlg.h:20: warning: this is the location of the previous definition editcmd.c:1412: warning: `B_CANCEL' redefined ../src/dlg.h:19: warning: this is the location of the previous definition gcc -c -I.. -I.. -I../slang -I../vfs -I../slang -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/local/include -DNEED_GNOMESUPPORT_H -I/usr/local/lib/gnome-libs/include -I/usr/local/lib/glib/include -I.. -DHAVE_CONFIG_H -g -O2 -Wall -DHAVE_X -DHAVE_GNOME -DGTK editdraw.c In file included from ../src/fs.h:10, from ../src/util.h:52, from edit.h:170, from editdraw.c:26: /usr/include/sys/param.h:348: warning: `MIN' redefined /usr/local/include/glib.h:126: warning: this is the location of the previous definition /usr/include/sys/param.h:349: warning: `MAX' redefined /usr/local/include/glib.h:123: warning: this is the location of the previous definition MIN/MAX happens a lot more screen.c: In function `string_file_perm_octal': screen.c:312: warning: unsigned int format, mode_t arg (arg 4) screen.c: In function `string_file_nlinks': screen.c:322: warning: int format, long int arg (arg 4) screen.c: In function `string_file_nuid': screen.c:342: warning: int format, uid_t arg (arg 4) screen.c: In function `string_file_ngid': screen.c:352: warning: int format, gid_t arg (arg 4) /usr/include/limits.h:185: warning: `RE_DUP_MAX' redefined gmc-chargrid.c: In function `gmc_char_grid_set_font': gmc-chargrid.c:523: warning: passing arg 1 of `gdk_fontset_load' discards `const' from pointer target type gnome-file-property-dialog.c: In function `perm_group_new': gnome-file-property-dialog.c:909: warning: int format, gid_t arg (arg 4) gview.c: In function `gview_quit': gview.c:253: warning: implicit declaration of function `view_ok_to_quit' ./magicdev.idl:3: Warning: `reread_config' underscores within identifiers are discouraged for use with C-language IDL mappings main.c: In function `OS_Setup': main.c:2389: warning: int format, pid_t arg (arg 4) main.c: In function `main': main.c:2974: warning: statement with no effect main.c:2975: warning: statement with no effect cc1: warning: `-g' not supported by this configuration of GCC main.c: In function `OS_Setup': main.c:2389: warning: int format, pid_t arg (arg 4) main.c: In function `main': main.c:2974: warning: statement with no effect main.c:2975: warning: statement with no effect orbit-idl `gnome-config --cflags idl` ./../idl/FileManager.idl magicdev-stubs.c: In function `GNOME_MagicDev_is_running': magicdev-stubs.c:95: warning: `_ORBIT_retval' might be used uninitialized in this function FileManager-stubs.c: In function `GNOME_FileManager_WindowFactory__get_the_desktop': FileManager-stubs.c:327: warning: `_ORBIT_retval' might be used uninitialized in this function FileManager-stubs.c: In function `GNOME_FileManager_WindowFactory_create_window': FileManager-stubs.c:416: warning: `_ORBIT_retval' might be used uninitialized in this function FileManager-stubs.c: In function `GNOME_FileManager_WindowFactory_get_windows_by_directory': FileManager-stubs.c:681: warning: `_ORBIT_retval' might be used uninitialized in this function gmc-client.c: In function `main': gmc-client.c:231: warning: statement with no effect gmc-client.c:232: warning: statement with no effect From proski at gnu.org Fri Aug 3 03:08:33 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 2 Aug 2001 23:08:33 -0400 (EDT) Subject: mc: new translation In-Reply-To: Message-ID: Hello! > I've committed mc.hint.zh_TW.Big5 into mc CVS, will that cause any > problem? I'm sorry that I'm moving the discussion to the mailing list without your prior consent. I believe you would not object if I asked you, but I have no time to send messages back and forth. In general, I reserve the right to forward any messages concerning exclusively software projects to the appropriate mailing lists unless otherwise requested. There are several important points to be made in this message, and I have no time to write the same things privately over and over again. It's not a matter between me and you - it's a public project. You have indeed caused a problem by adding a space after the backslash in lib/Makefile.in. The current CVS version doesn't compile because of that. I'm committing the fix now. Internationalization teams are welcome to edit translations to their languages, but makefiles are not translations. You should at least test your changes or, preferrably (and _always_ if you cannot test!), ask the developers in the list to make those changes for you. Next thing, also about testing. Have you been able to make MC show hints in Chinese? If not, there is no point in applying that file. Hints are only used in the text edition. I believe that there are modifications of xterm capable of displaying chinese texts, but I don't know whether MC can run on such terminals and whether the hints can be displayed correctly in that setup. You have included the charset name in the name of the hint file. If anybody sets "LANG=zh_TW" in the environment, the hints file won't be loaded, even though zh_TW assumes the Big5 charset. If you named the file mc.hint.zh_TW but the user had LANG=zh_TW.Big5 in the environment it would be easier to fix by probing 5 first characters of LANG (or LC_MESSAGES) after probing the whole name and before resorting to the 2-character language code. Doing the opposite (guessing zh_TW.Big5 from zh_TW) in the MC code would be much harder to implement - it would require some _knowledge_ about preferred encodings in different countries. See function load_mc_home_file in src/util.c for details. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 3 04:57:27 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 3 Aug 2001 00:57:27 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B698328.FD76C55B@sci.kun.nl> Message-ID: Hi, Steef! > vstofchem18[115]~/mc-4.5.54a>./gnome/plain-gmc > 5135:./gnome/plain-gmc: rld: Fatal Error: attempted access to > unresolvable symbol in /usr/local/lib/libgnome.so.33: bindtextdomain > Exit 1 The symbol is in libgnome, not in gmc. It is compiled with libintl, but the run-time library loader doesn't seem to know that. This may be a problem with libtool not supporting interlibrary dependencies on your platform. Or it may be a problem with the build system of libgnome. But it's certainly not mc. > I guess a similar problem is at hand here. Should there also be a i18n.h > in gnome? Well, If GNOME is compiled with libintl, than you must be using it, directly or indirectly (through interdependency). If you think it's wrong fix GNOME libraries, not MC. i18n.h from MC doesn't redefine bindtextdomain and other functions in the GNOME edition - GNOME headers should do it if needed. > Other spurious warnings I get (in order of appearance): > I don't know which errors are caused by the old age of my gcc (2.7.2) > and glib (libglib-1.2.so.1.6a) nd gnome (libgnome.so.33.11) and which > are truly caused by the IRIX platform. The only thing that really worry > me are the "statement with no effect" warnings "statement with no effect" is really harmless and can be reproduced on any platform. It a consequence of a rather crude "undefining" some features, i18n in this case. Better solutions are welcome. > Remember, I'm the guy with the IRIX 6.2 workstation. > using recent CVS version. Thank you. I appreciate it. Don't forget that some people may read this message in the archive without any context. > direntry.c: In function `vfs_s_dump': > direntry.c:1013: warning: int format, long int arg (arg 4) st_mode is int, not long int in glibc. I see no graceful solution here. Using casts is not. > screen.c: In function `string_file_perm_octal': > screen.c:312: warning: unsigned int format, mode_t arg (arg 4) Same story. > /usr/include/limits.h:185: warning: `RE_DUP_MAX' redefined > eregex.h:212: warning: this is the location of the previous definition Easy to fix. The order of includes should be: config.h, system includes, global.h, other local includes. global.h wasn't first. > subshell.c: In function `init_subshell': > subshell.c:438: warning: int format, pid_t arg (arg 4) Same story with casts between int and long int. > main.c:2974: warning: statement with no effect > main.c:2975: warning: statement with no effect Trivial to fix. > learn.c: In function `init_learn': > learn.c:235: warning: unused variable `i18n_flag' I'n trying to fix such warnings in the default configuration (i.e. with NLS). Placating the compiler with ifdefs for every configuration is ugly, especially because C doesn't allow mixing declarations with the code. Well, it's easy to fix this one. > /usr/include/limits.h:185: warning: `RE_DUP_MAX' redefined > eregex.h:212: warning: this is the location of the previous definition Also trivial. > filegui.c: In function `fmd_init_i18n': > filegui.c:817: warning: unused variable `len' > filegui.c:816: warning: unused variable `i' Again, easy to fix in this case. > /usr/include/sys/param.h:348: warning: `MIN' redefined > /usr/local/include/glib.h:126: warning: this is the location of the > previous definition This is specific for older compilers. I'll fix it later. The real fix should probably be in glib. > editcmd.c:1408: warning: `B_ENTER' redefined > ../src/dlg.h:20: warning: this is the location of the previous > definition Should be fixed. but strange that I couldn't reproduce it. > editcmd.c:1412: warning: `B_CANCEL' redefined > ../src/dlg.h:19: warning: this is the location of the previous > definition Likewise. > /usr/include/sys/param.h:348: warning: `MIN' redefined > /usr/local/include/glib.h:126: warning: this is the location of the > previous definition Same story. gcc-2.7.2 + glib. > gmc-chargrid.c: In function `gmc_char_grid_set_font': > gmc-chargrid.c:523: warning: passing arg 1 of `gdk_fontset_load' > discards `const' from pointer target type Old Gtk. I don't care. > gview.c: In function `gview_quit': > gview.c:253: warning: implicit declaration of function `view_ok_to_quit' I think this is already fixed in CVS. > ./magicdev.idl:3: Warning: `reread_config' underscores within > identifiers are discouraged for use with C-language IDL mappings Too late to change, I think. IDL defines a public interface. > cc1: warning: `-g' not supported by this configuration of GCC Whare does that -g come from? Perhaps from gnome-config? If you are concerned about warnings please elaborate more or send patches. I'm more concerned about stability than about warnings. Anyway, thank you for the report. I'm committing some patches based on this report. -- Regards, Pavel Roskin From proski at gnu.org Sat Aug 4 03:45:25 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 3 Aug 2001 23:45:25 -0400 (EDT) Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: <20010801102508.A3149@localhost.localdomain> Message-ID: Hi, Walery! > > Why are you using copy_full_prog_name() in two places - once in the table > > and then by calling it explicitly? Cannot we just do it is one place? If > > not, then I would like to fix the existing code first. > > Done. My suspicion was correct. Ctrl-F is already used to move one character forward in all input widgets, including the command line. It is one of the Emacs keys. It would be bad to use it for something else in the ccommand line. That's why it wasn't sufficient to add it to the table - because it is handled after the individual widgets get chance to handle the key. That's why I'm asking for the comments to the code. If you had to hack midnight_callback() because it doesn't work otherwise, please don't hesitate to mention this fact - it's very important. > > MC traditionally has symmetric shortcuts for the current and the other > > panel, like "Atl-a" and "Alt-A" and even "Ctrl-x r" and "Ctrl-x Ctrl-r" > > (I've never used the later - copy readlink from the other panel). There > > is no shortcut to copy the filename on the other panel. Shouldn't we have > > counterparts for Ctrl-Enter and the proposed Ctrl-F to work with the other > > panel? > > IMHO commands for other panel is not so useful. Not quite. Suppose I have /usr/src/linux in the current panel and the patch in the other. Then I want to put the patch name on the command line but stay in the same directory. Different people have different abilities to remember shortcuts. I'm quite bad at it. That's one of the reasons why I dosn't use Emacs. But other people have better memory than me, and I respect them. I don't know if anybody uses "Ctrl-x Ctrl-r" in MC, but copying the full path from the other panel would be more useful than copying the link destination. > > Where does Ctrl-F come from? It's better that every shortcut is already > > used somewhere, so that at least some people don't have to re-learn. > > >From the FAR manager. Just the other way about many people having > experience with FAR manager expects this functionality. I could not find Norton Commander, but I found Volcov Commander, and it uses Ctrl-F to move the cursors one word backwards. There is no single convention here, by MC stands on the solid ground by emulating Emacs. > mc.1.in.diff is attached. > Strage, but I have't found description for Meta-A there. Feel free to fix. There is a lot of stuff missing there :-( -- Regards, Pavel Roskin From max at tavrida.net Sat Aug 4 06:11:17 2001 From: max at tavrida.net (Max Schedriviy) Date: Sat, 4 Aug 2001 09:11:17 +0300 Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: References: Message-ID: <01080409111700.13104@humgat.tavrida.net> On Sat 04 Aug 2001 06:45, you wrote: > My suspicion was correct. Ctrl-F is already used to move one character > forward in all input widgets, including the command line. It is one of > the Emacs keys. It would be bad to use it for something else in the > ccommand line. This is right, but FAR is the best filemanager, and better to make another FAR, then another Emacs. From proski at gnu.org Sun Aug 5 08:02:58 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 5 Aug 2001 04:02:58 -0400 (EDT) Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: <01080409111700.13104@humgat.tavrida.net> Message-ID: Hi, Max! (Sorry for the second copy for you, and please don't use Bcc: to the list - your posts are marked as possible spam and need to be approved by moderator) > > My suspicion was correct. Ctrl-F is already used to move one character > > forward in all input widgets, including the command line. It is one of > > the Emacs keys. It would be bad to use it for something else in the > > ccommand line. > > This is right, but FAR is the best filemanager, and better to make another > FAR, then another Emacs. It's better to have a choice, like the one we have in the editor. This means that MC should stop acting in term of keys (like Ctrl-F) and switch to the actions (like CK_Delete in the editor). It's a major change. I'd rather do it after the GNOME edition goes to the branch. To be really similar to FAR, MC should interpret keys directly if possible (or at least store the ctrl-alt-shift state together with the key sequences). It should be possible if it's run under X or on the Linux console. However, the users accustomed to the enhanced keyboard support would have difficulties using MC over the net or on the *BSD console. I don't know if we should "spoil" our users. FAR is the best filemanager because: 1) FAR is for one OS and one terminal. It's the best if it runs for you at all :-) 2) FAR looks and acts like a program written by one author. MC does not. It lacks consistency in many aspects (classical example - hex editor in the viewer). Adding new stuff (Ctrl-F on the command like) overlaying the old stuff (Ctrl-F in other input widgets) would only make the situattion worse. -- Regards, Pavel Roskin From despair at sama.ru Sun Aug 5 19:35:33 2001 From: despair at sama.ru (Walery Studennikov) Date: Sun, 5 Aug 2001 15:35:33 -0400 Subject: Patch for switching to subshel in editor and viewer Message-ID: <20010805153533.A2889@localhost.localdomain> Hello. Here is the patch which allows to switch to subshell from internal viewer (Ctrl-O) and from internal editor (Ctrl-Shift-O, because Ctrl-O is already taken by another function). view.c.diff - viewer stuff. edit_key_translator.c - edutor stuff mc.1.in.diff - documentation patch I hope this patch will be included into CVS. Regards, Walery -------------- next part -------------- --- edit_key_translator.orig.c Sun Aug 5 15:00:40 2001 +++ edit_key_translator.c Sun Aug 5 15:13:50 2001 @@ -111,11 +111,24 @@ KEY_DOWN, KEY_RIGHT, KEY_HOME, KEY_UP, KEY_PPAGE}; + #define DEFAULT_NUM_LOCK 0 static int num_lock = DEFAULT_NUM_LOCK; int i = 0; +#if !HAVE_X && HAVE_SUBSHELL_SUPPORT + /* Show subshell */ + if (x_key == XCTRL('o') && (x_state & SHIFT_PRESSED)) { + view_other_cmd(); + + edit->force = REDRAW_COMPLETELY; + command = CK_Refresh; + goto fin; + } +#endif + + switch (edit_key_emulation) { case EDIT_KEY_EMULATION_NORMAL: key_map = cooledit_key_map; @@ -155,6 +168,7 @@ goto fin; } #endif + if (x_key == XCTRL ('q')) { char_for_insertion = edit_raw_key_query (_(" Insert Literal "), _(" Press any key: "), 0); -------------- next part -------------- --- view.orig.c Sat Jul 28 22:08:40 2001 +++ view.c Sun Aug 5 15:13:38 2001 @@ -2334,6 +2334,16 @@ return 1; #endif +#if !HAVE_X && HAVE_SUBSHELL_SUPPORT + case XCTRL('o'): + /* Show subshell */ + view_other_cmd(); + + view->dirty++; + view_update( view, TRUE ); + return 1; +#endif + } if (c >= '0' && c <= '9') view->marker = c - '0'; -------------- next part -------------- --- mc.1.in.orig Sun Aug 5 15:22:50 2001 +++ mc.1.in Sun Aug 5 15:33:16 2001 @@ -2416,6 +2416,9 @@ .B M-r Toggle the ruler. .PP +.B C-o +Temporarly switch to subshell. +.PP It's possible to instruct the file viewer how to display a file, look at the .\"LINK2" @@ -2488,6 +2491,10 @@ which is copied to .B .cedit/edit.indent.rc in your home directory the first time you use it. +.PP +You can use +.B Ctrl-Shift-O +to temporarly switch to subshell. .PP You can use scanf search and replace to search and replace a C format string. First take a look at the From despair at sama.ru Mon Aug 6 07:23:46 2001 From: despair at sama.ru (Walery Studennikov) Date: Mon, 6 Aug 2001 12:23:46 +0500 Subject: New release Message-ID: <20010806122346.A11654@localhost.localdomain> Questions to the maintainer: 1) When should we make the new release? 2) Would this be the last release before branch (mc and gmc separation)? Regards, Walery From proski at gnu.org Mon Aug 6 07:49:17 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 03:49:17 -0400 (EDT) Subject: New release In-Reply-To: <20010806122346.A11654@localhost.localdomain> Message-ID: Hi, Walery! > 1) When should we make the new release? I think we should make in this month. Not sure if we can make it early enough for GNOME 1.4.1 and RedHat 7.2, but we can try. I think we should inform the translation teams in gnome-i18n about the forthcoming release, so that they have chance to update the translations. There are no major issues in the current code - all known security holes and bugs that can cause data loss have been fixed (feel free to correct me if you know of any). I posted the remaining issues several times, but I see no interest in the list about fixing bugs - most people here want more features, not less bugs. I believe we should impose "string freeze" right now until the release (i.e. stop applying any patches adding new translatable strings), so that I can write to gnome-i18n. Is it Ok? > 2) Would this be the last release before branch (mc and gmc separation)? Yes. -- Regards, Pavel Roskin From proski at gnu.org Mon Aug 6 08:03:57 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 04:03:57 -0400 (EDT) Subject: Patch for switching to subshel in editor and viewer In-Reply-To: <20010805153533.A2889@localhost.localdomain> Message-ID: Hi, Walery! > Here is the patch which allows to switch to subshell > from internal viewer (Ctrl-O) and from internal editor > (Ctrl-Shift-O, because Ctrl-O is already taken by another function). > > view.c.diff - viewer stuff. What's wrong with `!'? Why don't you reuse this code? > edit_key_translator.c - edutor stuff What's wrong with `F11 s'? Is it really so important to access the same shell used by MC as subshell? And why Ctrl-Shift-O? This won't work on remote terminals at all. Maybe it's better to redefine "Open" to another key in the editor? Can you check what is the "traditional" key to open a new file? GNOME uses F3, but how about Far. > I hope this patch will be included into CVS. May be for the viewer. Creating another dependency on the get_modifier() is not nice - it doesn't work on all systems. -- Regards, Pavel Roskin From proski at gnu.org Mon Aug 6 08:30:42 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 04:30:42 -0400 (EDT) Subject: Copy full filename to command line (Ctrl-F) patch In-Reply-To: <01080513181800.01020@humgat.tavrida.net> Message-ID: Hi, Max! > > > This is right, but FAR is the best filemanager, and better to make > > > another FAR, then another Emacs. > > > > It's better to have a choice, like the one we have in the editor. > Why? I want to make customizable key bindings, like macroses in FAR. And one > default key binding. It's not 'learn keys', it's only binding key sequences > to functions. May be I'll make this after mc-4.5.55 released. Ok, I didn't really mean the choice between some preset configurations (like "emacs" and "intuitive" keybindings in mcedit). > > To be really similar to FAR, MC should interpret keys directly if possible > > (or at least store the ctrl-alt-shift state together with the key > > sequences). > I think, learn keys + binding will be enough for this. Well, how do you explain MC that Ctrl-O is "switch to subshell" and "Shift-Ctrl-O" is "show something fancy" in the "Learn Keys" dialog if the later has no idea of keyboard modifiers? How do you save these settings in the ~/.mc/ini file? If you simply mean that MC doesn't need all this to be "as good as FAR", then I probably agree. > > It should be possible if it's run under X or on the Linux > > console. However, the users accustomed to the enhanced keyboard support > > would have difficulties using MC over the net or on the *BSD console. I > > don't know if we should "spoil" our users. > Yes, I know this problems, but it's could be resolved if MC will store > configuration depends on hostname/remotename pair. For example, local/remote > pair from ssh2 session could be find here: > > ----------------------------- > #ssh2 login at host > login's password: > [login at host login]$ env|grep SSH2 > SSH2_CLIENT=xxx.xxx.xxx.xxx 2672 xxx.xxx.xxx.xxx 22 > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ > remotehost localhost > ----------------------------- Sorry, I'm afraid I wasn't clear. I meant that some new users accustomed e.g. to single escape or to working Stift-Ctrl-O may be confused when they start using MC remotely. But I now tend to think that we should spoil users - that's what the application software is for. Fallbacks can be graceful. Your comment about ssh seems to be irrelevant. > > FAR is the best filemanager because: > > 1) FAR is for one OS and one terminal. It's the best if it runs for you > > at all :-) > No, I saying about FAR structure, features, interface, etc. This things is > OS-independed, isn't it? I meant you cannot have _so_ polished interface if TERM is a variable. > > 2) FAR looks and acts like a program written by one author. MC does not. > It's MC problem? That alone is not a problem. Having separate keys to switch to the subshell in the listing, viewer and editor is a problem. MC acts like a program written by people not communicating enough with each other. > > It lacks consistency in many aspects (classical example - hex editor in > > the viewer). Adding new stuff (Ctrl-F on the command like) overlaying the > > old stuff (Ctrl-F in other input widgets) would only make the situattion > > worse. > It's right, but may be MC need to remove unused and/or double things? Oh yes. It's just not always easy. -- Regards, Pavel Roskin From despair at sama.ru Mon Aug 6 09:24:09 2001 From: despair at sama.ru (Walery Studennikov) Date: Mon, 6 Aug 2001 14:24:09 +0500 Subject: Patch for switching to subshel in editor and viewer In-Reply-To: ; from proski@gnu.org on Mon, Aug 06, 2001 at 04:03:57AM -0400 References: <20010805153533.A2889@localhost.localdomain> Message-ID: <20010806142409.A13327@localhost.localdomain> On Mon, Aug 06, 2001 at 04:03:57AM -0400, Pavel Roskin wrote: > Hi, Walery! > > > Here is the patch which allows to switch to subshell > > from internal viewer (Ctrl-O) and from internal editor > > (Ctrl-Shift-O, because Ctrl-O is already taken by another function). > > > > view.c.diff - viewer stuff. > > What's wrong with `!'? Why don't you reuse this code? Ok, now Ctrl-O and '!' reuse the same core. > > edit_key_translator.c - edutor stuff > > What's wrong with `F11 s'? Is it really so important to access the same > shell used by MC as subshell? Yes, it may be important. For instance if you want to see output of the previous command of if you continue to do the same task in the subshell. > And why Ctrl-Shift-O? This won't work on remote terminals at all. Maybe > it's better to redefine "Open" to another key in the editor? Can you > check what is the "traditional" key to open a new file? GNOME uses F3, > but how about Far. Fixed. "Open file" is rebinded to F18 (anyway IMHO this is not used very often). Now Ctrl-O is also used here for invoking subshell. > > I hope this patch will be included into CVS. > > May be for the viewer. Creating another dependency on the get_modifier() > is not nice - it doesn't work on all systems. Well, all problems are fixed. Now we have the same keys in all modes of operation. Also we invoke the same subshell. Also this will work in the remote terminals. I see no obstacles for including this into CVS. The new patch is attached. Regards, Walery -------------- next part -------------- --- edit_key_translator.c.orig Mon Aug 6 00:00:40 2001 +++ edit_key_translator.c Mon Aug 6 14:16:17 2001 @@ -47,7 +47,7 @@ KEY_PPAGE, CK_Page_Up, KEY_NPAGE, CK_Page_Down, KEY_LEFT, CK_Left, KEY_RIGHT, CK_Right, KEY_UP, CK_Up, KEY_DOWN, CK_Down, ALT ('\t'), CK_Return, ALT ('\n'), CK_Return, KEY_HOME, CK_Home, KEY_END, CK_End, '\t', CK_Tab, XCTRL ('u'), CK_Undo, KEY_IC, CK_Toggle_Insert, - XCTRL ('o'), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, + KEY_F (18), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, KEY_F (6), CK_Move, KEY_F (8), CK_Remove, KEY_F (12), CK_Save_As, KEY_F (2), CK_Save, XCTRL ('n'), CK_New, XCTRL ('l'), CK_Refresh, ESC_CHAR, CK_Exit, KEY_F (10), CK_Exit, @@ -70,7 +70,7 @@ KEY_PPAGE, CK_Page_Up, KEY_NPAGE, CK_Page_Down, KEY_LEFT, CK_Left, KEY_RIGHT, CK_Right, KEY_UP, CK_Up, KEY_DOWN, CK_Down, ALT ('\t'), CK_Return, ALT ('\n'), CK_Return, KEY_HOME, CK_Home, KEY_END, CK_End, '\t', CK_Tab, XCTRL ('u'), CK_Undo, KEY_IC, CK_Toggle_Insert, - XCTRL ('o'), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, + KEY_F (18), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, KEY_F (6), CK_Move, KEY_F (8), CK_Remove, KEY_F (12), CK_Save_As, KEY_F (2), CK_Save, ALT ('p'), CK_Paragraph_Format, @@ -107,7 +107,7 @@ 0, 0}; static long const key_pad_map[10] = - {XCTRL ('o'), KEY_END, KEY_DOWN, KEY_NPAGE, KEY_LEFT, + {KEY_F (18), KEY_END, KEY_DOWN, KEY_NPAGE, KEY_LEFT, KEY_DOWN, KEY_RIGHT, KEY_HOME, KEY_UP, KEY_PPAGE}; @@ -149,6 +149,17 @@ #ifdef HAVE_CHARSET if (x_key == XCTRL('t')) { do_select_codepage(); + + edit->force = REDRAW_COMPLETELY; + command = CK_Refresh; + goto fin; + } +#endif + +#if !HAVE_X && HAVE_SUBSHELL_SUPPORT + if (x_key == XCTRL('o')) { + /* Show subshell */ + view_other_cmd(); edit->force = REDRAW_COMPLETELY; command = CK_Refresh; -------------- next part -------------- 2421a2422,2424 > .B C-o > Temporarly switch to subshell. > .PP 2493a2497,2500 > .PP > You can use > .B Ctrl-O > to temporarly switch to subshell. -------------- next part -------------- --- view.orig.c Mon Aug 6 12:11:00 2001 +++ view.c Mon Aug 6 14:00:26 2001 @@ -2282,6 +2282,7 @@ view_move_forward (view, vheight - 1); return 1; + case XCTRL('o'): case '!': exec_shell (); return 1; From proski at gnu.org Mon Aug 6 14:54:41 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 10:54:41 -0400 (EDT) Subject: some gmc (mc) development questions In-Reply-To: <3B6EAA66.5238.7B7C1F55@localhost> Message-ID: Hello, Wilhelm! > Im running gnome on all my machines on my net, and im not > satisfied with the nautilus desktop/file manager, its to slow for my > not so fast clients... so i switched to gmc and speed is a lot better > now.. however there are some things im not satisfied with in gmc > and i am considering joining the development to make those ideas > come true! You probably should discuss it in some more GNOME-specific mailing lists. I know that some GNOME developers don't like Nautilus, but I have no idea whether they would prefer impoving GMC or writing another light-weight file manager. > the features im thinking of adding are: > > *importing mime types from gnomes mime types, because these > are easy to edit, and it lessens confusion between settings in > nautilus (that uses there mimetypes) and gmc This sounds good. The fact that GMC is using its own mime types (or associations between mime types and applications, I don't really know the situation) makes it somewhat similar to Nautilus - it's not fully integrated with the desktop. > *adding small icons for files when viewing detailed list (now just > folders appear) I even remember seeing a patch for that. But I'm not ready to discuss it. I believe that small icons are hard to distinguish, but I'm not a GUI expert. > *some "right click" pop up menus on files and folders for more > options In fact, the popup code is in the MC sources, but it's commented out. Perhaps because it's not finished. > *"cut and paste" capability for files and folders (that is: more easy > to use interface) > do you think this seems like a good idea or am i just ranting? I have never liked interface the that allows you to "cut" a 500Mb file on a machine with 64Mb of RAM. But since you are asking, you probably could discuss it e.g. on gnome-gui-list at gnome.org. > i have access to at least two more people who are willing to help > me with this coding (that is friends of mine working at my location) It's very good, but I really want that you discuss your changes with GUI experts. > and i read the devel mailing list, and read something about > branching the console and the gmc versions to two different parts? If you read that mailing list, you must have noticed that I'm asking not to write me personally about software projects and that I reserve the right to forward such messages to the list unless otherwise asked. It's not a private matter between me and you, so please don't be surprised. > what does this mean, and would that mean that the things i want to > do belongs to the gmc brach then? Yes, certainly. GMC will be removed from the head branch very soon. -- Regards, Pavel Roskin From sav at bcs.zp.ua Mon Aug 6 15:52:44 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Mon, 6 Aug 2001 18:52:44 +0300 Subject: New release In-Reply-To: ; from proski@gnu.org on Mon, Aug 06, 2001 at 03:49:17AM -0400 References: <20010806122346.A11654@localhost.localdomain> Message-ID: <20010806185244.A18821@bcs.zp.ua> Hi! Pavel Roskin wrote: : I believe we should impose "string freeze" right now until the release : (i.e. stop applying any patches adding new translatable strings), so that : I can write to gnome-i18n. Is it Ok? : Some time ago I commited a patch for vfs/smbfs.c with new translatable string: Index: smbfs.c =================================================================== RCS file: /home/sav/.cvsroot/mc/vfs/smbfs.c,v retrieving revision 1.21.2.3 diff -u -p -r1.21.2.3 smbfs.c --- smbfs.c 3 Aug 2001 13:32:57 -0000 1.21.2.3 +++ smbfs.c 5 Aug 2001 21:14:08 -0000 @@ -1923,15 +1914,17 @@ static int smbfs_unlink (vfs *me, char *path) { smbfs_connection *sc; - char *remote_file; + char *remote_file, *p; if ((remote_file = smbfs_get_path (&sc, path)) == 0) return -1; - + + p = remote_file; convert_path(&remote_file, FALSE); + g_free (p); if (!cli_unlink(sc->cli, remote_file)) { - message_3s (1, MSG_ERROR, _(" %s opening remote file %s "), + message_3s (1, MSG_ERROR, _(" %s removing remote file %s "), cli_errstr(sc->cli), CNV_LANG(remote_file)); g_free (remote_file); return -1; It was incorrect message and as for me it is better to have untranslated message than wrong translated. Best regards, Andrew. From proski at gnu.org Mon Aug 6 16:03:23 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 12:03:23 -0400 (EDT) Subject: New release In-Reply-To: <20010806185244.A18821@bcs.zp.ua> Message-ID: Hi, Andrew! > It was incorrect message and as for me it is better to have untranslated > message than wrong translated. I agree. Especially in the error messages and in the code disabled by default. -- Regards, Pavel Roskin From sxmboer at sci.kun.nl Mon Aug 6 17:20:06 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Mon, 06 Aug 2001 19:20:06 +0200 Subject: Updated mc.hint References: Message-ID: <3B6ED1C6.2EEED1C0@sci.kun.nl> Pavel, Sorry I didn't notice your question before. > The symbol is in libgnome, not in gmc. It is compiled with libintl, but > the run-time library loader doesn't seem to know that. You're right, it is indeed not a MC error. The problem is in dependencies among shared libraries on Irix. I've crossed this problem before and shoul have realized it! > > main.c:2974: warning: statement with no effect > > main.c:2975: warning: statement with no effect > Trivial to fix. Yes, but it is not very important either. putting some #ifdefs here and there should indeed do the job. > > cc1: warning: `-g' not supported by this configuration of GCC > > Whare does that -g come from? Perhaps from gnome-config? this -g comes from gcc-2.7.2 which did not support debugging information at that time for MIPS based machines. Otherwise, the person who compiled gcc might have turned that support of for some reason. I deleted most of these errors, but apparantly I forgot 1. > Anyway, thank you for the report. I'm committing some patches based on > this report. Ok, I hope it was helpful for you. Kind regards, Steef -- ------------------------------------------------------------------------ Drs. S.X.M. Boerrigter RIM Laboratory of Solid State Chemistry, University of Nijmegen Toernooiveld 1, 6525 ED Nijmegen, The Netherlands Telephone: (+31)-(0)24-3652831 Fax:(+31)-(0)24-3653067 email: sxmboer at sci.kun.nl http://savannah.gnu.org/users/sxmboer ------------------------------------------------------------------------ Quidquid latine dictum sit, altum viditur. "Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things." --Doug Gwyn Murphy's law: Anyt From proski at gnu.org Mon Aug 6 19:15:47 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 15:15:47 -0400 (EDT) Subject: Updated mc.hint In-Reply-To: <3B6ED1C6.2EEED1C0@sci.kun.nl> Message-ID: Hi, Steef! > > > cc1: warning: `-g' not supported by this configuration of GCC > > > > Whare does that -g come from? Perhaps from gnome-config? > this -g comes from gcc-2.7.2 which did not support debugging information > at that time for MIPS based machines. Otherwise, the person who compiled > gcc might have turned that support of for some reason. I deleted most of > these errors, but apparantly I forgot 1. It looked really weird because of that. Unfortunately, Autoconf doesn't check the compiler warnings (it's hard to parse them reliably). But next time you can just specify CFLAGS on the command line, like this: CFLAGS="-O2" ./configure > > Anyway, thank you for the report. I'm committing some patches based on > > this report. > Ok, I hope it was helpful for you. Maybe. It's better the keep the code warning-free, so that the new warnings (i.e. those created by new changes) are easier to spot. -- Regards, Pavel Roskin From 0 at pervalidus.net Mon Aug 6 22:34:17 2001 From: 0 at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Mon, 6 Aug 2001 19:34:17 -0300 Subject: [PATCH] INSTALL Message-ID: <20010806193417.Q135@pervalidus> Hi. Attached is another patch for the INSTALL file. It's against current CVS. Changes: - Removed http://mc.blackdown.org/mc/ . It doesn't exist anymore. - Removed "The X Windows^H System libraries" part since the Tk and Xview parts were removed in an earlier patch. - Removed gpm + Kernel part since most distributions include support and latest Kernel enables it by default. Also, there's no patch in recent gpm releases. - Removed all GCC mirrors. Added 2 official download sites and mirrors URL. Changed "GNU C Compiler" to "GNU Compiler Collection". - Cosmetic changes. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) -------------- next part -------------- A non-text attachment was scrubbed... Name: INSTALL.patch.gz Type: application/octet-stream Size: 3937 bytes Desc: not available URL: From proski at gnu.org Tue Aug 7 03:46:09 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 6 Aug 2001 23:46:09 -0400 (EDT) Subject: [PATCH] INSTALL In-Reply-To: <20010806193417.Q135@pervalidus> Message-ID: Hi, Fr?d?ric! > Hi. Attached is another patch for the INSTALL file. It's > against current CVS. Thank you! It's about time to fix the documentation. > - Removed http://mc.blackdown.org/mc/ . It doesn't exist > anymore. I really like that you are commenting your changes. Unfortunately, this document has several layers of rot. It says: S-Lang is the only library that will let you resize the Midnight Commander window on an xterm. and then Many Linux systems ship with ncurses version 1.9.9e, however, we recommend ncurses 4.1 or above, since the former version does not support resizing of the xterm window. So I'm now making more clean-ups. P.S. The patch has been committed. Thank you! -- Regards, Pavel Roskin From maddog at linuxhall.org Tue Aug 7 13:52:31 2001 From: maddog at linuxhall.org (R.I.P. Deaddog) Date: Tue, 7 Aug 2001 21:52:31 +0800 (HKT) Subject: mc: new translation In-Reply-To: Message-ID: On Thu, 2 Aug 2001, Pavel Roskin wrote: > In general, I reserve the right to forward any messages concerning > exclusively software projects to the appropriate mailing lists unless > otherwise requested. There are several important points to be made in > this message, and I have no time to write the same things privately over > and over again. It's not a matter between me and you - it's a public > project. Understand that, so definitely no objection. I've just subscribed to mc-devel too. > You have indeed caused a problem by adding a space after the backslash in > lib/Makefile.in. The current CVS version doesn't compile because of that. > I'm committing the fix now. Really sorry about that, and I've noticed my error just before seeing your email. I really sucks. > Next thing, also about testing. Have you been able to make MC show hints > in Chinese? If not, there is no point in applying that file. Hints are > only used in the text edition. I believe that there are modifications of > xterm capable of displaying chinese texts, but I don't know whether MC can > run on such terminals and whether the hints can be displayed correctly in > that setup. > > You have included the charset name in the name of the hint file. If > anybody sets "LANG=zh_TW" in the environment, the hints file won't be > loaded, even though zh_TW assumes the Big5 charset. Not sure if I've done wrong, but it's a difficult decision. The transition from native Big5 encoding to UTF8 is ongoing, so it's quite impossible to tell what encoding users are using. It's just because the hint file itself is using big5 encoding that I choosed to include the .Big5 name (as those using other encoding can't see it anyway). But probably I can be wrong as you have indicated. Since...... (see below) > If you named the file mc.hint.zh_TW but the user had LANG=zh_TW.Big5 in > the environment it would be easier to fix by probing 5 first characters of > LANG (or LC_MESSAGES) after probing the whole name and before resorting to > the 2-character language code. Doing the opposite (guessing zh_TW.Big5 > from zh_TW) in the MC code would be much harder to implement - it would > require some _knowledge_ about preferred encodings in different countries. mc is reading $LANGUAGE before $LANG. However $LANGUAGE can include multiple languages separated by colon (e.g. de:fr:hu), so what I saw is the mc is searching for "/usr/..../mc/mc.hint.$LANGUAGE" , which of course doesn't exist. After I renamed the file to mc.hint.zh it worked. Obviously I have done too few testing before committing (the testing machine doesn't have $LANGUAGE set). > See function load_mc_home_file in src/util.c for details. Thanks for direction. Abel From gz at lysator.liu.se Tue Aug 7 13:48:34 2001 From: gz at lysator.liu.se (Gernot Ziegler) Date: Tue, 7 Aug 2001 15:48:34 +0200 (MET DST) Subject: MC rocks ! Message-ID: Hej guys ! Aaaah, finally a working MC on the SGI Onyx2 I'm working on :-) ... file admin is suddenly done much faster - just start MC and fix it, without having to enter a lot of commands ;) Keep up the good work ! Servus, Gernot /-----------------------------W-E-L-C-O-M-E------------------------------\ T The Austria <=> Sweden connection..... T | E-Mail: gz at lysator.liu.se H O Homepage: http://www.lysator.liu.se/~gz E \------------------------------F-U-T-U-R-E-------------------------------/ From proski at gnu.org Tue Aug 7 14:45:59 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 10:45:59 -0400 (EDT) Subject: mc: new translation In-Reply-To: Message-ID: Hello! > > You have included the charset name in the name of the hint file. If > > anybody sets "LANG=zh_TW" in the environment, the hints file won't be > > loaded, even though zh_TW assumes the Big5 charset. > > Not sure if I've done wrong, but it's a difficult decision. The transition > from native Big5 encoding to UTF8 is ongoing, so it's quite impossible to > tell what encoding users are using. It's just because the hint file itself > is using big5 encoding that I choosed to include the .Big5 name (as those > using other encoding can't see it anyway). But probably I can be wrong as > you have indicated. Since...... (see below) I didn't think about it. I assumed that "LANG=zh_TW" has only one interpretation on all systems - the same as "LANG=zh_TW.Big5". I have seen a suggestion to keep all translations in Unicode. Another solution would be to use the most popular encoding and specify the encoding in the file. In any case, doing it requires a better integration of gettext into MC (to determine the current encoding). Hopefully, this will be done some day. > mc is reading $LANGUAGE before $LANG. However $LANGUAGE can include > multiple languages separated by colon (e.g. de:fr:hu), so what I saw is > the mc is searching for "/usr/..../mc/mc.hint.$LANGUAGE" , which of course > doesn't exist. After I renamed the file to mc.hint.zh it worked. Obviously > I have done too few testing before committing (the testing machine doesn't > have $LANGUAGE set). That's another reason to use more gettext functions in MC. Anyway, I'm glad that it works for you at all - I was wrongly assuming that it doesn't. Sorry for that. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 7 15:05:00 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 11:05:00 -0400 (EDT) Subject: MC rocks ! In-Reply-To: Message-ID: Hi, Gernot! > Aaaah, finally a working MC on the SGI Onyx2 I'm working on :-) ... file > admin is suddenly done much faster - just start MC and fix it, without > having to enter a lot of commands ;) Next time please tell us what version of MC is working for you. Thank you for the encouragement! -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 7 17:06:24 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 13:06:24 -0400 (EDT) Subject: uzip extfs new release - 1.4.0 In-Reply-To: <20010807183834.A8412@oskar> Message-ID: Hi, Oskar! On Tue, 7 Aug 2001, Oskar Liljeblad wrote: > I've made a new release of the uzip extfs VFS module which > is currently used in the Debian mc package and probably > also in the main distribution as well. > > In the future, how do I go about informing the mc developers > about the new releases? Is this list the right place? > > The 1.4.0 release can be downloaded from > > http://www.student.lu.se/~nbi98oli/src/uzip-1.4.0.tar.gz > > or via http://www.student.lu.se/~nbi98oli/. If you want it > emailed, please let me know. > > Oskar Liljeblad (osk at hem.passagen.se) The right way to contact MC developers is to write to the new list at mc-devel at gnome.org Thank you for your contribution! I'll review it shortly. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 7 19:18:41 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 15:18:41 -0400 (EDT) Subject: [patch] build fix for HURD In-Reply-To: <20010713224925.C488@212.23.136.22> Message-ID: Hi, Marcus! > > > The patch is wrong. PATH_MAX is not defined for a reason. There is no > > > upper limit for the path length on GNU/Hurd. Finally I have committed the fix. ".order" files are used to set the order of entries for GNOME applications. PATH_MAX (4095 in Linux) is clearly on overkill. MC uses a 1024-bytes long buffer now. > > Yes. Therefore, you have to define it, when the Hurd doesn't set it, but > > MC uses the value, right? > > Well, Pavel is correct. Except I didn't bother to fix it properly, as I > understood it that gmc is not actively maintained anyway, and sort of being > phased out. Yes, sort of. > A proper patch which deals with arbitrary filenames is always preferred, I > was just being very lazy in this case. That's correct. There is not way to exploit it, and menu items with more than 1024 characters shouldn't be used, since it's not user-friendly :-) > > > Note that the buffer in > > > get_presorted_from() is allocated on the stack - exceeding it means crash > > > in the best case or an exploit if a malicious user prepares `.order' for > > > you. > > Mmmmh. The main stack of a task is unlimited, isn't it? If you use > threading, on the Hurd each thread gets a fixed size thread, though. I meant a stack overflow, now so popular thanks to Code Red. But I was confusing fgets() and gets() - the former is not _so_ unsafe, although it has its own issues (no reliable way to determine string length if '\0' appears in the input, see info libc). -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 7 22:40:33 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 18:40:33 -0400 (EDT) Subject: uzip extfs new release - 1.4.0 In-Reply-To: Message-ID: Oskar, > Thank you for your contribution! I'll review it shortly. I've applied the new version. The testing has shown that copying empty files into the archive doesn't work. However, it's an MC problem. I have fixed it. I'll send it as a separate message. The problem you noted in README.uzip about permissions can be solved by inlementing extfs_chmod. I have a minimal implemenation that only works on the files for which local copies already exist - it should be sufficient for now. This also will be a separate message. I agree with you about symbolic links. It's a common MC problem - MC always runs stat() on symlinks. This is really annoying on slow FTP sites. This can be solved by having an option to stat() symlinks on demand only. But it's quite hard to implement, because it would require changing the `file_entry' structure. It should be changed anyway to support files for which lstat() has failed (e.g. files >4Gb if MC is compiled without largefile support). But it's certainly too much for 4.5.55 - I'll do it later. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 7 22:48:37 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 7 Aug 2001 18:48:37 -0400 (EDT) Subject: Copying empty files to extfs Message-ID: Hello! extfs_open() didn't set the `has_changed' flag on the extfs archive. Only extfs_write() did. That's why empty files could not be copied to extfs (e.g. into zip archives). Actually, there were three "flavors" of `has_changed' in three different structures, but only one of them was used. Two others were present only to confuse me :-) I'm applying the following patch. --------------------------------------- --- ChangeLog +++ ChangeLog @@ -1 +1,9 @@ +2001-08-07 Pavel Roskin + + * extfs.h (struct entry): Remove unused `has_changed' field. + It's only written but never read. + (struct inode): Likewise. + * extfs.c: All dependencies changed. + (extfs_open): Mark file as changed if it's open for writing. + 2001-08-07 Oskar Liljeblad --- extfs.c +++ extfs.c @@ -84,7 +84,6 @@ static void make_dot_doubledot (struct e parent = (parentry != NULL) ? parentry->inode : NULL; entry->name = g_strdup ("."); - entry->has_changed = 0; entry->inode = inode; entry->dir = ent; inode->local_filename = NULL; @@ -94,7 +93,6 @@ static void make_dot_doubledot (struct e entry->next_in_dir = g_new (struct entry, 1); entry=entry->next_in_dir; entry->name = g_strdup (".."); - entry->has_changed = 0; inode->last_in_subdir = entry; entry->next_in_dir = NULL; if (parent != NULL) { @@ -119,7 +117,6 @@ static struct entry *generate_entry (str entry = g_new (struct entry, 1); entry->name = g_strdup (name); - entry->has_changed = 0; entry->next_in_dir = NULL; entry->dir = parentry; if (parent != NULL) { @@ -128,7 +125,6 @@ static struct entry *generate_entry (str } inode = g_new (struct inode, 1); entry->inode = inode; - inode->has_changed = 0; inode->local_filename = NULL; inode->linkname = 0; inode->inode = (archive->__inode_counter)++; @@ -305,7 +301,6 @@ static int read_archive (int fstype, cha } entry = g_new (struct entry, 1); entry->name = g_strdup (p); - entry->has_changed = 0; entry->next_in_dir = NULL; entry->dir = pent; if (pent != NULL) { @@ -330,7 +325,6 @@ static int read_archive (int fstype, cha inode = g_new (struct inode, 1); entry->inode = inode; inode->local_filename = NULL; - inode->has_changed = 0; inode->inode = (current_archive->__inode_counter)++; inode->nlink = 1; inode->dev = current_archive->rdev; @@ -637,7 +631,7 @@ static void *extfs_open (vfs *me, char * extfs_info = g_new (struct pseudofile, 1); extfs_info->archive = archive; extfs_info->entry = entry; - extfs_info->has_changed = 0; + extfs_info->has_changed = do_create; extfs_info->local_handle = local_handle; /* i.e. we had no open files and now we have one */ @@ -1292,7 +1286,6 @@ static int extfs_ungetlocalcopy (vfs *me if (fp == NULL) return 0; if (!strcmp (fp->entry->inode->local_filename, local)) { - fp->entry->inode->has_changed = has_changed; fp->archive->fd_usage--; extfs_close ((void *) fp); return 0; --- extfs.h +++ extfs.h @@ -23,7 +23,6 @@ struct inode; struct entry { - int has_changed; struct entry *next_in_dir; struct entry *dir; char *name; @@ -33,7 +32,6 @@ struct archive; struct inode { - int has_changed; nlink_t nlink; struct entry *first_in_subdir; /* only used if this is a directory */ struct entry *last_in_subdir; --------------------------------------- -- Regards, Pavel Roskin From lists at pervalidus.net Wed Aug 8 03:20:05 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Wed, 8 Aug 2001 00:20:05 -0300 Subject: [PATCH] FAQ Message-ID: <20010808002005.Z135@pervalidus> Hi. Attached is another patch for the FAQ file. As always, it's against current CVS. Changes: - Use lxr instead of http://www.gnome.org/mc/answers.html . Any better approatch ? Bonsai ? I wasn't able to browse the contents of a file with Lynx. - Removed [NEW] and [UPDATED] parts. Maybe this change won't be applied, but after some years they don't make much sense. When was the last time someone included one of them ? ~3 years ago ? - "Terminal not powerful enough for SLang" is "Terminal not powerful enough for SLsmg" in S-Lang 1.4.4 (sldisply.c). - Use rxvt's URL instead of color_xterm. AFAIK there are various security holes in the color_xterm from ftp.x.org, and distributions don't include it anymore. - Updated Linux distributions list. Use alphabetical order to avoid distro wars:-) . Also updated 3 URLs and added Dickey's URL for termcap/terminfo sources (always in sync with ncurses snapshots - he's the maintainer). - Use mc at gnome.org instead of Janne's e-mail address for feedback. He doesn't seem to be maintaining the FAQ anymore. - Removed 404 http://www.gnome.org/mc/answers.html and "File formats". Also removed 404 http://www.gnome.org/cgi-bin/mc/download/DOS/.html . BTW, are there any up to date MSDOS ports ? - Cosmetic changes. I'd suggest the addition of Pavel's snapshots URL to 9.2. And maybe rewrite or improve the section ? -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) -------------- next part -------------- A non-text attachment was scrubbed... Name: FAQ.patch.gz Type: application/octet-stream Size: 5411 bytes Desc: not available URL: From lists at pervalidus.net Wed Aug 8 03:30:11 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Wed, 8 Aug 2001 00:30:11 -0300 Subject: MC rocks ! Message-ID: <20010808003011.A135@pervalidus> Gernot Ziegler wrote: > Aaaah, finally a working MC on the SGI Onyx2 I'm working on :-) Forgive my ignorance, but SGI Onyx2 = mips-sgi-irix5.x, 6.x ? If not, it'd be nice to update the FAQ with your system. Also, I don't know if there's anything new to list... The last update was ~3 years ago, or more. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Wed Aug 8 06:20:32 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 8 Aug 2001 02:20:32 -0400 (EDT) Subject: [PATCH] FAQ In-Reply-To: <20010808002005.Z135@pervalidus> Message-ID: Hi, Fr?d?ric! > Hi. Attached is another patch for the FAQ file. As always, it's > against current CVS. Thank you! > - Use lxr instead of http://www.gnome.org/mc/answers.html . Any > better approatch ? Bonsai ? I wasn't able to browse the > contents of a file with Lynx. http://cvs.gnome.org/lxr/source/mc/FAQ?raw=1 Not everybody wants to see the line numbers. > - Removed [NEW] and [UPDATED] parts. Maybe this change won't be > applied, but after some years they don't make much sense. When > was the last time someone included one of them ? ~3 years ago ? Thank you! Using [NEW] on 3 years old entries usually shows that the document isn't worth reading. > - "Terminal not powerful enough for SLang" is "Terminal not > powerful enough for SLsmg" in S-Lang 1.4.4 (sldisply.c). Ok. > - Use rxvt's URL instead of color_xterm. AFAIK there are > various security holes in the color_xterm from ftp.x.org, and > distributions don't include it anymore. There is an xterm by Thomas Dickey, but rxvt is better anyway. > - Updated Linux distributions list. Use alphabetical order to > avoid distro wars:-) . Also updated 3 URLs and added Dickey's > URL for termcap/terminfo sources (always in sync with ncurses > snapshots - he's the maintainer). We actually have a list in INSTALL. It's slightly different. Perhaps it's better to have that list in one place. > - Use mc at gnome.org instead of Janne's e-mail address for > feedback. He doesn't seem to be maintaining the FAQ anymore. Ok. > - Removed 404 http://www.gnome.org/mc/answers.html and "File > formats". Also removed 404 > http://www.gnome.org/cgi-bin/mc/download/DOS/.html . BTW, are > there any up to date MSDOS ports ? MC should compile with Cygwin. The NT port is broken, but not hopelessly. I don't think that any MS DOS ports make sence. I'm quite sure that the DOS code has never been integrated. I'm also removing the reference to the photographs of the authors. This page was actually very cool. I miss it. I remember how proud I was to be on that page! Many early developers of MC are now well known as Linux kernel developers (Jakub Jelinek, Pavel Machek) and GNOME programmers (Radek Doulik). > - Cosmetic changes. > > I'd suggest the addition of Pavel's snapshots URL to 9.2. And > maybe rewrite or improve the section ? Please don't. This URL is temporary. I just don't have time to organize it on the GNOME site. I'm applying your patch. Thank you! -- Regards, Pavel Roskin From lists at pervalidus.net Wed Aug 8 07:30:10 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Wed, 8 Aug 2001 04:30:10 -0300 Subject: [PATCH] FAQ Message-ID: <20010808043010.F135@pervalidus.net> Pavel Roskin wrote: >> - Use rxvt's URL instead of color_xterm. AFAIK there are >> various security holes in the color_xterm from ftp.x.org, and >> distributions don't include it anymore. > There is an xterm by Thomas Dickey, but rxvt is better > anyway. I wouldn't say rxvt is better (both have features), but yes, I don't list XTerm because it's part of XFree86. Anyway, new releases are at ftp://dickey.his.com/xterm/ . If you want, just change 4.7 to "Where can I get rxvt and XTerm?" BTW, the Mirrors list at the site is wrong. http://www.cs-net.gr/mc/ (Greece) -> 404. Maybe "Mirrors :" should be removed. The USA mirror is... the site. Have a nice day. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From bmidy at guddland.lu Wed Aug 8 10:00:46 2001 From: bmidy at guddland.lu (Benoit Midy) Date: Wed, 08 Aug 01 10:00:46 Subject: some propositions to improve mc... Message-ID: <200108080800.KAA03449@gateway1.guddland.lu> Hi, I don't know if it the place I hope. I have some proposition to improve mc : - when the Quick View is used, and you browse a directory with big fies (files of 1-2GB (ASCII Database export data) the mc takes a long to show the file content ? I think that the internal viewer try to load the full file and then display it ?? Isn't possible to load only a part in a buffer and then load according to the user actions. For example if we want to go to the end of the fiel to use a fseek (or something like this.. ) to improve the response time !! - is it possible to add in the listing mode an option to display files attribute (unders OS/2 or Windows; I use OS/2 :) ) HRSA - need a serious doc about the xternal panelize ?? - need info about the user-menu : which shell is used : which indicated by the SHELL env var ?? So it's all hoping I put this message where it must. Benoit Midy Guddland Digital S.A. Luxembourg Tel: (352) 50 35 21 / 360 mailto:bmidy at guddland.lu http://www.guddland.lu From gz at lysator.liu.se Wed Aug 8 08:30:44 2001 From: gz at lysator.liu.se (Gernot Ziegler) Date: Wed, 8 Aug 2001 10:30:44 +0200 (MET DST) Subject: MC rocks ! In-Reply-To: <20010808003011.A135@pervalidus> Message-ID: Hej folks ! > > Aaaah, finally a working MC on the SGI Onyx2 I'm working on :-) > > Forgive my ignorance, but SGI Onyx2 = mips-sgi-irix5.x, 6.x ? > If not, it'd be nice to update the FAQ with your system. > Also, I don't know if there's anything new to list... The > last update was ~3 years ago, or more. Ah, yeah sure: It's IRIX 6.2 (vanilla, I guess, since this system doesn't have any sysadmin :-} ) I'm just running the terminal part, of course, no Gnome ... only did a local install in my homedir ... but I didn't have to tell configure anything special, just ran it as usual - and that's not common on this system -> good portability work :) Servus, Gernot /-----------------------------W-E-L-C-O-M-E------------------------------\ T The Austria <=> Sweden connection..... T | E-Mail: gz at lysator.liu.se H O Homepage: http://www.lysator.liu.se/~gz E \------------------------------F-U-T-U-R-E-------------------------------/ From lists at pervalidus.net Thu Aug 9 03:32:54 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Thu, 9 Aug 2001 00:32:54 -0300 Subject: More documentation cleanups Message-ID: <20010809003254.I135@pervalidus.net> Hi. I noticed there are still 5 404 www.gnome.org URLs in the FAQ file. Attached is a suggested patch. Also, I think docs/LSM should be removed. The template is outdated and doesn't belong to the distribution anymore. The releases aren't uploaded to sunsite.unc.edu^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H metalab.unc.edu^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H ibiblio.org since ages. And I'd suggested that a maintainer (Pavel ?) contact the ibiblio.org ftpmaster, so he can remove tp://www.ibiblio.org/pub/Linux/utils/file/managers/mc/ . We don't want people blindly downloading and mirroring outdated releases, right ? ibiblio.org is widely used. BTW, attached is a patch for the lsm syntax file. I don't know if it's OK, but IMO it's better, so please verify. Did you notice I don't endorse Shareware ? I could just change it to black/0. What's the status of the BUGS file ? It's 2 years old. Are they all closed ? I think it's another file that should be removed or added to .cvsignore. The system types are duplicated in the FAQ (1.2 Does it run on my machine?) and INSTALL (Notes about the Midnight Commander installation) files. They're also listed in the LSM file. Anyway, it'd be nice to know if the latest release compiles on all these. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) -------------- next part -------------- --- mc/FAQ Thu Aug 9 00:03:38 2001 +++ mc/FAQ.new Thu Aug 9 00:11:27 2001 @@ -130,8 +130,6 @@ * i386-*-windows-nt-3.51, 4.0 * i386-*-windows95 * i386-*-os2 - - See http://www.gnome.org/mc/download.html. Windows 95/NT port can be compiled with Microsoft Visual C++, Borland C++, Cygwin32 and Mingw32. @@ -184,9 +182,6 @@ 1.6 Where can I get Midnight Commander? The main site is ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ - - For older versions and precompiled binaries see - http://www.gnome.org/mc/download.html 1.7 I don't have FTP access. Where can I get MC? @@ -589,12 +584,12 @@ 6.5 Is there any way to include additional options or hot keys to MC? - Yes, F2 invokes an user menu which fully configurable. You can add any - shell commands to the user menu. See - http://www.gnome.org/mc/manual-d.html#8 for more info. + Yes, F2 invokes an user menu which fully configurable. You can add + any shell commands to the user menu. See the mc(1) man page for more + info. - Another way to add functionality is the external panelize feature. See - http://www.gnome.org/mc/manual-d.html#4 for more info. + Another way to add functionality is the external panelize feature. + See the mc(1) man page for more info. And finally, you can code any feature you want yourself. MC source code is free which means you can change it anyway you want. There are @@ -777,10 +772,8 @@ 8.7 When I try to view a file MC hangs! - This is known bug. A quick fix is "chmod 666 /dev/tty". For a more - complete fix, see http://www.gnome.org/mc/maillist/97-10/98.html. - - This bug is fixed since 4.1.6. + This is known bug, and is fixed since 4.1.6. A quick fix is "chmod + 666 /dev/tty". 9 Development -------------- next part -------------- --- mc/syntax/lsm.syntax Wed Jul 21 16:56:42 1999 +++ mc/syntax/lsm.syntax.new Thu Aug 9 00:24:07 2001 @@ -1,14 +1,15 @@ +# Use http://www.ibiblio.org/pub/Linux/Incoming/LSM-TEMPLATE as a template. context default spellcheck - keyword linestart Begin3 brightmagenta/20 + keyword linestart Begin4 brightmagenta/20 keyword linestart Title:\s\s\s\s\s\s\s\s\s\s red/9 yellow/24 keyword linestart Version:\s\s\s\s\s\s\s\s red/9 yellow/24 keyword linestart Entered-date:\s\s\s red/9 yellow/24 keyword linestart Description:\s\s\s\s red/9 yellow/24 keyword linestart Keywords:\s\s\s\s\s\s\s red/9 yellow/24 - keyword linestart Alternate-site:\s red/9 yellow/24 keyword linestart Primary-site:\s\s\s red/9 yellow/24 + keyword linestart Alternate-site:\s red/9 yellow/24 keyword linestart Original-site:\s\s red/9 yellow/24 keyword linestart Platforms:\s\s\s\s\s\s red/9 yellow/24 keyword linestart Copying-policy:\s red/9 yellow/24 @@ -16,11 +17,14 @@ keyword linestart \t\t white/26 yellow/24 keyword linestart \s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s white/26 yellow/24 - keyword whole GPL green/6 + keyword whole Artistic green/6 keyword whole BSD green/6 - keyword whole Shareware green/6 - keyword whole sunsite.unc.edu green/6 - keyword wholeright \s*.tar.gz green/6 + keyword whole GPL green/6 + keyword whole LGPL green/6 + keyword whole MIT/X green/6 + keyword whole Open Source green/6 + keyword whole ibiblio.org green/6 + keyword wholeright \s*.tar.* green/6 keyword wholeright \s*.lsm green/6 context linestart Author:\s\s\s\s\s\s\s\s\s \n brightred/19 @@ -28,6 +32,3 @@ context linestart Maintained-by:\s\s \n brightred/19 keyword whole \s*@*\s(*) cyan/16 - -############################################################################### - From sav at bcs.zp.ua Thu Aug 9 12:45:26 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Thu, 9 Aug 2001 15:45:26 +0300 Subject: Fix for another dala loss bug In-Reply-To: ; from proski@gnu.org on Wed, Aug 01, 2001 at 05:56:51PM -0400 References: Message-ID: <20010809154526.A379@bcs.zp.ua> Pavel Roskin wrote: : Hello! : : "Safe save" and "Do backups" don't work on the remote VFS. Fixing it : properly is quite hard, because it requires on implementation of rename() : on VFS. Well, we discussed mcedit's "Do backups" and "Safe save" algorithms in 1999. I still think it do this in wrong way. Below are some lines from my and Norbert's letters. >> * if 1 (safe save) then >> * a) save to , >> * b) rename to ; >> * should be: >> * a) copy to ; >> * b) truncate file; >> * c) save to ; >> * d) unlink ; >> Else all of the hard link(s) is/are linked to the old version, >> that are renamed or deleted. And symlinks are just removed now. > How is this done in other editors? To the user what's the least > surprise with respect to hardlinks - saving affects any file name > with the same inode or saving breaks the connection to other file > names with the same inode by creating a new inode? This done in proposed way in joe. : Editing files on VFS with those options on can cause loss of data. Such : bugs should have a very high priority for us. : Best regards, Andrew. From proski at gnu.org Fri Aug 10 06:23:03 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 10 Aug 2001 02:23:03 -0400 (EDT) Subject: [PATCH] FAQ In-Reply-To: <20010808043010.F135@pervalidus.net> Message-ID: Hi, Fr?d?ric! > > There is an xterm by Thomas Dickey, but rxvt is better > > anyway. > > I wouldn't say rxvt is better (both have features), but yes, > I don't list XTerm because it's part of XFree86. You are right. Statements about something being better are usually wrong. > Anyway, new releases are at ftp://dickey.his.com/xterm/ . If > you want, just change 4.7 to "Where can I get rxvt and > XTerm?" Done. Thanks for the idea. > BTW, the Mirrors list at the site is wrong. > http://www.cs-net.gr/mc/ (Greece) -> 404. Maybe "Mirrors :" > should be removed. The USA mirror is... the site. I've just remade that page completely and committed my changes. I don't know if they are propagated automatically. If the page doesn't change soon I'll talk to the webmaster. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 10 06:39:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 10 Aug 2001 02:39:26 -0400 (EDT) Subject: Fix for another data loss bug In-Reply-To: <20010809154526.A379@bcs.zp.ua> Message-ID: Hi! > : "Safe save" and "Do backups" don't work on the remote VFS. Fixing it > : properly is quite hard, because it requires on implementation of rename() > : on VFS. > > Well, we discussed mcedit's "Do backups" and "Safe save" algorithms in 1999. > I still think it do this in wrong way. Below are some lines from my and > Norbert's letters. > > >> * if 1 (safe save) then > >> * a) save to , > >> * b) rename to ; > >> * should be: > >> * a) copy to ; > >> * b) truncate file; > >> * c) save to ; > >> * d) unlink ; So, you are eliminating "rename"! I think it's an excellent idea and should be implemented some day. It can be slower on VFS, because "copy" may involve sending data back and forth, but it can be eliminated on FiSH. Anyway, this will be _really_ safe. > This done in proposed way in joe. That's very encouraging. Thank you for taking time to investigate. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 10 07:21:33 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 10 Aug 2001 03:21:33 -0400 (EDT) Subject: some propositions to improve mc... In-Reply-To: <200108080800.KAA03449@gateway1.guddland.lu> Message-ID: Hi, Benoit! > I don't know if it the place I hope. > I have some proposition to improve mc : Please always specify the version of the software you are going to improve. Also the name of your operating system can be useful. > - when the Quick View is used, and you browse a directory with > big fies (files of 1-2GB (ASCII Database export data) the mc takes a > long to show the file content ? I think that the internal viewer try > to load the full file and then display it ?? Isn't possible to load > only a part in a buffer and then load according to the user actions. > For example if we want to go to the end of the fiel to use a fseek (or > something like this.. ) to improve the response time !! I could not reproduce this problem with CVS version of MC running on Linux-2.4.7-ac10 with the files on reiserfs. I have no time to test all other combinations. I don't have OS/2 to test. If you want your reports to be taken seriously please give more information. I don't think that the viewer loads the whole file. The Quick View uses the same viewer code, and from what I see in the code it uses pages 8192 bytes each. > - is it possible to add in the listing mode an option to display > files attribute (unders OS/2 or Windows; I use OS/2 :) ) HRSA It's possible. The code may already be there. If it doesn't work report it as a bug. Describe what you are doing, what you get and what you expect to get. > - need a serious doc about the xternal panelize ?? Why do you think that the manual (and the chapter in the help) aren't serious? > - need info about the user-menu : which shell is used : which > indicated by the SHELL env var ?? The CVS version uses SHELL, which must be wrong - the menu is written for Bourne shell. But nobody has complained yet. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 10 08:29:46 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 10 Aug 2001 04:29:46 -0400 (EDT) Subject: More documentation cleanups In-Reply-To: <20010809003254.I135@pervalidus.net> Message-ID: Hi, Fr?d?ric! > Hi. I noticed there are still 5 404 www.gnome.org URLs in the > FAQ file. Attached is a suggested patch. Thank you. It would be nice to distribute binaries, but I have no time to organize it. I'm applying it, except that I'm removing 8.7. There is no need to suggest quick fixes for old versions unless it's security related. > Also, I think docs/LSM should be removed. The template is I'm removing both docs/LSM and docs/FILES. The later is also outdated, and it's a wrong place to put file descriptions. > outdated and doesn't belong to the distribution anymore. The > releases aren't uploaded to > sunsite.unc.edu^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H > metalab.unc.edu^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H ibiblio.org since > ages. And I'd suggested that a maintainer (Pavel ?) contact the > ibiblio.org ftpmaster, so he can remove > tp://www.ibiblio.org/pub/Linux/utils/file/managers/mc/ > . We don't want people blindly downloading and mirroring outdated > releases, right ? ibiblio.org is widely used. I've just sent them this request. > BTW, attached is a patch for the lsm syntax file. I don't know > if it's OK, but IMO it's better, so please verify. Did you > notice I don't endorse Shareware ? I could just change it to > black/0. I believe it's a very bad idea to push any political agenda by technical means of this kind. It's not an excuse that the existing file already does it. By the way, why don't you want to highlight Begin3? Just because it's obsolete? I think that the primary role of syntax highlighting should be showing the role of the highlighted text, not spotting errors, and certainly not determining the political correctness of software licenses. > What's the status of the BUGS file ? It's 2 years old. > Are they all closed ? I think it's another file that should > be removed or added to .cvsignore. Those bugs don't exist in the database. ftp.cs.cuc.edu doesn't allow anonymous login anymore. I'm removing this file. > The system types are duplicated in the FAQ (1.2 Does it run > on my machine?) and INSTALL (Notes about the Midnight > Commander installation) files. They're also listed in the LSM > file. Anyway, it'd be nice to know if the latest release > compiles on all these. I suggest that we reset those lists. I know that mc-4.5.54 doesn't compile on AIX due to a useless comma in the VFS code (only detected by "gcc -pedantic" which is unfortunately too noisy). Ideally, the list should correspond to the binaries available for download. -- Regards, Pavel Roskin From sxmboer at sci.kun.nl Fri Aug 10 19:42:53 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Fri, 10 Aug 2001 21:42:53 +0200 Subject: glib memory handling References: Message-ID: <3B74393D.15D9B5ED@sci.kun.nl> Hi Pavel, A couple of weeks ago we were discussing the relevance of mad.[ch] You answered that it wasn't so big, because glib took care of some of mad's features. I said I'd check with glib, which I did. I found that most of mad's features are not taken care of by glib: no array bound checking, no detailed tracking of memory leaks, no checks on deallocating non-existent mem-pointers, etc. The only thing I found (in glib-1.3.6) is a tiny piece of memory profiling, which can report the total amount of memory alloced/dealloced. I am aware, however, that GNU has Checker, which can be compiled into gcc. I have no experience with it (other than failing to be able to use it). Normally I would recommend fortify, but it is not completely free software, as one is free to use it, but not to distribute modified versions. So this convinced me that it would be usefull to improve mad. Steef From sxmboer at sci.kun.nl Fri Aug 10 20:04:52 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Fri, 10 Aug 2001 22:04:52 +0200 Subject: Cure for "BAD BUG REPORTS" References: Message-ID: <3B743E64.77931DD7@sci.kun.nl> Pavel, You have more than once cried out for help about people giving useless bug reports: > You forgot to mention the MC version and the OS name. Just imagine > somebody reporting a problem in _your_ software without telling you the > version and the OS it's running on! > > To list subscribers: what should we do about such messages? It's getting > increasingly annoying, and I'm sorry for adding the messages with "my > frequently asked questions" to the list traffic. Moving those question to > the private discussion is not a good idea - interesting facts in the end > of the discussion don't appear on the list. On the other hand, it's > better to educate people than to ignore them. Is there any good FAQ > describing how to report software problems? I have found a reasonable FAQ on the internet about bug reports: http://www.rescomp.berkeley.edu/about/HOWTO/Bug-Reports-HOWTO I would however urge you, Pavel, to include a file in the root directory of the upcoming mc-4.5.55. I saw a very good example in the source distribution of XFree86-4.1.0., which I have included for reference (bug-report). I've also made another version: bug-report-mc with some changes that are needed to use it in mc. It is not finished, so you should have a look at it and add the items that you find are important for mc bugs. A third alternative is to revert to solely use bugzilla, but I'm not very keen on that idea myself. regards, Steef -- ------------------------------------------------------------------------ Drs. S.X.M. Boerrigter RIM Laboratory of Solid State Chemistry, University of Nijmegen Toernooiveld 1, 6525 ED Nijmegen, The Netherlands Telephone: (+31)-(0)24-3652831 Fax:(+31)-(0)24-3653067 email: sxmboer at sci.kun.nl http://savannah.gnu.org/users/sxmboer ------------------------------------------------------------------------ Quidquid latine dictum sit, altum viditur. "Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things." --Doug Gwyn Murphy's law: Anyt -------------- next part -------------- [PLEASE make your Subject: line as descriptive as possible. Subjects like "xterm bug" or "bug report" are not helpful!] [Remove all the explanatory text in brackets before mailing.] [Send to xbugs at x.org, as shown in the sample message header below] To: xbugs at x.org Subject: [area]: [synopsis] [replace with actual area and short description] VERSION: R6.5.1, public-patch-1 CLIENT MACHINE and OPERATING SYSTEM: [e.g. Sparc/SunOS 5.6, S.u.S.E. Linux 5.0 kernel 2.0.30, etc.] DISPLAY TYPE: [e.g. Xsun, Xhp, Xdec, XF86_*, /usr/openwin/bin/Xsun, etc. ] WINDOW MANAGER: [e.g. twm, mwm, fvwm95, enlightenment, etc.] COMPILER: [e.g. native ANSI cc, native cc, ecgs 1.0, etc.] AREA: [Area of the source tree affected, e.g., Xserver, Xlib, Xt, Xaw, PEX, twm, xterm, xmh, config, .... Please only one area per bug report.] SYNOPSIS: [Brief description of the problem and where it is located] DESCRIPTION: [Detailed description of problem. Don't presume that the bug is self evident. If possible cite specification references (X, ANSI/POSIX/ISO, X/Open, etc.) to support why it is a bug. For program crashes a little bit of analysis about why a NULL pointer was dereferenced or why a buffer overflowed goes a long way. If this is a request for an enhancement, justify it.] REPEAT BY: [What you did to get the error; include test program or session transcript if at all possible. Be specific -- if we can't reproduce it, we can't fix it. Don't just say "run this program and it will be obvious," tell us exactly what we should see when the program is run. Bug reports without a clear, deterministic way of reproducing them will be fixed only after all bug reports that do.] SAMPLE FIX: [Please send context diffs (`diff -c original-file fixed-file`). Be sure to include the "XConsortium" or "TOG" ident line in any diffs -- the best way to do this is to add your own versioning line immediately after ours.] -------------- next part -------------- [PLEASE make your Subject: line as descriptive as possible. Subjects like "xterm bug" or "bug report" are not helpful!] [Remove all the explanatory text in brackets before mailing.] [Send to mc-devel at gnome.org, as shown in the sample message header below] To: mc-devel at gnome.org Subject: [area]: [synopsis] [replace with actual area and short description] VERSION: [e.g. mc-4.5.55] CLIENT MACHINE and OPERATING SYSTEM: [e.g. Sparc/SunOS 5.6, S.u.S.E. Linux 5.0 kernel 2.0.30, etc.] WINDOW MANAGER: [e.g. twm, mwm, fvwm95, enlightenment, etc. only needed for gnome related issues] TERMINAL: [e.g. rxvt, xterm, linux console, only needed for text based interface] COMPILER: [e.g. native ANSI cc, native cc, ecgs 1.0, gcc 3.0, etc.] AREA: [Area of the source tree affected, e.g., documentation, editor, vfs, shell... Please only one area per bug report.] SYNOPSIS: [Brief description of the problem and where it is located] DESCRIPTION: [Detailed description of problem. Don't presume that the bug is self evident. If possible cite specification references (X, ANSI/POSIX/ISO, X/Open, etc.) to support why it is a bug. For program crashes a little bit of analysis about why a NULL pointer was dereferenced or why a buffer overflowed goes a long way. If this is a request for an enhancement, justify it.] REPEAT BY: [What you did to get the error; include test program or session transcript if at all possible. Be specific -- if we can't reproduce it, we can't fix it. Don't just say "run this program and it will be obvious," tell us exactly what we should see when the program is run. Bug reports without a clear, deterministic way of reproducing them will be fixed only after all bug reports that do.] SAMPLE FIX: [Please send unified diffs (`diff -u original-file fixed-file`).] From lists at pervalidus.net Sat Aug 11 03:14:59 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 11 Aug 2001 00:14:59 -0300 Subject: More documentation cleanups Message-ID: <20010811001459.T135@pervalidus.net> Pavel Roskin wrote: >> BTW, attached is a patch for the lsm syntax file. I don't >> know if it's OK, but IMO it's better, so please verify. Did >> you notice I don't endorse Shareware ? I could just change it >> to black/0. > I believe it's a very bad idea to push any political agenda > by technical means of this kind. It's not an excuse that the > existing file already does it. :-) OK. Let's say I don't want to encourage anyone writing Shareware. Anyway, it's listed as an option in LSM-TEMPLATE. I also believe it's a bad idea to use 'linuxconf' and some other commands like 'taper' in the sh syntax file. IMO fileutils, sh-utils, textutils, util-linux and crucial packages that are part of any distribution should be enough. > By the way, why don't you want to highlight Begin3? Just > because it's obsolete? Because I thought it was an example to write an accurate .lsm file. And since syntax highlighting doesn't work with F3 (could be used with ftpfs), I see no other reason to maintain Begin3. Of course, it'd be nice to maintain it and have a way to let the author know it was obsoleted by Begin4. > I think that the primary role of syntax highlighting should be > showing the role of the highlighted text, not spotting errors, > and certainly not determining the political correctness of > software licenses. Then another change is incorrect, and we should list sunsite.unc.edu, metalab.unc.edu, and ibiblio.org ? Also, any better way to list .tar.Z tar.gz tar.bz2 ? I'd add 3 lines, but with \s*.tar.* it matches them (and anything else...). And attached is a suggested patch for the README file. Changes: - pub/GNOME/sources -> pub/GNOME/stable/sources - ftp.gnome.org uses the mirrors. - Removed "European mirrors". - Cosmetic changes (I don't think "GNU/Linux system" is correct. The only distribution using it deliberately is Debian. Thoughts ?). What about the undelete and 2.0 Kernel part ? Fixed in recent 2.0 ? 2.0.39 ? >> The system types are duplicated in the FAQ (1.2 Does it run >> on my machine?) and INSTALL (Notes about the Midnight >> Commander installation) files. They're also listed in the LSM >> file. Anyway, it'd be nice to know if the latest release >> compiles on all these. > Ideally, the list should correspond to the binaries available > for download. Why not reports of success like GCC ? You could ask in the announcement for 4.5.55 (use gnome-announce ?), and add a note to the INSTALL file asking the same if compiling the latest release. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) -------------- next part -------------- A non-text attachment was scrubbed... Name: README.patch.gz Type: application/octet-stream Size: 1858 bytes Desc: not available URL: From proski at gnu.org Sat Aug 11 05:11:31 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 11 Aug 2001 01:11:31 -0400 (EDT) Subject: glib memory handling In-Reply-To: <3B74393D.15D9B5ED@sci.kun.nl> Message-ID: Hi, Steef! > Normally I would recommend fortify, but it is not completely free > software, as one is free to use it, but not to distribute modified > versions. > > So this convinced me that it would be usefull to improve mad. May I suggest that you try your improved mad with something other than mc? I think this could be a separate package. I don't see much interest in the MC lists about the issue. In the meantime I'm disabling glib support in MAD - it's defunct. Many glib functions are not taken into account (perhaps some tricks are needed to avoid reimplemented them all) and g_free(NULL) is considered a problem while it is not. Such code should not be enabled for anybody except developers trying to fix it. MAD without glib support has immediately detected a serious problem in vfs/sfs.c. MC runs after fixing it, but it's still quite unstable. I'll not delay 4.5.55 to fix it - it may take a lot of time and it affects very few platforms - those that use different storage for g_malloc and malloc. -- Regards, Pavel Roskin ---------------------------------------- --- mad.h +++ mad.h @@ -46,6 +46,13 @@ #define strndup(x, n) mad_strndup (x, n, __FILE__, __LINE__) #define free(x) mad_free (x, __FILE__, __LINE__) +/* + * Define MAD_GLIB to debug allocations in glib as well. + * This code is not functional yet. + */ +#undef MAD_GLIB + +#ifdef MAD_GLIB /* These definitions are grabbed from GLib.h */ #define g_new(type, count) \ ((type *) g_malloc ((unsigned) sizeof (type) * (count))) @@ -63,6 +70,7 @@ #define g_strconcat mad_strconcat #define g_strdup_printf mad_strdup_printf #define g_strdup_vprintf mad_strdup_vprintf +#endif /* MAD_GLIB */ void mad_init (void); void mad_set_debug (const char *file); ---------------------------------------- From proski at gnu.org Sat Aug 11 05:40:45 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 11 Aug 2001 01:40:45 -0400 (EDT) Subject: Cure for "BAD BUG REPORTS" In-Reply-To: <3B743E64.77931DD7@sci.kun.nl> Message-ID: Hi, Steef! > I have found a reasonable FAQ on the internet about bug reports: > http://www.rescomp.berkeley.edu/about/HOWTO/Bug-Reports-HOWTO In my opinion, it is only oriented to the users of multiuser systems. Many MC users are sysadmings of the machines they run MC on. > I've also made another version: bug-report-mc with some changes that are > needed to use it in mc. It is not finished, so you should have a look at > it and add the items that you find are important for mc bugs. Yes, it needs some polishing, but it's a good document. This can actully help somebody. I'll probably put it into the distribution. Thank you. > A third alternative is to revert to solely use bugzilla, but I'm not > very keen on that idea myself. I share your feelings. -- Regards, Pavel Roskin From dmartina at excite.es Sat Aug 11 22:46:35 2001 From: dmartina at excite.es (David Martin) Date: Sat, 11 Aug 2001 15:46:35 -0700 (PDT) Subject: Double // in codepages list error Message-ID: <17552744.997569995285.JavaMail.imail@hippie.excite.com> The error message about the codepages list missing shows a double slash before the file name. Just in case, I have a K6-400 PC with a freshly installed Mandrake 8.0, gcc 2.96 and kernel 2.4.7 and I'm compiling yesterday's snapshot. Here's the quick fix using concat_dir_and_file. The same thing happens in the called function (load_codepages_list() in charsets.c) hidden and hopefully harmless... I hope I'm doing better with Changelogs this time. I've already updated Spanish translations, but I'll wait a couple of days for this one. *8-) David ----------------------------------- diff -upr mc-4.5.54a-proski/src/ChangeLog mc-4.5.54a/src/ChangeLog --- mc-4.5.54a-proski/src/ChangeLog Wed Aug 8 04:19:14 2001 +++ mc-4.5.54a/src/ChangeLog Sat Aug 11 18:40:58 2001 @@ -1,3 +1,8 @@ +2001-08-11 David Martin + + * setup.c (load_setup): Use concat_dir_and_file() to avoid + the double '//' in path to file in error message. + 2001-08-07 Pavel Roskin * view.c: Warning fixes. Include "cmd.h". Rename help_cmd() diff -upr mc-4.5.54a-proski/src/setup.c mc-4.5.54a/src/setup.c --- mc-4.5.54a-proski/src/setup.c Tue Jul 24 02:22:05 2001 +++ mc-4.5.54a/src/setup.c Sat Aug 11 18:30:35 2001 @@ -651,7 +651,9 @@ load_setup (void) #ifdef HAVE_CHARSET if ( load_codepages_list() <= 0 ) { - message( 1, MSG_ERROR, _("Can't load %s/%s"), mc_home, CHARSETS_INDEX ); + char *tmpbuf = concat_dir_and_file ( mc_home, CHARSETS_INDEX ); + message( 1, MSG_ERROR, _("Can't load %s"), tmpbuf ); + g_free ( tmpbuf ); } else { char cpname[128]; load_string( "Misc", "display_codepage", "", _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qcharset_err0.diff URL: From proski at gnu.org Sun Aug 12 03:12:19 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 11 Aug 2001 23:12:19 -0400 (EDT) Subject: Double // in codepages list error In-Reply-To: <17552744.997569995285.JavaMail.imail@hippie.excite.com> Message-ID: Hi, David! > Here's the quick fix using concat_dir_and_file. The problem is not in the error message. concat_dir_and_file() should be used in load_codepages_list() (it is not used) and the message should be there, because only that function knows what happened, what file it _actually_ tried to open and whether the problem is worth user's attention. Guessing what file load_codepages_list() was trying to load is a bad idea. load_codepages_list() always uses '/', while concat_dir_and_file() used the OS-specific path separator. It may happen that load_codepages_list() e.g. on Windows tries to load "\usr\local\lib\mc/mc.charsets" while load_setup() would say that "\usr\local\lib\mc\mc.charsets" could not be loaded. That could mean hiding a problem, which defeats the whole purpose of this message. I understand that my criticism really should be directed at Walery, but I'm asking everybody to clean up the code being modified instead of piling one "quick fix" onto another. I'm not applying your patch - it cures the symptoms, not the disease. By the way, if you _have_ to introduce a new translatable message please avoid that british "Can't" - write "Cannot" instead. -- Regards, Pavel Roskin From despair at sama.ru Sun Aug 12 14:10:12 2001 From: despair at sama.ru (Walery Studennikov) Date: Sun, 12 Aug 2001 10:10:12 -0400 Subject: Double // in codepages list error In-Reply-To: ; from proski@gnu.org on Sat, Aug 11, 2001 at 11:12:19PM -0400 References: <17552744.997569995285.JavaMail.imail@hippie.excite.com> Message-ID: <20010812101012.B7877@localhost.localdomain> On Sat, Aug 11, 2001 at 11:12:19PM -0400, Pavel Roskin wrote: > > I understand that my criticism really should be directed at Walery, but > I'm asking everybody to clean up the code being modified instead of piling > one "quick fix" onto another. The patch is attached. Now we use concat_dir_and_file in charsets.c and on error we return filename that we failed to open. Regards, Walery -------------- next part -------------- 582c582 < char *profile; --- > char *profile, *cpindex_filename; 653,654c653,655 < if ( load_codepages_list() <= 0 ) { < message( 1, MSG_ERROR, _("Can't load %s/%s"), mc_home, CHARSETS_INDEX ); --- > if ( (cpindex_filename = load_codepages_list()) ) { > message( 1, MSG_ERROR, _("Cannot load %s"), cpindex_filename ); > g_free( cpindex_filename ); -------------- next part -------------- 7a8 > #include 9a11 > #include "util.h" 20c22,23 < int load_codepages_list(void) --- > /* When it fails it returns the filename */ > char* load_codepages_list(void) 22d24 < int result = -1; 27c29,31 < char * default_codepage = NULL; --- > char* default_codepage = NULL; > char* cpindex_filename = > concat_dir_and_file( mc_home, CHARSETS_INDEX ); 29,32c33,34 < strcpy ( buf, mc_home ); < strcat ( buf, "/" CHARSETS_INDEX ); < if ( !( f = fopen( buf, "r" ) ) ) < return -1; --- > if ( !( f = fopen( cpindex_filename, "r" ) ) ) > return cpindex_filename; 78c80,81 < result = n_codepages; --- > g_free( cpindex_filename ); > cpindex_filename = NULL; 81c84 < return result; --- > return cpindex_filename; -------------- next part -------------- 26c26 < int load_codepages_list(void); --- > char* load_codepages_list(void); From proski at gnu.org Sun Aug 12 05:35:44 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 01:35:44 -0400 (EDT) Subject: lsm.syntax (Re: More documentation cleanups) In-Reply-To: <20010811001459.T135@pervalidus.net> Message-ID: Hi, Fr?d?ric! > > I believe it's a very bad idea to push any political agenda > > by technical means of this kind. It's not an excuse that the > > existing file already does it. > > :-) OK. Let's say I don't want to encourage anyone writing > Shareware. Anyway, it's listed as an option in LSM-TEMPLATE. Still, it's not a function of the syntax checker. > I also believe it's a bad idea to use 'linuxconf' and some other > commands like 'taper' in the sh syntax file. IMO fileutils, sh-utils, > textutils, util-linux and crucial packages that are part of any > distribution should be enough. I agree, but I also think that the syntax checker should not know about any commands at all. Otherwise it's not a _syntax_ checking. > > By the way, why don't you want to highlight Begin3? Just > > because it's obsolete? > > Because I thought it was an example to write an accurate .lsm > file. And since syntax highlighting doesn't work with F3 (could > be used with ftpfs), I see no other reason to maintain Begin3. > Of course, it'd be nice to maintain it and have a way to let > the author know it was obsoleted by Begin4. The editor works on VFS in the CVS version of MC (but please don't write your love letters and resumes on VFS - I don't feel it has received a good testing so far). The editor has been ported from Cooledit, and I think that at the syntax rules should be synchronized with Cooledit from time to time. The actual code except the syntax engine probably should not be synchronized anymore, but it's debatable. I believe that MC should not change the meaning of "syntax highlighting" to something incompatible with Cooledit. Maybe this should issue should be discussed in the Cooledit mailing list (if it exists). I feel uncomfortable that two separate groups of developers (MC and Cooledit) may be discussing the same issues without talking to each other. > > I think that the primary role of syntax highlighting should be > > showing the role of the highlighted text, not spotting errors, > > and certainly not determining the political correctness of > > software licenses. > > Then another change is incorrect, and we should list > sunsite.unc.edu, metalab.unc.edu, and ibiblio.org ? Also, any I fail to see any reason to highlight URLs. They should be checked in the browser, not in the editor. > better way to list .tar.Z tar.gz tar.bz2 ? I'd add 3 lines, but > with \s*.tar.* it matches them (and anything else...). Again I don't understand why they should be highlighted. Perhaps somebody with an incorrect understanding of the word "syntax" (see webster.com for the definition) put this lsm.syntax together and now you are wasting your time trying to fix something broken by design. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 12 06:14:18 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 02:14:18 -0400 (EDT) Subject: README patch (Re: More documentation cleanups) In-Reply-To: <20010811001459.T135@pervalidus.net> Message-ID: > And attached is a suggested patch for the README file. Changes: > > - pub/GNOME/sources -> pub/GNOME/stable/sources Ok > - ftp.gnome.org uses the mirrors. Not sure what you mean. I don't see it in the patch. > - Removed "European mirrors". Ok > - Cosmetic changes (I don't think "GNU/Linux system" is > correct. The only distribution using it deliberately is Debian. > Thoughts ?). I think it was used correctly in this context. I use "Linux" if 1) it's about the kernel or kernel-specific features (e.g. ext2 undelete) 2) "Linux" is used in the distribution name. GNU/Linux is appropiate to denote the build system plus the kernel (which was the case in the document) or the whole OS. I'm applying your patch without this part. > What about the undelete and 2.0 Kernel part ? Fixed in recent > 2.0 ? 2.0.39 ? I'm sorry, but I have no time to investigate. > > Ideally, the list should correspond to the binaries available > > for download. > > Why not reports of success like GCC ? You could ask in the > announcement for 4.5.55 (use gnome-announce ?), and add a > note to the INSTALL file asking the same if compiling the > latest release. GCC is an extreme case. It may be hard to compile it if you don't already have it. I think that MC should follow the policy of GNOME with regard to the binary releases if it uses the GNOME ftp server. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 12 06:26:58 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 02:26:58 -0400 (EDT) Subject: Double // in codepages list error In-Reply-To: <20010812101012.B7877@localhost.localdomain> Message-ID: On Sun, 12 Aug 2001, Walery Studennikov wrote: > On Sat, Aug 11, 2001 at 11:12:19PM -0400, Pavel Roskin wrote: > > > > I understand that my criticism really should be directed at Walery, but > > I'm asking everybody to clean up the code being modified instead of piling > > one "quick fix" onto another. > > The patch is attached. > Now we use concat_dir_and_file in charsets.c and on error we > return filename that we failed to open. It's ugly. It's a nontrivial use of the return value that should be at least commented in the code (ideally: avoided). I don't understand what's wrong with moving the error messages to charset.c from setup.c as I proposed. Please use unified diff next time. By the way, I've already fixed charset.c to use concat_dir_and_file(). The only remaining change is moving GUI where it belongs. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 12 08:21:14 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 04:21:14 -0400 (EDT) Subject: Fix for case sensitive sort Message-ID: Hello! I have investigated the problem with strcoll() and it appears that there is a graceful (to a certain extent) solution. MC gives the user choice between case sensitive and case insensitive sort. There is no localized case sensitive sort, so strcmp() should be used for that. In the remaining case of case insensitive strcoll() is preferred since it respects the user settings, but it's not case insensitive in the POSIX locale. On the other hand, POSIX locale is where g_strcasecmp() shines. However, it doesn't work well in some non-C locales (e.g. Turkish). Solution: use strcoll() if it's case insensitive (i.e. it does what the user has requested in the MC menu), but if it's case sensitive, then use g_strcasecmp() from Glib. -- Regards, Pavel Roskin ------------------------------------------------ --- ChangeLog +++ ChangeLog @@ -1 +1,8 @@ +2001-08-12 Pavel Roskin + + * dir.c (string_sortcomp) [HAVE_STRCOLL]: Always use strcmp() + for case sensitive sort. For case insensitive sort use + strcoll() if it's case insensitive for ASCII and g_strcasecmp() + otherwise. + 2001-08-11 Pavel Roskin --- dir.c +++ dir.c @@ -76,14 +76,44 @@ sort_orders_t sort_orders [SORT_TYPES_TO { N_("&Group"), sort_group } }; +#ifdef HAVE_STRCOLL /* - * FIXME: strcoll() is not case sensitive in some locales, including en_US. - * The user gets a "choice" between two case insensitive sorts. - * Ideally, the user should be able to select between all three functions - - * strcoll() (if available), strcmp() and g_strcasecmp(). + * g_strcasecmp() doesn't work well in some locales because it relies on + * the locale-specific toupper(). On the other hand, strcoll() is case + * sensitive in the "C" and "POSIX" locales, unlike other locales. + * Solution: always use strcmp() for case sensitive sort. For case + * insensitive sort use strcoll() if it's case insensitive for ASCII and + * g_strcasecmp() otherwise. */ -#ifdef HAVE_STRCOLL -#define string_sortcomp(a,b) (case_sensitive ? strcoll (a,b) : g_strcasecmp (a,b)) +typedef enum { + STRCOLL_NO, + STRCOLL_YES, + STRCOLL_TEST +} strcoll_status; + +int string_sortcomp (char *str1, char *str2) +{ + static strcoll_status use_strcoll = STRCOLL_TEST; + + if (case_sensitive) { + return strcmp (str1, str2); + } + + /* Initialize use_strcoll once. */ + if (use_strcoll == STRCOLL_TEST) { + /* Only use strcoll() if it considers "B" between "a" and "c". */ + if (strcoll ("a", "B") * strcoll ("B", "c") > 0) { + use_strcoll = STRCOLL_YES; + } else { + use_strcoll = STRCOLL_NO; + } + } + + if (use_strcoll == STRCOLL_NO) + return g_strcasecmp (str1, str2); + else + return strcoll (str1, str2); +} #else #define string_sortcomp(a,b) (case_sensitive ? strcmp (a,b) : g_strcasecmp (a,b)) #endif ------------------------------------------------ From lists at pervalidus.net Sun Aug 12 08:34:16 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sun, 12 Aug 2001 05:34:16 -0300 Subject: README patch (Re: More documentation cleanups) Message-ID: <20010812053416.O135@pervalidus.net> Pavel Roskin wrote: >> - ftp.gnome.org uses the mirrors. > Not sure what you mean. I don't see it in the patch. Try to connect to ftp.gnome.org. It uses the mirrors, not the same old and busy site. BTW, the mirrors mirror from ? Good question. A secret ? I removed "Please note that this is a very busy site; use a mirror if possible." > What about the undelete and 2.0 Kernel part ? Fixed in > recent 2.0 ? 2.0.39 ? > I'm sorry, but I have no time to investigate. Maybe Pavel Machek know... -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Sun Aug 12 08:36:40 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 04:36:40 -0400 (EDT) Subject: Important typo fix in guess_message_value() Message-ID: Hello! Function guess_message_value() used the "LC_MESSAGE" environment variable (along with some others) to determine the locale settings. What was meant is obviously "LC_MESSAGES" - the variable that affects the messages translated by gettext. I'm replacing "LC_MESSAGE" with "LC_MESSAGES" so that the hints and the translations can be set by the same variable that doesn't affect other locale settings (e.g. LC_COLLATE). -- Regards, Pavel Roskin -------------------------------- --- ChangeLog +++ ChangeLog @@ -2,2 +2,5 @@ + * cmd.c (guess_message_value): Typo - replace "LC_MESSAGE" with + "LC_MESSAGES". + * dir.c (string_sortcomp) [HAVE_STRCOLL]: Always use strcmp() --- cmd.c +++ cmd.c @@ -1206,8 +1206,8 @@ void mkdir_panel_cmd (void) mkdir_cmd (cpanel); } -/* partly taken from dcgettect.c, returns "" for C locale */ -/* value should be gfreed by calling function */ +/* partly taken from dcigettext.c, returns "" for default locale */ +/* value should be freed by calling function g_free() */ char *guess_message_value (unsigned want_info) { const char *var[] = { @@ -1217,7 +1217,7 @@ char *guess_message_value (unsigned want /* Setting of LC_ALL overwrites all other. */ "LC_ALL", /* Next comes the name of the desired category. */ - "LC_MESSAGE", + "LC_MESSAGES", /* Last possibility is the LANG environment variable. */ "LANG", /* NULL exit loops */ -------------------------------- From maddog at linuxhall.org Sun Aug 12 12:03:37 2001 From: maddog at linuxhall.org (R.I.P. Deaddog) Date: Sun, 12 Aug 2001 20:03:37 +0800 (HKT) Subject: Important typo fix in guess_message_value() In-Reply-To: Message-ID: On Sun, 12 Aug 2001, Pavel Roskin wrote: > Function guess_message_value() used the "LC_MESSAGE" environment variable > (along with some others) to determine the locale settings. > > What was meant is obviously "LC_MESSAGES" - the variable that affects the > messages translated by gettext. > > I'm replacing "LC_MESSAGE" with "LC_MESSAGES" so that the hints and the > translations can be set by the same variable that doesn't affect other > locale settings (e.g. LC_COLLATE). Hmmm, this reminds me of a problem I have forgot to tell in detail: e.g. if $LANGUAGE is picked [it is at the first priority in guess_message_value() ], then if $LANGUAGE is set to something like "de:fr:pt_BR", then the hint file "/usr/lib/mc/mc.hint.de:fr:pt_BR" is searched, which obviously doesn't exist, and the fallback "/usr/lib/mc/mc.hint.de" will be used instead. In this case is it more appropriate to search for "/usr/lib/mc/mc.hint.fr" and "/usr/lib/mc/mc.hint.pt_BR" instead? Abel From proski at gnu.org Sun Aug 12 16:56:44 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 12:56:44 -0400 (EDT) Subject: Important typo fix in guess_message_value() In-Reply-To: Message-ID: Hi! > Hmmm, this reminds me of a problem I have forgot to tell in detail: > > e.g. if $LANGUAGE is picked [it is at the first priority in > guess_message_value() ], then if $LANGUAGE is set to something like > "de:fr:pt_BR", then the hint file "/usr/lib/mc/mc.hint.de:fr:pt_BR" is > searched, which obviously doesn't exist, and the fallback > "/usr/lib/mc/mc.hint.de" will be used instead. In this case is it more > appropriate to search for "/usr/lib/mc/mc.hint.fr" and > "/usr/lib/mc/mc.hint.pt_BR" instead? I remember this problem. I just looked into dcigettext.c from gettext-0.10.39, and it turns out that guess_category_value() is a static function. Its result (possibly the colon-separated value of LANGUAGE) is used in dcigettext(), which parses the colons. I don't see how to use dcigettext() in guess_message_value(). LANGUAGE is a GNU extention, but its implementation is internal to the gettext library. I don't want to reimplement the same code. If gettext maintainers don't want external programs to use their extensions it's better to tell them that they are wrong than to copy their code against their will. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 12 18:09:47 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 12 Aug 2001 14:09:47 -0400 (EDT) Subject: Patch for switching to subshel in editor and viewer In-Reply-To: <20010806142409.A13327@localhost.localdomain> Message-ID: Hi, Walery! > Ok, now Ctrl-O and '!' reuse the same core. I applied a patch a few day ago where Ctrl-O in the viewer uses the same code as the panels (view_other_cmd), whereas '!' works as it worked before (it forces the shell even if the subshell is not supports). I think it's the most consistent and backwards-compatible behavior. > > What's wrong with `F11 s'? Is it really so important to access the same > > shell used by MC as subshell? > > Yes, it may be important. > For instance if you want to see output of the previous command > of if you continue to do the same task in the subshell. I agree. Indeed, it's better to have the same Ctrl-O behavior in all three modes (panels, viewer, editor), > > And why Ctrl-Shift-O? This won't work on remote terminals at all. Maybe > > it's better to redefine "Open" to another key in the editor? Can you > > check what is the "traditional" key to open a new file? GNOME uses F3, > > but how about Far. > > Fixed. "Open file" is rebinded to F18 > (anyway IMHO this is not used very often). This choice seems random to me. There is a good reason why it's not used often - because it's easier to select the file on the panel. I'm removing the shortcut completely, both in the intuitive and in the emacs mode. > Now Ctrl-O is also used here for invoking subshell. You are doing it on a very low level. My implementation uses a new action, CK_Shell. > Well, all problems are fixed. > Now we have the same keys in all modes of operation. > Also we invoke the same subshell. > Also this will work in the remote terminals. > I see no obstacles for including this into CVS. I'm applying my patch, but it does what you want. ChangeLog: * edit_key_translator.c (cooledit_key_map): Use Ctrl-O for subshell, not for "Open file...". (emacs_key_map): Likewise. * edit.c: Handle CK_Shell. * editcmddef.h: Define CK_Shell. * editmenu.c (FileMenu): Remove C-o from the "Open file..." item. (FileMenuEmacs): Likewise. The message "&Open file..." is new. It should be translated. There is one problem - exiting from the subshell while in the viewer and editor is not handled gracefully. I don't think that MC should exit if a modified file is loaded in the editor just because the user typed "exit" in the subshell. -- Regards, Pavel Roskin ------------------------------------------- --- edit/edit_key_translator.c +++ edit/edit_key_translator.c @@ -47,7 +47,7 @@ KEY_PPAGE, CK_Page_Up, KEY_NPAGE, CK_Page_Down, KEY_LEFT, CK_Left, KEY_RIGHT, CK_Right, KEY_UP, CK_Up, KEY_DOWN, CK_Down, ALT ('\t'), CK_Return, ALT ('\n'), CK_Return, KEY_HOME, CK_Home, KEY_END, CK_End, '\t', CK_Tab, XCTRL ('u'), CK_Undo, KEY_IC, CK_Toggle_Insert, - XCTRL ('o'), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, + XCTRL ('o'), CK_Shell, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, KEY_F (6), CK_Move, KEY_F (8), CK_Remove, KEY_F (12), CK_Save_As, KEY_F (2), CK_Save, XCTRL ('n'), CK_New, XCTRL ('l'), CK_Refresh, ESC_CHAR, CK_Exit, KEY_F (10), CK_Exit, @@ -70,7 +70,7 @@ KEY_PPAGE, CK_Page_Up, KEY_NPAGE, CK_Page_Down, KEY_LEFT, CK_Left, KEY_RIGHT, CK_Right, KEY_UP, CK_Up, KEY_DOWN, CK_Down, ALT ('\t'), CK_Return, ALT ('\n'), CK_Return, KEY_HOME, CK_Home, KEY_END, CK_End, '\t', CK_Tab, XCTRL ('u'), CK_Undo, KEY_IC, CK_Toggle_Insert, - XCTRL ('o'), CK_Load, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, + XCTRL ('o'), CK_Shell, KEY_F (3), CK_Mark, KEY_F (13), CK_Column_Mark, KEY_F (5), CK_Copy, KEY_F (6), CK_Move, KEY_F (8), CK_Remove, KEY_F (12), CK_Save_As, KEY_F (2), CK_Save, ALT ('p'), CK_Paragraph_Format, --- gtkedit/edit.c +++ gtkedit/edit.c @@ -2612,6 +2612,9 @@ int edit_execute_cmd (WEdit * edit, int case CK_Mail: edit_mail_dialog (edit); break; + case CK_Shell: + view_other_cmd (); + break; #endif /* These commands are not handled and must be handled by the user application */ --- gtkedit/editcmddef.h +++ gtkedit/editcmddef.h @@ -142,6 +142,8 @@ #define CK_Selection_History 704 #ifdef MIDNIGHT /* cooledit now has its own full-featured script editor and executor */ +#define CK_Shell 801 + /* Process a block through a shell command: CK_Pipe_Block(i) executes shell_cmd[i]. shell_cmd[i] must process the file ~/cooledit.block and output ~/cooledit.block --- gtkedit/editmenu.c +++ gtkedit/editmenu.c @@ -125,7 +125,7 @@ void edit_user_menu_cmd (void) static menu_entry FileMenu[] = { - {' ', N_("&Open/load... C-o"), 'O', menu_load_cmd}, + {' ', N_("&Open file..."), 'O', menu_load_cmd}, {' ', N_("&New C-n"), 'N', menu_new_cmd}, {' ', "", ' ', 0}, {' ', N_("&Save F2"), 'S', menu_save_cmd}, @@ -144,7 +144,7 @@ static menu_entry FileMenu[] = static menu_entry FileMenuEmacs[] = { - {' ', N_("&Open/load... C-o"), 'O', menu_load_cmd}, + {' ', N_("&Open file..."), 'O', menu_load_cmd}, {' ', N_("&New C-x k"), 'N', menu_new_cmd}, {' ', "", ' ', 0}, {' ', N_("&Save F2"), 'S', menu_save_cmd}, ------------------------------------------- From despair at sama.ru Mon Aug 13 03:34:36 2001 From: despair at sama.ru (Walery Studennikov) Date: Sun, 12 Aug 2001 23:34:36 -0400 Subject: gmo cleanup Message-ID: <20010812233436.A5346@localhost.localdomain> Now when we "make clean" po/*.gmo files is not cleaned. From dmartina at excite.es Sun Aug 12 21:55:02 2001 From: dmartina at excite.es (David Martin) Date: Sun, 12 Aug 2001 14:55:02 -0700 (PDT) Subject: Double // in codepages list error Message-ID: <10529316.997653302823.JavaMail.imail@hippie.excite.com> > Hi, David! > > > Here's the quick fix using concat_dir_and_file. > > The problem is not in the error message. concat_dir_and_file() should be > used in load_codepages_list() (it is not used) and the message should be > there, because only that function knows what happened, what file it > _actually_ tried to open and whether the problem is worth user's > attention. I agree. I did this patch too, but I thought it might not be a good idea to send it. > > I understand that my criticism really should be directed at Walery, but > I'm asking everybody to clean up the code being modified instead of piling > one "quick fix" onto another. > > I'm not applying your patch - it cures the symptoms, not the disease. > > By the way, if you _have_ to introduce a new translatable message please > avoid that british "Can't" - write "Cannot" instead. > The line was there before. It wasn't me: Don't blame me. What about en_GB.po? Once someone complained in the list about it. ...and what about OK and Ok? How do "you" spell it? (I'm actually Australian but I've lived in Spain since I was 4 :) English humor, you know! You made no changes in setup.c so the original message and the "//" stay there. Is this the final solution? Keep in mind when changing charsets.c that the load_codepages_list() has two "return" (...) and that the message is now displayed both when the file is missing and when there are no codepages (<= 0). Just in case it's of any use here's the second patch I made. Someone could argue not to place GUI in charsets.c and this was the second reason no to post it yesterday. *8-) David _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qcharset_err2.diff URL: From dmartina at excite.es Sun Aug 12 22:01:54 2001 From: dmartina at excite.es (David Martin) Date: Sun, 12 Aug 2001 15:01:54 -0700 (PDT) Subject: gmo cleanup Message-ID: <6950619.997653714209.JavaMail.imail@hippie.excite.com> El Sun, 12 Aug 2001 23:34:36 -0400, Walery Studennikov escribi?: > Now when we "make clean" po/*.gmo files is not cleaned. > I remember I had problems in our old Sun (Solaris 2.5.1) and I had to copy the .gmo files from another machine. I think that is the reason to include them with releases and snapshots. *8-) David _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es From despair at sama.ru Mon Aug 13 07:37:04 2001 From: despair at sama.ru (Walery Studennikov) Date: Mon, 13 Aug 2001 12:37:04 +0500 Subject: New "Multiscreen" megapatch Message-ID: <20010813123704.A9842@localhost.localdomain> Hi, All! This patch (mc-multiscreen-patch) adds possibility to open multiple internal viewers and internal editors at once. This fearure is almost the same as in the FAR manager. I'm sure it is will be very convenient for developers, but not only. When you have at least one open editor or viewer, you can use the following keys: F12: Call "dialog list" to choose dialog to switch to. Just like FAR manager. Alt-U: Switch to previous dialog Alt-I: Switch to next dialog So, you can, for instance, open a viewer, switch to file manager, open editor, switch to file manager again, open another editor, switch to previous editor, etc. When you exit from MC when other editors and/or viewers are sleeping in the background, all viewers and unmodified editors are killed, but modified editors are activated and user have exit from this editors manually with or without saving a file. Now about the implementation. Implementing this feature was impossible without special hacks on MC dialog management system. With old system ALL dialogs HAVE TO BE modal, so you couldn't switch between whem randomly. But now it is fixed. Almost all screen switching framework is incorporated in the new module: dlglist.c. Now about applying the patch. Almost ALL new or changed code in enclosed into the #ifdef HAVE_DLGSWITCH #endif pair. HAVE_DLGSWITCH can be defined in config.h. So it is (probably) safe to apply to current sources, because it is easy to turn off the feature. Only some peaces of code is not enclosed in #ifdef HAVE_DLGSWITCH .. #endif pair. For example it is a new glib-based logging handler in main.c. I thinks it will be useful for debugging various peaces of MC anyway. Probably we can make this feature "experimental" and provide a ./configure switch to turn it on, for example "--enable-multiscreen" or "--enable-dlgswitch". About debugging. The patch extensively uses glib-based logging for debugging purposes. To turn this logging on you have to #define MY_DEBUG in config.h. The handler writes all logging messages to ~/.mc/debug.log. Without #define MY_DEBUG only fatal errors is handled: an error message is printed on the screen and program aborts with a core dump. IMO this logging framework can be used in other parts of MC as well. IMPORTANT NOTE! The patch is big and complex (that's why I've called it "megapatch"), so it should be applied AFTER the new release, but BEFORE cleaning from GNOME. If we clean from GNOME before applying the patch it would be wery difficult to apply it cause HUGE changes in the source core. The patch itself is located at http://www.sama.ru/~despair/mc-multiscreen-patch-0.1.tar.gz Enjoy it! Regards, Walery From bmidy at guddland.lu Mon Aug 13 10:12:34 2001 From: bmidy at guddland.lu (Benoit Midy) Date: Mon, 13 Aug 01 10:12:34 Subject: unsuscribe Message-ID: <200108130812.KAA19552@gateway1.guddland.lu> unsuscribe Benoit Midy Guddland Digital S.A. Luxembourg Tel: (352) 50 35 21 / 360 mailto:bmidy at guddland.lu http://www.guddland.lu From bmidy at guddland.lu Mon Aug 13 10:28:00 2001 From: bmidy at guddland.lu (Benoit Midy) Date: Mon, 13 Aug 01 10:28:00 Subject: (no subject) Message-ID: <200108130827.KAA02022@gateway1.guddland.lu> unsuscribe guddland From sav at bcs.zp.ua Mon Aug 13 10:05:12 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Mon, 13 Aug 2001 13:05:12 +0300 Subject: Fix for another data loss bug In-Reply-To: ; from proski@gnu.org on Fri, Aug 10, 2001 at 02:39:26AM -0400 References: <20010809154526.A379@bcs.zp.ua> Message-ID: <20010813130512.A24256@bcs.zp.ua> Pavel Roskin wrote: : Hi! : : > : "Safe save" and "Do backups" don't work on the remote VFS. Fixing it : > : properly is quite hard, because it requires on implementation of rename() : > : on VFS. What is wrong with rename on VFS? It is work well on ftpfs and smbfs as far as I know. And I think it is ok on fish. BTW, C-q is documented but does not work on command prompt in text edition. I use Slackware 7.1 based Linux distribution. Test case: $ echo "[ C-q Tab ]" There is dot "." in command prompt and nothing in shell. Another stange bug. Keypad asterics '*' is shown as 'o' letter in command prompt in xterm and all is fine in subshell (C-O). Best regards, Andrew. From sxmboer at sci.kun.nl Mon Aug 13 14:59:35 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Mon, 13 Aug 2001 16:59:35 +0200 Subject: README patch (Re: More documentation cleanups) References: Message-ID: <3B77EB57.65375356@sci.kun.nl> Pavel, It's true what Fr?d?ric states. If I lookup ftp.gnome.org from The Netherlands: # nslookup ftp.gnome.org it is addressed to 130.239.18.141:churchill.acc.umu.se It is apparently an automatic redirect scheme of the gnome project. > Not sure what you mean. I don't see it in the patch. > > - Removed "European mirrors". If you do an nslookup from within America you probably don't notice any redirection. Since the automatic mirroring is transparent and not an mc feature, I think it is irrelevant to put a note in the mc documentation. In other words: Fr?d?ric was right, but I still support your decision. Regards, Steef -- ------------------------------------------------------------------------ Drs. S.X.M. Boerrigter RIM Laboratory of Solid State Chemistry, University of Nijmegen Toernooiveld 1, 6525 ED Nijmegen, The Netherlands Telephone: (+31)-(0)24-3652831 Fax:(+31)-(0)24-3653067 email: sxmboer at sci.kun.nl http://savannah.gnu.org/users/sxmboer ------------------------------------------------------------------------ Quidquid latine dictum sit, altum viditur. "Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things." --Doug Gwyn Murphy's law: Anyt From proski at gnu.org Mon Aug 13 15:39:36 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 13 Aug 2001 11:39:36 -0400 (EDT) Subject: README patch (Re: More documentation cleanups) In-Reply-To: <3B77EB57.65375356@sci.kun.nl> Message-ID: Hi, Steef! > It's true what Fr?d?ric states. > If I lookup ftp.gnome.org from The Netherlands: > # nslookup ftp.gnome.org > it is addressed to > 130.239.18.141:churchill.acc.umu.se This is from the fencepost.gnu.org (Boston, USA) $ host ftp.gnome.org ftp.gnome.org CNAME ftp.acc.umu.se ftp.acc.umu.se CNAME churchill.acc.umu.se churchill.acc.umu.se A 130.239.18.141 And this is from sp.red-bean.com (Chicago, USA): $ host ftp.gnome.org ftp.gnome.org CNAME ftp.acc.umu.se ftp.acc.umu.se CNAME churchill.acc.umu.se churchill.acc.umu.se A 130.239.18.141 > It is apparently an automatic redirect scheme of the gnome project. Why "apparently"? > If you do an nslookup from within America you probably don't notice any > redirection. Unfortunately, I do. Those sites are quite slow sometimes. Anyway, I agree that there is nothing to be written about it in the documentation. -- Regards, Pavel Roskin From sxmboer at sci.kun.nl Mon Aug 13 16:51:45 2001 From: sxmboer at sci.kun.nl (Steef Boerrigter) Date: Mon, 13 Aug 2001 18:51:45 +0200 Subject: README patch (Re: More documentation cleanups) References: Message-ID: <3B7805A1.141E2A1C@sci.kun.nl> Hi, Pavel! > This is from the fencepost.gnu.org (Boston, USA) > > $ host ftp.gnome.org > ftp.gnome.org CNAME ftp.acc.umu.se > ftp.acc.umu.se CNAME churchill.acc.umu.se > churchill.acc.umu.se A 130.239.18.141 > > And this is from sp.red-bean.com (Chicago, USA): > > $ host ftp.gnome.org > ftp.gnome.org CNAME ftp.acc.umu.se > ftp.acc.umu.se CNAME churchill.acc.umu.se > churchill.acc.umu.se A 130.239.18.141 > > It is apparently an automatic redirect scheme of the gnome project. > Why "apparently"? Longman dictionary of contemporary English: ap.par.ent.ly adv 2 according to the way someone looks or a situation appears, although you canot be sure: She managed to climb out of her car, apparently unhurt. To me the situation is that a name lookup redirects to Sweden. This IP is generated by my name server and I have no idea where it gets it's information from. Hence I could not be sure whether this redirection was standard for the entire world, which appears to be so, based on your information from fencepost. Since I don't think I have a login account there and don't seem to be able to get my ssh to work anyway, I never bothered to check. Hence it appeared to be a redirection, but I wasn't sure, so I used the word "apparently". Steef From maddog at linuxhall.org Mon Aug 13 19:37:30 2001 From: maddog at linuxhall.org (R.I.P. Deaddog) Date: Tue, 14 Aug 2001 03:37:30 +0800 (HKT) Subject: README patch (Re: More documentation cleanups) In-Reply-To: <3B7805A1.141E2A1C@sci.kun.nl> Message-ID: On Mon, 13 Aug 2001, Steef Boerrigter wrote: > > This is from the fencepost.gnu.org (Boston, USA) > > > > $ host ftp.gnome.org > > ftp.gnome.org CNAME ftp.acc.umu.se > > ftp.acc.umu.se CNAME churchill.acc.umu.se > > churchill.acc.umu.se A 130.239.18.141 > > > > And this is from sp.red-bean.com (Chicago, USA): > > > > $ host ftp.gnome.org > > ftp.gnome.org CNAME ftp.acc.umu.se > > ftp.acc.umu.se CNAME churchill.acc.umu.se > > churchill.acc.umu.se A 130.239.18.141 The follow excerpt of ftp login gave some clue to me, I guess the original ftp.gnome.org is moving to download.gnome.org (but I can be wrong). And it must be noted that I am living in Hong Kong: ============================================================== xxxxxx at xxxxxx 00:12:47 ~> ncftp download.gnome.org NcFTP 3.0.2 (October 19, 2000) by Mike Gleason (ncftp at ncftp.com). Connecting to 209.116.70.80... ftp.gnome.org FTP server (Version wu-2.6.0(1) Fri Jun 23 09:17:44 EDT 2000) ready. Login incorrect. Sleeping 18 seconds... ============================================================== xxxxxx at xxxxxx 00:39:42 ~> ncftp ftp.gnome.org NcFTP 3.0.2 (October 19, 2000) by Mike Gleason (ncftp at ncftp.com). Connecting to 130.239.18.141... V?lkommen xxxxxxxxxxxxxxxxxxx! Du har kommit till churchill.acc.umu.se, Academic Computer Club-Ume? University ftp.acc.umu.se FTP server (Version wu-2.6.1(4) Thu Mar 15 21:20:54 MET 2001) ready. Logging in... Guest login ok, access restrictions apply. Logging in... ============================================================== From proski at gnu.org Mon Aug 13 23:50:12 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 13 Aug 2001 19:50:12 -0400 (EDT) Subject: Fix for another data loss bug In-Reply-To: <20010813130512.A24256@bcs.zp.ua> Message-ID: On Mon, 13 Aug 2001, Andrew V. Samoilov wrote: > Pavel Roskin wrote: > : Hi! > : > : > : "Safe save" and "Do backups" don't work on the remote VFS. Fixing it > : > : properly is quite hard, because it requires on implementation of rename() > : > : on VFS. > > What is wrong with rename on VFS? It is work well on ftpfs and smbfs as far > as I know. And I think it is ok on fish. I meant the rename() function that is used in mcedit. There is no mc_rename() in VFS - it is declared in vfs.h but not implemented. The mcedit code seems to rely on the atomic rename() to implement "Safe Save". > BTW, C-q is documented but does not work on command prompt in text edition. > I use Slackware 7.1 based Linux distribution. Test case: > > $ echo "[ C-q Tab ]" > > There is dot "." in command prompt and nothing in shell. Wow, great catch! In fact, MC sends Tab as is to bash, and the later does filename completion. Enter "lyn C-q Tab" - it will run lynx for you! It only confirms my point that the subshell support in MC is a hack that should be fixed by integrating the subshell into the MC code. If you really want to fix it before the subshell is integrated, you can make a patch that sends Ctrl-V to the shell before problematic symbols. It works in all currently supported subshells: bash, tcsh and zsh. > Another stange bug. Keypad asterics '*' is shown as 'o' letter > in command prompt in xterm and all is fine in subshell (C-O). I could not reproduce it (XFree 4.0.3, RedHat 7.1). Try debuging key.c. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 14 00:22:49 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 13 Aug 2001 20:22:49 -0400 (EDT) Subject: gmo cleanup In-Reply-To: <20010812233436.A5346@localhost.localdomain> Message-ID: On Sun, 12 Aug 2001, Walery Studennikov wrote: > Now when we "make clean" po/*.gmo files is not cleaned. That's correct. "make clean" removes the files that "make all" creates. *.gmo are included in the distribution, so "make all" doesn't create them. "make distclean" removes all but the files in the distribution. That's why even "make distclean" doesn't remove *.gmo. "make maintainer-clean" is not strictly defined. Usually it removes the files that the maintainer can rebuild. It removes *.gmo files. gettext follows the GNU coding standards that describe this behavior. Read "info standards" for details. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 14 01:15:11 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 13 Aug 2001 21:15:11 -0400 (EDT) Subject: Double // in codepages list error In-Reply-To: <10529316.997653302823.JavaMail.imail@hippie.excite.com> Message-ID: Hi, David! > > By the way, if you _have_ to introduce a new translatable message please > > avoid that british "Can't" - write "Cannot" instead. > > The line was there before. It wasn't me: Don't blame me. I know. Sorry that you didn't understand my point. My point was that it's better not to change translatable strings, but if you have to (e.g. because it hardcodes something that should be variable), it's always better to fix everything else that you may not like in that string. The alternative is changing that string in every translation. Well, maybe I'm wrong and this is better. I just don't feel good about changing translations to the languages that I don't speak, but it should be safe if done carefully. Ok, I have written a script that does it safely. I've just applied a huge patch that replaces "Can't" with "Cannot" everywhere. Enjoy. Sorry again if I offended you. > What about en_GB.po? Once someone complained in the list about it. Contributions are welcome. > ...and what about OK and Ok? How do "you" spell it? $ find -name '*.[ch]' -exec egrep -nH '\' {} \; | wc -l 33 $ find -name '*.[ch]' -exec egrep -nH '\' {} \; | wc -l 13 The sources use "Ok" more often than "OK". But webster.com uses "OK". > (I'm actually Australian but I've lived in Spain since I was 4 :) > English humor, you know! Then you could contribute en_OZ.po :-) > You made no changes in setup.c so the original message and the "//" > stay there. Is this the final solution? No, it's not the final solution. I just want to get down to the last issues that hold 4.5.55, which explains that I'm a bit angry that some minor issues pop up in the list all the time. But I'll fix this problem - I don't want discussions about trivial things. > Just in case it's of any use here's the second patch I made. Someone could > argue not to place GUI in charsets.c and this was the second reason no to > post it yesterday. Good argument. Thank you for the patch. I'll fix this problem shortly. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 14 01:47:04 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 13 Aug 2001 21:47:04 -0400 (EDT) Subject: New "Multiscreen" megapatch In-Reply-To: <20010813123704.A9842@localhost.localdomain> Message-ID: Hi, Walery! I just want to acknowledge reciving this patch. I really like that you documented it very well. I haven't read the patch yet, it will probably be a separate message. > This patch (mc-multiscreen-patch) adds possibility to > open multiple internal viewers and internal editors at once. > This fearure is almost the same as in the FAR manager. > I'm sure it is will be very convenient for developers, > but not only. I discussed this feature of Far with Miguel and he supported this idea. It's great that we have an implementation now. > When you have at least one open editor or viewer, > you can use the following keys: > > F12: Call "dialog list" to choose dialog to switch to. > Just like FAR manager. > Alt-U: Switch to previous dialog > Alt-I: Switch to next dialog Sounds good. > When you exit from MC when other editors and/or viewers > are sleeping in the background, > all viewers and unmodified editors are killed, > but modified editors are activated and user have exit > from this editors manually with or without saving a file. Unfortunately, there is a hex editor in the viewer. But we probably can ignore this problem for now. The hex editor is a hack and should not stand in our way. > Implementing this feature was impossible > without special hacks on MC dialog management system. > With old system ALL dialogs HAVE TO BE modal, > so you couldn't switch between whem randomly. > But now it is fixed. Great! > Almost ALL new or changed code in enclosed into the > #ifdef HAVE_DLGSWITCH > #endif > pair. HAVE_DLGSWITCH can be defined in config.h. Please use comments after #endif. Use /* HAVE_DLGSWITCH */ is the preceding code is used when HAVE_DLGSWITCH is defined. Otherwise use /* !HAVE_DLGSWITCH */ It's easier to read code with such comments. > So it is (probably) safe to apply to current sources, > because it is easy to turn off the feature. Yes. Some features affect portability (e.g. subshell support which doesn't work on QNX Neutrino), but your patch should be safer in the long run, so at some point all those directives will be hopefully removed (when the new code works well). I see no reasons to keep more configure options just for fun. > Only some peaces of code is not enclosed in > #ifdef HAVE_DLGSWITCH .. #endif pair. That's Ok. > For example it is a new glib-based logging handler > in main.c. I thinks it will be useful for debugging > various peaces of MC anyway. Great! I was thinking about implementing it! > Probably we can make this feature "experimental" > and provide a ./configure switch to turn it on, > for example "--enable-multiscreen" or > "--enable-dlgswitch". I'll check the patch to see if this precaution is necessary. > About debugging. > > The patch extensively uses glib-based logging for > debugging purposes. To turn this logging on you have > to #define MY_DEBUG in config.h. MC_DEBUG sounds better. > The handler writes all logging messages to ~/.mc/debug.log. > Without #define MY_DEBUG only fatal errors is handled: > an error message is printed on the screen > and program aborts with a core dump. That's also a good idea. There are some fatal cases in VFS that should be handled in such way. It's important to ask the user to write to the list what he or she was doing before the crash happened. > IMPORTANT NOTE! > > The patch is big and complex > (that's why I've called it "megapatch"), > so it should be applied AFTER the new release, > but BEFORE cleaning from GNOME. I was going to tell you exactly that! I appreciate your responsive approach. > If we clean from GNOME before applying the patch > it would be wery difficult to apply it > cause HUGE changes in the source core. Ok. Thank you! -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 14 06:19:29 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 14 Aug 2001 02:19:29 -0400 (EDT) Subject: Minor changes in the key database Message-ID: Hello! It is now safe to define many sequences to the same key. "Learn Keys" does not provide the interface to this feature (and probably it should not), but it's now used in mc.lib: home=\e[1~ home=\e[7~ end=\e[4~ end=\e[8~ Those definitions make it possible to use Home and End keys in MC running in xterm and rxvt even if they both set "TERM=xterm" and use different keys. The best part - "Learn Keys" is not required to make them work. Don't tell me that MC should not be doing that - this workaround (i.e. MC's own terminal database in mc.lib) existed for years, but now it's a workaround that works out of box on many systems. Another change makes it impossible to define a key sequence which is a subsequence of another sequence. MC would go crazy and stop recognizing Escape if user tried to use e.g. Alt-[ in the "Learn Keys" dialog. In fact, the base node of the key database would be set to 0, thus disabling the whole database. Now such sequences are rejected. Another case when it can happen - "Learn Keys" asks for some key, e.g. F8. The user presses F8 twice too fast for MC to distinguish. Then the user tries to redefine F8 as a single F8. The old code would do crazy. The new code would reject the new sequence. It's not ideal, but it's _much_ better than corrupting the key database, when even "Esc 0" stops working and you cannot exit. Enjoy. -- Regards, Pavel Roskin From proski at gnu.org Tue Aug 14 06:33:36 2001 From: proski at gnu.org (Pavel Roskin) Date: Tue, 14 Aug 2001 02:33:36 -0400 (EDT) Subject: OK vs. Ok In-Reply-To: Message-ID: Hi, David! I wrote: > The sources use "Ok" more often than "OK". But webster.com uses "OK". Please be careful here. "OK" is used in the "Learn Keys" dialog, which cannot be resized for longer translations, since it's already 80 characters wide. That's why some translations translate "OK" in this context, trying to keep it short. E.g. the French translation is "Vu", i.e. "Seen" - it acknowledges that the key has been accepted by MC. "Ok" on the other hand is translated as "Valider". There is also a corresponding translation for "ok" used in gwidget.c that recognizes the buttons by their translated names with "&" removed so that the corresponding GNOME icon can be added to the button (dirty hack, very unfriendly to translators). Unless the "Learn Keys" is redesigned or stops using "OK" we should be very careful - gettext doesn't like when the same word has different translations in different files. -- Regards, Pavel Roskin From dmartina at excite.es Tue Aug 14 11:25:22 2001 From: dmartina at excite.es (David Martin) Date: Tue, 14 Aug 2001 04:25:22 -0700 (PDT) Subject: OK vs. Ok Message-ID: <7257015.997788322749.JavaMail.imail@sammy> El Tue, 14 Aug 2001 02:33:36 -0400 (EDT), Pavel Roskin escribi?: > > Please be careful here. "OK" is used in the "Learn Keys" dialog, which > cannot be resized for longer translations, since it's already 80 > characters wide. > Hmm, I see... We could look for something else to use as a tick. What about "~"? As you are not refusing these "minor" fixes, I'll bring back the patch for hotkeys (set or remove extra uppercase as in "Vie&w file..." --> "vie&W file...") and right align key shortcuts in Command menu. See you. *8-) David _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es From dmartina at excite.es Tue Aug 14 11:39:14 2001 From: dmartina at excite.es (David Martin) Date: Tue, 14 Aug 2001 04:39:14 -0700 (PDT) Subject: OK vs. Ok Message-ID: <22254632.997789154016.JavaMail.imail@sammy> El Tue, 14 Aug 2001 02:33:36 -0400 (EDT), Pavel Roskin escribi?: "Ok" on the other hand is translated as "Valider". There is also a > corresponding translation for "ok" used in gwidget.c that recognizes the > buttons by their translated names with "&" removed so that the > corresponding GNOME icon can be added to the button (dirty hack, very > unfriendly to translators). > > Unless the "Learn Keys" is redesigned or stops using "OK" we should be > very careful - gettext doesn't like when the same word has different > translations in different files. > Sorry, I forgot this point. Appart from the hack in gwidget.c. As for gettext "OK" and "&OK" or "_OK" are different strings so there would be no problem to give them different translations. Anyway, it's time consuming to check every OK message in the code and look for side effects... I would just try the "&Ok" -> "&OK" Did I say I don't like the "cannot"? :( *8-) David _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es From dmartina at excite.es Tue Aug 14 18:16:50 2001 From: dmartina at excite.es (David Martin) Date: Tue, 14 Aug 2001 11:16:50 -0700 (PDT) Subject: SLang or not to SLang Message-ID: <12096287.997813010394.JavaMail.imail@sammy> A couple of things with SLang: a) Messages about Slang in "mc -V" seem to be swapped. b) I'm not sure if "configure --without-slang" (and variants) behaves as it is supossed to. ./configure (...) --enable-charset Text mode screen manager: SLang (system-installed library) with termcap LANGUAGE=c src/mc -V: Using S-Lang library with termcap database ./configure (...) --enable-charset --with-included-slang Text mode screen manager: SLang with terminfo LANGUAGE=c src/mc -V: Using system-installed S-Lang library with terminfo database (no trace of slang in ldd) ./configure (...) --enable-charset --without-slang Text mode screen manager: SLang (system-installed library) with termcap LANGUAGE=c src/mc -V: Using S-Lang library with termcap database ./configure (...) --enable-charset --without-slang --with-ncurses Text mode screen manager: ncurses on /usr/include (Compile error) gcc -c (...) main.c main.c: In function `setup_pre': main.c:1848: `eight_bit_clean' undeclared (first use in this function) main.c:1848: (Each undeclared identifier is reported only once main.c:1848: for each function it appears in.) main.c:1844: warning: unused variable `full_eight_bits' make[2]: *** [main.o] Error 1 make[2]: Saliendo directorio `/usr/src/mc-4.5.54a/src' make[1]: *** [all-recursive] Error 1 make[1]: Saliendo directorio `/usr/src/mc-4.5.54a' make: *** [all] Error 2 ./configure (...) --without-slang --with-ncurses Text mode screen manager: ncurses on /usr/include LANGUAGE=c src/mc -V: Using the ncurses library ------------------- (nearly fresh Mandrake 8.0) $ rpm -qa | grep slang libslang1-1.4.4-1mdk slang-doc-1.4.4-1mdk libslang1-devel-1.4.4-1mdk $ rpm -qa | grep ncurses ncurses-5.2-12mdk libncurses5-devel-5.2-12mdk libncurses5-5.2-12mdk ------------------- Lately I had to compile --with-included-slang to avoid those "qqqqqqqqq-----" in dialog frames. No trace of it now. Is this piece in textconf.c right? ----------------------- # ifdef HAVE_SYSTEM_SLANG N_("Using S-Lang library"), # else N_("Using system-installed S-Lang library"), # endif ---------------------- *8-) David _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es From dmartina at excite.es Tue Aug 14 18:22:39 2001 From: dmartina at excite.es (David Martin) Date: Tue, 14 Aug 2001 11:22:39 -0700 (PDT) Subject: Uppercase in Hotkeys & menus Message-ID: <27971656.997813359887.JavaMail.imail@sammy> This is the patch. If fixes Hotkeys and aligns the Command menu for the original C locale. The patch to reset al .po files is included *8-) David --------------------------- diff -1 -upr mc-4.5.54a-proski/src/ChangeLog mc-4.5.54a/src/ChangeLog --- mc-4.5.54a-proski/src/ChangeLog Tue Aug 14 06:48:01 2001 +++ mc-4.5.54a/src/ChangeLog Tue Aug 14 18:12:01 2001 @@ -1 +1,16 @@ +2001-08-13 David Martin + + * achown.c: Use uppercase in messages (only) for hotkeys. + * boxes.c: Likewise + * chmod.c: Likewise + * chown.c: Likewise + * file.c: Likewise + * find.c: Likewise + * hotlist.c: Likewise + * panelize.c: Likewise + + * main.c: Right align menu shortcuts and some code tidying. + Use ... in menu entries when dialog is opened. + Use uppercase in messages (only) for hotkeys. + 2001-08-14 Pavel Roskin diff -1 -upr mc-4.5.54a-proski/src/achown.c mc-4.5.54a/src/achown.c --- mc-4.5.54a-proski/src/achown.c Sun Aug 12 06:25:48 2001 +++ mc-4.5.54a/src/achown.c Tue Aug 14 18:12:01 2001 @@ -72,11 +72,11 @@ static struct { } chown_advanced_but [BUTTONS] = { - { B_CANCEL, NORMAL_BUTTON, 4, 53, N_("&Cancel") }, - { B_ENTER, DEFPUSH_BUTTON,4, 40, N_("&Set") }, - { B_SKIP, NORMAL_BUTTON, 4, 23, N_("S&kip") }, - { B_SETALL, NORMAL_BUTTON, 4, 0, N_("Set &all")}, - { B_ENTER, NARROW_BUTTON, 0, 47, " "}, - { B_ENTER, NARROW_BUTTON, 0, 29, " "}, - { B_ENTER, NARROW_BUTTON, 0, 19, " "}, - { B_ENTER, NARROW_BUTTON, 0, 11, " "}, - { B_ENTER, NARROW_BUTTON, 0, 3, " "}, + { B_CANCEL, NORMAL_BUTTON, 4, 53, N_("&Cancel") }, + { B_ENTER, DEFPUSH_BUTTON, 4, 40, N_("&Set") }, + { B_SKIP, NORMAL_BUTTON, 4, 23, N_("s&Kip") }, + { B_SETALL, NORMAL_BUTTON, 4, 0, N_("set &All") }, + { B_ENTER, NARROW_BUTTON, 0, 47, " " }, + { B_ENTER, NARROW_BUTTON, 0, 29, " " }, + { B_ENTER, NARROW_BUTTON, 0, 19, " " }, + { B_ENTER, NARROW_BUTTON, 0, 11, " " }, + { B_ENTER, NARROW_BUTTON, 0, 3, " " }, }; diff -1 -upr mc-4.5.54a-proski/src/boxes.c mc-4.5.54a/src/boxes.c --- mc-4.5.54a-proski/src/boxes.c Tue Aug 7 02:09:46 2001 +++ mc-4.5.54a/src/boxes.c Tue Aug 14 18:13:54 2001 @@ -281,3 +281,3 @@ sort_box (sortfn *sort_fn, int *reverse, char* reverse_label = _("&Reverse"); - char* case_label = _("case sensi&tive"); + char* case_label = _("case sensi&Tive"); char* sort_title = _("Sort order"); @@ -464,3 +464,3 @@ static int new_meta; char *display_bits_str [] = -{ N_("Full 8 bits output"), N_("ISO 8859-1"), N_("7 bits") }; +{ N_("full &8 bits output"), N_("&ISO 8859-1"), N_("&7 bits") }; @@ -471,3 +471,3 @@ static QuickWidget display_widgets [] = 0, B_ENTER, 0, 0, "o" }, -{ quick_checkbox, 4, DISPX, 7, DISPY, N_("F&ull 8 bits input"), +{ quick_checkbox, 4, DISPX, 7, DISPY, N_("f&Ull 8 bits input"), 0, 0, &new_meta, 0, "u" }, @@ -619,3 +619,3 @@ void init_disp_bits_box() inpcheck = check_new( 6, 4, !use_8th_bit_as_meta, - _("F&ull 8 bits input"), NULL ); + _("f&Ull 8 bits input"), NULL ); add_widget( dbits_dlg, inpcheck ); diff -1 -upr mc-4.5.54a-proski/src/chmod.c mc-4.5.54a/src/chmod.c --- mc-4.5.54a-proski/src/chmod.c Sun Aug 12 06:25:48 2001 +++ mc-4.5.54a/src/chmod.c Tue Aug 14 18:12:01 2001 @@ -110,6 +110,6 @@ static struct { { B_ENTER, DEFPUSH_BUTTON, 2, 17, N_("&Set") }, - { B_CLRMRK, NORMAL_BUTTON, 0, 42, N_("C&lear marked") }, - { B_SETMRK, NORMAL_BUTTON, 0, 27, N_("S&et marked") }, + { B_CLRMRK, NORMAL_BUTTON, 0, 42, N_("c&Lear marked") }, + { B_SETMRK, NORMAL_BUTTON, 0, 27, N_("s&Et marked") }, { B_MARKED, NORMAL_BUTTON, 0, 12, N_("&Marked all") }, - { B_ALL, NORMAL_BUTTON, 0, 0, N_("Set &all") }, + { B_ALL, NORMAL_BUTTON, 0, 0, N_("set &All") }, }; diff -1 -upr mc-4.5.54a-proski/src/chown.c mc-4.5.54a/src/chown.c --- mc-4.5.54a-proski/src/chown.c Sun Aug 12 06:25:48 2001 +++ mc-4.5.54a/src/chown.c Tue Aug 14 18:12:01 2001 @@ -81,5 +81,5 @@ static struct { { B_ENTER, DEFPUSH_BUTTON, 0, 40, N_("&Set") }, - { B_SETUSR, NORMAL_BUTTON, 0, 25, N_("Set &users") }, - { B_SETGRP, NORMAL_BUTTON, 0, 11, N_("Set &groups") }, - { B_SETALL, NORMAL_BUTTON, 0, 0, N_("Set &all") }, + { B_SETUSR, NORMAL_BUTTON, 0, 25, N_("set &Users") }, + { B_SETGRP, NORMAL_BUTTON, 0, 11, N_("set &Groups") }, + { B_SETALL, NORMAL_BUTTON, 0, 0, N_("set &All") }, }; diff -1 -upr mc-4.5.54a-proski/src/file.c mc-4.5.54a/src/file.c --- mc-4.5.54a-proski/src/file.c Tue Aug 14 02:55:38 2001 +++ mc-4.5.54a/src/file.c Tue Aug 14 18:12:01 2001 @@ -2252,3 +2252,3 @@ real_query_recursive (FileOpContext *ctx _("&Yes"), _("&No"), - _("a&ll"), _("non&E"), + _("al&L"), _("non&E"), _("&Abort")); diff -1 -upr mc-4.5.54a-proski/src/find.c mc-4.5.54a/src/find.c --- mc-4.5.54a-proski/src/find.c Wed Aug 1 02:58:06 2001 +++ mc-4.5.54a/src/find.c Tue Aug 14 18:12:01 2001 @@ -105,3 +105,3 @@ static struct { { N_("&Suspend"), 11, 29 }, - { N_("Con&tinue"), 12, 29 }, + { N_("con&Tinue"), 12, 29 }, { N_("&Chdir"), 11, 3 }, @@ -109,3 +109,3 @@ static struct { { N_("&Quit"), 8, 43 }, - { N_("Pane&lize"), 12, 3 }, + { N_("pane&Lize"), 12, 3 }, { N_("&View - F3"), 13, 20 }, diff -1 -upr mc-4.5.54a-proski/src/hotlist.c mc-4.5.54a/src/hotlist.c --- mc-4.5.54a-proski/src/hotlist.c Mon Jul 9 09:02:02 2001 +++ mc-4.5.54a/src/hotlist.c Tue Aug 14 18:12:01 2001 @@ -131,4 +131,4 @@ static struct _hotlist_but { { B_INSERT, NORMAL_BUTTON, 1, 0, N_("&Insert"), "g", LIST_MOVELIST}, - { B_NEW_ENTRY, NORMAL_BUTTON, 1, 15, N_("New &Entry"), "e", LIST_HOTLIST}, - { B_NEW_GROUP, NORMAL_BUTTON, 1, 0, N_("New &Group"), "g", LIST_HOTLIST}, + { B_NEW_ENTRY, NORMAL_BUTTON, 1, 15, N_("new &Entry"), "e", LIST_HOTLIST}, + { B_NEW_GROUP, NORMAL_BUTTON, 1, 0, N_("new &Group"), "g", LIST_HOTLIST}, { B_CANCEL, NORMAL_BUTTON, 0, 53, N_("&Cancel"), "cc", LIST_HOTLIST|LIST_VFSLIST|LIST_MOVELIST}, @@ -136,3 +136,3 @@ static struct _hotlist_but { { B_ADD_CURRENT, NORMAL_BUTTON, 0, 20, N_("&Add current"),"ad", LIST_HOTLIST}, - { B_ENTER, DEFPUSH_BUTTON, 0, 0, N_("Change &To"), "ct", LIST_HOTLIST|LIST_VFSLIST|LIST_MOVELIST}, + { B_ENTER, DEFPUSH_BUTTON, 0, 0, N_("change &To"), "ct", LIST_HOTLIST|LIST_VFSLIST|LIST_MOVELIST}, }; diff -1 -upr mc-4.5.54a-proski/src/main.c mc-4.5.54a/src/main.c --- mc-4.5.54a-proski/src/main.c Wed Aug 8 04:19:14 2001 +++ mc-4.5.54a/src/main.c Tue Aug 14 18:12:01 2001 @@ -1256,16 +1256,16 @@ listmode_cmd (void) static menu_entry PanelMenu [] = { - { ' ', N_("&Listing mode..."), 'L', listing_cmd }, - { ' ', N_("&Quick view C-x q"), 'Q', quick_view_cmd }, - { ' ', N_("&Info C-x i"), 'I', info_cmd }, - { ' ', N_("&Tree"), 'T', tree_cmd }, + { ' ', N_("&Listing mode..." ), 'L', listing_cmd }, + { ' ', N_("&Quick view C-x q"), 'Q', quick_view_cmd }, + { ' ', N_("&Info C-x i"), 'I', info_cmd }, + { ' ', N_("&Tree" ), 'T', tree_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("&Sort order..."), 'S', sort_cmd }, + { ' ', N_("&Sort order..." ), 'S', sort_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("&Filter..."), 'F', filter_cmd }, + { ' ', N_("&Filter..." ), 'F', filter_cmd }, #ifdef USE_NETCODE { ' ', "", ' ', 0 }, - { ' ', N_("&Network link..."), 'N', netlink_cmd }, - { ' ', N_("FT&P link..."), 'P', ftplink_cmd }, + { ' ', N_("&Network link..." ), 'N', netlink_cmd }, + { ' ', N_("FT&P link..." ), 'P', ftplink_cmd }, #ifdef WITH_SMBFS - { ' ', N_("SM&B link..."), 'B', smblink_cmd }, + { ' ', N_("SM&B link..." ), 'B', smblink_cmd }, #endif @@ -1274,5 +1274,5 @@ static menu_entry PanelMenu [] = { #ifdef OS2_NT - { ' ', N_("&Drive... M-d"), 'D', drive_cmd_a }, + { ' ', N_("&Drive... M-d"), 'D', drive_cmd_a }, #endif - { ' ', N_("&Rescan C-r"), 'R', reread_cmd } + { ' ', N_("&Rescan C-r"), 'R', reread_cmd } }; @@ -1280,16 +1280,16 @@ static menu_entry PanelMenu [] = { static menu_entry RightMenu [] = { - { ' ', N_("&Listing mode..."), 'L', listing_cmd }, - { ' ', N_("&Quick view C-x q"), 'Q', quick_view_cmd }, - { ' ', N_("&Info C-x i"), 'I', info_cmd }, - { ' ', N_("&Tree"), 'T', tree_cmd }, + { ' ', N_("&Listing mode..." ), 'L', listing_cmd }, + { ' ', N_("&Quick view C-x q"), 'Q', quick_view_cmd }, + { ' ', N_("&Info C-x i"), 'I', info_cmd }, + { ' ', N_("&Tree" ), 'T', tree_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("&Sort order..."), 'S', sort_cmd }, + { ' ', N_("&Sort order..." ), 'S', sort_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("&Filter..."), 'F', filter_cmd }, + { ' ', N_("&Filter..." ), 'F', filter_cmd }, #ifdef USE_NETCODE { ' ', "", ' ', 0 }, - { ' ', N_("&Network link..."), 'N', netlink_cmd }, - { ' ', N_("FT&P link..."), 'P', ftplink_cmd }, + { ' ', N_("&Network link..." ), 'N', netlink_cmd }, + { ' ', N_("FT&P link..." ), 'P', ftplink_cmd }, #ifdef WITH_SMBFS - { ' ', N_("SM&B link..."), 'B', smblink_cmd }, + { ' ', N_("SM&B link..." ), 'B', smblink_cmd }, #endif @@ -1298,5 +1298,5 @@ static menu_entry RightMenu [] = { #ifdef OS2_NT - { ' ', N_("&Drive... M-d"), 'D', drive_cmd_b }, + { ' ', N_("&Drive... M-d"), 'D', drive_cmd_b }, #endif - { ' ', N_("&Rescan C-r"), 'R', reread_cmd } + { ' ', N_("&Rescan C-r"), 'R', reread_cmd } }; @@ -1306,21 +1306,21 @@ static menu_entry FileMenu [] = { { ' ', N_("&View F3"), 'V', view_cmd }, - { ' ', N_("Vie&w file... "), 'W', view_file_cmd }, - { ' ', N_("&Filtered view M-!"), 'F', filtered_view_cmd }, + { ' ', N_("vie&W file..." ), 'W', view_file_cmd }, + { ' ', N_("&Filtered view... M-!"), 'F', filtered_view_cmd }, { ' ', N_("&Edit F4"), 'E', edit_cmd }, - { ' ', N_("&Copy F5"), 'C', copy_cmd }, - { ' ', N_("c&Hmod C-x c"), 'H', chmod_cmd }, + { ' ', N_("&Copy... F5"), 'C', copy_cmd }, + { ' ', N_("c&Hmod... C-x c"), 'H', chmod_cmd }, #ifndef OS2_NT - { ' ', N_("&Link C-x l"), 'L', link_cmd }, - { ' ', N_("&SymLink C-x s"), 'S', symlink_cmd }, + { ' ', N_("&Link... C-x l"), 'L', link_cmd }, + { ' ', N_("&SymLink... C-x s"), 'S', symlink_cmd }, { ' ', N_("edit s&Ymlink C-x C-s"), 'Y', edit_symlink_cmd }, - { ' ', N_("ch&Own C-x o"), 'O', chown_cmd }, - { ' ', N_("&Advanced chown "), 'A', chown_advanced_cmd }, + { ' ', N_("ch&Own... C-x o"), 'O', chown_cmd }, + { ' ', N_("&Advanced chown..." ), 'A', chown_advanced_cmd }, #endif - { ' ', N_("&Rename/Move F6"), 'R', ren_cmd }, - { ' ', N_("&Mkdir F7"), 'M', mkdir_cmd }, + { ' ', N_("&Rename/Move... F6"), 'R', ren_cmd }, + { ' ', N_("&Mkdir... F7"), 'M', mkdir_cmd }, { ' ', N_("&Delete F8"), 'D', delete_cmd }, - { ' ', N_("&Quick cd M-c"), 'Q', quick_cd_cmd }, + { ' ', N_("&Quick cd... M-c"), 'Q', quick_cd_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("select &Group M-+"), 'G', select_cmd }, - { ' ', N_("u&Nselect group M-\\"),'N', unselect_cmd }, + { ' ', N_("select &Group... M-+"), 'G', select_cmd }, + { ' ', N_("u&Nselect group... M-\\"),'N', unselect_cmd }, { ' ', N_("reverse selec&Tion M-*"), 'T', reverse_selection_cmd }, @@ -1336,18 +1336,18 @@ static menu_entry CmdMenu [] = { */ - { ' ', N_("&Directory tree"), 'D', tree_box }, - { ' ', N_("&Find file M-?"), 'F', find_cmd }, - { ' ', N_("s&Wap panels C-u"), 'W', swap_cmd }, - { ' ', N_("switch &Panels on/off C-o"), 'P', view_other_cmd }, - { ' ', N_("&Compare directories C-x d"), 'C', compare_dirs_cmd }, - { ' ', N_("e&Xternal panelize C-x !"), 'X', external_panelize }, - { ' ', N_("show directory s&Izes"), 'I', dirsizes_cmd }, + { ' ', N_("&Directory tree" ), 'D', tree_box }, + { ' ', N_("&Find file... M-?"), 'F', find_cmd }, + { ' ', N_("s&Wap panels C-u"), 'W', swap_cmd }, + { ' ', N_("switch &Panels on/off C-o"), 'P', view_other_cmd }, + { ' ', N_("&Compare directories... C-x d"), 'C', compare_dirs_cmd }, + { ' ', N_("e&Xternal panelize... C-x !"), 'X', external_panelize }, + { ' ', N_("show directory s&Izes" ), 'I', dirsizes_cmd }, { ' ', "", ' ', 0 }, - { ' ', N_("command &History"), 'H', history_cmd }, - { ' ', N_("di&Rectory hotlist C-\\"), 'R', quick_chdir_cmd }, + { ' ', N_("command &History" ), 'H', history_cmd }, + { ' ', N_("di&Rectory hotlist... C-\\"), 'R', quick_chdir_cmd }, #ifdef USE_VFS - { ' ', N_("&Active VFS list C-x a"), 'A', reselect_vfs }, - { ' ', N_("Fr&ee VFSs now"), 'E', free_vfs_now }, + { ' ', N_("&Active VFS list... C-x a"), 'A', reselect_vfs }, + { ' ', N_("fr&Ee VFSs now" ), 'E', free_vfs_now }, #endif #ifdef WITH_BACKGROUND - { ' ', N_("&Background jobs C-x j"), 'B', jobs_cmd }, + { ' ', N_("&Background jobs... C-x j"), 'B', jobs_cmd }, #endif @@ -1358,3 +1358,3 @@ static menu_entry CmdMenu [] = { #ifdef LISTMODE_EDITOR - { ' ', N_("&Listing format edit"), 'L', listmode_cmd}, + { ' ', N_("&Listing format edit..." ), 'L', listmode_cmd}, #endif @@ -1363,6 +1363,6 @@ static menu_entry CmdMenu [] = { #endif - { ' ', N_("&Extension file edit"), 'E', ext_cmd }, - { ' ', N_("&Menu file edit"), 'M', menu_edit_cmd }, + { ' ', N_("&Extension file edit..." ), 'E', ext_cmd }, + { ' ', N_("&Menu file edit..." ), 'M', menu_edit_cmd }, #ifdef USE_INTERNAL_EDIT - {' ', N_("Menu edi&Tor edit"), 'T', edit_user_menu_cmd} + {' ', N_("menu edi&Tor edit..." ), 'T', edit_user_menu_cmd} #endif /* USE_INTERNAL_EDIT */ @@ -1372,14 +1372,14 @@ static menu_entry CmdMenu [] = { static menu_entry OptMenu [] = { - { ' ', N_("&Configuration..."), 'C', configure_box }, - { ' ', N_("&Layout..."), 'L', layout_cmd }, - { ' ', N_("c&Onfirmation..."), 'O', confirm_box }, - { ' ', N_("&Display bits..."), 'D', display_bits_box }, + { ' ', N_("&Configuration..."), 'C', configure_box }, + { ' ', N_("&Layout..." ), 'L', layout_cmd }, + { ' ', N_("c&Onfirmation..." ), 'O', confirm_box }, + { ' ', N_("&Display bits..." ), 'D', display_bits_box }, #ifndef OS2_NT - { ' ', N_("learn &Keys..."), 'K', learn_keys }, + { ' ', N_("learn &Keys..." ), 'K', learn_keys }, #endif /* !OS2_NT */ #ifdef USE_VFS - { ' ', N_("&Virtual FS..."), 'V', configure_vfs }, + { ' ', N_("&Virtual FS..." ), 'V', configure_vfs }, #endif /* !USE_VFS */ { ' ', "", ' ', 0 }, - { ' ', N_("&Save setup"), 'S', save_setup_cmd } + { ' ', N_("&Save setup" ), 'S', save_setup_cmd } }; diff -1 -upr mc-4.5.54a-proski/src/panelize.c mc-4.5.54a/src/panelize.c --- mc-4.5.54a-proski/src/panelize.c Sun Jul 15 04:41:38 2001 +++ mc-4.5.54a/src/panelize.c Tue Aug 14 18:12:01 2001 @@ -85,3 +85,3 @@ static struct { { B_REMOVE, NORMAL_BUTTON, 0, 16, N_("&Remove"), "r"}, - { B_ENTER, DEFPUSH_BUTTON, 0, 0, N_("Pane&lize"),"l"}, + { B_ENTER, DEFPUSH_BUTTON, 0, 0, N_("pane&Lize"),"l"}, }; _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotkeys13.diff.bz2 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fixall17.diff.bz2 URL: From despair at sama.ru Wed Aug 15 11:22:40 2001 From: despair at sama.ru (Walery Studennikov) Date: Wed, 15 Aug 2001 16:22:40 +0500 Subject: Synchronyzing MC and Cooledit Message-ID: <20010815162240.A2226@localhost.localdomain> The cooledit sources in the MC distribution is VERY outdated (I can guess that the last syncronization was in 1997). So, many useful features from modern cooledit are not available in MC now. For instance it is "bookmarks". Personally I suffer without this feature. It would be grate if those new useful features would be backported to MC. For example I can try to port bookmarks. Anyway, if cooledit and MC sources are not syncronizing now we can safely strip !MIDNIGHT sections from the editor sources. This code is NEVER used and it is inconvenient to keep this dead code which only confuses developers working with editor sources. IMO this pieces of code should be cleaned along with GNOME pieces in the new versions of MC. Regards, Walery. From despair at sama.ru Wed Aug 15 13:05:28 2001 From: despair at sama.ru (Walery Studennikov) Date: Wed, 15 Aug 2001 18:05:28 +0500 Subject: New version of multiscreen patch Message-ID: <20010815180528.A5699@localhost.localdomain> It contains small fixes and I've also included bookmarks support for editor (this is a backport from modern cooledit). This support in incomplete now (you can't clean all bookmarks and bookmarks are not highlighted - but IMO it is better than nothing and this can be improved in the future). The keysbindings for working with bookmarks are the following: Ctrl-Alt-Insert: Add bookmark Ctrl-Alt-Up: Move to previous bookmark Ctrl-Alt-Down: Move to next bookmark I know it is a bad idea to mix unrelated patches, but I have no time and aspiration now to separate them. No documentation patches for now. I think it will be written when the patch will be applied, criticized, improved and tested. Or may be earlier if I have a time... You can download the new version here: http://www.sama.ru/~despair/mc/mc-multiscreen-patch-0.2.tar.gz From despair at sama.ru Thu Aug 16 04:03:06 2001 From: despair at sama.ru (Walery Studennikov) Date: Thu, 16 Aug 2001 00:03:06 -0400 Subject: The final version of multiscreen+bookmarks patch is avalable Message-ID: <20010816000306.A1021@localhost.localdomain> Hi, All. Now, at last, I'm glad to annouce the first "stable" version of the multiscreen+bookmsks patch. Changes: 1. Full bookmarks support (bookmark stuff was already in the sources but there were no keybindings for that). I've used the same keybindings as cooledit itself: Ctrl-Alt-Ins, Ctrl-Alt-Up, Ctrl-Alt-Down. Yes it will only work in the linux console and under xterm, maybe we can rebind this keys later to make them work with other terminals too. Bookmark commands are now included into the editor menu too. 2. Now when user tries to view or edit file which is already opened with another background viewer / editor, this sleeping viewer / editor is activated instead of opening new one. 3. Bugfixes. Now the patch seems to be pretty robust. 4. Some user-readable documentation is included. It is not in roff format yet but in the plain text. But it is easy to make mc.1.in patch using this plain text help. Probably it will be done in the next release of the patch. The patch can be downloaded from: www.sama.ru/~despair/mc/mc-multiscreen+bookmarks-patch-0.3.tar.gz Regards, Walery From proski at gnu.org Wed Aug 15 22:07:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 18:07:26 -0400 (EDT) Subject: OK vs. Ok In-Reply-To: <7257015.997788322749.JavaMail.imail@sammy> Message-ID: Hi, David! > > Please be careful here. "OK" is used in the "Learn Keys" dialog, which > > cannot be resized for longer translations, since it's already 80 > > characters wide. > > Hmm, I see... We could look for something else to use as a tick. What about > "~"? I tried several variants and I like "*" immediately after the the closing bracket: [Home key ] [Page Down key ]* [Page Up key ] Anyway, that "OK" is documented in several places, so I'm not going to fix it before the release. > As you are not refusing these "minor" fixes, I'll bring back the patch for > hotkeys (set or remove extra uppercase as in "Vie&w file..." --> "vie&W > file...") and right align key shortcuts in Command menu. I'm probably too easy to influence :-) I really should go through all the remaining issues this night and sent a notice to the translators, or we won't see mc-4.5.55 in August. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 15 22:10:14 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 18:10:14 -0400 (EDT) Subject: OK vs. Ok In-Reply-To: <22254632.997789154016.JavaMail.imail@sammy> Message-ID: > Sorry, I forgot this point. Appart from the hack in gwidget.c. As for > gettext "OK" and "&OK" or "_OK" are different strings so there would be no > problem to give them different translations. Anyway, it's time consuming to > check every OK message in the code and look for side effects... Not only it is time consuming. It is wrong. We should not expect the translators to be experts in anything but their language. > I would just try the "&Ok" -> "&OK" Not now, OK? :-) > Did I say I don't like the "cannot"? :( Sorry, I can't make everyone happy :-) -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 15 22:47:13 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 18:47:13 -0400 (EDT) Subject: SLang or not to SLang In-Reply-To: <12096287.997813010394.JavaMail.imail@sammy> Message-ID: > A couple of things with SLang: > > a) Messages about Slang in "mc -V" seem to be swapped. Good catch! Fixed. > b) I'm not sure if "configure --without-slang" (and variants) behaves as it > is supossed to. I don't think that --without-slang is supposed to be used. Use --with-ncurses to use ncurses and nothing to use S-Lang. Ideally, MC should have one option --with-screen=(slang|ncurses), like Lynx. > ./configure (...) --enable-charset Thank you for taking time to test all that. > ./configure (...) --enable-charset --without-slang --with-ncurses > Text mode screen manager: ncurses on /usr/include > (Compile error) I knew that. The charset patch is doing it wrong. I'm applying a quick fix: --------------------------------- --- main.c +++ main.c @@ -1841,8 +1841,13 @@ setup_pre (void) { /* Call all the inits */ #ifdef HAVE_CHARSET - int full_eight_bits = (display_codepage != 0 && display_codepage != 1); -#endif +/* + * Don't restrict the output on the screen manager level, + * the translation tables take care of it. + */ +#define full_eight_bits (1) +#define eight_bit_clean (1) +#endif /* !HAVE_CHARSET */ #ifndef HAVE_SLANG meta (stdscr, eight_bit_clean); --------------------------------- I'm really don't like the idea of MC asking the user, not the terminal library, whether 8-bit characters are allowed. It's another example when the first working (somehow) solution is the solution used in the code. I hope that I'll be able to do it better some day. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 15 23:07:58 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 19:07:58 -0400 (EDT) Subject: Uppercase in Hotkeys & menus In-Reply-To: <27971656.997813359887.JavaMail.imail@sammy> Message-ID: Hi, David! > This is the patch. If fixes Hotkeys and aligns the Command menu for the > original C locale. The patch to reset al .po files is included I'm sorry, but this should be done programmatically in my opinion. Translators should deal with plain text, without ampersands, spaces for alignment and strangely capitalized letters. Function keys should be translated separately. I suggest that we use the same hotkeys in all translations. I learned "F9 C C" since Norton Comander and I want it to work in every translation. MC should highlight the hotkey in the translated text if it can find it. If you want to capitalize hotkeys, do it programmatically, too. This is a lot of work, I know. But currently the following texts have to be translated separately into 30 languages: "&New C-n" "&New C-x k" Put yourself in a position of a translator without much knowledge about our ugly menu system, and imagine his or her frustration. Sorry, but I don't even want to touch all that without _fixing_ it. -- Regards, Pavel Roskin From proski at gnu.org Wed Aug 15 23:39:41 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 19:39:41 -0400 (EDT) Subject: Synchronyzing MC and Cooledit In-Reply-To: <20010815162240.A2226@localhost.localdomain> Message-ID: Hi, Walery! > The cooledit sources in the MC distribution is VERY outdated > (I can guess that the last syncronization was in 1997). Last synchronization tookplace in July 1999, according to the history of gtkedit/bookmark.c > So, many useful features from modern cooledit are not available > in MC now. > For instance it is "bookmarks". It's in the code. But it's not in the MC menu and there are no hotkeys. It looks like that it should be easy to fix without new synchronization, just by porting the cooledit menu already in the MC source. > Anyway, if cooledit and MC sources are not syncronizing > now we can safely strip !MIDNIGHT sections from the editor > sources. This code is NEVER used and it is inconvenient to > keep this dead code which only confuses developers working > with editor sources. I agree. Even if we plan to synchronize some code in the future, it will be done very carefully, on the per-function basic. > IMO this pieces of code should be cleaned along with > GNOME pieces in the new versions of MC. I'll do it. -- Regards, Pavel Roskin From proski at gnu.org Thu Aug 16 00:42:02 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 20:42:02 -0400 (EDT) Subject: New version of multiscreen patch In-Reply-To: <20010815180528.A5699@localhost.localdomain> Message-ID: Hi, Walery! > The keysbindings for working with bookmarks are the following: > > Ctrl-Alt-Insert: Add bookmark > Ctrl-Alt-Up: Move to previous bookmark > Ctrl-Alt-Down: Move to next bookmark Supporting this in xterm may be problematic, unless mc is linked with libX11. Perhaps linking with libX11 should become the default at some point. > I know it is a bad idea to mix unrelated patches, > but I have no time and aspiration now to separate them. I think you don't have _tools_. If I want to make significant changes in a project that I cannot (or don't want to) modify immediately, I usually reimport the source in a local CVS repository and tag the repository after every patch. If the patches are unrelated it may be better to use separate branches for every patch. -- Regards, Pavel Roskin From proski at gnu.org Thu Aug 16 03:57:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 15 Aug 2001 23:57:26 -0400 (EDT) Subject: Mangled prompt in xterm under XFree86 4.x In-Reply-To: <1124B458699A@csd.inp.nsk.su> Message-ID: Hello, Dmitry! > In xterm under XFree86 4.x the prompt is "prefixed" with a "^O", so that > instead of e.g. "goofy:~ " one sees "^Ogoofy:~" (shell is zsh with > PS1='%m:%~%# '). Finally I have fixed this problem. Actually, there were two problems: strip_ctrl_codes() wasn't using is_printable(). There are still many places where is_printable() should be used, but let's fix your problem first. strip_ctrl_codes() didn't work are advertized. Stripping of the sequences beginning with '\e[' was buggy. Unfortunately, this function was the finest example of "primadonna style coding", so I just rewrote it using pointers instead of indices - it was easier than to understand the existing code :-/ The patch: ------------------------------------ --- ChangeLog +++ ChangeLog @@ -2,2 +2,5 @@ + * util.c (strip_ctrl_codes): Rewrite using pointers. Fix + stripping sequences beginning with "\e[". Check is_printable(). + * man2hlp.c: Remove HTML support. Remove old link support. --- util.c +++ util.c @@ -841,28 +841,28 @@ char *skip_numbers (char *s) * terminfo databases, except the Hewlett-Packard 70092 and some Wyse * terminals. If I hear from a single person who uses such a terminal * with MC, I'll be glad to add support for it. (Dugan) + * Non-printable characters are also removed. */ char *strip_ctrl_codes (char *s) { - int i; /* Current length of the string's correct (stripped) prefix */ - int j; /* Number of control characters we have skipped so far */ + char *w; /* Current position where the stripped data is written */ + char *r; /* Current position where the original data is read */ if (!s) return 0; - - for (i = 0, j = 0; s [i+j]; ++i) - if (s [i+j] != ESC_CHAR){ - if (j) - s [i] = s [i+j]; + + for (w = s, r = s; *r; ++r) + if (*r != ESC_CHAR){ + if (is_printable(*r)) + *w++ = *r; } else { - ++j; - if (s [i+j++] == '[') - while (strchr ("0123456789;?", s [i+j++])) + if (*(++r) == '[') { + while (strchr ("0123456789;?", *(++r))) /* Skip the control sequence's arguments */ ; - --i; + } } - s[i] = 0; + *w = 0; return s; } ------------------------------------ The fixed snapshot is at http://www.red-bean.com/~proski/mc/ Thank you for reporting the problem! -- Regards, Pavel Roskin From dmartina at excite.com Thu Aug 16 12:54:34 2001 From: dmartina at excite.com (David Martin) Date: Thu, 16 Aug 2001 05:54:34 -0700 (PDT) Subject: Uppercase in Hotkeys & menus Message-ID: <7910596.997966474304.JavaMail.imail@jake.excite.com> Hmm... I could understand the time shortage but the automatic thing seems too poor for me. The idea of my patch was to have some GUI fixes before what seems to be a "semi stable" release supposed to take the place of 4.1.36 (even when it can't ftp Mcafee's site :) Most people is using translations and is not involved, but as there's no English l18n some people have to use the original C/POSIX mc and they would like some tidying of menus (which is already done this same way in the translations I've checked). On Wed, 15 Aug 2001 19:07:58 -0400 (EDT), Pavel Roskin wrote: | | I'm sorry, but this should be done programmatically in my opinion. | Translators should deal with plain text, without ampersands, spaces for | alignment and strangely capitalized letters. Function keys should be | translated separately. | | I suggest that we use the same hotkeys in all translations. I learned "F9 | C C" since Norton Comander and I want it to work in every translation. | MC should highlight the hotkey in the translated text if it can find it. | I disagree. - It can't be done in short (say for 4.5.55) - Shortcuts (in the right of the menu) are used even when the menu is not in screen, and they should be well known (and set by programmers). It won't be hard as I remember I did a patch to translate menu's only once (not everytime) and that seems a good bottleneck to do that. But, what if the translator (say, the language) wants the shortcut on the left, or whereever? Can we deal with all choices? - Hotkeys are not that important. You're used to F9 C C, but there's people who have been using our translations for ages and they got used to different things. How many different languages do you use at a time? Nevertheless, hotkeys are just a way to make every option usable from the keyboard without using arrow keys. You can't automatically set hotkeys as you don't even know if such key even exist in any language. - It's hard to choose the Hotkey for each menu as there are some long menus and the number of "single char keys used" is limited. It's the translator the only one who can make the best choice. It's hard, but it would be harder the other way. | If you want to capitalize hotkeys, do it programmatically, too. This is a | lot of work, I know. But currently the following texts have to be | translated separately into 30 languages: | | "&New C-n" | "&New C-x k" | I don't care for C-n and C-x k. Think of new XXX nn XXX nnn XXX | Put yourself in a position of a translator without much knowledge about | our ugly menu system, and imagine his or her frustration. | I do that quite often and I read their lists. Time for lunch. I'll take the time shortage argument. I'll go for my es.po and es_ES.po this evening with the latest snapshot. *8-) David _______________________________________________________ http://inbox.excite.com From proski at gnu.org Thu Aug 16 21:10:22 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 16 Aug 2001 17:10:22 -0400 (EDT) Subject: Double // in codepages list error In-Reply-To: Message-ID: Hi, David! > > You made no changes in setup.c so the original message and the "//" > > stay there. Is this the final solution? > > No, it's not the final solution. The "final" (for 4.5.55) solution has been committed. Any popups in the setup code cause MC to crash if it's linked with ncurses. I put fprintf instead, but the right solution would be to use logging, as Walery suggested. -- Regards, Pavel Roskin From proski at gnu.org Thu Aug 16 21:56:37 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 16 Aug 2001 17:56:37 -0400 (EDT) Subject: mc-4.5.55 to be released, please update translations Message-ID: Hello! I'm planning to release GNU Midnight Commander version 4.5.55 on Monday, August 20. The string freeze is now in effect. No changes in the translatable strings will be accepted until the release. GNU Midnight Commander has two frontends - text edition, running on the console and resembling Norton Commander (TM) and GNOME edition, which is historically the first file manager for GNOME. Please update the translations if you want MC to speak your language. If you are actually planning to update a translation really soon but cannot complete it by August 20, please contact me so that the release date is adjusted. I'm aware that many strings in GNU Midnight Commander were written without translation in mind. I'm not going to change them before the release, but if you have any ideas (not flames) please direct them to mc-devel at gnome.org If you don't have CVS access please send po files (preferrably compressed) to mc-devel at gnome.org The homepage of GNU Midnight Commander is http://www.gnome.org/projects/mc/ The CVS module in the GNOME reporitory is called "mc". You will need gettext-0.10.38 or 0.10.39 to build GNU Midnight Commander from CVS. Unofficial snapshots are at http://www.red-bean.com/~proski/mc/ They should not require anything special to be built (but note that glib is required). Portability testing of the current code will be appreciated. It is known that the subshell doesn't work on QNX Neutino due to unimlemented SA_RESTART on that platform. No other portability problems are known. -- Regards, Pavel Roskin From dmartina at excite.es Fri Aug 17 11:21:48 2001 From: dmartina at excite.es (David Martin) Date: Fri, 17 Aug 2001 04:21:48 -0700 (PDT) Subject: Gettext PO syntax file Message-ID: <745807.998047308174.JavaMail.imail@speedy.excite.com> I've got a syntax template for PO files used by translators: *8-) David ------------------------ # --------------------------------------------------- # po.syntax # GNU Gettext PO files syntax highlighting template. # Syntax highlighting rules for files produced with # Gettext tools as used in Midnight Commander and # Cooledit editors. # # It highlights: # - Original and translated messages (blue/green) # - Generic comments added by Gettext (white) # - C-style format modifiers, # as in c.syntax (brightgreen) # + Messages marked as "fuzzy" (red) # + Untranslated messages (red) # # Author: David Martin # August 17, 2001 # --------------------------------------------------- context default keyword linestart msgstr\s\"\"\n\n brightred/18 keyword linestart msgid brightcyan/14 keyword linestart msgstr brightcyan/14 context linestart #,\sfuzzy \n\n brightred/18 context linestart #: \n white/26 context linestart #, \n white/26 keyword c-format yellow/24 context linestart #~ \n gray/4 context linestart # \n brown/22 spellcheck context exclusive linestart msgid \n brightblue/11 spellcheck keyword \"\n\" keyword \\" brightgreen/16 keyword \\\n brightgreen/16 keyword %% brightgreen/16 keyword %\[#0\s-\+,\]\[0123456789\]\[.\]\[0123456789\]\[L\]\{eEfgG\} brightgreen/16 keyword %\[0\s-\+,\]\[0123456789\]\[.\]\[0123456789\]\[hl\]\{diouxX\} brightgreen/16 keyword %\[hl\]n brightgreen/16 keyword %\[.\]\[0123456789\]s brightgreen/16 keyword %[*] brightgreen/16 keyword %c brightgreen/16 keyword \\\{0123\}\{01234567\}\{01234567\} brightgreen/16 keyword \\\\ brightgreen/16 keyword \\' brightgreen/16 keyword \\\{abtnvfr\} brightgreen/16 context exclusive linestart msgstr \n green/6 spellcheck keyword \"\n\" keyword \\" brightgreen/16 keyword \\\n brightgreen/16 keyword %% brightgreen/16 keyword %\[#0\s-\+,\]\[0123456789\]\[.\]\[0123456789\]\[L\]\{eEfgG\} brightgreen/16 keyword %\[0\s-\+,\]\[0123456789\]\[.\]\[0123456789\]\[hl\]\{diouxX\} brightgreen/16 keyword %\[hl\]n brightgreen/16 keyword %\[.\]\[0123456789\]s brightgreen/16 keyword %[*] brightgreen/16 keyword %c brightgreen/16 keyword \\\{0123\}\{01234567\}\{01234567\} brightgreen/16 keyword \\\\ brightgreen/16 keyword \\' brightgreen/16 keyword \\\{abtnvfr\} brightgreen/16 --------------------------- _______________________________________________________ ?Tienes cuentas de e-mail GRATIS en Excite Espa?a! A tu disposici?n en http://correo.excite.es -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: po.syntax URL: From max at tavrida.net Fri Aug 17 12:34:08 2001 From: max at tavrida.net (Max Schedriviy) Date: Fri, 17 Aug 2001 15:34:08 +0300 Subject: (no subject) Message-ID: <200108171234.f7HCYB768141@skif.tavrida.net> patch for quick_input in the QuickDialog. Move cursor in copy/move/symlink/etc dialogs to end of string. --------------------------- --- wtools.c Wed Jun 27 16:29:24 2001 +++ wtools.c.new Fri Aug 17 15:02:16 2001 @@ -479,7 +479,10 @@ input = input_new (ypos, xpos, INPUT_COLOR, qw->hotkey_pos, qw->text, qw->tkname); input->is_password = qw->value == 1; - input->point = 0; + if (qw->text) + input->point = strlen(qw->text); + else + input->point = 0; if (qw->value & 2) input->completion_flags |= INPUT_COMPLETE_CD; widget = input; --------------------------- -- C U L8er! Max Schedriviy mailto:max at tavrida.net From max at tavrida.net Fri Aug 17 12:34:46 2001 From: max at tavrida.net (Max Schedriviy) Date: Fri, 17 Aug 2001 15:34:46 +0300 Subject: quick_input patch Message-ID: <200108171234.f7HCYk768201@skif.tavrida.net> patch for quick_input in the QuickDialog. Move cursor in copy/move/symlink/etc dialogs to end of string. --------------------------- --- wtools.c Wed Jun 27 16:29:24 2001 +++ wtools.c.new Fri Aug 17 15:02:16 2001 @@ -479,7 +479,10 @@ input = input_new (ypos, xpos, INPUT_COLOR, qw->hotkey_pos, qw->text, qw->tkname); input->is_password = qw->value == 1; - input->point = 0; + if (qw->text) + input->point = strlen(qw->text); + else + input->point = 0; if (qw->value & 2) input->completion_flags |= INPUT_COMPLETE_CD; widget = input; --------------------------- -- C U L8er! Max Schedriviy mailto:max at tavrida.net From dmartina at excite.com Fri Aug 17 11:42:13 2001 From: dmartina at excite.com (David Martin) Date: Fri, 17 Aug 2001 04:42:13 -0700 (PDT) Subject: Update to Spanish translations Message-ID: <1128273.998048533908.JavaMail.imail@jake.excite.com> I've just synced with CVS and remove those obsoleted messages (nice color GUI !!!). *8-) David _______________________________________________________ http://inbox.excite.com -------------- next part -------------- A non-text attachment was scrubbed... Name: es-4.5.55-4.po.bz2 Type: application/octet-stream Size: 34755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: es_ES-4.5.55-4.po.bz2 Type: application/octet-stream Size: 34780 bytes Desc: not available URL: From proski at gnu.org Fri Aug 17 14:13:59 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 17 Aug 2001 10:13:59 -0400 (EDT) Subject: Gettext PO syntax file In-Reply-To: <745807.998047308174.JavaMail.imail@speedy.excite.com> Message-ID: Hi, David! > I've got a syntax template for PO files used by translators: It's a great contribution! Thank you very much! I'm applying it. > context exclusive linestart msgid \n brightblue/11 I'm changing brightblue to cyan. It's very hard to read brightblue on blue with the default rxvt colors. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 17 14:44:46 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 17 Aug 2001 10:44:46 -0400 (EDT) Subject: Update to Spanish translations In-Reply-To: <1128273.998048533908.JavaMail.imail@jake.excite.com> Message-ID: On Fri, 17 Aug 2001, David Martin wrote: > I've just synced with CVS and remove those obsoleted messages (nice color > GUI !!!). Thank you! I've applied them. -- Regards, Pavel Roskin From max at tavrida.net Fri Aug 17 15:06:42 2001 From: max at tavrida.net (Max Schedriviy) Date: Fri, 17 Aug 2001 18:06:42 +0300 Subject: mc in mc patch Message-ID: <200108171506.f7HF6h791395@skif.tavrida.net> This patch not allow run mc in mc (from Advanced mc). --------------------------------- --- main.c Thu Aug 16 13:59:19 2001 +++ main.c.new Fri Aug 17 18:00:29 2001 @@ -2974,6 +2974,11 @@ int main (int argc, char *argv []) { + if(getenv("MC_CONTROL_FILE")){ + printf("It is NOT a good idea running mc from mc!\n"); + exit(1); + } + /* We had LC_CTYPE before, LC_ALL includs LC_TYPE as well */ setlocale (LC_ALL, ""); bindtextdomain ("mc", LOCALEDIR); --------------------------------- -- C U L8er! Max Schedriviy mailto:max at tavrida.net From mc at listserv.bat.ru Fri Aug 17 17:00:12 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Fri, 17 Aug 2001 19:00:12 +0200 Subject: mc in mc patch In-Reply-To: <200108171506.f7HF6h791395@skif.tavrida.net>; from max@tavrida.net on Fri, Aug 17, 2001 at 06:06:42PM +0300 References: <200108171506.f7HF6h791395@skif.tavrida.net> Message-ID: <20010817190012.A98717@bat.ru> On Fri, Aug 17, 2001 at 06:06:42PM +0300, Max Schedriviy wrote: > > This patch not allow run mc in mc (from Advanced mc). > I do have a habbit to edit/compile mc from mc and the run it... With this patch applied it will not be possible anymore.... Maube, just fprintf(stderr, ....); will be enough? WBR, BaT From nerijus at users.sourceforge.net Fri Aug 17 17:19:13 2001 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 17 Aug 2001 19:19:13 +0200 (EET) Subject: mc in mc patch In-Reply-To: <20010817190012.A98717@bat.ru> References: <200108171506.f7HF6h791395@skif.tavrida.net> <20010817190012.A98717@bat.ru> Message-ID: <200108171720.TAA1654295@mail.takas.lt> TIB> > This patch not allow run mc in mc (from Advanced mc). TIB> TIB> I do have a habbit to edit/compile mc from mc and the run it... TIB> TIB> With this patch applied it will not be possible anymore.... TIB> TIB> Maube, just fprintf(stderr, ....); will be enough? Or better an option? Regards, Nerijus From max at tavrida.net Fri Aug 17 17:24:20 2001 From: max at tavrida.net (mAX) Date: Fri, 17 Aug 2001 20:24:20 +0300 Subject: mc in mc patch In-Reply-To: <20010817190012.A98717@bat.ru> References: <200108171506.f7HF6h791395@skif.tavrida.net> <20010817190012.A98717@bat.ru> Message-ID: <1041074500.20010817202420@tavrida.net> TIB> I do have a habbit to edit/compile mc from mc and the run it... TIB> With this patch applied it will not be possible anymore.... TIB> Maube, just fprintf(stderr, ....); will be enough? You can compile with -DALLOW_MC_IN_MC option, but may be fprintf(... will be enough. -- Best regards, mAX mailto:max at tavrida.net From proski at gnu.org Fri Aug 17 17:23:54 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 17 Aug 2001 13:23:54 -0400 (EDT) Subject: mc in mc patch In-Reply-To: <20010817190012.A98717@bat.ru> Message-ID: Hi! > > This patch not allow run mc in mc (from Advanced mc). > > > I do have a habbit to edit/compile mc from mc and the run it... > > With this patch applied it will not be possible anymore.... Not only that. I often run "su" (not "su -l") from mc and then run mc as root to edit some file. This would be impossible too. Another situation. Sometimes (usually when playing with XF86Config) I run "startx" from mc and then run mc in xterm. This would also be impossible for no real reason. It's better to make sure that the parent mc is in the same process group before complaining. And still it should not be a fatal warning. Maybe if we implement logging using glib facilities mc could display a warning after it finishes initialization if there have been any warnings in the log. One of those warnings would be about parent mc. Another interesting idea would be to disable Ctrl-O in the child mc and force "Pause after run". > Maybe, just fprintf(stderr, ....); will be enough? The problem is not everybody will notice it. There are already some messages in vfs that use fprintf. MC could ask to "press y to continue, any other key to abort" in case of serious warnings, like missing extfs.ini and "mc in mc". -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 17 18:43:21 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 17 Aug 2001 14:43:21 -0400 (EDT) Subject: quick_input patch In-Reply-To: <200108171234.f7HCYk768201@skif.tavrida.net> Message-ID: Hi, Max! > patch for quick_input in the QuickDialog. Move cursor in > copy/move/symlink/etc dialogs to end of string. I think there is a good reason why the cursor is not a the end. It shows that if you start typing, the whole text will disapper. Modern software usually shows such easy-to-kill text in reverse color or at least changes the background. I remember that Far also does it (cyan on black or something like that). Next time please send ChangeLog entries with your patch. It helps understand your changes and makes it possible for me to use your name in ChangeLog. I cannot write my text in ChanleLog and put your name on it. -- Regards, Pavel Roskin From pavel at suse.cz Fri Aug 17 20:54:10 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 22:54:10 +0200 Subject: files highlighting In-Reply-To: <01070605212301.30735@humgat.tavrida.net>; from Max Schedriviy on Fri, Jul 06, 2001 at 05:21:23AM +0300 References: <01070605212301.30735@humgat.tavrida.net> Message-ID: <20010817225410.C4241@bug.ucw.cz> Hi! > 3) this patch allow to highlight files in depend of they are extensions > Patch isn't complete, and in future I want to describe extensions in ini-file. I thought midnight already has this feature? Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 20:55:21 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 22:55:21 +0200 Subject: Local copy/rename In-Reply-To: <01070605232502.30735@humgat.tavrida.net>; from Max Schedriviy on Fri, Jul 06, 2001 at 05:23:25AM +0300 References: <01070605232502.30735@humgat.tavrida.net> Message-ID: <20010817225521.D4241@bug.ucw.cz> Hi! > 4) this is simple patch to allow copy/rename files in current directory with > F15/F16 keys. Remove "added by mAX" comments, and it looks good. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 20:57:21 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 22:57:21 +0200 Subject: CTRL-"+|-|*" selection In-Reply-To: <01070605281203.30735@humgat.tavrida.net>; from Max Schedriviy on Fri, Jul 06, 2001 at 05:28:12AM +0300 References: <01070605281203.30735@humgat.tavrida.net> Message-ID: <20010817225721.E4241@bug.ucw.cz> Hi! > 5) this patch for select/unselect/reverse selections. using CTRL-"+", > CTRL-"-" keys select/unselect all files and dirs (mask "*"). > CTRL-"*" reverse selection including dirs. Instead of adding "force" parameter, I'd suggest passing char *. If it is NULL, ask user, otherwise use it as regexp. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 20:58:47 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 22:58:47 +0200 Subject: clocks in mc In-Reply-To: <01070605314104.30735@humgat.tavrida.net>; from Max Schedriviy on Fri, Jul 06, 2001 at 05:31:41AM +0300 References: <01070605314104.30735@humgat.tavrida.net> Message-ID: <20010817225847.F4241@bug.ucw.cz> Hi! > 6) clocks in right up corner. If using on Linux, clocks update only if key > pressed (may be need to change something in getch_with_delay() ?) I do not quite like this feature. It makes mc do "something" even when it is idle. If you want clock, well, put them into kernel or run X and use them as applet. This is filemanager, not clock-showing program. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 21:00:07 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 23:00:07 +0200 Subject: my other mc patches In-Reply-To: <01070605365405.30735@humgat.tavrida.net>; from Max Schedriviy on Fri, Jul 06, 2001 at 05:36:54AM +0300 References: <01070605365405.30735@humgat.tavrida.net> Message-ID: <20010817230007.G4241@bug.ucw.cz> Hi! > they are: > - assign filename to symlink Can you explain? > - F-keys on numbers > - copy filename with full path to command line - CTRL-'f' > - quick ftp dialog - ALT-'f' (works strange?) > - Show/Hide hidden files - CTRL-'h' > - change panels height - CTRL-Up/CTRL-Down This looks good. Pavel > - changed help colors (I like it :)) -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 21:06:57 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 23:06:57 +0200 Subject: Crash in vfs_s_close() In-Reply-To: ; from Pavel Roskin on Thu, Jul 19, 2001 at 07:12:15PM -0400 References: Message-ID: <20010817230657.H4241@bug.ucw.cz> Hi! > I was playing with compressed cpio files on fish and soon after that MC > crashed. I cannot reproduce this problem. > > Here's the info from the debugger. It looks bad. Sorry, I probably do not have time to chase it. > (gdb) where > #0 0x080aa165 in vfs_s_close (fh=0x8133230) at direntry.c:890 > #1 0x0809e2d3 in mc_close (handle=3) at vfs.c:501 > #2 0x080a968b in vfs_s_free_super (me=0x80c5b60, super=0x81066b8) at > direntry.c:445 > #3 0x080aa7b3 in vfs_s_free (id=0x81066b8) at direntry.c:1108 > #4 0x0809fbd9 in vfs_expire (now=0) at vfs.c:1200 > #5 0x0809fc3d in vfs_timeout_handler () at vfs.c:1212 > #6 0x080542c7 in get_event (event=0xbffffb00, redo_event=0, block=1) at > key.c:684 > #7 0x0806748e in run_dlg (h=0x80e36c8) at dlg.c:922 > #8 0x08082c6a in setup_panels_and_run_mc () at main.c:2186 > #9 0x08082e1a in do_nc () at main.c:2262 > #10 0x0808390e in main (argc=1, argv=0xbffffbd4) at main.c:3160 > #11 0x400e3177 in __libc_start_main (main=0x8083760
, argc=1, > ubp_av=0xbffffbd4, > init=0x804b0ac <_init>, fini=0x80aefb0 <_fini>, rtld_fini=0x4000e184 > <_dl_fini>, > stack_end=0xbffffbcc) at ../sysdeps/generic/libc-start.c:129 > (gdb) l > 885 > 886 int > 887 vfs_s_close (void *fh) > 888 { > 889 int res = 0; > 890 vfs *me = FH_SUPER->me; > 891 > 892 FH_SUPER->fd_usage--; > 893 if (!FH_SUPER->fd_usage){ > 894 struct vfs_stamping *parent; > (gdb) p *((struct vfs_s_fh *) fh) > $4 = {ino = 0x0, pos = 135272184, handle = 16, changed = 129, linear = 0, > u = {fish = {got = 0, total = -1}, ftp = {sock = 0}}, magic = -1} Is "magic" right at this point? Is changed expected to be 129? Looks strange. > (gdb) up > #1 0x0809e2d3 in mc_close (handle=3) at vfs.c:501 > 501 result = (*vfs->close)(vfs_info (handle)); > (gdb) p vfs_file_table[3]->operations->name > $14 = 0x80be24a "fish" > (gdb) > > Obviously, FH->ino is NULL, hence FH->ino->super cannot be accessed, not > to mention FH->ino->super->me. > > I can put a trivial workaround (check for FH->ino), but it looks like a > bug that we shouldn't hide. Forget workaround, leave it there for someone else to debug ;-). Or at least find reproducible testcase. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 21:13:20 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 23:13:20 +0200 Subject: Fix for another dala loss bug In-Reply-To: ; from Pavel Roskin on Wed, Aug 01, 2001 at 05:56:51PM -0400 References: Message-ID: <20010817231320.I4241@bug.ucw.cz> Hi! > "Safe save" and "Do backups" don't work on the remote VFS. Fixing it > properly is quite hard, because it requires on implementation of rename() > on VFS. VFS should have rename implemented, no? I seem to remember implementing it on ftp. OTOH, it may not be implemented, and many ftp servers probably can not do it, so rename is going to return error. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From pavel at suse.cz Fri Aug 17 21:15:27 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 17 Aug 2001 23:15:27 +0200 Subject: Fix for another data loss bug In-Reply-To: ; from Pavel Roskin on Mon, Aug 13, 2001 at 07:50:12PM -0400 References: <20010813130512.A24256@bcs.zp.ua> Message-ID: <20010817231527.J4241@bug.ucw.cz> Hi! > > : > : "Safe save" and "Do backups" don't work on the remote VFS. Fixing it > > : > : properly is quite hard, because it requires on implementation of rename() > > : > : on VFS. > > > > What is wrong with rename on VFS? It is work well on ftpfs and smbfs as far > > as I know. And I think it is ok on fish. > > I meant the rename() function that is used in mcedit. There is no > mc_rename() in VFS - it is declared in vfs.h but not implemented. The > mcedit code seems to rely on the atomic rename() to implement "Safe > Save". There is mc_rename... Or you have simple bug to fix. Many low-level vfs-es implement it and it is supposed to be there. Notice last line: pavel at bug:~/gnome/mc/vfs$ grep rename *.c fish.c:FISH_OP(rename, XTEST, "#RENAME /%s /%s\nmv \"/%s\" \"/%s\"; echo '### 000'" ); fish.c: fish_rename, /* rename */ ftpfs.c:static int ftpfs_rename (vfs *me, char *path1, char *path2) ftpfs.c: ftpfs_rename, local.c:local_rename (vfs *me, char *a, char *b) local.c: return rename (a, b); local.c: local_rename, mcfs.c:static int mcfs_rename (vfs *me, char *a, char *b) mcfs.c: mcfs_rename, mcserv.c:void do_rename (void) mcserv.c: status = rename (f1, f2); mcserv.c: { "rename", do_rename }, smbfs.c: *p = 0; /* cut off dir/files: sharename only */ smbfs.c:smbfs_rename (vfs *me, char *a, char *b) smbfs.c: if (!cli_rename(sc->cli, ra, rb)) { smbfs.c: smbfs_rename, vfs.c:MC_RENAMEOP (rename) Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From despair at sama.ru Sat Aug 18 14:06:46 2001 From: despair at sama.ru (Walery Studennikov) Date: Sat, 18 Aug 2001 10:06:46 -0400 Subject: mc in mc patch In-Reply-To: ; from proski@gnu.org on Fri, Aug 17, 2001 at 01:23:54PM -0400 References: <20010817190012.A98717@bat.ru> Message-ID: <20010818100646.A644@localhost.localdomain> On Fri, Aug 17, 2001 at 01:23:54PM -0400, Pavel Roskin wrote: > Hi! > > > > This patch not allow run mc in mc (from Advanced mc). > > > > > I do have a habbit to edit/compile mc from mc and the run it... > > > > With this patch applied it will not be possible anymore.... > > Not only that. I often run "su" (not "su -l") from mc and then run mc as > root to edit some file. This would be impossible too. Many people (including me) only suffer when running mc from mc by misprint (mv -> mc). Maybe we can make this a configurable feature, during compile time or from options dialog? Regards, Walery From max at tavrida.net Sat Aug 18 12:01:34 2001 From: max at tavrida.net (Max Schedriviy) Date: Sat, 18 Aug 2001 15:01:34 +0300 Subject: files highlighting In-Reply-To: <20010817225410.C4241@bug.ucw.cz> References: <01070605212301.30735@humgat.tavrida.net> <20010817225410.C4241@bug.ucw.cz> Message-ID: <200108181201.f7IC1Z701712@skif.tavrida.net> On Fri 17 Aug 2001 23:54, you wrote: > > 3) this patch allow to highlight files in depend of they are extensions > > Patch isn't complete, and in future I want to describe extensions in > > ini-file. > > I thought midnight already has this feature? are you sure? man what? :) -- C U L8er! Max Schedriviy mailto:max at tavrida.net From max at tavrida.net Sat Aug 18 12:07:15 2001 From: max at tavrida.net (Max Schedriviy) Date: Sat, 18 Aug 2001 15:07:15 +0300 Subject: clocks in mc In-Reply-To: <20010817225847.F4241@bug.ucw.cz> References: <01070605314104.30735@humgat.tavrida.net> <20010817225847.F4241@bug.ucw.cz> Message-ID: <200108181207.f7IC7G702142@skif.tavrida.net> On Fri 17 Aug 2001 23:58, you wrote: > Hi! > > > 6) clocks in right up corner. If using on Linux, clocks update only if > > key pressed (may be need to change something in getch_with_delay() ?) > > I do not quite like this feature. It makes mc do "something" even when > it is idle. If you want clock, well, put them into kernel or run X and > use them as applet. This is filemanager, not clock-showing program. This feature is optional. If you don't need it, you may disable it. Kernel is not right place for clock, and many peoples works in console, where current time may be shown only with `date` command. -- C U L8er! Max Schedriviy mailto:max at tavrida.net From max at tavrida.net Sat Aug 18 12:17:11 2001 From: max at tavrida.net (Max Schedriviy) Date: Sat, 18 Aug 2001 15:17:11 +0300 Subject: quick_input patch In-Reply-To: References: Message-ID: <200108181217.f7ICHE702969@skif.tavrida.net> On Fri 17 Aug 2001 21:43, you wrote: > > patch for quick_input in the QuickDialog. Move cursor in > > copy/move/symlink/etc dialogs to end of string. > > I think there is a good reason why the cursor is not a the end. It shows > that if you start typing, the whole text will disapper. I think, if you press F5, you remember, that if you start typing, text will be disappear. > Modern software usually shows such easy-to-kill text in reverse color or > at least changes the background. I remember that Far also does it (cyan > on black or something like that). I thnk, color highligthing will be enough. > Next time please send ChangeLog entries with your patch. Ok, next time I'll describe it. -- C U L8er! Max Schedriviy mailto:max at tavrida.net From lists at pervalidus.net Sat Aug 18 19:11:51 2001 From: lists at pervalidus.net (=?unknown-8bit?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 18 Aug 2001 16:11:51 -0300 Subject: clocks in mc Message-ID: <20010818161151.B102@pervalidus> Max Schedriviy wrote: > This feature is optional. If you don't need it, you may > disable it. Kernel is not right place for clock, and many > peoples works in console, where current time may be shown > only with date command. You can use GNU screen with caption always "%Y%m%d (%D) %0c:%s %l" in your ~/.screenrc -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Sun Aug 19 01:23:46 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 18 Aug 2001 21:23:46 -0400 (EDT) Subject: Uppercase in Hotkeys & menus In-Reply-To: <7910596.997966474304.JavaMail.imail@jake.excite.com> Message-ID: Hi, David! Sorry for the late reply. > Hmm... I could understand the time shortage but the automatic thing > seems too poor for me. No, I didn't mean that we should do settle for some quick fix before the release. I meant that we sould not expect the translators to care about things like spacing, menu alignment and the way how hotkeys (not shorcuts) are highlighted (i.e. by capitalization, by color etc). I probably was too radical in my suggestion to decide for the translators what the hotkeys (not shorcuts) should be. I agree with you that it would be too far (if that's what you meant). > The idea of my patch was to have some GUI fixes before what seems to > be a "semi stable" release supposed to take the place of 4.1.36 (even > when it can't ftp Mcafee's site :) Most people is using translations > and is not involved, but as there's no English l18n some people have > to use the original C/POSIX mc and they would like some tidying of > menus (which is already done this same way in the translations I've > checked). I understand that you were trying to capitalize all hotkeys. If I understand you correctly, some translations are very careful about it, but the original english text is not. Actually, modern GUI applications for X don't capitalize the hotkeys (I checked klyx, abiword, mozilla, konqueror, nautilus and of course gmc). They use underscores, and it looks better than "sKip" and "chOwn", in my personal opinion. I would rather go in the opposite direction and stop this abuse of uppercase letters. But it's not an issue that has any significant importance for me. I'm more annoyed by yellow on gray used in hotkeys. > - Shortcuts (in the right of the menu) are used even when the menu is > not in screen, and they should be well known (and set by programmers). > It won't be hard as I remember I did a patch to translate menu's only > once (not everytime) and that seems a good bottleneck to do that. But, > what if the translator (say, the language) wants the shortcut on the > left, or whereever? Can we deal with all choices? We should, if we want to implement so much requested redefinition of keys. Moving hotkeys to the left should be done programmatically. The alternative would be using "%s" in place of shortcut, but I don't think it would be better. Here are possible ways of what could be done. 1) "Create foo C-F" 2) "Create foo\tC-F" 3) "Create foo C-F" 4) "Create foo", "C-F" 5) "Create foo\t%s", "C-F" 1 is what we have now. Developers and and translators are responsible for the alignment. Shortcuts are hardcoded. 2 is used in cooledit (but not in the mcedit code). The alignment is automatic, but the shortcuts are still hardcoded. 3 - variation of the above, but backwards compatible and easier to read. It is assumed that two or more spaces can always be considered as a separator between left-aligned and right-aligned parts. 4 - my favorite. Alignment is automatic, shortcuts are variable. Names of shortcuts could be found using translations for "C-%s", "M-%s" etc. 5 - the same plus the ability to put %s on the left. I think the shortcut placement could be an option independent of the translation. > - Hotkeys are not that important. You're used to F9 C C, but there's > people who have been using our translations for ages and they got used > to different things. How many different languages do you use at a > time? Nevertheless, hotkeys are just a way to make every option usable > from the keyboard without using arrow keys. You can't automatically > set hotkeys as you don't even know if such key even exist in any > language. Good point. > - It's hard to choose the Hotkey for each menu as there are some long > menus and the number of "single char keys used" is limited. It's the > translator the only one who can make the best choice. It's hard, but > it would be harder the other way. Correct. If the hotkey is used more than once it should cycle through all matching items without activating them. I read it long ago in some standad. > | Put yourself in a position of a translator without much knowledge about > | our ugly menu system, and imagine his or her frustration. > > I do that quite often and I read their lists. I appreciate it. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 19 03:39:48 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 18 Aug 2001 23:39:48 -0400 (EDT) Subject: Crash in vfs_s_close() In-Reply-To: <20010817230657.H4241@bug.ucw.cz> Message-ID: Hi! > > I was playing with compressed cpio files on fish and soon after that MC > > crashed. I cannot reproduce this problem. I remember that some broken cpio archives were involved. I could reproduce the problem when MC crashes immediately on entering a truncated cpio archive on ftpfs (that time it was fish). I don't know if this bug is related (I think 20% probability that it is), but I'm fixing it anyway. ------------------------------------------ --- ChangeLog +++ ChangeLog @@ -1 +1,6 @@ +2001-08-18 Pavel Roskin + + * cpio.c (cpio_read_head): Check return value of cpio_find_head, + because it's not equal to super->u.cpio.type in case of errors. + 2001-08-16 Pavel Roskin --- cpio.c +++ cpio.c @@ -183,8 +183,7 @@ static int cpio_open_cpio_file(vfs *me, static int cpio_read_head(vfs *me, vfs_s_super *super) { - cpio_find_head(me, super); - switch(super->u.cpio.type) { + switch(cpio_find_head(me, super)) { case CPIO_UNKNOWN: return -1; case CPIO_BIN: ------------------------------------------ By the way, fh->changed=129 clearly indicates memory corruption. The code only assigns 0 and 1 to it. -- Regards, Pavel Roskin From max at tavrida.net Sun Aug 19 16:59:39 2001 From: max at tavrida.net (Max Schedriviy) Date: Sun, 19 Aug 2001 19:59:39 +0300 Subject: cursor at EOL in input widget Message-ID: <200108191659.f7JGxe740976@skif.tavrida.net> This patch move cursor in input fields to end of line and change color of this text if it will be disappear on typing. ChangeLog: --------------------------------- 2001-08-19 Max Schedriviy * color.[ch], main.c, text.c: Defined color for not changed text in WInput widget (INPUT_COLOR_NOTCH). Default color is gray on cyan. * wtools.c (quick_dialog_skip): Move cursor position on creation WInput widget to end of line. Set text color to INPUT_COLOR_NOTCH. * widget.c (handle_char): Set color to INPUT_COLOR if color is INPUT_COLOR_NOTCH. --------------------------------- input_EOL.diff --------------------------------- diff -Naur src/color.c src_new/color.c --- src/color.c Tue Jul 31 13:32:50 2001 +++ src_new/color.c Sun Aug 19 17:46:31 2001 @@ -104,7 +104,7 @@ { "core=", 0, 0 }, /* core files */ /* 29 */ { 0, 0, 0 }, /* not usable (DEFAULT_COLOR_INDEX) *//* 30 */ - { 0, 0, 0 }, /* unused */ + { "inputnotch=", 0, 0 }, /* not changed input field */ { 0, 0, 0 }, /* not usable (A_REVERSE) */ { 0, 0, 0 }, /* not usable (A_REVERSE_BOLD) */ diff -Naur src/color.h src_new/color.h --- src/color.h Tue May 29 20:02:28 2001 +++ src_new/color.h Sun Aug 19 17:44:36 2001 @@ -80,6 +80,7 @@ /* For the default color any unused index may be chosen. */ #define DEFAULT_COLOR_INDEX 30 #define DEFAULT_COLOR (PORT_COLOR (MY_COLOR_PAIR(DEFAULT_COLOR_INDEX),0)) +#define INPUT_COLOR_NOTCH (PORT_COLOR (MY_COLOR_PAIR(DEFAULT_COLOR_INDEX+1),0)) /* * editor colors - only 3 for normal, search->found, and select, respectively diff -Naur src/main.c src_new/main.c --- src/main.c Sat Aug 18 18:18:56 2001 +++ src_new/main.c Sun Aug 19 19:00:46 2001 @@ -2551,7 +2551,7 @@ "{FORE} and {BACK} can be ommited, and the default will be used\n" "\n" "Keywords:\n" - " Global: errors, reverse, gauge, input\n" + " Global: errors, reverse, gauge, input, inputnotch\n" " File display: normal, selected, marked, markselect\n" " Dialog boxes: dnormal, dfocus, dhotnormal, dhotfocus\n" " Menus: menu, menuhot, menusel, menuhotsel\n" diff -Naur src/text.c src_new/text.c --- src/text.c Thu Jun 14 18:59:52 2001 +++ src_new/text.c Sun Aug 19 17:40:28 2001 @@ -39,6 +39,7 @@ "helpslink=yellow,blue:" "gauge=white,black:" "input=black,cyan:" +"inputnotch=gray,cyan:" "directory=white,blue:" "executable=brightgreen,blue:" "link=lightgray,blue:" diff -Naur src/widget.c src_new/widget.c --- src/widget.c Tue Jul 31 14:04:21 2001 +++ src_new/widget.c Sun Aug 19 18:58:09 2001 @@ -1584,6 +1584,9 @@ v = 0; + if (in->color == INPUT_COLOR_NOTCH) + in->color = INPUT_COLOR; + if (quote){ free_completions (in); v = insert_char (in, c_code); diff -Naur src/wtools.c src_new/wtools.c --- src/wtools.c Wed Jun 20 20:12:47 2001 +++ src_new/wtools.c Sun Aug 19 17:47:36 2001 @@ -476,10 +476,13 @@ /* We use the hotkey pos as the field length */ case quick_input: - input = input_new (ypos, xpos, INPUT_COLOR, + input = input_new (ypos, xpos, INPUT_COLOR_NOTCH, qw->hotkey_pos, qw->text, qw->tkname); input->is_password = qw->value == 1; - input->point = 0; + if (qw->text) + input->point = strlen(qw->text); + else + input->point = 0; if (qw->value & 2) input->completion_flags |= INPUT_COMPLETE_CD; widget = input; --------------------------------- -- C U L8er! Max Schedriviy mailto:max at tavrida.net From Uraeus at linuxrising.org Mon Aug 20 15:57:28 2001 From: Uraeus at linuxrising.org (Christian Schaller) Date: 20 Aug 2001 17:57:28 +0200 Subject: PATCH: IBM AIX patches Message-ID: <998323048.1227.34.camel@localhost.localdomain> Hi, Here is the patch for MC from the official IBM package. (From http://www-1.ibm.com/servers/aix/products/aixos/linux/index.html) Since I believe that these patches haven't been submitted before I am sending them to the respective lists. Christian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mc-4.5.49-aixlt.patch URL: From proski at gnu.org Mon Aug 20 17:01:13 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 20 Aug 2001 13:01:13 -0400 (EDT) Subject: PATCH: IBM AIX patches In-Reply-To: <998323048.1227.34.camel@localhost.localdomain> Message-ID: Hi, Christian! I actually submitted some AIX-related patches from Dan McNichol . They looked very similar to your patch. The only change that was not applied is using EXTRALIBS for gmc-client. I understand that it needs libintl, but it certainly doesn't need libvfs and libgtkedit. I'm applying the following patch: ChangeLog: * Makefile.in: Move i18n part of EXTRALIBS to INTLLIBS. Use INTLLIBS when linking gmc-client. --------------------------------- --- gnome/Makefile.in +++ gnome/Makefile.in @@ -24,7 +24,8 @@ CORBA_LDFLAGS = $(XLDFLAGS) @GNOME_LIBDIR@ @GNOMEGNORBA_LIBS@ DEFS = $(XDEFS) LIBS = $(XLIBS) @TERMNET@ -EXTRALIBS = -L../vfs @LVFS@ -L../gtkedit -lgtkedit @LINTL@ @LIBICONV@ +INTLLIBS = @LINTL@ @LIBICONV@ +EXTRALIBS = -L../vfs @LVFS@ -L../gtkedit -lgtkedit $(INTLLIBS) DEPLIBS = $(top_builddir)/vfs/@LIBVFS@ \ $(top_builddir)/gtkedit/@libgtkedit@ @INTLDEPS@ INSTALL = @INSTALL@ @@ -246,7 +247,7 @@ $(CC) -o corba-gmc $(CORBAOBJS) $(OBJS) $(EXTRALIBS) $(CORBA_LDFLAGS) $(LIBS) gmc-client: $(CLIENTOBJS) - $(CC) -o gmc-client $(CLIENTOBJS) $(CORBA_LDFLAGS) $(LIBS) + $(CC) -o gmc-client $(CLIENTOBJS) $(INTLLIBS) $(CORBA_LDFLAGS) $(LIBS) mc.keys: mc.keys.in Makefile sed -e 's^\@icondir\@^$(icondir)^g' \ --------------------------------- I would like you to test the latest snapshot on http://www.red-bean.com/~proski/mc/ on AIX and report the results. Please give more information if you experience problems (compiler messages etc). I hope to release mc-4.5.55 tonight. It compiles out-of-box on RedHat Linux 7.1, FreeBSD 4.3 and QNX Neutrino. In the meantime I'll try to install more systems to test it on. Only very urgent patches will be applied before the release. -- Regards, Pavel Roskin From mc at listserv.bat.ru Mon Aug 20 17:57:08 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Mon, 20 Aug 2001 19:57:08 +0200 Subject: PATCH: IBM AIX patches In-Reply-To: ; from proski@gnu.org on Mon, Aug 20, 2001 at 01:01:13PM -0400 References: <998323048.1227.34.camel@localhost.localdomain> Message-ID: <20010820195708.A21797@bat.ru> On Mon, Aug 20, 2001 at 01:01:13PM -0400, Pavel Roskin wrote: > > The only change that was not applied is using EXTRALIBS for gmc-client. > I understand that it needs libintl, but it certainly doesn't need libvfs > and libgtkedit. I'm applying the following patch: > Hi, Pavel! I've tried new mc on bsd/os 4.1 - in general, it works. Minor problems were: 1. When compile with ncurses support, 'End' button stop to work. I.e. pressing 'End' generates only '^[', dunno, why. 2. With external Slang keys work, but tool bar at the bottom looks as one cyan line, without separators.... In general, screen is not refreshing properly, C-L need to be pressed. 3. Configure doesn't add system wide libintl to the list of the libraries, necessary for linking, even it finds it with libintl.h. But in other areas it looks good and usable. One more time - thanks a lot! With best regards, Timur. From proski at gnu.org Mon Aug 20 23:31:51 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 20 Aug 2001 19:31:51 -0400 (EDT) Subject: PATCH: IBM AIX patches In-Reply-To: <20010820195708.A21797@bat.ru> Message-ID: Hi, Timur! > I've tried new mc on bsd/os 4.1 - in general, it works. Minor problems were: Good news. Thank you. > 1. When compile with ncurses support, 'End' button stop to work. I.e. pressing > 'End' generates only '^[', dunno, why. Perhaps ncurses uses another terminal databas (termcap vs. terminfo) or interprets it differently. "Learn keys" should help. If it does, then it's fine, broken terminal databases are still quite common. If it doesn't help, then more information is needed - value of $TERM, version of ncurses, what terminal software is used (dtterm, xterm, console etc), and what the "End" button generates. Use "cat >file" to capture standard input and press End Enter Ctrl-C. > 2. With external Slang keys work, but tool bar at the bottom looks as one cyan > line, without separators.... In general, screen is not refreshing properly, C-L > need to be pressed. Sounds like that Slang is doing something too complicated for the terminal to handle properly. Try --with-included-slang - Slang 0.99.38 was nicer to UNIX terminals. > 3. Configure doesn't add system wide libintl to the list of the libraries, > necessary for linking, even it finds it with libintl.h. Do you have unresolved symbols? I understand that your libintl is incompatible with GNU gettext. In general, if you want to pursue any of those problems, more information will be helpful. But thank you for the report anyway. -- Regards, Pavel Roskin From timur at com.bat.ru Mon Aug 20 21:54:17 2001 From: timur at com.bat.ru (Timur I. Bakeyev) Date: Mon, 20 Aug 2001 23:54:17 +0200 Subject: cursor at EOL in input widget In-Reply-To: <200108191659.f7JGxe740976@skif.tavrida.net>; from max@tavrida.net on Sun, Aug 19, 2001 at 07:59:39PM +0300 References: <200108191659.f7JGxe740976@skif.tavrida.net> Message-ID: <20010820235417.A23137@bat.ru> Hi. Maxim! On Sun, Aug 19, 2001 at 07:59:39PM +0300, Max Schedriviy wrote: > > This patch move cursor in input fields to end of line and change color of > this text if it will be disappear on typing. Quite user-friendly :) > ChangeLog: > --------------------------------- > 2001-08-19 Max Schedriviy > * color.[ch], main.c, text.c: Defined color for not changed text > in WInput widget (INPUT_COLOR_NOTCH). Default color is gray on cyan. I'd suggest the name - INPUT_SELECT_COLOR, or smth. like this. The reason is, that: a. in Far, NC and others this is primary a selection, which kills the text, if any of altha-numeric character is inputed. b. We also do have a concept of a selecton in an input field, even it is not perfect - you can cut text by pressing C-@ at the beggining of the selection, go to it's end, press C-w, etc. It'll be neat to make this behaviour more coherent, and also highlight selection in this case with the same color. Speaking about grey on cyan - did you check, that this combination in B/W gives usefull color pair? I guess, it should look like white on black, but what are the actual colors? Also, I think, there is something error-prone in the color pairs - we need to define it for any situation, which may occure. I was scared to introduce that 8(or about) pairs for different file tipes and now you are goung to make file colors per extension. It can be nice, or maytbe not, but I'm afraid we'll end up with unmaintainable amount of color pairs. It'll be nice to be able just to specify colors directly, but I dunno, is it possible? Any ideas? With regards, Timur. From max at tavrida.net Tue Aug 21 14:25:42 2001 From: max at tavrida.net (Max Schedriviy) Date: Tue, 21 Aug 2001 17:25:42 +0300 Subject: cursor at EOL in input widget In-Reply-To: <20010820235417.A23137@bat.ru> References: <200108191659.f7JGxe740976@skif.tavrida.net> <20010820235417.A23137@bat.ru> Message-ID: <200108211425.f7LEPgm00959@skif.tavrida.net> On Tue 21 Aug 2001 00:54, Timur I. Bakeyev wrote: > I'd suggest the name - INPUT_SELECT_COLOR, or smth. like this. It isn't selection, it just show that text not changed and will be removed when you start typing. Selection must be another color. > The reason is, that: > a. in Far, NC and others this is primary a selection, which kills the > text, if any of altha-numeric character is inputed. In FAR not changed text has gray on cyan color, and selected text is white on black. > b. We also do have a concept of a selecton in an input field, even it > is not perfect - you can cut text by pressing C-@ at the beggining of the > selection, go to it's end, press C-w, etc. I think, this is not useful, better make normal select/copy/cut/paste with common shortcuts like S-Arrows/C-Ins/S-Ins and C-c/C-v/etc. > Speaking about grey on cyan - did you check, that this combination in B/W > gives usefull color pair? I guess, it should look like white on black, but > what are the actual colors? I think, this in not a problem, because it is only cosmetic feature. -- C U L8er! Max Schedriviy mailto:max at tavrida.net From despair at sama.ru Thu Aug 23 21:12:10 2001 From: despair at sama.ru (Walery Studennikov) Date: Thu, 23 Aug 2001 17:12:10 -0400 Subject: MC release Message-ID: <20010823171210.A638@localhost.localdomain> Is MC 4.5.55 not released yet? The announced release date was 20 Aug, but it is not in ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ yet. Regsrds, Walery From proski at gnu.org Thu Aug 23 13:37:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 23 Aug 2001 09:37:26 -0400 (EDT) Subject: MC release In-Reply-To: <20010823171210.A638@localhost.localdomain> Message-ID: Hi, Walery! > Is MC 4.5.55 not released yet? > The announced release date was 20 Aug, First gnu.org was down, so I waited for it to be fixed, so I could check my mail for possible urgent bugreports. Next, my internet connection went down, so I was only ably to test MC offline. Sorry for all that. Before going offline I asked in gnome-hackers at gnome.org how to release a new version and where to upload it. Unfortunately, moderators didn't let my message in. I'll try asking Miguel personally. I don't feel I can use red-bean.com to distribute the new version - it may generate too much traffic. I'll try to sort it out today. -- Regards, Pavel Roskin From proski at gnu.org Fri Aug 24 09:03:23 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 24 Aug 2001 05:03:23 -0400 (EDT) Subject: MC 4.5.55 tagged, 4.5.x branch created Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Version 4.5.55 of GNU Midnight Commander has been tagged in CVS by the tag MC_4_5_55. Use the following command to retrieve it from CVS: cvs up -r MC_4_5_55 I don't have the necessary bandwidth to distribute the tarball at this time, but I do have the tarball. It should appear on ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ as soon as I get access to upload it. The stable branch "Branch_MC_4_5_x" has been created on CVS. The version on the branch has been bumped to 4.5.55a. The version of the head branch has been bumped to 4.5.99a. All changes to the GNOME frontend belong to the stable branch only. Support for GNOME will be removed from the head branch in the next few days. Version 4.5.55 is known to work on RedHat Linux 7.1 (i386), Debian unstable for SPARC, FreeBSD 4.3 (i386), Cygwin 1.3.2 (current) and QNX Neutrino 6.0.0. Recent prereleases have been successfully tested by me on Slackware 7.0, Slackware 7.1 and OpenBSD 2.9 (all i386). I also have positive reports about BSDi (i386) and Solaris 2.5.1 (SPARC). *BSD support is basically on a par with GNU/Linux, except that you are more likely to need "Learn Keys" and --with-internal-slang. Cygwin support is very poor. Both the viewer and the editor emit useless warnings every time they are used. But it compiles cleanly. QNX Neutrino doesn't support subshell by default due to lack of SA_RESTART support. It can be compiled with SA_RESTART removed from the system headers (which is the right thing IMO). In this case mc works with bash, but not with zsh. BeOS is not supported due to serious limitations of its select() call - it only works on sockets. The native (non-cygwin) port for Win32 and OS/2 is out of date and does not work, but can be fixed. - -- Regards, Pavel Roskin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hhhi5AxqmNHPNskRAkvAAKC1FSrLElV24Z1Lvrh4xfsWVSDYqwCfSBWO QFCBGJY3MiC/p4mSCDY17hM= =03aU -----END PGP SIGNATURE----- From proski at gnu.org Fri Aug 24 15:45:11 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 24 Aug 2001 11:45:11 -0400 (EDT) Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 Message-ID: Hello everybody! GNU Midnight Commander 4.5.55 has been released. Development of the GNOME frontend will continue on the stable branch only: "Branch_MC_4_5_x". All GNOME support will be removed from the head branch in the next few days. NEWS: - Mostly bugfixes and portability fixes. Making things work as they were meant to work. - Text edition improvements. - Ctrl-O supported in the viewer and editor. - Better terminal support. Should not need "Learn Keys" on rxvt and xterm in most cases. - GNOME edition improvements. - Find dialog rewritten. - Editor and viewer ask whether to save modified file when closed from window manager. - Editor. - New syntax rules - S-Lang, PO files, Octave. - Alt-B goes to matching bracket. - Portability improvements. - Should compile out-of-box on Cygwin and QNX Neutrino. - Can be compiled by BSD make. - Subshell and VFS code are safer and more portable. - Experimental features (disabled by default). - Charset conversion support. - Large (64-bit) file support on 32-bit systems. Homepage: http://www.gnome.org/projects/mc/ The source tarball is currently available here: http://www.gnome.org/projects/mc/mc-4.5.55.tar.gz Note that the final location will be ftp://ftp.gnome.org/pub/GNOME/stable/sources/mc/ Any help with moving the tarball to the final location (or giving me access to do so) will be appreciated. -- Regards, Pavel Roskin From mc at listserv.bat.ru Fri Aug 24 22:01:25 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Sat, 25 Aug 2001 00:01:25 +0200 Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: ; from proski@gnu.org on Fri, Aug 24, 2001 at 11:45:11AM -0400 References: Message-ID: <20010825000125.A50459@bat.ru> Hi, Pavel! Just found a bug with 4.5.54a: If a have a path with one of the directories with 0711 permissions for example, like: /tmp/a/b/ where 'ls -ald /tmp/a' says: drwx--x--x 2 root wheel 512 Aug 24 23:45 /tmp/a and make a symlink: ln -s /tmp/a/b c then tapping on a directory c/ in MC throws you to the root directory '/'. With old MC I'm getting desired behaviour. Regards, Timur. From proski at gnu.org Fri Aug 24 23:20:00 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 24 Aug 2001 19:20:00 -0400 (EDT) Subject: Status update Message-ID: Hello! Finally I could make some changes that I delayed for "after 4.5.55". GNOME support has been removed. The GNOME-specific directories are not used in the build and are not included into the distribution produced by "make dist". Sources from "gtkedit" have been returned to "edit". Don't modify anything in the "gtkedit" directory in the HEAD branch - it will have no effect apart from your frustrations and lost time. Miguel asked me not to remove GNOME-specific files from CVS, because the CVS server on gnome.org is old and has some problems handling files on branches if the file is removed from the HEAD branch. Let's see if there is any demand to create new versions from the stable branch. Then we could revisit this problem. It should be possible to remove unused directories from the CVS working directory and from CVS/Entries. Here's the list: gtkedit gnome new_icons idl doc-gnome macros Of course, using "cvs up -d" will bring them back, so be careful if your connection is slow. The GNOME code will be removed from source files step-by-step, possibly after applying Walery's patches. Another change is removing support for curses libraries other than ncurses. It is very old and nobody needs that since S-Lang is included in the MC distribution. I also enabled large file support by default. I know that the Autoconf macro AC_SYS_LARGEFILE is not quite stable yet, but we should be able to fix it by the time when mc-4.6 is released (I expect it to happen in December 2001). -- Regards, Pavel Roskin From proski at gnu.org Sat Aug 25 03:37:25 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 24 Aug 2001 23:37:25 -0400 (EDT) Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: <20010825000125.A50459@bat.ru> Message-ID: Hi, Timur! > then tapping on a directory c/ in MC throws you to the root directory '/'. I could not reproduce this problem on Linux 2.4.8-ac7 with /tmp mounted as tmpfs, logged in as ordinary user. In your case it is probably *BSD. I have no time to guess. Please either give more details right away or send the patch. > With old MC I'm getting desired behaviour. I don't know how old your "old" MC is, but I cannot think of any changes that could have changed this behavior. But just in case, try the same without the subshell support (mc -u). -- Regards, Pavel Roskin From lists at pervalidus.net Sat Aug 25 05:36:22 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 02:36:22 -0300 Subject: --with-ncurses problems Message-ID: <20010825023622.Q10189@pervalidus> Hi. I just read a message about ncurses problems with keys and decided to give it a try. I have ncurses-5.2-20010811. CVS of 24h ago compiled with --libdir=/usr/local/share --disable-nls --disable-glibtest --without-samba --without-gpm-mouse --without-gnome --with-netrc --without-ext2undel --with-ncurses --without-slang I thought --without-slang would skip the S-Lang tests in configure, but it doesn't. OK. It compiled. I'm using screen on Linux console. Problems: - Syntax highlighting doesn't work at all. I thought the --libdir option was causing the problem, but tried symlinking it to /usr/local/lib/mc to no avail. - Shift+FX doesn't work. I can't get Midnight Commander to create a new file in the editor and other options that use Shift+Fx. Shift+F1 prints [25~ Shift+F2 [26~[28~ Shift+F3 [28~ Shift+F4 [29~ And so on. Learn keys doesn't help, but it recognizes the keys. Only until F10. And some keys aren't recognized. As an example, if I try End: Cannot accept this key You have entered "h" Maybe time to declare ncurses BROKEN ? -:) -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From lists at pervalidus.net Sat Aug 25 06:04:51 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 03:04:51 -0300 Subject: Status update Message-ID: <20010825030451.R10189@pervalidus> Pavel Roskin wrote: > Miguel asked me not to remove GNOME-specific files from CVS, > because the CVS server on gnome.org is old and has some > problems handling files on branches if the file is removed > from the HEAD branch. Let's see if there is any demand to > create new versions from the stable branch. Then we could > revisit this problem. Remove = add to .cvsignore ? > It should be possible to remove unused directories from the > CVS working directory and from CVS/Entries. Here's the list: > gtkedit gnome new_icons idl doc-gnome macros > Of course, using "cvs up -d" will bring them back, so be > careful if your connection is slow. I have "update -d -P" in ~/.cvsrc and my connection is slow :( I don't like the idea of downloading everything again if I do cvs co or up with -d... Any better approach than not using -d ? > I also enabled large file support by default. I know that > the Autoconf macro AC_SYS_LARGEFILE is not quite stable yet, > but we should be able to fix it by the time when mc-4.6 is > released (I expect it to happen in December 2001). What do you mean with "not quite stable yet" ? What are the problems if "we should be able to fix" ? I have Autoconf 2.52 / Automake 1.5. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From lists at pervalidus.net Sat Aug 25 06:46:36 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 03:46:36 -0300 Subject: --with-ncurses problems Message-ID: <20010825034636.T10189@pervalidus> BTW, I forgot to report the warnings using GCC 3.0.1: /usr/local/src/CVS/GNU/mc/vfs/cpio.c: In function cpio_read_bin_head': /usr/local/src/CVS/GNU/mc/vfs/cpio.c:261: warning: const qualifier ignored on asm edit.c: In function edit_execute_cmd': edit.c:2577: warning: %c' yields only last 2 digits of year in some locales -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From martin at internet-treff.uni-koeln.de Sat Aug 25 08:10:35 2001 From: martin at internet-treff.uni-koeln.de (Martin Bialasinski) Date: 25 Aug 2001 10:10:35 +0200 Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: References: Message-ID: <87heuwy2ys.fsf@haitech.martin.home> Pavel Roskin wrote: Hi, > GNU Midnight Commander 4.5.55 has been released. way cool :-) > - Experimental features (disabled by default). > - Charset conversion support. > - Large (64-bit) file support on 32-bit systems. I got a request for enabling the conversion support in the Debian package of mc. Do you say it is OK to enable this feature for distributions, or should I rather wait until it is declared stable? Same goes for the large file support. Could it do something nasty to the user's files if there is a bug? Ciao, Martin From samoylik at mail.od.ua Sat Aug 25 05:34:45 2001 From: samoylik at mail.od.ua (Vitaly Samoylik) Date: Sat, 25 Aug 2001 08:34:45 +0300 (EEST) Subject: Old versions of mc Message-ID: Hello. Where can I find old versions of mc? I need very small and simple mc. Bye --- Vitaly Samoylik samoylik at mail.od.ua 2:467/106.28 at FidoNet ICQ# 23566772 From proski at gnu.org Sat Aug 25 17:29:23 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 25 Aug 2001 13:29:23 -0400 (EDT) Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: <87heuwy2ys.fsf@haitech.martin.home> Message-ID: Hi, Martin! > > - Experimental features (disabled by default). > > - Charset conversion support. > > - Large (64-bit) file support on 32-bit systems. > > I got a request for enabling the conversion support in the Debian > package of mc. > > Do you say it is OK to enable this feature for distributions, or > should I rather wait until it is declared stable? I'll give you some facts that you should consider, but I'd rather leave the decision up to you. Charsest conversion support includes new dialogs and new strings. I believe that they are not translated to many languages. For example, "Input / display codepage:" is only translated to 15 languages of the 30 supported. Charsest conversion support replaces the old "Display bits" stuff, that allows you to limit the display to the ASCII characters (32-127) or to ISO-8859-1 (32-127,160-255). Now libc is responsible for the conversion. I haven't tested whether it will reliably remove the "harmful" characters from the output when the output codepage is set to ASCII or ISO-8859-1. What is worse is that limiting the output range is bundled with output conversion. If I want to view files in koi8-r with occasional "noise" (e.g. pseudographics) in the 128-159 area on a terminal that goes crazy because of that "noise", I may be forced to used ISO-8859-1 for output and thus have all cyrillic symbols converted to their latin couterparts. This may be too confusing for some users even if the right solution can be found. Don't forget that even Debian GNU/Linux boxes can be accessed from outside, so it's not a matter of capabilities of Debian's xterm. All charsest conversion setting are common for all terminals. This is also wrong. The old code (Display bits) has this problem too, but it may be more visible if many users who didn't need display bits limitation start using charset conversion. In short - it's won't eat your data, it will be useful for many, but expect more confused users and more bugreports. > Same goes for the large file support. Could it do something nasty to > the user's files if there is a bug? Of course it can. Big-endian machines (SPARC, PPC) are more in danger because even small files (below 4G) will be affected. But I don't expect any bugs of this kind because there are no warnings from gcc. The real reason why the large file support is disabled by default is because some systems (Solaris) use preprocessor directives to implement 64-bit file access. Somewhere in the headers they enable #define stat stat64 and for this to work correctly, the identifier "stat" should not be used to denote anything else but the "stat" structure as defined in libc. This is not the case for MC, which uses "stat" in vfs.h as a member name in "struct _vfs". Needless to say that GNU libc does it better. On the positive side, enabling the large file support works around another bug in MC - files on which stat() files are not shown on panels. It happens with large files if the large file support is disabled. In short, the large file support should be safe and useful if it compiles without warnings. -- Regards, Pavel Roskin From lists at pervalidus.net Sat Aug 25 17:38:34 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 14:38:34 -0300 Subject: Old versions of mc Message-ID: <20010825143834.Y10189@pervalidus> Vitaly Samoylik wrote: > Where can I find old versions of mc? I need very small and > simple mc. How old ? http://uiarchive.uiuc.edu/mirrors/ftp/ftp.gnu.org/gnu/mc/ The old original site is ftp://ftp.nuclecu.unam.mx/linux/local/ , but I couldn't connect. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From despair at sama.ru Sun Aug 26 03:10:40 2001 From: despair at sama.ru (Walery Studennikov) Date: Sat, 25 Aug 2001 23:10:40 -0400 Subject: Old versions of mc In-Reply-To: <20010825143834.Y10189@pervalidus>; from lists@pervalidus.net on Sat, Aug 25, 2001 at 02:38:34PM -0300 References: <20010825143834.Y10189@pervalidus> Message-ID: <20010825231040.A2020@localhost.localdomain> Vitaly Samoylik wrote: > Where can I find old versions of mc? I need very small and > simple mc. You can use Advanced Midnight Commander. It can be found via freshmeat. -- Regards, Walery From proski at gnu.org Sat Aug 25 18:44:17 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 25 Aug 2001 14:44:17 -0400 (EDT) Subject: Status update In-Reply-To: <20010825030451.R10189@pervalidus> Message-ID: Hi, Fr?d?ric! > Remove = add to .cvsignore ? No. .cvsignore only affects the quiestion marks that cvs prints for unknown files. It also affects "cvs import". Please read "info cvs" for more details. I mean removing (by "cvs remove") all files so that "cvs up -P" removes empty directories. This is what was done with the "tk" and "xview" directories. > > Of course, using "cvs up -d" will bring them back, so be > > careful if your connection is slow. > > I have "update -d -P" in ~/.cvsrc and my connection is slow > :( I don't like the idea of downloading everything again if I do > cvs co or up with -d... Any better approach than not using -d ? 1) Using "cvs up -d" only on the projects where you need it. 2) Creating an "mc-text" module in CVS. I'll have a look, but it will only affect "cvs co", not "cvs up". 3) Finding Miguel and persuading him that he is wrong. The first part is already hard to implement, not to mention the second :-) 4) Fix CVS client to omit "-d" from "cvs up" if run in certain directories. 5) Fix CVS to support blacklists (i.e. .cvsignore in your interpretation) and _real_ modules surviving "cvs up -d". 6) Switch from CVS to Subversions or BitKeeper. > > I also enabled large file support by default. I know that > > the Autoconf macro AC_SYS_LARGEFILE is not quite stable yet, > > but we should be able to fix it by the time when mc-4.6 is > > released (I expect it to happen in December 2001). > > What do you mean with "not quite stable yet" ? What are the > problems if "we should be able to fix" ? I have Autoconf 2.52 > / Automake 1.5. I remember seeing a lot of bugreports in the Autoconf lists regarding AC_SYS_LARGEFILE. Notably, it doesn't work with C++. I don't know if any of general problems affect MC anyhow. For the MC-specific problem, see my message to Martin. -- Regards, Pavel Roskin From mc at listserv.bat.ru Sat Aug 25 18:55:51 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Sat, 25 Aug 2001 20:55:51 +0200 Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: ; from proski@gnu.org on Fri, Aug 24, 2001 at 11:37:25PM -0400 References: <20010825000125.A50459@bat.ru> Message-ID: <20010825205551.A61483@bat.ru> Hi, Pavel! It seems, I was wrong with the description, or, you tried it in a different way. Basically, the conditions, that can expose the bug are - you have no read access to one of the dirs in the path in symlink. Then you'll be thrown to '/'. Ok, the cause of this problem is in one of your recent changes: 2001-07-17 Pavel Roskin * util.c (get_current_wd): Remove. It's obsoleted by g_get_current_dir() from glib. Unfortunatelly, g_get_current_dir() has a strange 'feature', that makes it im- possible to use it in MC - in case of inability to read the path instead of returning NULL it returns '/'(actually, G_DIR_SEPARATOR). So, there is no clear way to distinct error and a leagal case when your current dir is root, or when it is a symlink to root. I guess, the cheapest solution is to revert this change, unless we can change the behaviour of the glib function. With best regards, Timur. On Fri, Aug 24, 2001 at 11:37:25PM -0400, Pavel Roskin wrote: > Hi, Timur! > > > then tapping on a directory c/ in MC throws you to the root directory '/'. > > I could not reproduce this problem on Linux 2.4.8-ac7 with /tmp mounted as > tmpfs, logged in as ordinary user. > > In your case it is probably *BSD. I have no time to guess. Please either > give more details right away or send the patch. > > > With old MC I'm getting desired behaviour. > > I don't know how old your "old" MC is, but I cannot think of any changes > that could have changed this behavior. > > But just in case, try the same without the subshell support (mc -u). > > -- > Regards, > Pavel Roskin From proski at gnu.org Sat Aug 25 19:05:39 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 25 Aug 2001 15:05:39 -0400 (EDT) Subject: GCC 3.0.1 In-Reply-To: <20010825034636.T10189@pervalidus> Message-ID: > BTW, I forgot to report the warnings using GCC 3.0.1: > > /usr/local/src/CVS/GNU/mc/vfs/cpio.c: In function cpio_read_bin_head': > /usr/local/src/CVS/GNU/mc/vfs/cpio.c:261: warning: const qualifier ignored on asm > > edit.c: In function edit_execute_cmd': > edit.c:2577: warning: %c' yields only last 2 digits of year in some locales This compiler is so smart to find out that I'm passing %c to strftime() (unlike 2.95.2, which can be fooled by placing %c to a separate constant), yet it's so dumb to print this warning at all! "%c" is used in the "insert Date/time" command. User settings should be respected, at least in the code that outputs text for the user. I know that "%c" is correct here. There is no simple way to suppress the warning. I reported this problem to the gcc maintainers. They acknowledged it (it's my understanding of the reply I got), but didn't fix it in gcc-3.0.1. Unless you have an idea how to suppress this warning without doing insane stuff (like moving time_format to another file or removing "const" from it), I'm not going to fix it. GNU Coding Standards say: "Don't make the program ugly to placate `lint'." Ironically, this time it applies to GNU C Compiler. -- Regards, Pavel Roskin From proski at gnu.org Sat Aug 25 19:21:24 2001 From: proski at gnu.org (Pavel Roskin) Date: Sat, 25 Aug 2001 15:21:24 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: <20010825023622.Q10189@pervalidus> Message-ID: Hi! > I thought --without-slang would skip the S-Lang tests in > configure, but it doesn't. That's because it wasn't me who wrote this test. I hope to fix it some day. > OK. It compiled. I'm using screen on Linux console. Problems: > > - Syntax highlighting doesn't work at all. I thought the > --libdir option was causing the problem, but tried symlinking > it to /usr/local/lib/mc to no avail. It is a known limitation of the ncurses build. It should be fixed - I see no fundamental reasons for this limitation. > - Shift+FX doesn't work. I can't get Midnight Commander to > create a new file in the editor and other options that use > Shift+Fx. I could not reproduce this problem. Please give more information - terminal name, ncurses version, OS version etc. > Shift+F1 prints [25~ Where? In mc? Or in dd? > Shift+F2 [26~[28~ This looks bad. I'm not surprised that MC has hard time learning this. > Learn keys doesn't help, but it recognizes the keys. Only > until F10. > > And some keys aren't recognized. As an example, if I try End: > > Cannot accept this key > > You have entered "h" But what exactly happens when you try to teach MC F11, F12 etc? > Maybe time to declare ncurses BROKEN ? -:) No. I haven't seen a single detailed bugreport regarding ncurses support in MC (your message doesn't qualify as a detailed bugreport for obvious reasons). But old UNIX curses are not supported anymore in the head branch. -- Regards, Pavel Roskin From lists at pervalidus.net Sat Aug 25 19:27:38 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 16:27:38 -0300 Subject: Status update Message-ID: <20010825162738.A10189@pervalidus> Pavel Roskin wrote: >> I have "update -d -P" in ~/.cvsrc and my connection is slow >> :( I don't like the idea of downloading everything again if I >> do cvs co or up with -d... Any better approach than not using >> -d ? > 1) Using "cvs up -d" only on the projects where you need it. But apparently I need for everything except mc. All other projects create new directories. XFree86, GNOME, KDE, Mozilla, LFTP, Mutt, and more. Maybe a few don't. > 3) Finding Miguel and persuading him that he is wrong. The > first part is already hard to implement, not to mention the > second :-) Or moving the new text version to Savannah ? I thought GNU would be used now that the GNOME version was removed. > 5) Fix CVS to support blacklists (i.e. .cvsignore in your > interpretation) and _real_ modules surviving "cvs up -d". What I miss. If I could remove all po/*.po without losing anything... My last attempt was to chmod 700 po , but cvs up aborts. Without write permission for the user it won't write any files in po/ , but still uploads them (in memory I bet). -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From iamcliff at freeengineer.org Sat Aug 25 19:29:39 2001 From: iamcliff at freeengineer.org (C R Johnson) Date: Sat, 25 Aug 2001 15:29:39 -0400 Subject: gmc goes insane Message-ID: <3B87FCA3.9040708@freeengineer.org> When gmc (mc 4.5.51 or 4.5.55) runs , it uses all my CPU, grabs all my memory ( all 512 MB + swap ) , and ends up pretty much making the desktop unusable, requiring me to to kill X. I also get the "no response from the saveyourself program" message. Needles to say, Gnome is pretty broken without gmc, but I had to remove it make it work at all. My system is rh7.1 / Gnome 1.2 except for 3 unusual things which are probably be related to this: First, I am using XIG Accelerated X 1.1 instead of XFree86. Second I am using the xfs filesystem. Third, I am using devfs. Things were working fine before when I was using rh6.2, ext2, and no devfs - but still XIG. Please help me fix this. Regards, Cliff From lists at pervalidus.net Sat Aug 25 19:44:16 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sat, 25 Aug 2001 16:44:16 -0300 Subject: --with-ncurses problems Message-ID: <20010825164416.B10189@pervalidus> Pavel Roskin wrote: >> - Shift+FX doesn't work. I can't get Midnight Commander to >> create a new file in the editor and other options that use >> Shift+Fx. > I could not reproduce this problem. Please give more > information - terminal name, ncurses version, OS version etc. TERM=screen on console. screen 3.9.9 on Linux 2.4.9. ncurses 5.2-20010811. If it's broken Thomas E. Dickey will fix in the next releases, but I really doubt. >> Shift+F1 prints [25~ > Where? In mc? Or in dd? dd ? The utility from fileutils ? No. If I press Shift+F1 in MC: root(16:33:58)[mc] # [25~ The subshell. >> Shift+F2 [26~[28~ > This looks bad. I'm not surprised that MC has hard time > learning this. Sorry, Shift+F2 prints [26~, not [26~[28~. > But what exactly happens when you try to teach MC F11, F12 > etc? Nothing. No OK or any other message. >> Maybe time to declare ncurses BROKEN ? -:) > No. I haven't seen a single detailed bugreport regarding > ncurses support in MC (your message doesn't qualify as a > detailed bugreport for obvious reasons). OK, syntax highlighting doesn't work and I have problems with keys. The rest apparently works. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Sun Aug 26 04:31:34 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 00:31:34 -0400 (EDT) Subject: gmc goes insane In-Reply-To: <3B87FCA3.9040708@freeengineer.org> Message-ID: Hi, Cliff! > When gmc (mc 4.5.51 or 4.5.55) runs , it uses all my CPU, grabs all my > memory ( all 512 MB + swap ) , and ends up pretty much making the > desktop unusable, requiring me to to kill X. > > I also get the "no response from the saveyourself program" message. It looks like that you are logging into a GNOME session. In this case many programs start simultaneously, so it's very hard to say which program goes insane. > Needles to say, Gnome is pretty broken without gmc, but I had to remove > it make it work at all. That's interesting. But what happens if you start "gmc" from "xterm"? Also try "plain-gmc" - it's like gmc, but without CORBA support. > My system is rh7.1 / Gnome 1.2 except for 3 unusual things which are > probably be related to this: > > First, I am using XIG Accelerated X 1.1 instead of XFree86. Second I am > using the xfs filesystem. Third, I am using devfs. > > Things were working fine before when I was using rh6.2, ext2, and no > devfs - but still XIG. Most likely it's XIG plus some GNOME (or image) library that was updated between RH 6.2 and RH 7.1. But I'm guessing. First of all, try replacing XIG with XFree86. It would be interesing to run gmc and XIG in the debugger just to make sure that they are not getting some signals, like SIGSEGV and ignoring them. Also strace could give us a clue. Look for brk() calls. The first brk(0) returns the initial data segment boundary. The subsequent calls show how it changes. You don't need sources to find out which program runs out of memory - the one that requests too much memory with brk(). > Please help me fix this. It looks like a hard problems, so let's collect more information first. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 26 05:06:00 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 01:06:00 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: <20010825164416.B10189@pervalidus> Message-ID: Hi, Fr?d?ric! > >> Shift+F1 prints [25~ > > > Where? In mc? Or in dd? > > dd ? The utility from fileutils ? No. If I press Shift+F1 in > MC: dd would show if the sequences begin with Escape or you are losing them somewhere: [proski at portland src]$ dd ^[[23~^[[24~^[[25~^[[26~^[[28~ 0+0 records in 0+0 records out > > But what exactly happens when you try to teach MC F11, F12 > > etc? > > Nothing. No OK or any other message. That's the most interesting part. Let's do it step by step. This is how it works for me: Esc 9 o k the "learn ley" dialog appears l k the cursor goes to "Function key 13" Space the "Teach me a key" dialog appears Shift-F3 the dialog disappears Shift-F3 OK appears near "Function key 13" Esc s the "learn ley" dialog disappears Esc 0 y MC exits $ sed -n '/\[terminal:screen\]/,/\[/s/f13/&/p' ~/.mc/ini f13=\e[25~ When does it go differently for you? Obviously, it should be \e[28~ for you, but I'll be surprised it you cannot get to this point at all. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 26 07:19:51 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 03:19:51 -0400 (EDT) Subject: Status update In-Reply-To: <20010825162738.A10189@pervalidus> Message-ID: > > 1) Using "cvs up -d" only on the projects where you need it. > > But apparently I need for everything except mc. All other > projects create new directories. XFree86, GNOME, KDE, > Mozilla, LFTP, Mutt, and more. Maybe a few don't. Try explaining it in info-cvs at gnu.org. Discuss there how to implement it better. There is no use of discussing this problem in the MC list. > > 3) Finding Miguel and persuading him that he is wrong. The > > first part is already hard to implement, not to mention the > > second :-) > > Or moving the new text version to Savannah ? I thought GNU > would be used now that the GNOME version was removed. There is an important advantage in having MC in the GNOME repository - translators. MC messages are translated in 30 languages. MC project is very liberal toward translators and gives them access to every project. Many people want to internationalize GNOME and they do it to MC as well. Less people would want to internationalize GNU software and get write access to Savannah just for that. > > 5) Fix CVS to support blacklists (i.e. .cvsignore in your > > interpretation) and _real_ modules surviving "cvs up -d". > > What I miss. If I could remove all po/*.po without losing > anything... This should go to info-cvs at gnu.org. CVS developers should know what their users want. By the way, I have created the "mc-text" module. Use the following command to check it out: cvs -d :pserver:anonymous at anoncvs.gnome.org:/cvs/gnome co mc-text Remember that it doesn't survive "mc up -d". Also, to exclude directories, the alias module has to be used (another dumb limitation), so the checked out files will go to the "mc" directory, not to "mc-text". -- Regards, Pavel Roskin From lists at pervalidus.net Sun Aug 26 07:44:38 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sun, 26 Aug 2001 04:44:38 -0300 Subject: --with-ncurses problems Message-ID: <20010826044438.G10189@pervalidus> Pavel Roskin wrote: >>> But what exactly happens when you try to teach MC F11, F12 >>> etc? >> >> Nothing. No OK or any other message. > That's the most interesting part. Let's do it step by step. > This is how it works for me: OK. It worked. I don't know what I forgot, but am sure I did the same before. Certainly too fast. But I can't teach F19 and F20. The screen stays at "Teach me a key". The End key doesn't work too: Cannot accept this key You have entered "h" And the others: Page Down: You have entered "R" Page Up: You have entered "S" Insert: You have entered "K" Delete: You have entered "J" What's Completion/M-tab ? Alt ? Tab ? I can't teach any. +: You have entered "+" -: You have entered "-" *: You have entered "*" Yes, I tried with keypad and Num Lock on/off. OK. Shift+F4 created a new file. But for example Insert is used to tag files, and works. I just don't know why I get 'You have entered "K"'. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Sun Aug 26 09:18:11 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 05:18:11 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: <20010826044438.G10189@pervalidus> Message-ID: Hi, Fr?d?ric! ... > +: You have entered "+" > -: You have entered "-" > *: You have entered "*" Which of those problems are ncurses specific and which are not? > But for example Insert is used to tag files, and works. I > just don't know why I get 'You have entered "K"'. Run "dd" ithout arguments and press Insert in it. What do you see? The same applies to all other problematic keys. I don't think it's an ncurses vs. slang problem - it looks like a limitation of your terminal. -- Regards, Pavel Roskin From lists at pervalidus.net Sun Aug 26 11:09:45 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sun, 26 Aug 2001 08:09:45 -0300 Subject: --with-ncurses problems Message-ID: <20010826080945.H10189@pervalidus> Pavel Roskin wrote: >> +: You have entered "+" >> -: You have entered "-" >> *: You have entered "*" > Which of those problems are ncurses specific and which are > not? How to determine ? Compile with included S-Lang ? >> But for example Insert is used to tag files, and works. I >> just don't know why I get 'You have entered "K"'. > Run "dd" ithout arguments and press Insert in it. What do > you see? [[2~^ > The same applies to all other problematic keys. End: ^[[4~ Page Up: ^[[5~ Page Down: ^[[6~ Delete: ^[[3~ +: + -: - *: * Can't test F19 and F20. > I don't think it's an ncurses vs. slang problem - it looks > like a limitation of your terminal. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From proski at gnu.org Sun Aug 26 16:28:09 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 12:28:09 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: <20010826080945.H10189@pervalidus> Message-ID: Hi, Fr?d?ric! > > Which of those problems are ncurses specific and which are > > not? > > How to determine ? Compile with included S-Lang ? You mean you haven't tried yet? And you were suggesting to remove ncurses support without having checked that your problems are related to ncurses? I actually compiled MC both with S-Lang and ncurses trying to reproduce your problem. Yes, compiling with included S-Lang is probably better that using installed S-Lang, because the former is always the same. > > Run "dd" ithout arguments and press Insert in it. What do > > you see? > > [[2~^ Are you sure that "^" is in the end and not in the beginning? > > The same applies to all other problematic keys. > > End: ^[[4~ > Page Up: ^[[5~ > Page Down: ^[[6~ > Delete: ^[[3~ All this looks good. > +: + > -: - > *: * Well, obviously your terminal doesn't distinguish between "normal +" and "keypad +". I don't know why you expect MC to distinguish them, and most importantly, how it relates to ncurses. > Can't test F19 and F20. You mean that they emit no sequences? Then how can any program use them? Please double check your results, otherwise you are wasting time of everybody in this list. Don't expect me to continue this discussion - it takes too much time (my time at least, I don't know about yours) and brings no useful results. -- Regards, Pavel Roskin From proski at gnu.org Sun Aug 26 18:13:02 2001 From: proski at gnu.org (Pavel Roskin) Date: Sun, 26 Aug 2001 14:13:02 -0400 (EDT) Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: <20010825205551.A61483@bat.ru> Message-ID: Hi, Timur! > Ok, the cause of this problem is in one of your recent changes: > > 2001-07-17 Pavel Roskin > > * util.c (get_current_wd): Remove. It's obsoleted by > g_get_current_dir() from glib. Thank you for finding it! > Unfortunatelly, g_get_current_dir() has a strange 'feature', that makes it im- > possible to use it in MC - in case of inability to read the path instead of > returning NULL it returns '/'(actually, G_DIR_SEPARATOR). I think it's a minor problem. The fix belongs to glib, not to MC. I don't see any urgent need to put a workaround in the MC sources. If you want, I can take g_get_current_dir() from the head version of glib (it's better than the one from 1.2.10) and copy it into the MC sources with the appropiate fix. > So, there is no clear way to distinct error and a leagal case when your current > dir is root, or when it is a symlink to root. Yes, glib repeats the flaws of the functions it's trying to replace :-) -- Regards, Pavel Roskin From dmartina at excite.com Sun Aug 26 18:36:38 2001 From: dmartina at excite.com (David Martin) Date: Sun, 26 Aug 2001 11:36:38 -0700 (PDT) Subject: Update info.c to use size_trun_len() & Co. Message-ID: <23205814.998850998298.JavaMail.imail@prickles> I've been messing with the info panel and I've got some patches: - Use the new size_trunc_len() in util.c instead of print_bytesize() in win.c. I think the change of adding an extra parameter is harmless for the file list panels. In the way group some strings to ease translation. - Changes to sizes when using tiny widths. We're now printing senseless things. The alternative is to print nothing when len < 3+1. - Move a comment in info.c so that it appears in translator's files. It would be nice to do some cleaning in this kind of messages to avoid useless stuff confusing translators. As they're quite small I'm usign the same message for all three. *8-) David ------------------------ diff -1 -upr mc-4.5.55.orig/src/ChangeLog mc-4.5.55/src/ChangeLog --- mc-4.5.55.orig/src/ChangeLog Fri Aug 24 06:51:11 2001 +++ mc-4.5.55/src/ChangeLog Sun Aug 26 00:40:27 2001 @@ -1 +1,18 @@ +2001-08-26 David Martin + + * info.c (info_show_info): Use size_trunc_len() instead of + print_bytesize(). Group strings ("don't assume English + word ordering"). Add singular message when single block. + + * win.c (print_bytesize): Remove. + (sprint_bytesize): Remove. + * win.h: Remove print_bytesize() and sprint_bytesize(). + + * util.c (size_trunc_len): Update to support 1K blocks in + filesystem sizes. Add units parameter. + * util.h: Add units parameter in size_trunc_len. + + * screen.c (string_file_size): Add units (0=byte) to + size_trunc_len() call. + 2001-08-24 Pavel Roskin diff -1 -upr mc-4.5.55.orig/src/info.c mc-4.5.55/src/info.c --- mc-4.5.55.orig/src/info.c Tue Jun 19 00:24:04 2001 +++ mc-4.5.55/src/info.c Sun Aug 26 00:04:32 2001 @@ -32,3 +32,3 @@ #include "main.h" /* opanel, cpanel definitions */ -#include "win.h" /* print_bytesize */ +#include "util.h" /* size_trunc_len */ #include "layout.h" @@ -123,7 +123,7 @@ info_show_info (WInfo *info) if (myfs_stats.avail > 0 || myfs_stats.total > 0){ - addstr (_("Free space ")); - print_bytesize (myfs_stats.avail, 1); - printw (_(" (%d%%) of "), myfs_stats.total - ? 100 * myfs_stats.avail / myfs_stats.total : 0); - print_bytesize (myfs_stats.total, 1); + char buffer1 [6], buffer2[6]; + size_trunc_len (buffer1, 5, myfs_stats.avail,1); + size_trunc_len (buffer2, 5, myfs_stats.total,1); + printw (_("Free space %sb (%d%%) of %sb"), buffer1, myfs_stats.total ? + 100 * myfs_stats.avail / myfs_stats.total : 0, buffer2); } else @@ -169,6 +169,8 @@ info_show_info (WInfo *info) { - printw (_("Size: ")); - print_bytesize (buf.st_size, 0); + char buffer[10]; + size_trunc_len(buffer, 9, buf.st_size, 0); + printw (_("Size: %sb"), buffer); #ifdef HAVE_ST_BLOCKS - printw (_(" (%d blocks)"), buf.st_blocks); + printw ((buf.st_blocks==1) ? + _(" (%d block)") : _(" (%d blocks)"), buf.st_blocks); #endif diff -1 -upr mc-4.5.55.orig/src/screen.c mc-4.5.55/src/screen.c --- mc-4.5.55.orig/src/screen.c Sun Aug 19 19:33:26 2001 +++ mc-4.5.55/src/screen.c Sun Aug 26 00:04:32 2001 @@ -208,3 +208,3 @@ string_file_size (file_entry *fe, int le { - size_trunc_len (buffer, len, fe->buf.st_size); + size_trunc_len (buffer, len, fe->buf.st_size,0); } diff -1 -upr mc-4.5.55.orig/src/util.c mc-4.5.55/src/util.c --- mc-4.5.55.orig/src/util.c Thu Aug 16 05:52:51 2001 +++ mc-4.5.55/src/util.c Sun Aug 26 00:17:22 2001 @@ -313,5 +313,8 @@ char *size_trunc_sep (double size) * floating point by any means. + * + * Units: size units (filesystem sizes are 1K blocks) + * 0=bytes, 1=Kbytes, 2=Mbytes, etc. */ void -size_trunc_len (char *buffer, int len, off_t size) +size_trunc_len (char *buffer, int len, off_t size, unsigned units) { @@ -329,3 +332,3 @@ size_trunc_len (char *buffer, int len, o - for (j = 0; suffix [j] != NULL; j++) { + for (j = units; suffix [j] != NULL; j++) { if (size < power10 [len - (j > 0)]) { diff -1 -upr mc-4.5.55.orig/src/util.h mc-4.5.55/src/util.h --- mc-4.5.55.orig/src/util.h Thu Jun 28 06:17:28 2001 +++ mc-4.5.55/src/util.h Sun Aug 26 00:04:32 2001 @@ -20,3 +20,3 @@ char *size_trunc (double size); char *size_trunc_sep (double size); -void size_trunc_len (char *buffer, int len, off_t size); +void size_trunc_len (char *buffer, int len, off_t size, unsigned units); int is_exe (mode_t mode); diff -1 -upr mc-4.5.55.orig/src/win.c mc-4.5.55/src/win.c --- mc-4.5.55.orig/src/win.c Wed Jun 6 23:41:44 2001 +++ mc-4.5.55/src/win.c Sun Aug 26 00:04:32 2001 @@ -46,27 +46,2 @@ static Fkey_Table_List *fkey_table_list -/* Width of output is always seven characters */ -void sprint_bytesize (char *buffer, int size, int scale) -{ - char scales[] = " kMGT"; - - if (size > 0){ - while (size > 9999 && scale < sizeof (scales)){ - size = (size + 512) / 1024; - scale ++; - } - } - if (scale > 0) - g_snprintf (buffer, 10, "%4d %cb", size, scales[scale]); - else - g_snprintf (buffer, 10, "%4d b ", size); -} - -void print_bytesize (int size, int scale) -{ - char buffer [10]; - - sprint_bytesize (buffer, size, scale); - printw (buffer); -} - /* Return values: 0 = not a fkey, other = was a fkey */ diff -1 -upr mc-4.5.55.orig/src/win.h mc-4.5.55/src/win.h --- mc-4.5.55.orig/src/win.h Fri Feb 27 05:54:43 1998 +++ mc-4.5.55/src/win.h Sun Aug 26 00:04:32 2001 @@ -6,5 +6,2 @@ -void print_bytesize (int size, int scale); -void sprint_bytesize (char *buffer, int size, int scale); - ------------------------------------------------------- diff -1 -upr mc-4.5.99a/src/ChangeLog mc-4.5.99a.patched/src/ChangeLog --- mc-4.5.99a/src/ChangeLog Fri Aug 24 20:49:00 2001 +++ mc-4.5.99a.patched/src/ChangeLog Sun Aug 26 18:22:40 2001 @@ -1 +1,6 @@ +2001-08-26 David Martin + + * util.c (size_trunc_len): Print size values with some (little) + sense for tiny and even wee lengths (i.e. squeezed X terminals). + 2001-08-24 Pavel Roskin diff -1 -upr mc-4.5.99a/src/util.c mc-4.5.99a.patched/src/util.c --- mc-4.5.99a/src/util.c Thu Aug 16 05:52:51 2001 +++ mc-4.5.99a.patched/src/util.c Sun Aug 26 17:58:37 2001 @@ -331,3 +331,8 @@ size_trunc_len (char *buffer, int len, o if (size < power10 [len - (j > 0)]) { - g_snprintf (buffer, len + 1, "%lu%s", (unsigned long) size, suffix[j]); + if (len > 1 || !size) + /* Empty files will print "0" even with minimal width */ + g_snprintf (buffer, len + 1, "%lu%s", (unsigned long) size, suffix[j]); + else + /* Sort of "~1", "~K", etc. (see below) with one single character */ + g_snprintf (buffer, len + 1, "%s", (j) ? suffix[j] : "1"); break; @@ -335,4 +340,17 @@ size_trunc_len (char *buffer, int len, o - /* Powers of 1024, no rounding. */ - size = size >> 10; + /* + * Powers of 1024, with rounding. + * 1000 should do 1K, not 0K. + */ + size = ( size + 512 ) >> 10; + if ( size == 0 ) { + /* + * These would lead to non-zero values represented like "0X" (for example: "0M"). + * Let's break now with "~K" or just "K" if there's no room. + * "~1" or just "1" if dealign with units (bytes). + */ + g_snprintf (buffer, len + 1, (len == 1) ? "%s" : "~%s", + (j) ? suffix[j] : "1"); + break; + } } ------------------------------------------ diff -1 -upr mc-4.5.99a/src/ChangeLog mc-4.5.99a-patched/src/ChangeLog --- mc-4.5.99a/src/ChangeLog Sun Aug 26 18:43:06 2001 +++ mc-4.5.99a-patched/src/ChangeLog Fri Aug 24 20:49:00 2001 @@ -1,8 +1 @@ -2001-08-26 David Martin - - * info.c (info_show_info): Move comment line just before translatable - message so it's shown in .po files to alert translators; the message - (translated) is used to know the start column (so the available width) - for some "truncatable" strings. - 2001-08-24 Pavel Roskin diff -1 -upr mc-4.5.99a/src/info.c mc-4.5.99a-patched/src/info.c --- mc-4.5.99a/src/info.c Tue Jun 19 00:24:04 2001 +++ mc-4.5.99a-patched/src/info.c Sun Aug 26 18:33:32 2001 @@ -99,2 +99,3 @@ info_show_info (WInfo *info) if(!i18n_adjust) { + /*This printf pattern string will be used as a reference for size*/ file_label=_("File: %s"); @@ -102,3 +103,2 @@ info_show_info (WInfo *info) } - /*The printf pattern string is used as a reference for size*/ _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ -------------- next part -------------- A non-text attachment was scrubbed... Name: info.diff.gz Type: application/x-gzip-compressed Size: 1691 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wee.diff.gz Type: application/x-gzip-compressed Size: 846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: info_i18n.diff.gz Type: application/x-gzip-compressed Size: 548 bytes Desc: not available URL: From lists at pervalidus.net Sun Aug 26 19:05:32 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Sun, 26 Aug 2001 16:05:32 -0300 Subject: --with-ncurses problems Message-ID: <20010826160532.J10189@pervalidus> >> How to determine ? Compile with included S-Lang ? > You mean you haven't tried yet? And you were suggesting to > remove ncurses support without having checked that your > problems are related to ncurses? No, I thought it wasn't necessary - I always compile with --with-included-slang. And it always worked. Maybe a new termcap/terminfo broke something. >> [[2~^ > Are you sure that "^" is in the end and not in the beginning? No... [[2~ . Again sorry. >> +: + >> -: - >> *: * > Well, obviously your terminal doesn't distinguish between > "normal +" and "keypad +". I don't know why you expect MC to > distinguish them, and most importantly, how it relates to > ncurses. OK. The same with S-Lang. >> Can't test F19 and F20. > You mean that they emit no sequences? Then how can any > program use them? Yes. Ditto. > Please double check your results, otherwise you are wasting > time of everybody in this list. Don't expect me to continue > this discussion - it takes too much time (my time at least, I > don't know about yours) and brings no useful results. Changes using --with-included-slang: End, Page Up, Page Down, Delete, Insert: Recognized with 'Learn keys'. But they work using --with-ncurses. The only problem is that they aren't recognized by 'Learn keys'. Why, if they work ? Another problem. Under screen you don't need -c if compiled with --with-ncurses. If compiled with --with-included-slang colors aren't displayed without -c. I tested on Linux console with TERM=linux . F19 and F20 aren't recognized but +, -, and * are. -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From kloczek at rudy.mif.pg.gda.pl Mon Aug 27 06:37:13 2001 From: kloczek at rudy.mif.pg.gda.pl (=?ISO-8859-2?Q?Tomasz_K=B3oczko?=) Date: Mon, 27 Aug 2001 08:37:13 +0200 (CEST) Subject: --with-ncurses problems In-Reply-To: Message-ID: On Sat, 25 Aug 2001, Pavel Roskin wrote: [..] > > - Shift+FX doesn't work. I can't get Midnight Commander to > > create a new file in the editor and other options that use > > Shift+Fx. > > I could not reproduce this problem. Please give more information - > terminal name, ncurses version, OS version etc. > > > Shift+F1 prints [25~ > > Where? In mc? Or in dd? > > > Shift+F2 [26~[28~ > > This looks bad. I'm not surprised that MC has hard time learning this. Without information on which $TERM this was you can't say authoritativly "this looks bad". Of course on TERM=xterm yes you are right because: $ TERM=xterm infocmp -I | grep kf12 kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, ^^^^^^^^^^ (shift+F2 is the same as F12). Remember some terminals has only few function keys (for example VT100 have *only* F1-F4). kloczek -- ----------------------------------------------------------- *Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?* ----------------------------------------------------------- Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek at rudy.mif.pg.gda.pl* From lists at pervalidus.net Mon Aug 27 07:39:49 2001 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Mon, 27 Aug 2001 04:39:49 -0300 Subject: --with-ncurses problems Message-ID: <20010827043949.M10189@pervalidus> Tomasz Kl/oczko wrote: >>> Shift+F2 [26~[28~ >> This looks bad. I'm not surprised that MC has hard time >> learning this. > Without information on which $TERM this was you can't say > authoritativly "this looks bad". Of course on TERM=xterm > yes you are right because: > $ TERM=xterm infocmp -I | grep kf12 > kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, > ^^^^^^^^^^ > (shift+F2 is the same as F12). Remember some terminals has > only few function keys (for example VT100 have *only* F1-F4). Actually, forget everything I wrote except the problem with syntax highlighting and my last message. I think what Pavel said is that "[26~[28~" looks bad. It was a typo. On screen it reported "[26~", but gpm... And because I was too fast in 'Learn keys' I'd have to press 3 times, not 2, what I didn't. BTW, I bought a new ABNT2 keyboard in the last days. The real problem is F19 and F20. Now I don't know what's wrong with them, if termcap/terminfo or the keyboard from China... OK, screen or my termcap/terminfo doesn't support the + - * keys. IIRC it used to work. And there's a problem with End, Page Up, Page Down, Delete, Insert not recognized by 'Learn keys' with ncurses, but working ! And the -c problem. Again, forget everything I wrote about key problems except the last message. If I get syntax highlighting with ncurses, I think --with-included-slang will problably be removed from my builds. 475468 Aug 24 06:28 mc-ncurses 534276 Aug 26 15:43 mc-slang -- 0 at pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niter?i-RJ BR) From timur at gnu.org Mon Aug 27 09:43:00 2001 From: timur at gnu.org (Timur I. Bakeyev) Date: Mon, 27 Aug 2001 11:43:00 +0200 Subject: ANNOUNCE: GNU Midnight Commander 4.5.55 In-Reply-To: ; from proski@gnu.org on Sun, Aug 26, 2001 at 02:13:02PM -0400 References: <20010825205551.A61483@bat.ru> Message-ID: <20010827114300.A74813@bat.ru> Hi, Pavel! On Sun, Aug 26, 2001 at 02:13:02PM -0400, Pavel Roskin wrote: > > > Unfortunatelly, g_get_current_dir() has a strange 'feature', that makes it im- > > possible to use it in MC - in case of inability to read the path instead of > > returning NULL it returns '/'(actually, G_DIR_SEPARATOR). > > I think it's a minor problem. The fix belongs to glib, not to MC. I > don't see any urgent need to put a workaround in the MC sources. I guess, we need to do smth with this problem - otherwise, the behaviour of MC becomes broken - you can't relay, that navigation throw the file system works reliable. > If you want, I can take g_get_current_dir() from the head version of glib > (it's better than the one from 1.2.10) and copy it into the MC sources > with the appropiate fix. I think, that's the minimum what we shall do. I'll make a bug report to glib, but, not sure that we'll get any changes - API is frosen already(I guess), so... > > So, there is no clear way to distinct error and a leagal case when your current > > dir is root, or when it is a symlink to root. > > Yes, glib repeats the flaws of the functions it's trying to replace :-) > Regards, Timur. From proski at gnu.org Mon Aug 27 18:10:09 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 27 Aug 2001 14:10:09 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: Message-ID: Hi, Tomasz! > Remember some terminals has only few function keys (for example VT100 have > *only* F1-F4). That's why the "Learn keys" dialog is confusing to some people. Just because you cannot teach MC a key (e.g. keypad plus or F13) it doesn't mean that MC is buggy or something is wrong with the system. Essentially, MC implements its own key sequences for almost all keys: "Esc number" for F1-F10, "Esc [+-*]" for keypad +, - and *, "Esc >" for End, "Esc <" for Home, Ctrl-D for Delete and so on. Unfortunetely, those keys are not documented in one place, they are not configurable (they could be in [terminal:general] in mc.lib) and they are not defined for F11-F20, so that you cannot start editing a new file on a terminal without F14 and you cannot bypass viewer filters (which is more a more serious problem) if you don't have F13. MC has a lot of sequences hardcoded, but some of them cannot be expressed in terms of mc.lib, for example the sequences for all terminals starting with "xterm". mc.lib parser doesn't code to recognize things like [terminal:xterm.*] (not that I consider this a good idea). -- Regards, Pavel Roskin From proski at gnu.org Mon Aug 27 21:20:00 2001 From: proski at gnu.org (Pavel Roskin) Date: Mon, 27 Aug 2001 17:20:00 -0400 (EDT) Subject: --with-ncurses problems In-Reply-To: <20010826160532.J10189@pervalidus> Message-ID: Hi, Fr?d?ric! All my recent messages to you have bounced. On the other hand, you are losing my e-mail address from CC: all the time. If the software does it for you, consider using a better mail program. If you do it by hand, then you are probably wrong. I don't like private discussions, but I would not mind getting a personal copy of messages that are meant for me. > Changes using --with-included-slang: > > End, Page Up, Page Down, Delete, Insert: Recognized with > 'Learn keys'. But they work using --with-ncurses. The only > problem is that they aren't recognized by 'Learn keys'. Why, > if they work ? I could reproduce this problem now. I know why! Because learn_key() in src/key.c uses xgetch(), which is not the same for ncurses and S-Lang. For S-Lang it's a low-level function, that returns for every byte in the input. In ncurses it's a more complicated function, that gets the whole sequence and returns the interpreted code, KEY_IC in the case of Insert. But then learn_store_key() casts the key code to char, and this gives "K". I'm changing learn_keys so that the keypad mode is turned off when xgetch is called. --------------------------------- --- key.c +++ key.c @@ -870,10 +870,12 @@ char *learn_key (void) fd_set Read_FD_Set; struct timeval endtime; struct timeval timeout; - int c = xgetch (); + int c; char buffer [256]; char *p = buffer; + keypad(stdscr, FALSE); /* disable intepreting keys by ncurses */ + c = xgetch (); while (c == ERR) c = xgetch (); /* Sanity check, should be unnecessary */ learn_store_key (buffer, &p, c); @@ -904,8 +906,9 @@ char *learn_key (void) } if (c == ERR) break; - learn_store_key (buffer, &p, c); + learn_store_key (buffer, &p, c); } + keypad(stdscr, TRUE); #ifdef BUGGY_CURSES notimeout (stdscr, TRUE); #else --------------------------------- > Another problem. Under screen you don't need -c if compiled > with --with-ncurses. If compiled with --with-included-slang > colors aren't displayed without -c. Not enabling the color by default is a limitation of S-Lang support in MC. Missing support for "-c" with ncurses is a limitation of ncurses support in MC. Fixes are possible and welcome, but nobody was annoyed enough to make them. > I tested on Linux console with TERM=linux . F19 and F20 > aren't recognized but +, -, and * are. That's not surprizing. F19 and F20 are assigned to Shift-F7 and Shift-F8 is some linux keymaps. Those keymaps map Shift-Fn to F(n+12) to distinguish between F12 and Shift-F2, but Shift-F9 and Shift-F10 become unmapped. Try "loadkeys defkeymap_V1.0" for a keymap that supports Shift-F9 and Shift-F10. Screen really can do nothing in the host terminal (linux) doesn't provide the keys. On the other hand, srceen interpretes keypad + according to the terminal settings so that the programs have a unified "screen" terminal. -- Regards, Pavel Roskin From pavel at ucw.cz Mon Aug 27 23:07:15 2001 From: pavel at ucw.cz (Pavel Machek) Date: Tue, 28 Aug 2001 01:07:15 +0200 Subject: files highlighting In-Reply-To: <200108181201.f7IC1Z701712@skif.tavrida.net>; from Max Schedriviy on Sat, Aug 18, 2001 at 03:01:34PM +0300 References: <01070605212301.30735@humgat.tavrida.net> <20010817225410.C4241@bug.ucw.cz> <200108181201.f7IC1Z701712@skif.tavrida.net> Message-ID: <20010828010715.A7374@bug.ucw.cz> Hi! > > > 3) this patch allow to highlight files in depend of they are extensions > > > Patch isn't complete, and in future I want to describe extensions in > > > ini-file. > > > > I thought midnight already has this feature? > > are you sure? man what? :) At least I see colorful files when browsing directories. (Directories one color, broken symlinks red, executables bright). Ah-ha it does not seem extension based. Ok. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From sav at bcs.zp.ua Tue Aug 28 11:21:37 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Tue, 28 Aug 2001 14:21:37 +0300 Subject: Backward search in internal viewer - 2nd Approximation In-Reply-To: ; from proski@gnu.org on Wed, Jun 20, 2001 at 12:57:00PM -0400 References: <20010619133514.A223@bcs.zp.ua> Message-ID: <20010828142137.A14349@bcs.zp.ua> Hi! : : > This patch adds backward search feature for normal search : > in internal viewer. This one is for non gnome edition, sorry. : : Thanks for trying, but an implementation for GNOME would be nice too. I : understand that you cannot use input_dialog(), so this means writing a : real GNOME dialog. You can find some examples in gdialogs.c. I think now we don't care about GNOME edition. : : Another problem is that your patch doesn't implement backward search in : the Hex mode and for regular expressions. This would make the behavior of Now backward search in the Hex mode is implemented. Regular expressions are still waiting... : the viewer inconsistent. From the user's point of view, backward search : makes sence in all of those modes. Well, but now I have time to satisfy only my needs ;-( : Now let's see your patch. : > - p = (found_len ? search_start : view->last) - 1; : > + p = found_len ? (search_start ? search_start - 1 : 0) : search_start; : : Not clear. Why aren't you using view->last anymore? I understand it : affects GNOME too. I don't want cycling now, but it may be implemented in future... BTW, first field of view structure is always 0 and can be safely removed. I did it 2 years ago and don't find any side effects. Regards, Andrew. Index: view.c =================================================================== RCS file: /home/sav/.cvsroot/mc/src/view.c,v retrieving revision 1.57 diff -u -p -r1.57 view.c --- view.c 14 Aug 2001 16:45:05 -0000 1.57 +++ view.c 14 Aug 2001 16:53:37 -0000 @@ -1383,11 +1379,32 @@ icase_search_p (WView *view, char *text, char *q; int lng; +#ifdef HAVE_GNOME if ((q = _icase_search (text, data, &lng)) != 0) { view->found_len = lng; view->search_start = q - data - lng; return 1; } +#else + int direction = view->direction; + + if (direction == -1) + reverse_string (text); + + q = _icase_search (text, data, &lng); + + if (direction == -1) + reverse_string (text); + + if (q != 0) { + if (direction > 0) + view->search_start = q - data - lng; + else + view->search_start = strlen (data) - (q - data); + view->found_len = lng; + return 1; + } +#endif return 0; } @@ -1417,8 +1434,13 @@ get_line_at (WView *view, unsigned long long i = 0; int prev = 0; + if (!pos && direction == -1) + return 0; + /* skip over all the possible zeros in the file */ while ((ch = get_byte (view, pos)) == 0) { + if (!pos && direction == -1) + return 0; pos += direction; i++; } *skipped = i; @@ -1436,21 +1458,27 @@ get_line_at (WView *view, unsigned long usable_size = buffer_size - 2; } - pos += direction; i++; + i++; + buffer [i] = ch; - if (ch == '\n' || !ch){ + if (!pos && direction == -1) + break; + + pos += direction; + + if (ch == '\n' || !ch) break; - } - buffer [i] = ch; } + if (buffer){ buffer [0] = prev; buffer [i] = 0; - +#ifdef HAVE_GNOME /* If we are searching backwards, reverse the string */ if (direction < 0) { reverse_string (buffer + 1); } +#endif } *p = pos; @@ -1535,7 +1563,7 @@ search (WView *view, char *text, int (*s if (view->direction == 1){ p = found_len ? search_start + 1 : search_start; } else { - p = (found_len ? search_start : view->last) - 1; + p = (found_len && search_start) ? search_start - 1 : search_start; } beginning = p; @@ -1598,7 +1626,7 @@ search (WView *view, char *text, int (*s if (view->direction == 1) t += forward_line_start; else - t += reverse_line_start ? reverse_line_start + 3 : 0; + t = reverse_line_start ? reverse_line_start + 2 : 0; view->search_start += t; if (t != beginning){ @@ -1632,18 +1660,51 @@ static long block_search (WView *view, char *buffer, int len) { int w = view->widget.cols - view->have_frame + 1; - + int direction = view->direction; char *d = buffer, b; unsigned long e; /* clear interrupt status */ got_interrupt (); enable_interrupt_key (); - e = view->found_len ? view->search_start + 1 : view->search_start; + if (direction == 1) + e = view->found_len ? view->search_start + 1 : view->search_start; + else + e = (view->found_len && view->search_start) ? view->search_start - 1 : view->search_start; search_update_steps (view); update_activate = 0; - + +#ifndef HAVE_GNOME + if (direction == -1) { + + for (d += len - 1; ; e--) { + if (e <= update_activate){ + update_activate -= update_steps; + if (verbose){ + view_percent (view, e, w, TRUE); + mc_refresh (); + } + if (got_interrupt ()) + break; + } + b = get_byte (view, e); + + if (*d == b){ + if (d == buffer){ + disable_interrupt_key (); + return e; + } + d--; + } else { + e += buffer + len - 1 - d; + d = buffer + len - 1; + } + if (e == 0) + break; + } + } else +#endif while (e < view->last_byte){ if (e >= update_activate){ update_activate += update_steps; @@ -1993,7 +2054,54 @@ normal_search (WView *view, int directio convert_to_display( exp ); #endif +#ifndef HAVE_GNOME + { + + enum { + SEARCH_DLG_HEIGHT = 8, + SEARCH_DLG_WIDTH = 58 + }; + + static int replace_backwards; + int treplace_backwards = replace_backwards; + char *tsearch_text; + + QuickWidget quick_widgets[] = { + {quick_button, 6, 10, 5, SEARCH_DLG_HEIGHT, N_("&Cancel"), 0, B_CANCEL, + 0, 0, NULL}, + {quick_button, 2, 10, 5, SEARCH_DLG_HEIGHT, N_("&Ok"), 0, B_ENTER, + 0, 0, NULL}, + {quick_checkbox, 3, SEARCH_DLG_WIDTH, 4, SEARCH_DLG_HEIGHT, N_("&Backwards"), 0, 0, + 0, 0, NULL}, + {quick_input, 3, SEARCH_DLG_WIDTH, 3, SEARCH_DLG_HEIGHT, "", 52, 0, + 0, 0, N_(" Search ")}, + {quick_label, 2, SEARCH_DLG_WIDTH, 2, SEARCH_DLG_HEIGHT, N_(" Enter search string:"), 0, 0, + 0, 0, 0}, + {0} + }; + + quick_widgets[2].result = &treplace_backwards; + quick_widgets[3].str_result = &tsearch_text; + quick_widgets[3].text = exp; + + { + QuickDialog Quick_input = { + SEARCH_DLG_WIDTH, SEARCH_DLG_HEIGHT, -1, 0, N_(" Search "), + "[Input Line Keys]", "quick_input", 0, 0 + }; + Quick_input.widgets = quick_widgets; + if (quick_dialog (&Quick_input) == B_CANCEL) { + return; + } + exp = *(quick_widgets[3].str_result); + replace_backwards = treplace_backwards; + direction = (replace_backwards) ? -1 : 1; + } +} +#else exp = input_dialog (_(" Search "), _(" Enter search string:"), exp); +#endif /* !HAVE_GNOME */ + if ((!exp)){ return; } From sav at bcs.zp.ua Tue Aug 28 11:53:25 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Tue, 28 Aug 2001 14:53:25 +0300 Subject: Eliminate egrep in Find file feature: 1st Approximation Message-ID: <20010828145325.A14797@bcs.zp.ua> Hi! This patch eliminates egrep usage in Find file feature. So we can search desired regular expression over VFS and in binary files and on platforms without egrep. ChangeLog: * find.c (get_line_at): New function. Returns malloced null-terminated string from file descriptor file_fd. Input is buffered in buf buf_size long. Newline(s) accounted in line variable. (search_content): Use get_line_at and regex. TODO: Move regcomp and regfree calls and r variable from search_content. Make r static. Inform user about malformed regular experssion (message can be taken from view.c). Add get_line_at description in comment. Remove locate_egrep. Regards, Andrew. Index: find.c =================================================================== RCS file: /home/sav/.cvsroot/mc/src/find.c,v retrieving revision 1.37 diff -u -p -r1.37 find.c --- find.c 27 Apr 2001 10:07:45 -0000 1.37 +++ find.c 28 Aug 2001 06:20:25 -0000 @@ -50,6 +50,12 @@ #include "cmd.h" /* view_file_at_line */ #include "../vfs/vfs.h" +#if defined(HAVE_RX_H) && defined(HAVE_REGCOMP) +# include +#else +# include +#endif + #ifndef PORT_HAS_FLUSH_EVENTS # define x_flush_events() #endif @@ -409,10 +414,52 @@ locate_egrep (void) } #endif +static char * +get_line_at (int file_fd, char *buf, int *pos, int *n_read, int buf_size, int *line) +{ + char *buffer = 0; + int buffer_size = 0; + char ch; + int i = 0; + + for (;;){ + if (*pos == *n_read){ + if ((*n_read = mc_read (file_fd, buf, buf_size)) <= 0) + break; + *pos = 0; + } + + ch = buf [(*pos)++]; + /* skip over all the possible zeros in the file */ + if (ch == 0) { + if (i == 0) + continue; + else + break; + } + + if (i >= buffer_size - 1){ + buffer = g_realloc (buffer, buffer_size += 80); + } + + buffer [i++] = ch; + if (ch == '\n'){ + (*line)++; + break; + } + } + + if (buffer){ + buffer [i] = 0; + } + + return buffer; +} + /* * search_content: * - * Search with egrep the global (FIXME) content_pattern string in the + * Search the global (FIXME) content_pattern string in the * DIRECTORY/FILE. It will add the found entries to the find listbox. */ static void @@ -421,12 +468,11 @@ search_content (Dlg_head *h, char *direc struct stat s; char buffer [BUF_SMALL]; char *fname, *p; - int file_fd, pipe, ignoring; - char c; + int file_fd; int i; - pid_t pid; - char *egrep_path = "egrep"; - char *egrep_opts = case_sensitive ? "-n" : "-in"; + int pos, n_read; + regex_t r; + int flags = REG_EXTENDED|REG_NOSUB; fname = concat_dir_and_file (directory, filename); @@ -441,57 +487,33 @@ search_content (Dlg_head *h, char *direc if (file_fd == -1) return; -#ifndef GREP_STDIN - pipe = mc_doublepopen (file_fd, -1, &pid, egrep_path, egrep_path, egrep_opts, content_pattern, NULL); -#else /* GREP_STDIN */ - pipe = mc_doublepopen (file_fd, -1, &pid, egrep_path, egrep_path, egrep_opts, content_pattern, "-", NULL); -#endif /* GREP STDIN */ - - if (pipe == -1){ - mc_close (file_fd); - return; - } - g_snprintf (buffer, sizeof (buffer), _("Grepping in %s"), name_trunc (filename, FIND2_X_USE)); status_update (buffer); mc_refresh (); - p = buffer; - ignoring = 0; enable_interrupt_key (); got_interrupt (); - while ((i = read (pipe, &c, 1)) == 1){ - - if (c == '\n'){ - p = buffer; - ignoring = 0; - } - - if (ignoring) - continue; - - if (c == ':'){ - char *the_name; + if (!case_sensitive) + flags |= REG_ICASE; - *p = 0; - ignoring = 1; - the_name = g_strconcat (buffer, ":", filename, NULL); - find_add_match (h, directory, the_name); - g_free (the_name); - } else { - if (p - buffer < (sizeof (buffer)-1) && ISASCII (c) && isdigit (c)) - *p++ = c; - else - *p = 0; + if (regcomp (&r, content_pattern, flags) == 0){ + i = 1; + pos = 0; + n_read = 0; + + while ((p = get_line_at (file_fd, buffer, &pos, &n_read, sizeof (buffer), &i))){ + if (regexec (&r, p, 1, 0, 0) == 0){ + char *the_name = g_strdup_printf ("%d:%s", i, filename); + find_add_match (h, directory, the_name); + g_free (the_name); + } + g_free (p); } } + regfree (&r); disable_interrupt_key (); - if (i == -1) - message (1, _(" Find/read "), _(" Problem reading from child ")); - - mc_doublepclose (pipe, pid); mc_close (file_fd); } From mc at listserv.bat.ru Tue Aug 28 12:39:20 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Tue, 28 Aug 2001 14:39:20 +0200 Subject: files highlighting In-Reply-To: <20010828010715.A7374@bug.ucw.cz>; from pavel@ucw.cz on Tue, Aug 28, 2001 at 01:07:15AM +0200 References: <01070605212301.30735@humgat.tavrida.net> <20010817225410.C4241@bug.ucw.cz> <200108181201.f7IC1Z701712@skif.tavrida.net> <20010828010715.A7374@bug.ucw.cz> Message-ID: <20010828143920.A83474@bat.ru> On Tue, Aug 28, 2001 at 01:07:15AM +0200, Pavel Machek wrote: > Hi! > > > > > > 3) this patch allow to highlight files in depend of they are extensions > > > > Patch isn't complete, and in future I want to describe extensions in > > > > ini-file. > > > > > > I thought midnight already has this feature? > > > > are you sure? man what? :) > > At least I see colorful files when browsing directories. (Directories > one color, broken symlinks red, executables bright). Ah-ha it does not > seem extension based. Ok. That's what I added couple of years ago. It distinc the same file types, MC showss as a very first column - '/', '@', '*', '!', '|', '-', ' '. This is based on a file type plus broken symlynks. The reason, why I'm a bit afraid of extension based coloring(and why I didn't implement it) was the limit on the color pairs which one of the curses libraries sets - 32 or 64, anyhow, very low. I dunno, is this an issue for ncurses and slang, which are the only defaults now. In general, I'd like to get rid of color pairs and be able to use simply fore- ground and background colors. With regards, Timur. From pavel at ucw.cz Wed Aug 29 19:32:17 2001 From: pavel at ucw.cz (Pavel Machek) Date: Wed, 29 Aug 2001 21:32:17 +0200 Subject: mc in mc patch In-Reply-To: <20010818100646.A644@localhost.localdomain>; from Walery Studennikov on Sat, Aug 18, 2001 at 10:06:46AM -0400 References: <20010817190012.A98717@bat.ru> <20010818100646.A644@localhost.localdomain> Message-ID: <20010829213217.A477@bug.ucw.cz> Hi! > > > > This patch not allow run mc in mc (from Advanced mc). > > > > > > > I do have a habbit to edit/compile mc from mc and the run it... > > > > > > With this patch applied it will not be possible anymore.... > > > > Not only that. I often run "su" (not "su -l") from mc and then run mc as > > root to edit some file. This would be impossible too. > > Many people (including me) only suffer when running mc from mc > by misprint (mv -> mc). > Maybe we can make this a configurable feature, > during compile time or from options dialog? No. Too much configuration options can kill good project, and midnight already has way too much config options. Pavel -- I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org From proski at gnu.org Wed Aug 29 22:55:41 2001 From: proski at gnu.org (Pavel Roskin) Date: Wed, 29 Aug 2001 18:55:41 -0400 (EDT) Subject: mc in mc patch In-Reply-To: <20010829213217.A477@bug.ucw.cz> Message-ID: Hi, Pavel! > > Many people (including me) only suffer when running mc from mc > > by misprint (mv -> mc). > > Maybe we can make this a configurable feature, > > during compile time or from options dialog? > > No. Too much configuration options can kill good project, and midnight > already has way too much config options. I fully agree with this statement. Even worse, the combinations of options grow exponentially, and not all of the combinations work well together (for example ncurses + internal editor). -- Regards, Pavel Roskin From proski at gnu.org Thu Aug 30 17:06:26 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 30 Aug 2001 13:06:26 -0400 (EDT) Subject: Update info.c to use size_trun_len() & Co. In-Reply-To: <23205814.998850998298.JavaMail.imail@prickles> Message-ID: Hi, David! > I've been messing with the info panel and I've got some patches: I'm applying your patches. Sorry that I couldn't do it earlier. Just few notes that I'm writing while applying your patch. Please don't make a big deal of them - it's just better that you know it, so that you can save me some time in the future. I don't want to apply code that I don't understand, and your comments and coding style make it hard (for me) sometimes. Width for text files, including ChangeLog should not exceed 72 bytes. Please don't send reversed patches. Consider using some automated tool, for example CVS utilities (http://www.red-bean.com/cvsutils/) or ldiff (http://www.red-bean.com/~proski/ldiff/ldiff), just change "v0" to your favorite backup extension. Moving a comment doesn't deserve 4 lines in ChangeLog :-) Don't comment the code you are replacing and the bugs you are fixing - e.g. "1000 should do 1K, not 0K." I think that "~B" looks better than "~1". Please use braces in "if" whenever your are writing more that one line after it, even if only one line is not a comment. Put comments before statements they belong to or on the same line, not on the next line, as you do here: if (len > 1 || !size) /* Empty files will print "0" even with minimal width */ g_snprintf (buffer, len + 1, "%lu%s", (unsigned long) size, suffix[j]); It took me to much time to understand. There is no "~" in the following statement, so why do you refer to it? /* Sort of "~1", "~K", etc. (see below) with one single character */ g_snprintf (buffer, len + 1, "%s", (j) ? suffix[j] : "1"); Well, I'm rewriting the whole patch. This complicated logic is not needed. (size == 0) can be checked only once. I'm applying this: -------------------------------- --- util.c +++ util.c @@ -328,13 +328,26 @@ size_trunc_len (char *buffer, int len, o len = 9; for (j = 0; suffix [j] != NULL; j++) { + if (size == 0) { + if (j == 0) { + /* Empty files will print "0" even with minimal width. */ + g_snprintf (buffer, len + 1, "0"); + break; + } + + /* Use "~K" or just "K" if len is 1. Use "B" for bytes. */ + g_snprintf (buffer, len + 1, (len > 1) ? "~%s" : "%s", + (j > 1) ? suffix[j - 1] : "B"); + break; + } + if (size < power10 [len - (j > 0)]) { g_snprintf (buffer, len + 1, "%lu%s", (unsigned long) size, suffix[j]); break; } - /* Powers of 1024, no rounding. */ - size = size >> 10; + /* Powers of 1024, with rounding. */ + size = (size + 512) >> 10; } } -------------------------------- Don't list trivial changes in the function callers. GNU Coding Standards says so. Use indentation of the text your are changing. E.g. add space after the comma here: size_trunc_len (buffer, len, fe->buf.st_size,0); Don't use "unsigned" - use "unsigned int". I remember seeing a warning in some compiler about it. If you want to be consistent, be consistent. Adding "b" in info.c is useless, since it's not used on the panels. Not to mention that "b" means "bits" at least in some technical literature, as opposed to "B" - bytes. Enough for now. I'm applying your patches. Again, please don't make a big deal of my nitpicking. -- Regards, Pavel Roskin From mc at listserv.bat.ru Thu Aug 30 20:48:41 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Thu, 30 Aug 2001 22:48:41 +0200 Subject: Update info.c to use size_trun_len() & Co. In-Reply-To: ; from proski@gnu.org on Thu, Aug 30, 2001 at 01:06:26PM -0400 References: <23205814.998850998298.JavaMail.imail@prickles> Message-ID: <20010830224841.A660@bat.ru> On Thu, Aug 30, 2001 at 01:06:26PM -0400, Pavel Roskin wrote: > > Don't comment the code you are replacing and the bugs you are fixing - > e.g. "1000 should do 1K, not 0K." I was writing new patch this evening, and asked myself - what commenting policy we should use. For ex. at my work in average we comment every 4 lines of code, so, very detailed commenting. MC, in turn, practically not commented. I think, we should agree on amount of comments for future patches. > Please use braces in "if" whenever your are writing more that one line > after it, even if only one line is not a comment. In general, it's better to use braces ALL the time, even for one line stat- ments. Actually, some "smart" compilers complaining on the construnctions like: while(1) for(i=0; i < 10000; i++) if(i == 500) break; which is legal, but difficult to read and understand(well, example is bad, but you got the idea, right? :). > Don't use "unsigned" - use "unsigned int". I remember seeing a warning in > some compiler about it. I think, as we started once that movement into the glib direction, we should continue with it. I've started to rewrite some small independent arts of MC to use glib data types, functions, etc. I think, we should try to use as much from this library, as possible. It'll make MC smaller, mor portable, less buggy(I hope:). So, I'd like your confirmation, that we are prefer constructions like: "gint" in opposit to "unsigned int" and so on. At the moment we have very dangerous mix, so it's better to eliminate it as much as possible. Regards, Timur Bakeyev. From scottlockwood at hotmail.com Thu Aug 30 22:07:28 2001 From: scottlockwood at hotmail.com (William Scott Lockwood III) Date: Thu, 30 Aug 2001 17:07:28 -0500 Subject: Cygwin Compilation Message-ID: Has anyone been able to compile 4.5.55 for Cygwin? I keep getting a warning that GLIB support is not found, but is required. I cannot seem to build GLIB 1.2.10 either. Additionally, GLIB documentation says we should not be using GLIB 1.2.x on Win32, but should build a more current version. MC documentation says nothing else will work. Help? :-) Warm Regards, Scott ICQ: 9554946 IM: bbwa1969 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From proski at gnu.org Fri Aug 31 01:53:01 2001 From: proski at gnu.org (Pavel Roskin) Date: Thu, 30 Aug 2001 21:53:01 -0400 (EDT) Subject: Cygwin Compilation In-Reply-To: Message-ID: Hi, Scott! > Has anyone been able to compile 4.5.55 for Cygwin? I keep getting a warning > that GLIB support is not found, but is required. I cannot seem to build > GLIB 1.2.10 either. Additionally, GLIB documentation says we should not be > using GLIB 1.2.x on Win32, but should build a more current version. MC > documentation says nothing else will work. Help? :-) Actually, glib 1.2.10 compiles quite straightforward under the current Cygwin (1.3.2). The only problem is a useless external declaration in gstrfuncs.c that conflicts with with the libc headers. Here's the trivial patch: --------------------- --- gstrfuncs.c +++ gstrfuncs.c @@ -702,7 +702,6 @@ g_strsignal (gint signum) char *msg; #ifdef HAVE_STRSIGNAL - extern char *strsignal (int sig); return strsignal (signum); #elif NO_SYS_SIGLIST switch (signum) --------------------- Since you didn't provide the information about your problems with glib I suppose that it was your problem and you just didn't try to fix it. I compiled MC 4.5.55 for the current (as of August 23) Cygwin with glib 1.2.10. It compiles, but it doesn't work well. Both the editor and the viewer display warnings. The viewer is trying to run nm on every file, the editor doesn't like something in the Syntax file. My guess is that the regex function doesn't work well. Maybe MC should use external regex on Cygwin or we should update src/regex.c. I considered support for glib-1.3.x, but it requires support for pkgconfig. Unfortunately, pkgconfig is a beta (at least) software. The latest version I was able to find is 0.7.0. It lacks any documentation except the manpage. Even the NEWS file is empty. It also integrates glib-1.2.8 for some obscure reason. I would be glad to add pkgconfig if it were better documented. I tried to add the PKG_CHECK_MODULES macro as described in README, but it seems that pkgconfig should be installed on the system that builds MC. This is a new requirement. Users with glib-1.2.x and without pkgconfig won't be able to compile MC. I don't think it's a good idea to use pkgconfig if doing so creates a strict dependency on beta quality software for all operating systems where MC is compiled. I'd like to be proven wrong. Any comments will be appreciated. -- Regards, Pavel Roskin From mc at listserv.bat.ru Fri Aug 31 12:08:03 2001 From: mc at listserv.bat.ru (Timur I. Bakeyev) Date: Fri, 31 Aug 2001 14:08:03 +0200 Subject: Where to get uptodate version of MC? Message-ID: <20010831140803.A6564@bat.ru> Hi, Pavel! I'm a bit lost - where now we should get the most uptodate version of MC for development? PReferably, from CVS> Is it still cvs.gnome.org or we should look around red-bean.com for it? Also, is it possible to commit patches into CVS or it always should be approved by you? Regards, Timur Bakeyev. From proski at gnu.org Fri Aug 31 14:42:08 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 31 Aug 2001 10:42:08 -0400 (EDT) Subject: Update info.c to use size_trun_len() & Co. In-Reply-To: <20010830224841.A660@bat.ru> Message-ID: Hi, Timur! > > Don't comment the code you are replacing and the bugs you are fixing - > > e.g. "1000 should do 1K, not 0K." > > I was writing new patch this evening, and asked myself - what commenting > policy we should use. I prefer to have comments for functions - what they do, what arguments they take and how they should be used. Whenever you use a function, consult its comment - the internal implementation is more likely to change than the semantic of the function. Comments for the code inside functions should be used with care - they often describe details that should already be clear from the code. Changing the code can make comments irrelevant and confusing. > For ex. at my work in average we comment every 4 lines of code, so, very > detailed commenting. MC, in turn, practically not commented. I think, we > should agree on amount of comments for future patches. Commenting every 4 lines is probably too much. But I don't know what comments you mean. There are two types of comment - useful and useless. These are useless comments: if (size = 0) /* Do it only is size is 0 */ len = 5; /* or it won't work */ This is a useful comment: /* Warning, recalc may be a macro */ x++; recalc(x); I prefer to use only comments that give information beyound the code. This doesn't apply to functions - their comments are very important even if the function is trivial. > > Don't use "unsigned" - use "unsigned int". I remember seeing a warning in > > some compiler about it. > > I think, as we started once that movement into the glib direction, we should > continue with it. I've started to rewrite some small independent arts of MC > to use glib data types, functions, etc. I think, we should try to use as much > from this library, as possible. It'll make MC smaller, mor portable, less > buggy(I hope:). I don't object against use of gint and guint, but don't expect too much from glib. My experience shows that glib-1.2.10 is less portable than mc itself. The 1.3.x series depend on pkgconfig, which is badly designed - it must be present on the compiling system, unlike e.g. libtool, which is distributed in the tarball. > So, I'd like your confirmation, that we are prefer constructions like: > > "gint" in opposit to "unsigned int" I think you mean "guint". > and so on. At the moment we have very dangerous mix, so it's better to eliminate > it as much as possible. The really dangerous mix is malloc vs. g_malloc and free vs. g_free. To fix the problem, g_malloc and g_free should be used in the editor, and this would mean that we can forget the idea of further synchronization with Cooledit, except maybe the syntax engine. -- Regards, Pavel Roskin From hvv at hippo.ru Fri Aug 31 13:11:07 2001 From: hvv at hippo.ru (Vlad Harchev) Date: Fri, 31 Aug 2001 18:11:07 +0500 (SAMST) Subject: Where to get uptodate version of MC? In-Reply-To: <20010831140803.A6564@bat.ru> Message-ID: On Fri, 31 Aug 2001, Timur I. Bakeyev wrote: Hi, Since anoncvs for gnome.org lags friom non-anonymous gnome.org CVS by 2 weeks or so, I would propose to setup a read-only CVS somewhere so people who want to get current MC will be able to run CVS update and produce patches agaist current code. It would be nice to also upload 'cvsdirs' (only 'CVS' directories and their content - won't be larger 30 kb gzipped) to be copied over extracted tarball to turn it into checked out MC-4.5.55 (with CVSROOT file pointing to that readonly cvs). That would be extremely handy. Best regards, -Vlad > Hi, Pavel! > > I'm a bit lost - where now we should get the most uptodate version of > MC for development? PReferably, from CVS> > > Is it still cvs.gnome.org or we should look around red-bean.com for > it? Also, is it possible to commit patches into CVS or it always > should be approved by you? > > Regards, > Timur Bakeyev. From proski at gnu.org Fri Aug 31 15:35:05 2001 From: proski at gnu.org (Pavel Roskin) Date: Fri, 31 Aug 2001 11:35:05 -0400 (EDT) Subject: Where to get uptodate version of MC? In-Reply-To: <20010831140803.A6564@bat.ru> Message-ID: Hi, Timur! > I'm a bit lost - where now we should get the most uptodate version of > MC for development? PReferably, from CVS> This is described at midnightcommander.org If you have problems with anoncvs.gnome.org, then report them to cvsadmin at gnome.org and copy to the list, so that I can change the CVS instructions until the problem is fixed. > Is it still cvs.gnome.org or we should look around red-bean.com for > it? Also, is it possible to commit patches into CVS or it always > should be approved by you? You are welcome to commit patches, but please inform the list and quote the patches inline for quality control. If you want to do something radical (like adding ksh support or running all code through indent) please ask first in the list and wait for approval. Please always make copies of your messages to the list. -- Regards, Pavel Roskin From sav at bcs.zp.ua Fri Aug 31 16:22:31 2001 From: sav at bcs.zp.ua (Andrew V. Samoilov) Date: Fri, 31 Aug 2001 19:22:31 +0300 Subject: Where to get uptodate version of MC? Vlad Harchev Message-ID: <20010831192231.A8515@bcs.zp.ua> Hi, Pavel! There is no patch file for mc-4.5.54 in http://www.gnome.org/projects/mc. Another desired feature is a weekly diffs on http://www.red-bean.com/~proski/mc. Some of corporative users have access to http and ftp ports only ;-( I spent a half of my time in business trips now and often can enjoy with Internet only from Internet cafes with terrible connection ;-( Another wanted feature in configure is to test where is current mc located before guessing it is /usr/local. I tired to answer letters like 'I compile and install new version of mc, but old one is started when I type mc. What is wrong ?' Old one is in /usr and often /usr/bin have higher priority than /usr/local/bin. Next. Home is defined as '\eOw' and End is '\eOq' in MC_HOME/mc.lib for xterm. I use Slackware and Home is \eOH and End is \eOF there. Regards, Andrew. From rado at autoparts.sk Fri Aug 31 23:28:36 2001 From: rado at autoparts.sk (Radovan Bukoci) Date: Sat, 01 Sep 2001 01:28:36 +0200 Subject: Bug: sizes of big dirs Message-ID: <3B901DA4.A5CF286C@autoparts.sk> Hallo, I found a bug. Maybe You already know about this, but, here we go: The problem is (in TEXT-MODE mc): F9 - C - I (F9 - Command - show directory sIzes) doesn't correctly show sizes for directories containing more than 2 GB of data. Insted of real size (something like "4824M") it shows number "2147488" for any dir > 2GB. Second bug, depending on the first one: When selecting directories, the bottom line of panel shows the sum of bytes. But these "2147488" dirs are summed as minus 2 GB,making the total smaller. E.g. selecting only such a big directory shows this: "-2,147,483,648 bytes in 1 file" And, for example when I select all subdirs of my directory /data (where 2 subdirs are over 2GB), I see result "2,412,928Kb bytes in 22 files" (but correct value should be somewhere at 15 GigaBytes in 22 files)) My system is: Linux Slackware 8.0.0 PC AMD Duron 750, mc-4-5-55 and I compiled it with this commands: ./configure --prefix=/usr --enable-mcserv-install --with-tm-x-support --with-samba --with-ext2undel && \ make install && \ touch ../Done And one more note: I hope You will not stop developing BOTH versions of mc (Gnome and text-mode). I know Linux is aiming to desktops, but it is also a great server with good remote administration, where mc takes a big, important role (probably the most important after telnet & telnetd, IMHO). Thank You Radovani Bukoci From pavel at suse.cz Fri Aug 31 06:35:58 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 31 Aug 2001 06:35:58 +0000 Subject: PATCH: IBM AIX patches In-Reply-To: <998323048.1227.34.camel@localhost.localdomain>; from Uraeus@linuxrising.org on Mon, Aug 20, 2001 at 05:57:28PM +0200 References: <998323048.1227.34.camel@localhost.localdomain> Message-ID: <20010831063557.B156@toy.ucw.cz> Hi! > Here is the patch for MC from the official IBM package. > > (From http://www-1.ibm.com/servers/aix/products/aixos/linux/index.html) > > Since I believe that these patches haven't been submitted before I am > sending them to the respective lists. > *** gnome1.2/mc-4.5.49/vfs/cpio.c:1.1 Mon Jun 12 16:57:30 2000 > --- gnome1.2/mc-4.5.49/vfs/cpio.c Tue Sep 5 11:50:06 2000 > *************** > *** 101,107 **** > static int cpio_read(void *fh, char *buffer, int count); > > #define CPIO_POS(super) cpio_position > ! //#define CPIO_POS(super) (super)->u.cpio.fd /* If some time reentrancy should be needed */ > > #define CPIO_SEEK_SET(super, where) mc_lseek((super)->u.cpio.fd, CPIO_POS(super) = (where), SEEK_SET) > #define CPIO_SEEK_CUR(super, where) mc_lseek((super)->u.cpio.fd, CPIO_POS(super) += (where), SEEK_SET) > --- 101,107 ---- > static int cpio_read(void *fh, char *buffer, int count); > > #define CPIO_POS(super) cpio_position > ! /* //#define CPIO_POS(super) (super)->u.cpio.fd */ /* If some time reentrancy should be needed */ You shoud have removed "//", not leave it there. Ditto few more places. > diff -c gnome1.2/mc-4.5.49/vfs/tar.c:1.1 gnome1.2/mc-4.5.49/vfs/tar.c:1.2 > *** gnome1.2/mc-4.5.49/vfs/tar.c:1.1 Mon Jun 12 16:57:30 2000 > --- gnome1.2/mc-4.5.49/vfs/tar.c Tue Sep 5 11:51:03 2000 > *************** > *** 192,198 **** > STATUS_BADCHECKSUM, > STATUS_SUCCESS, > STATUS_EOFMARK, > ! STATUS_EOF, > } ReadStatus; > /* > * Return 1 for success, 0 if the checksum is bad, EOF on eof, What's wrong with this? I thought C allowed leaving "," at the end, and it is easier to add to list like this. > --- 192,198 ---- > STATUS_BADCHECKSUM, > STATUS_SUCCESS, > STATUS_EOFMARK, > ! STATUS_EOF > } ReadStatus; > /* > * Return 1 for success, 0 if the checksum is bad, EOF on eof, -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From pavel at suse.cz Fri Aug 31 06:39:00 2001 From: pavel at suse.cz (Pavel Machek) Date: Fri, 31 Aug 2001 06:39:00 +0000 Subject: MC 4.5.55 tagged, 4.5.x branch created In-Reply-To: ; from proski@gnu.org on Fri, Aug 24, 2001 at 05:03:23AM -0400 References: Message-ID: <20010831063859.C156@toy.ucw.cz> Hi! > Cygwin support is very poor. Both the viewer and the editor emit useless > warnings every time they are used. But it compiles cleanly. > > QNX Neutrino doesn't support subshell by default due to lack of SA_RESTART > support. It can be compiled with SA_RESTART removed from the system > headers (which is the right thing IMO). In this case mc works with bash, > but not with zsh. > > BeOS is not supported due to serious limitations of its select() call - it > only works on sockets. > > The native (non-cygwin) port for Win32 and OS/2 is out of date and does > not work, but can be fixed. Maybe killing native win32 port is good idea? We have cygwin, right? Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.