Re: Changes in the keymap?
Amen to Chris. Though I do not know if the post below was from a developer or from an individual user. But I would say that the key mappings of MC are so well established by long tradition that they really ought not to be messed with. And in particular things like Cntrl-C really do have long established meanings of their own, which even pre-date both Midnight Commander and its long-ago ancestor Norton Commander and are used in those old meanings in many other contexts, too. For example in my mail program Cntrl-C means "Cancel" whatever one was doing, which is essentially what Cntrl-C always used to mean. On Wed, 5 Sep 2018, chris glur via mc wrote: No! Remapping COPY from F5 to Ctrl-C is a disaster. Since the 70s orignal DOS NortonComndr, through linux, Win, Android. <=> F5 In ALL computing Ctrl-C has a SPECIAL meaning. Don't map concepts to the current ENGLISH word, unless it's for some strangely disabled user. On Tue, Sep 4, 2018 at 8:01 AM wrote: Send mc mailing list submissions to mc@gnome.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.gnome.org/mailman/listinfo/mc or, via email, send a message with subject or body 'help' to mc-requ...@gnome.org You can reach the person managing the list at mc-ow...@gnome.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mc digest..." Today's Topics: 1. How to Get Midnight Comannder to Change the Help Text to Reflect Changes in the Keymap? (Hunter Jozwiak) -- Message: 1 Date: Mon, 3 Sep 2018 13:30:43 -0400 From: Hunter Jozwiak To: mc@gnome.org Subject: How to Get Midnight Comannder to Change the Help Text to Reflect Changes in the Keymap? Message-ID: < caj1hvuf8dpdqnoxeuk6motkfef70nkka8jhvsep0htfteag...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I made a few changes to the Midnight Commander keybindings, namely I mapped copy to ctrl-c and quit to ctrl-q. However, the help bar on the bottom still shows copy as F5 and quit as F10; how do I fix this problem? Thanks, Hunter -- next part -- An HTML attachment was scrubbed... URL: < https://mail.gnome.org/archives/mc/attachments/20180903/e5e1f050/attachment.html -- Subject: Digest Footer ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc -- End of mc Digest, Vol 166, Issue 2 ** ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: unrecoverable ftp timeout
Hello Joerg, On Wed, 05 Sep 2018 11:47:01 +0200 Joerg Thuemmler wrote: > Am 05.09.2018 um 10:12 schrieb wwp: > > Hello Joerg, > > > > > > On Wed, 05 Sep 2018 09:50:09 +0200 Joerg Thuemmler > > wrote: > > > >> Am 03.09.2018 um 11:34 schrieb wwp: > >>> Hello! > >>> > >>> there's something I'm experiencing quite frequently now, I'm not sure I > >>> was facing this behaviour w/ former versions: it's losing the FTP > >>> connection after a while being inactive then there is no way to free the > >>> VFs from the 'Active VFS directories' (it's listed in) and there is no > >>> way to re-instantiate the connection again. > >>> > >>> If I try from the 'Directory hotlist', I get a: > >>> Cannot chdir to "/ftp://; > >>> Remote I/O error (121)) > >>> if I try from 'FTP link...', I get only: > >>> Cannot chdir to "/ftp://; > >>> > >>> The only way I've found to reconnect to a lost FTP connection is > >>> restarting mc, which is not convenient nor expected. > >>> > >>> mc 4.8.1 compiled from the sources, on am up-to-date CentOS7 box: > >>> $ mc --version > >>> GNU Midnight Commander 4.8.21 > >>> Built with GLib 2.54.2 > >>> Using the S-Lang library with terminfo database > >>> With builtin Editor > >>> With subshell support as default > >>> With support for background operations > >>> With mouse support on xterm and Linux console > >>> With support for X11 events > >>> With internationalization support > >>> With multiple codepages support > >>> Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, > >>> smbfs > >>> Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; > >>> > >>> > >>> Regards, > >>> > > [snip] > >> Also I noted ftp servers, which do block the connection after some idle > >> time and if you try to use this connection, they want you to reconnect and > >> to put in your password once more. Mc caches your pw and resends it, but > >> the new connection is started in the ftp users root dir (on the ftp > >> server) again, not in the dir you last used. That may confuse the vfs > >> system, but it's a problem connected with the ftp server's usual behavior > >> (mc could resend the "cd" commands then after reconnection, dunno whether > >> it's possible to cache last dir before timeout disconnect). > > > > I experience this specific behaviour quite often (back to root or > > parent folder). > > > > > > [snip] > >> I would try to get a later timeout on the used ftp server, as I believe > >> it's an old "feature" and will not be changed next time, espacially as > >> sftp will become a more important ftp replacing... Maybe you should change > >> some other properties of your ftp servers making trouble if you try to > >> re-connect. But this depends on ftp server program used. > > > > I'm afraid I can't change anything on the FTP server side, it's not > > mine at all.. All I know is that mc is not behaving correctly (and > > possibly differently than "before"?) - I don't face such issues w/ > > filezilla against the same FTP servers. > > > > > > Regards, > > > > > > > > ___ > > mc mailing list > > https://mail.gnome.org/mailman/listinfo/mc > > > > Hi, > > filezilla is disconnecting too after timeout? AFAIK it has a > "heartbeat"-feature preventing disconnects by timeout. That was to be my next > idea: run some "heartbeat" on your side, e.g. a "ls" cmd via ftp to prevent > from connection timeouts... > > yes, it's a "quick & dirty" workaround, but IMHO the "reconnect" problem is > in mc since I'm using it... You're right, it seems to use a keep-alive thing! Regards, -- wwp pgpB4jkyOB6Ef.pgp Description: OpenPGP digital signature ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: unrecoverable ftp timeout
Am 05.09.2018 um 10:12 schrieb wwp: Hello Joerg, On Wed, 05 Sep 2018 09:50:09 +0200 Joerg Thuemmler wrote: Am 03.09.2018 um 11:34 schrieb wwp: Hello! there's something I'm experiencing quite frequently now, I'm not sure I was facing this behaviour w/ former versions: it's losing the FTP connection after a while being inactive then there is no way to free the VFs from the 'Active VFS directories' (it's listed in) and there is no way to re-instantiate the connection again. If I try from the 'Directory hotlist', I get a: Cannot chdir to "/ftp://; Remote I/O error (121)) if I try from 'FTP link...', I get only: Cannot chdir to "/ftp://; The only way I've found to reconnect to a lost FTP connection is restarting mc, which is not convenient nor expected. mc 4.8.1 compiled from the sources, on am up-to-date CentOS7 box: $ mc --version GNU Midnight Commander 4.8.21 Built with GLib 2.54.2 Using the S-Lang library with terminfo database With builtin Editor With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; Regards, [snip] Also I noted ftp servers, which do block the connection after some idle time and if you try to use this connection, they want you to reconnect and to put in your password once more. Mc caches your pw and resends it, but the new connection is started in the ftp users root dir (on the ftp server) again, not in the dir you last used. That may confuse the vfs system, but it's a problem connected with the ftp server's usual behavior (mc could resend the "cd" commands then after reconnection, dunno whether it's possible to cache last dir before timeout disconnect). I experience this specific behaviour quite often (back to root or parent folder). [snip] I would try to get a later timeout on the used ftp server, as I believe it's an old "feature" and will not be changed next time, espacially as sftp will become a more important ftp replacing... Maybe you should change some other properties of your ftp servers making trouble if you try to re-connect. But this depends on ftp server program used. I'm afraid I can't change anything on the FTP server side, it's not mine at all.. All I know is that mc is not behaving correctly (and possibly differently than "before"?) - I don't face such issues w/ filezilla against the same FTP servers. Regards, ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc Hi, filezilla is disconnecting too after timeout? AFAIK it has a "heartbeat"-feature preventing disconnects by timeout. That was to be my next idea: run some "heartbeat" on your side, e.g. a "ls" cmd via ftp to prevent from connection timeouts... yes, it's a "quick & dirty" workaround, but IMHO the "reconnect" problem is in mc since I'm using it... regards -- Joerg Thuemmler ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 166, Issue 2
No! Remapping COPY from F5 to Ctrl-C is a disaster. Since the 70s orignal DOS NortonComndr, through linux, Win, Android. <=> F5 In ALL computing Ctrl-C has a SPECIAL meaning. Don't map concepts to the current ENGLISH word, unless it's for some strangely disabled user. On Tue, Sep 4, 2018 at 8:01 AM wrote: > Send mc mailing list submissions to > mc@gnome.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gnome.org/mailman/listinfo/mc > or, via email, send a message with subject or body 'help' to > mc-requ...@gnome.org > > You can reach the person managing the list at > mc-ow...@gnome.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mc digest..." > > > Today's Topics: > >1. How to Get Midnight Comannder to Change the Help Text to > Reflect Changes in the Keymap? (Hunter Jozwiak) > > > -- > > Message: 1 > Date: Mon, 3 Sep 2018 13:30:43 -0400 > From: Hunter Jozwiak > To: mc@gnome.org > Subject: How to Get Midnight Comannder to Change the Help Text to > Reflect Changes in the Keymap? > Message-ID: > < > caj1hvuf8dpdqnoxeuk6motkfef70nkka8jhvsep0htfteag...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I made a few changes to the Midnight Commander keybindings, namely I mapped > copy to ctrl-c and quit to ctrl-q. However, the help bar on the bottom > still shows copy as F5 and quit as F10; how do I fix this problem? > > Thanks, > > Hunter > -- next part -- > An HTML attachment was scrubbed... > URL: < > https://mail.gnome.org/archives/mc/attachments/20180903/e5e1f050/attachment.html > > > > -- > > Subject: Digest Footer > > ___ > mc mailing list > https://mail.gnome.org/mailman/listinfo/mc > > > -- > > End of mc Digest, Vol 166, Issue 2 > ** > ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: unrecoverable ftp timeout
Hello Joerg, On Wed, 05 Sep 2018 09:50:09 +0200 Joerg Thuemmler wrote: > Am 03.09.2018 um 11:34 schrieb wwp: > > Hello! > > > > there's something I'm experiencing quite frequently now, I'm not sure I > > was facing this behaviour w/ former versions: it's losing the FTP > > connection after a while being inactive then there is no way to free the > > VFs from the 'Active VFS directories' (it's listed in) and there is no > > way to re-instantiate the connection again. > > > > If I try from the 'Directory hotlist', I get a: > >Cannot chdir to "/ftp://; > >Remote I/O error (121)) > > if I try from 'FTP link...', I get only: > >Cannot chdir to "/ftp://; > > > > The only way I've found to reconnect to a lost FTP connection is > > restarting mc, which is not convenient nor expected. > > > > mc 4.8.1 compiled from the sources, on am up-to-date CentOS7 box: > > $ mc --version > > GNU Midnight Commander 4.8.21 > > Built with GLib 2.54.2 > > Using the S-Lang library with terminfo database > > With builtin Editor > > With subshell support as default > > With support for background operations > > With mouse support on xterm and Linux console > > With support for X11 events > > With internationalization support > > With multiple codepages support > > Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs > > Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; > > > > > > Regards, > > [snip] > Also I noted ftp servers, which do block the connection after some idle time > and if you try to use this connection, they want you to reconnect and to put > in your password once more. Mc caches your pw and resends it, but the new > connection is started in the ftp users root dir (on the ftp server) again, > not in the dir you last used. That may confuse the vfs system, but it's a > problem connected with the ftp server's usual behavior (mc could resend the > "cd" commands then after reconnection, dunno whether it's possible to cache > last dir before timeout disconnect). I experience this specific behaviour quite often (back to root or parent folder). [snip] > I would try to get a later timeout on the used ftp server, as I believe it's > an old "feature" and will not be changed next time, espacially as sftp will > become a more important ftp replacing... Maybe you should change some other > properties of your ftp servers making trouble if you try to re-connect. But > this depends on ftp server program used. I'm afraid I can't change anything on the FTP server side, it's not mine at all.. All I know is that mc is not behaving correctly (and possibly differently than "before"?) - I don't face such issues w/ filezilla against the same FTP servers. Regards, -- wwp pgpbSIdnUcazk.pgp Description: OpenPGP digital signature ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: unrecoverable ftp timeout
Am 03.09.2018 um 11:34 schrieb wwp: Hello! there's something I'm experiencing quite frequently now, I'm not sure I was facing this behaviour w/ former versions: it's losing the FTP connection after a while being inactive then there is no way to free the VFs from the 'Active VFS directories' (it's listed in) and there is no way to re-instantiate the connection again. If I try from the 'Directory hotlist', I get a: Cannot chdir to "/ftp://; Remote I/O error (121)) if I try from 'FTP link...', I get only: Cannot chdir to "/ftp://; The only way I've found to reconnect to a lost FTP connection is restarting mc, which is not convenient nor expected. mc 4.8.1 compiled from the sources, on am up-to-date CentOS7 box: $ mc --version GNU Midnight Commander 4.8.21 Built with GLib 2.54.2 Using the S-Lang library with terminfo database With builtin Editor With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; Regards, Hi, AFAIK it's an old thing mc is blocked after some ftp trouble. For instance, copying files on the server's side usually blocks. Opening FTP dir, pressing F5 on a file on the ftp side and giving a destination name without path (so it has to copy on the ftp server itself) always leads to an blocked mc (there is no "copy"-command in ftp). Also I noted ftp servers, which do block the connection after some idle time and if you try to use this connection, they want you to reconnect and to put in your password once more. Mc caches your pw and resends it, but the new connection is started in the ftp users root dir (on the ftp server) again, not in the dir you last used. That may confuse the vfs system, but it's a problem connected with the ftp server's usual behavior (mc could resend the "cd" commands then after reconnection, dunno whether it's possible to cache last dir before timeout disconnect). I'm usually connecting via "FTP link", which reconnects correctly but restarts in the users root. Classical "ftp" command cannot reconnect. And there is maybe a servers property possible, that forbids auto reconnection... There may be another problem. dunno whether that's real, as I'm not a network pro. In http connections can use a session ID, after timeout disconnect and reconnect you always get a new one. If the same thing is possible and used in ftp, maybe in newer implementations, you will get a problem too. I would try to get a later timeout on the used ftp server, as I believe it's an old "feature" and will not be changed next time, espacially as sftp will become a more important ftp replacing... Maybe you should change some other properties of your ftp servers making trouble if you try to re-connect. But this depends on ftp server program used. regards -- Joerg Thuemmler ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
