Re: IBM Systems Mag sez "All Hail the Midnight Commander!"
Same for me. I started to use Linux when Win95 came out. One of the reasons was that I hated the Win95 file manager, having learned to use the Norton Commander on DOS. I also had been running Norton DOS and had constructed a number of *.bat files to streamline my work, especially handling the writing of LaTeX files, and Win95 would not let them run because they depended on the enhanced features of the N-DOS command.com. And Win95 would not let me use the N-DOS command.com and provided no acceptable substitute for its functionality. It seemed that Win95 was designed to punish me for everything I had learned about how to make a computer work for me instead of forcing me to work for it. So when I heard about the existence of Linux I downloaded it and installed it, found out that it met my needs, and have never looked back. The only thing that messes me up nowadays is that the format of mc.ext was changed at some point and a lot of stuff in it quit working. I either have to use an old-style one that I kept, or else I have to edit by hand the new ones that come out. Otherwise, it seems that xdg-open simply does not work in the terminal for a lot of stuff, seems to think I am in an X environment when I am not, wants to run an X-dependent application, and can't. But I have never found any adequate substitute for MC. Theodore Kilgore On Thu, 29 Nov 2018, James Wonnacott wrote: I've only ever used CLI since I started with Linux in mid 90s and MC is always the first thing I install on a new system. Many thanks to all! James On 30/11/2018 02:56, solarflow99 via mc wrote: I have to say i'm also very grateful for it. Having mc installed is a necessity, i'm really surprised its use isn't even more widespread among CLI users. On Thu, Nov 29, 2018 at 6:13 PM Nate Bargmann <mailto:n...@n0nb.us>> wrote: I'll take this opportunity to thank all of the contributors to this wonderful program that I have been using since 1996 with my first foray into Slackware Linux. I recall that its package description said something about Norton Commander, but I never saw it or used it back in my MS/PC-DOS days. Midnight Commander is the first package I install on a new system if it isn't installed already. I recommend it to everyone interested in trying Linux. It is such a versatile program that over time I'll have five or six instances of mc running in various virtual terminals. Sometimes I'll find I started it twice in the same vt! Thanks again. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
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: use of graphics characters recently disabled in xterm
Thomas, Thank you very much. I was not aware uxterm and I will look into it. However, to compound the ironies of this situation, I live in Auburn, Alabama. Hurricane Irma blew into town yesterday afternoon. By then, it was not much of a storm any more. My original suspicion was almost right, that it would miss us altogether and get pushed to the east because we had been in a high pressure area with coolish temperatures. But, I suspect, the previous high pressure and cool weather are what did in the hurricane so quickly. But Irma did turn my power off for four hours yesterday by dropping a tree somewhere in the neighborhood, leaving the street without electricity. The computer was on when this happened. And four hours later when it was re-started, the problem we have been discussing had gone away. I do not know how this could be the case because to reboot after an upgrade is supposed to be a Windows thing, not required in Linux except to replace the kernel. With due acknowledgement of the human suffering caused by Irma, it seems that an old saying is justified again. It's an ill wind indeed that blows no one any good. So, let's close this thread for now, and reopen it only if the problem comes back. Cheers, Theodore Kilgore On Tue, 12 Sep 2017, Thomas Dickey wrote: On Mon, Sep 11, 2017 at 11:03:23AM -0500, Theodore Kilgore wrote: Thomas, The output of locale (invoked without arguments) is as follows, between the two lines. kilgota@khayyam:/etc/X11/app-defaults$ locale |less LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= --- Those settings should work (the important ones are LC_ALL and LC_CTYPE, LANG). There is a line called "line-drawing characters" which is *not* turned on. It is unclear to me what this does (see the xterm man page for an explanation, which is not totally clear). What it might be doing is turning on the line-drawing characters from X itself, to replace the ones which are provided by the font, or alternatively what it might be doing is enabling the line-drawing characters which are already provided by the font. As I said, the explanation in the man page is not very clear and these two meanings are obviously opposite to each other. In any event, to toggle this setting on and off all by itself, when other settings are not changed, seems to have no effect. There are also lines in that menu for UTF-8 Encoding, UTF-8 Fonts, and UTF-8 Titles. These are also apparently not turned on (no check marks in front). Setting UTF-Encoding *and* UTF-8 Fonts *and* Line-Drawing Characters all to be on seems to solve the problem. But by default all three of them are turned off. Why are all three of these settings turned off by default? I have no Line-Drawing is normally turned off because a well-designed font will look better than xterm's built-in equivalent (since it may use thick lines for large characters). UTF-8 Fonts would be turned on if you used the "uxterm" shell script to setup xterm, which gives better coverage of Unicode. UTF-8 Encoding isn't on either because there's some problem with the locale _tables_ or due to a resource setting. If you have "appres" installed, you may see the problem in the output of "appres XTerm". idea. In particular, this is even more amazing because it seems to be in conflict with the locale settings displayed above. So, in order to get back to the bottom of this problem it seems to me that what needs to be done is to set up a way to turn all three of these settings on. However, I do not know what I am supposed to do in order to carry that out. Change some configuration file, I suppose, or else do a local override. But I suspect that the settings are already set correctly in some file somewhere and that somehow the settings in that file are being ignored. I'd try using the "uxterm" script (it's supposed to do most of the fixes you need). -- Thomas E. Dickey <dic...@invisible-island.net> http://invisible-island.net ftp://ftp.invisible-island.net ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: use of graphics characters recently disabled in xterm
Thomas, The output of locale (invoked without arguments) is as follows, between the two lines. kilgota@khayyam:/etc/X11/app-defaults$ locale |less LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= --- Now, what is also interesting is that after reading closely the man page for xterm and trying to make sense of it, I discovered that there are two things which one can do in order to make the settings in an xterm to be visible. There are two things called "menu" and one can get to them by holding down a control key and clicking either the left or the right mouse button while the pointer is in the window. The right button click displays a window called "VT fonts" and it contains relevant information. Unfortunately, I do not know if it is possible to mouse-copy its contents because it goes away immediately as soon as one lets go of that button. This VT Font menu depicts the current settings by a check mark in front of whichever setting is highlighted. One can scroll down that menu and change a setting by hand, by leaving the highlighting on top of that particular setting and then closing the menu. Also, the settings in this menu are specific to the xterm which has been opened. They remain as they previously were if one opens another xterm next to the one in which the settings have already been set by hand. And in the same manner those settings cannot be saved for another X session. A further description of possibly relevant settings in this window follows. There is a line called "line-drawing characters" which is *not* turned on. It is unclear to me what this does (see the xterm man page for an explanation, which is not totally clear). What it might be doing is turning on the line-drawing characters from X itself, to replace the ones which are provided by the font, or alternatively what it might be doing is enabling the line-drawing characters which are already provided by the font. As I said, the explanation in the man page is not very clear and these two meanings are obviously opposite to each other. In any event, to toggle this setting on and off all by itself, when other settings are not changed, seems to have no effect. There are also lines in that menu for UTF-8 Encoding, UTF-8 Fonts, and UTF-8 Titles. These are also apparently not turned on (no check marks in front). Setting UTF-Encoding *and* UTF-8 Fonts *and* Line-Drawing Characters all to be on seems to solve the problem. But by default all three of them are turned off. Why are all three of these settings turned off by default? I have no idea. In particular, this is even more amazing because it seems to be in conflict with the locale settings displayed above. So, in order to get back to the bottom of this problem it seems to me that what needs to be done is to set up a way to turn all three of these settings on. However, I do not know what I am supposed to do in order to carry that out. Change some configuration file, I suppose, or else do a local override. But I suspect that the settings are already set correctly in some file somewhere and that somehow the settings in that file are being ignored. Theodore Kilgore On Sun, 10 Sep 2017, Thomas Dickey wrote: On Sun, Sep 10, 2017 at 01:58:38PM -0500, Theodore Kilgore wrote: On Sun, 10 Sep 2017, Thomas Dickey wrote: On Fri, Sep 08, 2017 at 05:57:33PM -0500, Theodore Kilgore wrote: I have recently done some upgrades, keeping current with slackware-64-current. And what has happened is that suddenly MC started to print funny characters around the panels instead of a screenshot would help: In the screenshot, I see a single character, which is always the same value: 226 (octal 342). That happens to be the first byte of the UTF-8 encoding for the various line-drawing characters which is odd, since they are all 3-bytes: \342\224\2140x250c /* upper left corner */ \342\224\2240x2514 /* lower left corner */ \342\224\2200x2510 /* upper right corner */ \342\224\2300x2518 /* lower right corner */ \342\224\2340x251c /* tee pointing left */ \342\224\2440x2524 /* tee pointing right */ \342\224\2640x2534 /* tee pointing up */ \342\224\2540x252c /* tee pointing down */ \342\224\2000x2500 /* horizontal line */ \342\224\2020x2502 /* vertical line */ \342\224\2740x253c /* large plus
use of graphics characters recently disabled in xterm
I have recently done some upgrades, keeping current with slackware-64-current. And what has happened is that suddenly MC started to print funny characters around the panels instead of printing vertical and horizontal lines. This happens only in an xterm, not in the console terminal where all remains OK. The command mc -a replaces the straight lines with vertical and horizontal dashes, but that does not look nearly so nice. Oh, I should also say that this happens only on my home machine which has an AMD processor and on-board ATI video. It does not happen on the machine at my office, which is an Intel CPU with on-board Intel graphics. The two machines both run slackware-64-current and as far as I know the two machines have exactly the same list of distro packages installed. The only thing I can think of is that something in the options for xterm needs to be changed, but I have no clue about what that magic option might be. Or, it could possibly be some library which deals with graphics and is somehow broken on an AMD-based machine. I am pretty much guessing, of course, but to fix the problem would be nice. Anyone have an idea? Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: Why does one have to "Press any key to continue" after running a command?
On Tue, 23 Aug 2016, Mike wrote: F9 -> Options -> Configuration... -> Pause after run -> set to Never. OK, I will try that. Right now it is something like "Only on dumb terminals" or similar wording. But the explanation in the man page for this option was not exactly clear. Thanks. On 2016-08-23 10:38, Theodore Kilgore wrote: For example: Running Midnight Commander, with the panels turned on, I do a command such as latex Cntl-Enter (using the Cntl-Enter seqiemce tp bring a filename down to the command line, so that it says latex file.tex Then after the latex command has done its thing one does not get the panel back. Instead, one sees "Press any key to continue" Perhaps there is a good reason for doing things this way, but I cannot figure out what it might be. Also I can not find any option in "man mc" which would look as though it ought to be what one should do to turn this off. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc -- Peace and Cheer ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Why does one have to "Press any key to continue" after running a command?
For example: Running Midnight Commander, with the panels turned on, I do a command such as latex Cntl-Enter (using the Cntl-Enter seqiemce tp bring a filename down to the command line, so that it says latex file.tex Then after the latex command has done its thing one does not get the panel back. Instead, one sees "Press any key to continue" Perhaps there is a good reason for doing things this way, but I cannot figure out what it might be. Also I can not find any option in "man mc" which would look as though it ought to be what one should do to turn this off. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Problem with Shell link
In MC, the option Shell link from the drop-down menu is supposed to provide in the relevant one of the two MC panels a display of the directory structure of another machine, to which one connects by ssh. In general, this option works for me well enough. But there is a machine at work to which I need to connect for which it does not work. What I would hope is that, if nothing else, someone can point me toward ways to diagnose the problem or to get some debug output so that the problem can be traced. The (remote) machine for which the Shell link option seems to fail is a central server machine at my university. I have an account on that machine, and I can access that account by ssh (name of that machine). Then, no problem. I get a password prompt, and I log in, and I get a command prompt. But if I start MC and do from one of the panels the Shell link option, then what happens is, I get a password prompt, then type the password, and after that a blank screen. If I type a deliberately wrong password, then it is rejected and I get asked again for the password (probably indicating that the problem does not occur at this step). If I type the right password, then the terminal (or xterm, it makes no difference) just hangs. Nothing happens, except that one must open another terminal or xterm and kill the connection. To do this, I have to do ps ax and find the attempted ssh connection, and kill it. The remote machine is running Linux, apparently Red Hat Enterprise Linux (uname output available if needed). The only peculiar thing about its setup is that it is running csh, and when I log in I have there a .profile file which tells it to start bash. And when I log out after doing a regular, command line connection I have to type exit to get out of bash, then type exit again to log out. I do not know the underlying cause of the problem which I have just described. I have asked a couple of local IT people what might be causing the problem, and they do not seem to know, either. Thus, unless someone has experienced similar problems and has some good guesses, it is very difficult to work toward a solution in the absence of debug output. Does anyone have any clever suggestions? Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 120, Issue 7
Chris, I don't completely understand. Please see my comments in-line, below. On Sat, 31 May 2014, chris glur wrote: Re. hardware with unfamiliar keybrd: the hardware must adjust to YOU. First, are you familiar with the Samsung Chromebook keyboard? There are missing keys. Keys which most of us use quite often. And those keys are not switched around. They are simply not there. So, exactly what I am trying to do is to make the hardware adjust to me. If we've been accustomed to 'asdf' for decades, we shouldn't need to re-adjust to 'afds'. Unfortunately, it is worse than that. Just supposeing that you were confronted with keyboard which had something like 'a(missing key)(another missing key) f' then exactly what would you do about that? And by missing key what I precisely mean is that there is a blank area on the keyboard where those two keys are supposed to be, between the 'a' and the 'f' keys. Suppose further that the machine otherwise had a nice CPU and a cheap price and intersting hardware features. Well, the situation is not that bad, actually. All the alphanumeric keys are present. But, to reiterate, 1. there is no Delete key, so just for starters there is no Cntrl-Alt-Delete for rebooting. 2. The PageUp and PageDown and Home and End keys are not physically present, either. 3. no Insert key. 4. no keypad, and no substitute for it by use of, for example, a 'Fn' key which re-maps some of the alphanumeric keys to other meanings when it is used in combination with them. Over a period of decades, many laptops of various brands have resorted to the use of the 'Fn key in order to double up on the meanings of some of the keys, most particularly in order to remap some other keys to the keypad keys. I am almost certain that you have seen sometime during your life a laptop which has such a key on it and perhaps have even used it. But the Samsung 303 Chromebook does not have any such key. And you can't use some other key for that. The Wikipedia article on the 'Fn' key might help to explain why not. If chromebook breaks PC-keybrd conventions, this will be worked on by many other users [besides mc], who will do the research for you. Funny, that is what I happen to be working on at the moment. And I have had some success, though I could try something else in the future. And you are trying to tell me to sit and wait until someone else does it? I think it would be far more helpful to me if you, or someone, could give me a brief overview of how that MC recogizes the keys you pressed. Specifically, it appears that MC does not consult or use the console keymap files and the lists of key codes which they give, and the functionality which is associated in those files with the respective keycodes. As evidence for this statement, I can say that changing those key mappings in certain ways leads to results which are visible in the console and on the command line, provided that one is not running MC in the foreground. But if one opens MC, then some of those re-mappings which I created are inoperative inside of MC or the MC editor. If I am wrong in what I say just above, it would be very nice to have an explanation of what is wrong about it. But if I am right or even if I am wrong then it would be even nicer to have an explanation of what is really happening instead. I did not ask you or anyone else to go and get busy right now and do a bunch of work and drastically re-code everything related to the keyboard. What I wanted was some information about how the keyboard access works in MC as of now. It could be that there has been some misunderstanding on your part. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Key bindings for the Samsung Chromebook
Hello, I am trying to make a Samsung Chromebook to support Linux functionality in a manner to which I am accustomed. The problem is missing keys. A possibly noninclusive list follows, for anyone who might possibly not be familiar with the hardware: 1. There is a Backspace key, but no Delete key. 2. No Insert key (useful in MC for highlighting files for various actions). 3. There are not PageUp nor PageDown keys. 4. The Home and End keys are missing, too. 5. The Function keys 1 through 10 are present, but they are not labeled as such because the default OS maps them to various hardware functionalities, such as more sound, less sound, more brightness, less brightness, and such. In Linux these are mapped to the usual F-* keys, and it is not obvious how to recover their original functionality at the moment. That is a longer-term project. 6. There is no Fn key of the type common on many laptops. This hurts, actually. So it cannot be used to modify the behavior of anything, neither the F-* keys nor anything else. 7. There is a search key at the left of the keyboard, which does absolutely nothing in the Linux console. It gives the same keycode response if 125 (as seen from the showkey command) as the windows key on a regular PC keyboard. I have been working with the console keymap files, supplying missing functionality due to the missing keys, and I have solved some of the problems -- so long as one stays purely in the console. The following all seem to work: 1. altgr-backspace key deletes the character instead of the previous one (altgr is also known as the right alt key and the leftalt key is just called alt in the console keymap file) 2. control-alt-altgr-backspace reboots the machine 3. altgr-uparrow does PageUp 4. shift-altgr-uparrow scrolls the console up 5 and 6 similar to 4 and 5 for the downarrow key 7. altgr-leftarrow does Home 8. altgr-rightarrow does End 9. Mapped the search key to Insert. All of the above are done by suitable editing of the defkeymap.map file which is found in /usr/share/kbd/keymaps/i386 I have not yet begun to work on the X keymappings which I understand are different. But the next thing on the list is to figure out what to do in Midnight Commander. Or, perhaps better, in the editor. What I discovered so far is that, 1. the mc editor understands some of what I did and is ignorant of other things that I did. For example: --when mc is started, then the command line at the bottom is ignorant of what I did, except that the functionality does come back if one does control-o and thereby puts the mc screen in the background. -- the Insert key works, both for highlighting files and also in the editor. It also toggles, as it should. -- the PageUp and PageDown functionality does not work in the panels. -- in the editor things are rather chaotic. The new PageUP and PageDown functionality works in the editor, but the new delete-character function does not. Also the new Home and End functions do not work. -- the Learn Keys option could not understand anything which I had done, either. So, when all else fails one should read the man page, where there is a section called Redefine hotkey bindings. So I went and got a copy of the file and put it in a local directory to fool with. When I opened the mc.keymap file, I was a little bit puzzled. There is no way there to distinguish between the two keys which the default terminal keymap file calls, separately, by the names alt and altgr (in which alt is left alt and altgr is right alt). Let us take as a specific example the Delete functionality in the editor. One of the problems, to be sure, is that under the [editor] section the default behavior of Delete is listed as delete, cntrl-d and backspace is listed differently. Now, cntrl-d does work. But, very unfortunately, the console keymap (which is actually pretty much the same as the keymap file on a PC) lists the key number 14 (which has an arrow pointing left on it, or the word Backspace on some keyboards) as doing Delete, but it does what the rest of us call Backspace instead. The key on a regular PC keyboard which has the keycode 111 and which has the name Delete on it, is, as I said, not present on the Samsung Chromebook keyboard. The console keymap file says the action of this key with keycode 111 is Remove instead of Delete. Thus in the console keymap file I mapped altgr keycode 14 to Remove in order to get that functionality back again. Unfortunately, the mc.keymap file does not seem to understand what I did, and no visible method of passing this functionality into the mc.keymap file is obvious. Similar remarks pertain to the functionality of the Home and End keys. I cannot seem to make them work, either. Suggestions from the knowledgeable are most welcome. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: disabling F4 opening large files
On Tue, 29 Apr 2014, Martin Vegter wrote:
I would prefer no action at all when pressing F4. I can define rules for:
Open=
View=
but AFAIK, there is no option for
Edit=
or is there?
I think there is.
Read ./home/YOU/.config/mc/mc.ext:
#Open (if the user presses Enter or doubleclicks it),
#
#View (F3), Edit (F4)
I have tried following, but that does not have any effect:
include/video
Open=([ $(id -u) != 0 ] [ $DISPLAY ] mplayer %f
/dev/null 21 )
View=%view{ascii} mediainfo %f
Edit=
When I click F4 on a video file, mc still tries to open in in my text
editor. What am I doing wrong?
Martin,
I can not comment about what you are doing wrong but what I understand
about F4 is that it is supposed to open the raw file, whatever it is. This
means to look into what is inside the file, for the purpose of editing it
or otherwise seeing what is really there. That means if for example it is
a binary file then one may be privileged to see plain text or, possibly, a
bunch of hex numbers in a nice rectangular array. One might keep in mind
that this is exactly what some people want to see, and they are glad to
have a convenient way to do that.
Cheers,
Theodore Kilgore
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
Re: What is audio/x-wav D)download or C)cancel anyway?
On Tue, 3 Sep 2013, Andrew Borodin wrote:
On Mon, 2 Sep 2013 19:41:17 -0500 (CDT) Theodore Kilgore wrote:
and why do I get a black screen with this mysterious message at the bottom
when I am attempting to play a WAV file in MC running in a terminal (not
in X!)? And, of course, I just get this message, no music. What in the
world is happening, here?
MC supports system-wide file bindings using xdg-open.
Just upgraded to Slackware Current on my old eeepc netbook, decided to
play a piece of music afterward to relax, and I confronted this.
I looked into the extension editor, and it says about wav files and other
sound files that it follows what is in /usr/libexec/mc/ext.d/sound.sh
That file does not seem to contain anything of the kind. It says it is
going to use play in the terminal (which is what I expected) and it says
it wants to use xmms in X.
Look at the end of sound.sh:
86 open)
87 ${MC_XDG_OPEN} ${MC_EXT_FILENAME} 2/dev/null || \
88 do_open_action ${filetype}
To disable xdg-open in mc, you can define MC_XDG_OPEN=/bin/false.
Andrew,
I suppose I can do that. But, OTOH what exactly am I supposed to do
actually to make this xdg-open actually to do its work and not to go
crazy instead?
It occurs to me that the problem I had on my main computer a few months
ago was somehow similar, in that a recent upgrade of MC on the main
computer was adopting the crazy and extremely inconvenient practice of
trying to open everything using the web browser, no matter what the file
was and no matter whether I had an appropriate application installed on
the computer or not. It seemed at the time that something was suddenly
needed which had never been needed before, and was not specifically
explained in any related documentation. We had a discussion about this,
and it was suggested to create a $HOME/.mime.types file and to put stuff
in it as needed.
I also corresponded with Patrick Volkerding about this and asked him what
the problem was. He said, essentially, that there is not supposed to be
any problem, and probably he is right if one were doing a fresh and clean
install. There is, he averred, support for mime types in Slackware. The
problem thus seems to boil down to xdg-open trying to look in some default
location for that information, and on an older and previously running
system that particular, default location might not be present because
whatever software package it happens to be in was never needed for
anything at all on that particular machine. The man
page for xdg-open does not provide any enlightenment about this either.
So, do you happen to know exactly where the information is supposed to be
which xdg-open is supposed to find, so that xdg-open can be stopped from
going crazy and forcing every file to be opened in the browser if one is
in an X session, and other really weird stuff to happen if one is in a
terminal? What application is it that I do not have installed on the
netbook which it is somehow just assumed that everybody has installed, on
which xdg-open is relying?
Theodore Kilgore
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
What is audio/x-wav D)download or C)cancel anyway?
and why do I get a black screen with this mysterious message at the bottom when I am attempting to play a WAV file in MC running in a terminal (not in X!)? And, of course, I just get this message, no music. What in the world is happening, here? Just upgraded to Slackware Current on my old eeepc netbook, decided to play a piece of music afterward to relax, and I confronted this. I looked into the extension editor, and it says about wav files and other sound files that it follows what is in /usr/libexec/mc/ext.d/sound.sh That file does not seem to contain anything of the kind. It says it is going to use play in the terminal (which is what I expected) and it says it wants to use xmms in X. But nowhere that I could think of looking did I find any message resembling what is above. And what could it conceivably have to do with opening a WAV file which is on my hard drive, not somewhere else, and wanting to do the obvious which is to play it? This is totally weird. ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 109, Issue 2
On Sat, 4 May 2013, chris glur wrote: Perhaps it's just another passing fad like FB/twitter. mc dates from 70s DOS:nc. Chris, If you are referring to MTP and PTP as a passing fad I think you are probably not correct. They appear to me to be pretty standard protocols these days. For example, many if not most of the newer still cameras from the various major brands are using PTP, and libgphoto2 contains support for it. And, historically, I understand that PTP originally grew out of MTP and the two protocols are in fact closely related. To support them in MC might be an interesting idea. However, I myself own no hardware which uses either one of these protocols. BTW, how do I ask a 800 char question to a user whose twitter-adr only is known? No idea. I don't do Twitter or any other social-media setup. Theodore Kilgore == TIA. On 5/3/13, mc-requ...@gnome.org mc-requ...@gnome.org 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. MTP/PTP support in mc? (Weiwu Zhang) -- Message: 1 Date: Fri, 3 May 2013 16:37:17 +0800 From: Weiwu Zhang zhangwe...@realss.com To: mc@gnome.org Subject: MTP/PTP support in mc? Message-ID: CAEvpD615EKe4-UzPuONTzhb3GmdN7JQnTb=vksiowdesfpa...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hello. I hardly believe I am the first person who bring up this issue, but a quick google searc reveals nothing. MTP/PTP is like ftp, with which a user can upload and download files from devices but not randomly access the file. As in the example of Ubuntu 13.04, MTP/PTP is uncomprehensible to mc. It is mounted somewhere under /run/user/$USER/gvfs and every file name / directory name is a number. Higher level facility (like nautilus) can see them as named files / directories. I am afraid people would find transferring files between computer and mobile phone being an important part of daily file management - at least in my case, it is the most frequent file management task, more frequent than managing My Documents. Is mc coming with some support of this scenario? Best regards Zhang Weiwu -- Subject: Digest Footer ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc -- End of mc Digest, Vol 109, Issue 2 ** ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 107, Issue 3
On Wed, 3 Apr 2013, chris glur wrote: Thanks, I'll try SlakARM. One or two things ought to be mentioned about this before you start, though: First, it is not a distro which is specifically intended for the RPi. It is not specifically optimized for the RPi but is pretty generic for ARM hardware. One consequence of that is, the distro as far as I know does not provide a kernel which specifically supports that hardware, and therefore an attempt to boot one of the distro-provided kernels will not work. At least this was true when I did my install, which was several months ago. One had better use the stock Debian kernel and its associated modules. Second, unless things have changed recently there is not full support for the RPi in Linus's git kernel, either, not to mention a numbered non-rc release. This may have changed recently. I have not kept current with that due to other stuff like working for a living. And naturally there is an ongoing effort to integrate the RPi fully into the main line, an effort which is (was?) still incomplete. Anyway, I did try to compile a git kernel back then and it would not run. Third, SlackARM runs quite well even as it is. But the RPi has some kind of math coprocessor, I understand. SlackARM's libc is set up only to use math mode emulation and so does not use the full abilities of that specific ARM cpu (reason: many ARM cpus will only use emulation and the distro is supposed to run on them. One of the good things to do is then, to use a libc which direcly supports using math mode. I did not go through the rather intricate steps to do this, but I am quite happy with the results even without that. There are a couple of whinges and whines about the RPi which I fully agree with. One is that the USB support is just a little bit flaky. As you know, I have written some kernel stuff to support webcams. What I found out (after making sure that all of this stuff was implemented in my RPi kernel) is that there is a rather chaotic and semi-random pattern of cameras working, or not working. And sometimes it is cameras supported by the same kernel driver some of which work and some of which do not. I don't know why, because I have not had time to look into it deeply enough. Another whinge is that the sound chip works, but there is a really annoying loud pop when one plays a sound file, and another equally loud pop when the file comes to an end. Apparently, this happens because the sound chip is in standby mode by default and the first thing is it has to be turned full on, and then turned full off again. And I have not been able to figure out if there is any way to do a soft on and a soft off to fix that. At least, a first look at the kernel code did not seem to make it obvious what to do. Probably, if they had gone to the trouble to do something like to install a tiny buffer capacitor on the board it might be able to make this go away. But they didn't. Also it is probably better to buy a new SD card to stick SlackArm on it instead of wiping the old one. Also as I said I think that Debian does have a functioning mc in its repository somewhere. Anyway, it's lots of fun for them that likes things like this. Theodore Kilgore I've analysed why many people HATE mc. The sports-man/soldier-type who train to do the task by reflex, like your dog catches a ball, want to go-straight-to-the-goal, by writing a mesg to the-little-man-in-the-box. The don't want to see the 'clutter' of multiple fileNames and have to make decisions, during the game. They have a complete mental-model of how to reach the goal. On 4/2/13, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Tue, 2 Apr 2013, chris glur wrote: Can someone confirm that mc is available for ARM:rPi ? I've often wondered why Debian doesn't acknowledge that gpm is the most essential utility and mc is the 2nd most. Hi, Chris, ArmedSlack (Slackware for ARM, aka Slackarm) does contain a package for mc. I can also confirm that, as of a couple of months ago, slackarm-current is running well enough on the RPi. In Debian, you might possibly be able to get mc by the routine of running sudo apt-get install mc. In fact, I think that I vaguely recall doing that successfully during my first attempt to get the RPi up and running, back when I first got one of them. As to why Debian seems to bypass mc as part of the basic distribution and seems to want to make people go and get it instead, I have no idea. I have often wondered about that obvious omission, myself. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 107, Issue 3
On Tue, 2 Apr 2013, chris glur wrote: Can someone confirm that mc is available for ARM:rPi ? I've often wondered why Debian doesn't acknowledge that gpm is the most essential utility and mc is the 2nd most. Hi, Chris, ArmedSlack (Slackware for ARM, aka Slackarm) does contain a package for mc. I can also confirm that, as of a couple of months ago, slackarm-current is running well enough on the RPi. In Debian, you might possibly be able to get mc by the routine of running sudo apt-get install mc. In fact, I think that I vaguely recall doing that successfully during my first attempt to get the RPi up and running, back when I first got one of them. As to why Debian seems to bypass mc as part of the basic distribution and seems to want to make people go and get it instead, I have no idea. I have often wondered about that obvious omission, myself. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 105, Issue 7
On Sun, 27 Jan 2013, chris glur wrote: } it happened (and happened on my little RPI too) How did you get mc to run on RPI? I bought 2 RPI. 1 with the default debian OS, and 1 with no CF-card yet. After booting RPI, the first apps I checked for were `mc` `gpm`. Neither existed. I lent the RPI to someone, to find out how to make sounds via `scratch`. I couldn't believe that the sound card was included in the CPU-chip! Since you use slak64, what about ARMslak? Someone else on the USEnet-slak-group has it on his RPI. I do. And probably not relevant here, but it is running on a 32-gig SD card, too. So I almost have a real machine out of the RPI. The biggest limitation of the RPI seems to me to be the apparently flaky USB setup, and the fact that the NIC is hooked to the USB, too. So, if something gets overloaded then the keyboard, the mouse, and the network can all crap out simultaneously. An adequate power supply mitigates things but does not solve all of the problems. As an example of a problem which seems to be related to the funky USB setup on the RPI, some of the USB webcams which I have supported in the kernel do not work. But some others which use the same driver code do work. Strange. Someone high up in the Linux media project has advised me to give up trying to track down the problem. He says that the basic problem is the RPI's USB hardware and consequently one will probably never be able to locate where exactly the problem is. If he is right, then that is kind of too bad. But BTW, xdg-open can be made to work well enough in Slackware. Here is what Patrick Volkerding says about it: Both xdg-open and shared-mime-info come from freedesktop.org. We include both of them, so unless the mime support package that you're speaking of is something different, we already have it. Maybe running update-mime-database would help? Indeed, running update-mime-database does fix the problem. Patrick also says it is one of the standard options when doing a new install. Thus, probably the way that I got into the soup about that is, I rarely do a completely new install these days, but just do incremental updates and so the update-mime-database was not run when I upgraded MC. Why it did not get run when I did an install on the RPI I am not sure, but it obviously did not get run there, even though it was a new installation. ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: Funny action on opening a pdf document
On Sun, 20 Jan 2013, Piotr Ozarowski wrote: [Theodore Kilgore, 2013-01-19] OK. I can not do any more of this on the machine which is in the workplace right now, but I tried it at home on my Raspberry Pi which was having the same problem. It seems to fix the problem well enough. great Some observations, both for you who apparently are connected with xdg-open and for the MC people: I'm just a xdg-open user 1. The RPI is a little machine, with minimal resources. It is not expected to deal with mail, so there was no .mailcap file. No mail programs, not even client programs, and so nothing related was installed, either. Hence, the only way that was reasonable for creating a .mailcap file was to copy one over there. For similar reasons, there was no /etc/mime.types, either, and no .mime.types file in my user directory. On Debian, it is provided by mime-support package which is Priority: standard so you have to do some work to... not have this files installed by default. Not all distros are identical. What you have, of course, is an indirect proof that I am not running Debian on the Raspberry Pi. Thanks for the help. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 102, Issue 3
On Mon, 15 Oct 2012, Holger Herrlich wrote: To copy text from one mcedit instance to another, mark the text via [F3], copy it to a file (dflt: .mc/cedit/cooledit.clip) via [ctl]+[f], switch to the other mcedit and load the text via [F15] (maybe [shift]+[F3]). This will work for all instances of mcedit if run by the same user. hth Holger Ah, but suppose that one wants to copy out from something being edited with mcedit into some other place? For example, you are writing code and you would like to discuss some code snippet with a colleague. So you open pine and start an e-mail and want to copy into the e-mail. What then? The point is, mcedit needs to be not just friendly to itself but also to other applications. Theodore Kilgore On 10/15/2012 08:54 AM, Martin Mísa? wrote: I do all my coding in mcedit, I usually have about 8 windows with mc opened and copying between them is important to me. I usually use shift-mouse method. When there was first release of MC where invisible characters (Visible trailing spaces and Visible tabs) was present I turned them off due this mouse copy(-paste) problem. Is it possible to detect shift-mousepress and switch them off automatically and after copying switch them on again? Or do it in the copy buffer to avoid redrawing of the screen on slow terminals? I also turned off Return does autoindent also due (copy-)paste problem. Maybe it also could be detected that paste was done (shift-middlepress) and swith autoindent off for that moment... Both these functions helps and I would use them, but if they breaks mouse copy-paste which is important to me, I have switched them off. I use mouse copy-paste about twice/hour, sometimes more. Thanks Martin ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 102, Issue 3
On Sat, 13 Oct 2012, chris glur wrote: -- 2. The ghost tabs and ghost single space characters are not transferred anywhere else when mouse-paste is done You mean an exta comminication between the mouse-paster and the editor? Such complications are to be avoided. I understand that there is an option to turn these ghost characters on, or to turn them off. GOOD! Show me how ? Well, I had to go and check on this because I find it rather too inconvenient to turn this stuff off and on all the time. But the following does work: 1. You are editing a file where you see the objectionable -- things which indicate tabs, and you want them to go away. So ... 2. Hit F9, Open the Options tab on the upper bar. 3. Go down to General and open it. You will see a table called Editor Options. 4. Among the editor options you will see [ ] Visible tabs and another one which is [ ] Visible trailing spaces among others. These are of course on if you see an x inside the brackets, like this [x] and they are off if there is only [ ] so you switch these either on or off according to taste and then exit with save by hitting the OK option. Thus, it would seem to me that this gives you what you need. Apparently you do not want to have these invisible characters under any circumstances so just turn them off. Unfortunately, it does not solve *my* problem which is that it is so difficult to turn them on or off that it is disruptive. Thus, I continue to wish for an option to turn on and off, which would let the human editing the file to see the invisible characters but cause them to be invisible to the mouse. As to your statement But paste-ability must take precedence over your special example, because it's a more basic operation. I am in fact not Editing files, or copying pieces of what you are editing to some other place? Me, I spend more time with editing the files. And if what I am editing is code, which is often the case, then I really do not want the hidden characters to be turned off and no way to turn them on. That would render relatively useless an editor which I have come to rely on for much of that work, which would make me unhappy.. No. My requiremet trumps yours. The most primitive requirement is UNIQUE. All further fancy-facilities are merely ONE of an infinite fad posibility. In law and common sense, drinking water may be a human-right; tea, coke...whisky is not. True enough. But I bet that I am not alone in saying that the editor is in your sense more primitive than the mouse. Look at history. Which came first? The editor? Or the mouse? Which was a more basic need for the development of the modern computer? The editor? Or the mouse? Some, I believe, would think that your statement about further fancy-facilities applies more appropriately to the mouse, not to the editor. I have known a lot of people who thought that, and some of them have hardly been geeks at all, just ordinary users who wanted to get work done. It is good to keep that in perspective and not to get too dogmatic about whether modern feature X of a computer is more essential than modern feature Y. Sometimes _both_ X and Y have their appropriate uses and the best approach of all is to make sure that X and Y do not clash and interfere with each other and/or cripple some really nice and useful feature of the other. But all of that is by the way. In the present circumstances what I understand is that you want tabs and spaces to be invisible at all times because they get in the way of mouse-copy or mouse-paste. In the mcedit config options, there is indeed a way to turn them off, which would seem to solve that problem for you. Cheers, Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 102, Issue 3
) Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 102, Issue 3
On Fri, 12 Oct 2012, chris glur wrote: Sure, there are applications for the ghost-tabs. But paste-ability must take precedence over your special example, because it's a more basic operation. Chris, In a more ideal world we would be able to have both of 1. The ghost tabs and ghost single spaces show up in the editor 2. The ghost tabs and ghost single space characters are not transferred anywhere else when mouse-paste is done. In my understanding, there is already a third choice which I would say is an imperfect solution. Namely, I understand that there is an option to turn these ghost characters on, or to turn them off. But this is a separate operation. Namely, if one were going to use it to paste something from a file where the ghost characters are turned on then one has to do a reconfiguration (something with F9 and doing something with the config for mcedit) and then make the pasting operation, and then turn right around and turn the ghost characters back on. But this is obviously an inconvenience and it would be much nicer if we had a config option which lets us do both (1) and (2) above, without confronting the need to re-configure mcedit twice in order to get the copying job done. As to your statement But paste-ability must take precedence over your special example, because it's a more basic operation. I am in fact not sure that I agree at all. Which do you spend more of your time doing? Editing files, or copying pieces of what you are editing to some other place? Me, I spend more time with editing the files. And if what I am editing is code, which is often the case, then I really do not want the hidden characters to be turned off and no way to turn them on. That would render relatively useless an editor which I have come to rely on for much of that work, which would make me unhappy. But I really do suspect that it ought to be possible, somehow, to combine my two desires, above. After all, the hidden characters do indeed show up as ghosts already in the file opened in mcedit. Why can not an option be implemented which will pick up everything else with a mouse-copy but will just not pick up the ghost-characters? I myself am not sufficiently familiar with the internals of the MC code to look into this, sorry to say. But it sure would be a nice feature if we had it. Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 102, Issue 3
On Thu, 11 Oct 2012, chris glur wrote: Can we switch-off mcedit's ghost tab marks ? So that when we paste like:--- -i --ignore-case -- Ignore case differences in file contents. --ignore-file-name-case -- Ignore case when comparing file names. -- we don't carry the spurious -- which are apparently supposed to show that tabs were used. Yes, they do represent tabs and they are not exactly spurious. There is a problem which I wish were fixed, as described in the next paragraph, but they are quite useful nevertheless. Have you ever written code using mcedit? For example, code for the kernel, where using the space bar to create indentation is a big no-no, an explicit violation of the kernel coding style, and it will get your code patch rejected? And as to the question of sticking in invisible characters, such as a small . to signify one use of the space bar, that can be important, too. For example, if you indentation looks like instead of you have used eight hits on the space bar instead of two tabs. Fix it. Moreover, another of the big no-nos in kernel coding is a trailing whitespace at the end of a line. If you have committed this, which is very easy to do, then your one whitespace character shows up at the end of the line as a trailing . in mcedit. Delete it. For kernel coding style, the last visible character on the line is supposed to be followed immediately by a carriage return and then you see nothing trailing the text at the end of the line. But in both of these circumstances if the invisible characters show up in the file in no way at all, then how is it possible to find them and fix the mistakes? It isn't. The above issues are reason enough to have these two items to show up in an editor, if that editor is going to be used for coding. They are thus definitely not present for artistic only reasons. This being said, imagine the following scenario in which the presence of these features is definitely bad: You are writing some program, where the two features I itemized are a big help in doing everything right. You want to extract some lines of code from that work and mouse-copy it into an e-mail which you are sending to someone else, perhaps intending for the receiving party either to make some intelligent comments about those lines, or asking him to drop it into his local copy and try out what you did. So, you copy into the e-mail using the mouse. And lo and behold every indented line of the code starts with because somehow the mouse is not able to distinguish this, which shows up in faint white characters in mcedit, from text which really is there and is visible. Most definitely, that is an irritation. Similar bad afflictions occur if one is going to mouse-copy some lines of code from one file to another, too. Thus, to me what would appear to be the very nicest solution that I can imagine would be to have a setting where the invisible characters show up in mcedit but if one is going to do mouse cut-and-paste then the mouse does not see the invisible characters and makes no attempt to copy them. I understand that it is possible to turn the showing of invisible characters on or off, but I would ask for more, possibly a third setting in which they show up and then automatically they do not get sent along as ordinary, visible characters if portions of the file are copied with the mouse. Too smart-ass facilities, which are for artistic only reasons, and can't be switched off are of NEGATIVE value: like auto-indent, or absurdly breaking words, like be-cause just to get news-paper-like uniformly-spaced-columns, or *.pdf when. plain-text is adequate and better. BUG !! After using spell check via mcedit,. cursor-moving-keys cause characters to be written. And amazingly this fault stays with the file, even after it's saved and re-opened later. So it looks as if an attribute, like. interpret all cursor-arrows as eg. AB.. is carried with THAT previously ispelled-file. Yes, that does sound bad. I never experienced it. I tend to avoid using spell-check because I am old-fashioned and do not trust a program to do that kind of work. But if what you describe is happening I would agree it is a bug. However, my main point was that there are good, user-friendly reasons for having some of the invisible characters in a file to be semi-visible in an editor. Now if only the mouse could be trained not to copy them ... Theodore Kilgore ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mc Digest, Vol 101, Issue 10
On Fri, 28 Sep 2012, chris glur wrote:
}}Man, this rocks! Excellent job. Many problems and solutions discussed plus a
lot of tips. And I like the presentation. I am proud to see LaTeX still leads
to beautiful products. {{
Yes, it does. I am a mathematician, had to learn to use LaTex years ago,
and still use it routinely.
I vote for apartheid between the art-students and the computer-scientists.
Surely nc/mc's intention was NOT to be arty.
Which differs from to be NOT arty. English is real crap. It's too arty.
mc is for utility. We don't want to PAY for art.
How much energy is needed to eg. extract text from your *.pdf/latex and
insert it in email or USEnet or fax?
That part ought to be easy. Open a PDF file, and you ought to be able to
do a mouse-copy of any part of the text and copy it into a text-based
e-mail. Details of the procedure:
Open your mail program (I use apine these days) in an xterm.
Fire up something like xpdf (file.pdf) in another xterm.
Find the text you want to copy. Then mouse over it while holding down the
left mouse button. If you start at the top left corner of whatever you
want to copy and end at the bottom right corner, you will end up with a
highlighted rectangular block.
Then go over to the other xterm, where you are working on a mail to send
to someone, and click the middle mouse button. The text within the
highlighted block will then appear in your mail, starting at whatever
point the cursor was in the mail program when you hit the middle button.
What is actually being used here, by the way, is basic functionality which
is built into X. It is perhaps unfortunate that lots of people do not know
this can be done with any X-conformant program. I myself did not know, for
example, that it can be done for several years after I started to use
Linux and X. The propagation of knowledge about this feature seems to
proceed by the transmission of old folklore from those who know to those
who apparently do not yet know, on an ad-hoc basis as is happening right
now.
A similar transmission of old folklore was what informed me about this
years ago. There was one of those sometimes-recurring discussions out
there somewhere, started by someone moaning that X on Linux lacks the
ability to do cut and paste. Some old timer pointed out that cut and paste is a
fundamental feature of X. It just isn't done using Cntrl-C and Cntrl-V as
it is in some other operating system, but instead it is done by using the
mouse. Several people did not want to believe the old timer and said so in
their responses. Me, I went and tried it, and it worked perfectly.
As far as the specific case of copying from a PDF into an e-mail is
concerned, my most recent use of that was yesterday evening. The
piece I copied was a rectangle containing a block of text from the right
hand column of a two-column document, and I put it right into the e-mail.
Thus, I assume that the same procedure would work equally well for you.
You can also use the mouse to copy, of course, from one linux terminal to
another. Unfortunately, you can not copy out of X to a linux terminal by
mouse-highlighting and then switching to the linux terminal. Neither can
you copy from a linux terminal into an X session. Also if you have opened
a file in a linux terminal with the mc viewer or editor you can mousecopy
into it or from it to another linux terminal. But when mc is running in
the terminal you have to push a Shift key while doing something with the
mouse.
A recent feature (which is irritating because it is a new behavior) is
that you still need to press the Shift key even if mc is put into the
background with Cntrl-O. Until the most recent version of mc this used not
to be the case. That is, if you put mc in the background and then started
an app (an editor, for example) and you wanted to copy into it from
another linux terminal, then one used not to need to remember that mc is
running in the background. But now you have to remember that and use the
shift key. I am sorry for this change and consider it more or less of
a recently introduced bug. But I guess that I will simply have to adjust.
Hope that the above helps. Happy mouse-copying.
Theodore Kilgore
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
Re: go to parent directory with backspace
On Thu, 17 May 2012, Alan Corey wrote: Yep, have another better way. F9 - Options - Panel options - [x] Lynx-like motion NB: panel listing mode shouldn't be a 'Brief file list' ... and you will navigate as well by left arrow (leave directory) and right arrow (enter to directory). An in my opinion, this behaviour much better, rather than navigation by 'Backspace' key. I haven't seen that work in Total Commander, but as long as we're on the subject of comparing, here's one thing I miss: In Total Commander you can quickly sync up your left and right panes to the same place by using the drive letter dropdown, even if they were both already on the same drive to start with. Is there a quick way in mc to set one pane to where the other one is? Unless things have changed in a newer version that I have not yet installed, this is an old feature. Use Alt-i to make the other panel to show the same directory, and you can also use Alt-o to make the other panel go to the parent directory of the current one. BTW, these two items are well documented. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: What is the difference between Change time and Modify time?
On Sun, 31 Jul 2011, Andrew Borodin wrote: On Sat, 30 Jul 2011 14:10:41 -0500 (CDT) Theodore Kilgore wrote: To answer your question, please read the stat(2) man page and find description of change time (ctime) and modify time (mtime) Probably, the built-in help should be more verbose about sort orders. No joke. As to your advice to look up stat yes it does seem to help, but it still leaves questions about consistent behavior, or the lack thereof, which I will describe in more detail below. First, here is what the man page says: The field st_mtime is changed by file modifications, for example, by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or dele- tion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode. The field st_ctime is changed by writing or by setting inode informa- tion (i.e., owner, group, link count, mode, etc.). The above says clearly that the mtime data is changed by the creation of deletion of files whereas nothing is said about that under ctime. Presumably, applying basic logic, the ctime would of course also need to be changed (i. e. applied in the first place) if the file is a brand new one which previously did not exist, and therefore it might have approximately the same effect to sort by ctime under those circumstances as to sort by mtime. Now, here is what is very funny: Connecting to an ftp site (ftp.osuosl.org, for example), one might wish to look for the new files in a certain directory. To do that, the sensible thing is to arrange the files by date of creation. When I tried to do this recently from a certain netbook, the mtime option produced absolutely no visible effect on the file listing, but the ctime option did what was intended, instead. I do have to amend something I said yesterday, though. My mistake and I apologize. It was not on the ARM netbook that the funny behavior occurred. It was on an ASUS eeePC (Intel architecture, and running Slackware-current). The intent was to keep current with Slackware-current, obviously. On my regular-sized machines, I have always used the mtime option previously on simmilar occasions, with no problems, but here it did not work, as I said. The only other difference was that my partitions on the eeePC are all mounted with the option noatime in order to save on writes to the SSD devices inside it. But atime and ctime are not the same thing, are they? And furthermore one would expect that to mount physical partitions noatime would have no influence at all upon the way that virtual filesystems get mounted. For the above reasons, I am still a bit puzzled about what happened, but thanks for the information about where to look all this stuff up. The explanation in the stat man page is quite clear. Of course, I could try to reproduce the problem. But for all we know the problem might have been a bug in a previous version of MC which was on the eeePC prior to the upgrade, or some other package which was causing the screwy behavior. So if on testing the problem is not repeatable I guess we would never know what caused it. :-/ Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
What is the difference between Change time and Modify time?
The question in the header refers, of course, to the options found under Sort Order. Frankly, I can not tell the difference between the meanings of these two options -- unless perhaps I would take a deep dive into the source code. The man page does not seem to provide enlightenment on this point, either. I have found out that the two options can sometimes act slightly differently, perhaps depending on distro or hardware, or something even more mysterious. The usual occasion on which I would wish to sort files by date instead of by name occurs when I would connect to some repository and I want to get the most recent files in a certain directory. I have always used modify time to do the sorting, and it worked perfectly. But recently I tried to do this using an ARM netbook. The modify time then produced no change in the listing order of the files at all. But when I tried change time instead, I got the desired results. Now, as well as being built on ARM architecture, the netbook is also running a different distro from the rest of my machines. Thus, the important factor might possibly be the configuration of the distro, or it could be due to some quirk of the ARM architecture. However, I still can not tell what the difference between Modify time and Change time was supposed to be in the first place, nor, for that matter, why both of these are separately listed as options when their names seem to mean the same thing with synonymous words. It seems to me to be something which is either redundant or confusing, or possibly both. Therefore, I thought it might be good to ask. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Unity redefines F10
On Sat, 30 Apr 2011, Yury V. Zaytsev wrote: On Sat, 2011-04-30 at 09:27 +0200, Piotr Ozarowski wrote: yeah, I don't understand why they all do not include mc even in the = 200 MiB installations. The system is not usable without mc after all. Hi Piotr! Actually, do you know what are the criteria in place for making the selection? The popcon data or what? I've seen people filling a whishlist bug against Ubuntu, but given that these distro bastards are consistently making the system less usable by keyboard people to the benefit of mouse draggers (one recent achievement was a brilliant change in the /etc/inputrc, which hasn't been modified for years!), I think there is little chance it will ever get there... I'm pretty sure the pointing devices wiseguys own the joints all over the place, and they might even be already on my track now that I am denouncing this publicly... g Yury, First: Not all the distros are the same about things like this. Tried Slackware lately, which is still going strong after all these years? Second: There really are problems to solve as far as keymappings are concerned. To me, it seems that the big issue is the switch over to Unicode. As one consequence of this, some of the MC keymappings are really messed up in the X environment unless one takes some kind of special action. Most particularly, the ones involving Alt- combinations. I wonder if there are any long-range plans to deal with that. Third: The issue of other keyboards besides American or English is a serious one. The message about the Hungarian keyboard strikes rather close to home. My wife is Hungarian. She decided years ago to adjust to the US keyboard, on the grounds that not to do so would have made things even worse. But it took her a while at the beginning. I do not know if you know that the y and z key locations are opposite to what is done in English? This dates back to the days of the bread-powered typewriter. As to your complaints about mouse draggers I am not sure I would have indulged in your colorful language, at least not in print. But unfortunately, the mouse draggers as you refer to them seem to act in total ignorance of the traditional strengths of Linux and its predecessor, Unix. In this apparent ignorance, they have tended to do rather too many things which are in-one's-face. The following describes one of the consequences of this wilful ignorance: An application program should be willing to coexist with the directory hierarchy which exists on a user's machine instead of telling the user where things are supposed to be kept. If one goes to a certain directory where one keeps files of type X and starts application X_processor, then X_processor ought to look for its fodder in $PWD, as the first default. Some applications with graphical content are good about this. But some otherwise very nice applications (office suites, for example, and some image viewing programs) fail miserably, and quite consciously so. The designers have decided so (and have sometimes told me so when I submitted bug reports) based upon the design philosopy of the project. What that boils down to is that the design philosopy of their project presumes to tell me how I am supposed to organize the files and applications on _my_ computer instead of letting me make my own decisions about that. I don't think that is funny. The similar behavior of Windows 95 was one of my main motivations to seek out Linux, way back in 1996. Alas, all of the above is so unnecessary. All that would be needed would be for a few of the mouse draggers actually to learn something about the history and origins of the operating system and environment which they claim to be improving, and then everyone could be much happier. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Unity redefines F10
On Fri, 29 Apr 2011, Yury V. Zaytsev wrote: Hi! On Fri, 2011-04-29 at 03:52 -0400, Jabba Laci wrote: Do you know how to get back F10 in Unity? I haven't found it yet. Yes, that's a PITA, affect yourself with this bug to increase the heat: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/750700 -- Sincerely yours, Yury V. Zaytsev Hi, While I fully agree that they should not do that, let me mention that I faced the same problem a couple of years ago when I installed MC on a Mac OS-10 system. The Mac already has F10 mapped to something like minimize window or such. Also, for that matter, F9 already has a specific meaning. In such situations it is possible to do some kind of re-mapping. Try to figure out which of Cntl-F10, Alt-F10, Shift-F10 or whatever do not already have a designated meaning, and re-map the exit function to one of those. How I did that at the moment escapes me, but it was not that difficult, actually. This is certainly not an ideal solution, but it can alleviate an annoyance, at least to some extent. Also, while one could hardly expect OS-10 to accommodate the key conventions of MC, I do emphatically agree that a Linux distribution really ought to. MC has a long and widespread usage pattern on Linux, and distros ought simply to understand that there are going to be lots of people who continue to want to use it no matter what kind of fancy new desktop designs that they want to introduce. Hoping that the above suggestions might help a little bit, Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Unity redefines F10
On Sat, 30 Apr 2011, William Kimber wrote: On Saturday 30 April 2011 04:32:42 Theodore Kilgore wrote: On Fri, 29 Apr 2011, Yury V. Zaytsev wrote: Hi! On Fri, 2011-04-29 at 03:52 -0400, Jabba Laci wrote: Do you know how to get back F10 in Unity? I haven't found it yet. Yes, that's a PITA, affect yourself with this bug to increase the heat: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/750700 -- Sincerely yours, Yury V. Zaytsev Hi, While I fully agree that they should not do that, let me mention that I faced the same problem a couple of years ago when I installed MC on a Mac OS-10 system. The Mac already has F10 mapped to something like minimize window or such. Also, for that matter, F9 already has a specific meaning. In such situations it is possible to do some kind of re-mapping. Try to figure out which of Cntl-F10, Alt-F10, Shift-F10 or whatever do not already have a designated meaning, and re-map the exit function to one of those. How I did that at the moment escapes me, but it was not that difficult, actually. This is certainly not an ideal solution, but it can alleviate an annoyance, at least to some extent. Also, while one could hardly expect OS-10 to accommodate the key conventions of MC, I do emphatically agree that a Linux distribution really ought to. MC has a long and widespread usage pattern on Linux, and distros ought simply to understand that there are going to be lots of people who continue to want to use it no matter what kind of fancy new desktop designs that they want to introduce. One of the reasons the don't bother about keeping the mc keys is that they do not put mc in the distro. Why I have no idea as it is the first thing I have to add. Well, AFAIR the same could be said about several distros, starting with Debian (which might account for mc being missing in the default Ubuntu install) and, I think, Red Hat as well. Why? I have no idea, either. But if you do get into a jam about this on some new system and cannot otherwise get out, then as I rememember it is is indeed possible to re-map the F10 key's functionality to something else which is close enough to avoid acute discomfort. I forget now exactly how I did it, though. I think it had something to do with MC setup functions but at this point I cannot be sure. As my students in calculus courses say about things like basic trigonometry, Sir, it has been a long time since I studied that. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mc from minicom
On Sun, 28 Nov 2010, Thomas Dickey wrote:
On Mon, 29 Nov 2010, Eric Gillespie wrote:
On 29 November 2010 07:53, Thomas Dickey dic...@his.com wrote:
On Sun, 28 Nov 2010, Kevin Wilson wrote:
Hi,
I am trying to use mc on a machine to which I am connected via minicom
(serial connection).
MC opens ok, but the keys are not functioning well.
minicom acts as a terminal emulator - sort of like a vt100, with color
(and odd line-drawing). That probably means it doesn't have function
keys - vt100's don't have home/end, etc.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
...
If you can, try this: export TERM=vt220; then start mc. That probably has
support for more keys. I'm not entirely sure of that.
well... looking at the source for version 2.4, in src/wkeys.c it does
have some limited ability to match keys from the terminal description.
But it's limited. Here are the (termcap) names it looks for:
static const char *func_key[] = {
, k1, k2, k3, k4, k5, k6, k7, k8, k9, k0,
kh, kP, ku, kl, kr, kd, kH, kN, kI, kD,
F1, F2, NULL };
That is (more/less) function-keys 1-10, cursor-keys and the editing-keypad.
The names would be documented in terminfo(5).
But it's limited: it doesn't really know about application-mode.
(minicom was originally designed to just use the Linux terminal description,
modify it a little to make it act like a vt100, and has probably a number of
assumptions about that, still embedded in the code).
Hi,
There are a couple of old tricks which might or might not help, given the
circumstances. Understand, these are not guaranteed.
1. Esc followed by a number (from the regular keys at the top of the
QWERTY keyboard) can often be used to substitute for the corresponding Fn
key, at least for F1 through F10, with Esc 0 giving F10. This is an old
trick indeed, which was intended to work in situations where the keyboard
does not even have any function keys on it or where some of the function
keys already have different meanings reserved.
2. The Learn keys setup option might possibly also be helpful.
Theodore Kilgore
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc
Re: mc editor shows
On Sat, 30 Oct 2010, Yury V. Zaytsev wrote: Hi! Maybe you should start by reading the manual... Editor - Options - General... [ ] Visible tabs -- Sincerely yours, Yury V. Zaytsev Hi, Yuri. I guess I am not up to speed, either. After writing my previous post 5 minutes ago, I found this one. So, OK. I read the man page for mcedit and I find these things are indeed discussed there. But, alas. Where exactly is the place in the menu where one can toggle these changes, and how can one get there? Specifically, I can not find the way to such a thing as Editor - Options - General... [ ] Visible tabs from within the editor itself (which would be really nice to have, by the way, because then one could toggle this while editing a file). I also can not seem to find it using F9 and going through the list on the top bar. I see Left and File and Options and Right and under none of these am I able to find an item labelled Editor. This leaves me feeling a bit frustrated, as well as, possibly, foolish... Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Irritations and frustrations with improved(?) search functionality
On Mon, 26 Apr 2010, Yury V. Zaytsev wrote: Hi! On Sun, 2010-04-25 at 20:17 -0500, Theodore Kilgore wrote: Catch 22. I am supposed to give a complete description of a problem, and then the message is too long. I think you know very well what I am talking about. It's just the question WHO makes the effort. Either you express your thoughts in a condensed form, e.g.: Subject line summarizing each individual annoyance 4.6.x behavior: XXX 4.7.x behavior: YYY Motivations for keeping consistency with the old behavior. Alternative / compromise suggestions. OR I will have to do it for you and subsequently file a Trac ticket, so that other people can digest it, triage the report and fix the bug. The point is that this is certainly much easier for you, being a native English speaker to make this effort. Also it will leave me with more time to maybe actually come up with a fix or push these changes in the development team. As you might imagine I'm neither working full time on supporting mc nor getting paid for it, so it's crucial to optimize the efficiency of the time I spend triaging bugs. It's not all about the length per se, it's all about the entropy and the information transfer function. Why? It appears to me it just gets in the way. Perhaps you need more than one content field? Because of the technical issues. Before there were three different search engines with their own set of features and their own bugs. Now we have just one, but as a side-effect the history of all three is shared even if it should not be the case. 2. Search for file by name only is a useful and time-honored feature. It was not broken and did not need fixing. 3. Search for file by name, or search for content, or the two combined together, may also be a useful feature to somebody. But it should be separately enabled from item 2, so that people who just want to search for a file can live in peace. How about a specific Find file with content option? See my last comment to this bug with the historical analysis of this situation and three suggestions which would probably satisfy both of us and hopefully the other developers. 1. The two different kinds of searches are different kinds of searches. They should not share the same buffer or history and thus mix things together. It turns out, that / and F7 functions in 4.6.x were documented, different and didn't share buffers for a reason. In fact, F7 was normal search, while / was explicitly a RegExp search. Note that this made it possible for the two search functions to be used independently of each other. Now that the search engine is the same for everybody you can do RegExp searches from F7. I am in favor of submitting a Trac ticket to ask to 1) Make / call a RegExp search by default, no matter what was the previous choice 2) Make separate buffer for /, but keep the history unified. This leaves us with the question on which buffer should Shift+F7 use and how to justify efforts to re-implement 2) as apparently you were the only person using it. Please take seriously my comments about that and try to think of situations where you might wish for the same kind of functionality. I suspect it would not be difficult to imagine that If only I could do this and if you stop and think about it, there is probably not any other easy way which is readily available. At least, I do not know of such. I ask you and the rest of the team please to think about this issue again. [...] Have you never wanted to look through a file full of C code or assembler for more than one thing at once? Something like, search for foo, then bar, then foo then bar ... If you have never wanted to do that, can you see why someone else might want to? The problem here is that the old code was maintained by the old developers it wouldn't be an issue. But what happened in fact is that they have left the code to rot for some five years until it became completely unmaintainable and now for every small change we need a huge rewrite instead of a small incremental patch. There's a huge amount of code duplication, copy and paste bugs and so on and so forth. And it is not possible to extend this code or even make it work with newer software stack unless you re-write some parts of it, e.g. replace three different search engines with one. What happens is that these rewrites introduce bugs, which is inevitable, but this is the only way to move forward, because if you don't move forward you don't stay were you are, but fall behind. Thank you for this description. I was not fully aware how bad the situation is. I have certainly done enough coding of my own to be aware of what can happen, and you have my sympathy. You would also have my help, except that we all must specialize to some extent. Sorry that I can not do more than I can do, actually. The consensus has been reached
Re: Irritations and frustrations with improved(?) search functionality
On Sun, 25 Apr 2010, Yury V. Zaytsev wrote: On Sun, 2010-04-25 at 21:46 +0200, Yury V. Zaytsev wrote: Assuming that you are talking about viewer, its forward search does wrap, but displays a dialog (Search done, continue from the beginning?) beforehand. Backwards search does not wrap, which might be considered as a bug. Open a ticket for that. http://www.midnight-commander.org/ticket/1917 http://www.midnight-commander.org/ticket/2091 Yuri, As I said, the problem is that forward search does not display the dialog which you say is supposed to pop up. It just wraps without any warning at all. This may be fixed in a more recent version than I am using, of course. As to wrapping the backward search, well, as I said in my other message, I do not think that is so terribly important. I would much rather have things fixed which I used to use and they quit working. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Bug in internal viewer in mc 4.7.1
On Wed, 10 Mar 2010, Joe(theWordy)Philbrook wrote: It would appear that on Mar 9, Theodore Kilgore did say: On Sat, 6 Mar 2010, Reynir Stefansson wrote: Indeed. For that matter, why would I want to continue a search after finding one or more occurrences of the search string, and then have it automatically loop back to the top of the file and find the first occurrence a second time? I would find it more logical, understandable, and actually useful if search would start at the top of the file, progress downward as the search for the same string is repeated, and quit when it reaches the bottom of the file. It appears to me from several recent uses that it is in fact looping around to the top of the file, which is a bit strange. I Lets see if I understand you Theodore; At the moment I'm logged into my Elive distro which still has mc 4.6.2-pre1, so I can't check how much of this behavior has changed... In 4.6.2-pre1, doing a search from the internal file viewer always seems to start at the top of the document. Which is one of the reasons I usually use less instead of the internal viewer... But since it would only make sense for mc 4.7.1 to ask this at all if it now starts the search from something like the top of the current screenful of the displayed file??? And thus the complaint was merely that it doesn't notice when the said first displayed line was in fact also the very first line in the file, and that mc should in that case, remember not to ask? In which case it seems like a small thing to me... Or do you mean that even if you were half way through viewing a large file and noticed that some interesting phrase or word that appeared a gazillion times in the first half of the file hasn't been mentioned for several screen fulls And want to know if it occurs AGAIN. You would find it more useful to HAVE to search from the top, and try to keep track of when you run out of matching expressions from parts of the file you've already looked at??? Yes, it is this one. The problem I noticed is that search automatically _wraps_ back to the top of the file and therefore recovers (again) the first item in the file which would come up with the particular search. While some might find that really clever, it is clearly not always so very, very clever. I suspect that everyone reading this can imagine circumstances in which one might not want that to happen. It might be greatly preferable to know that one has found the last occurrence of the searched item, and that there are no more to be found from that point on to the bottom of the file. If the search functionality has to be locked in to just one of these, I would greatly prefer the second alternative, myself, and a window popping up with String not found or whatever, and then, if it is intensely desired by someone, Repeat this search from the beginning of the file? could be in that window, too, with an appropriate box to tick. One could even put under Repeat this search from the beginning of the file? another choice, saying, Always do this? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 10 Mar 2010, Yury V. Zaytsev wrote: On Wed, 2010-03-10 at 10:34 -0700, Ben wrote: Is there truly no way to search for ^M or other embedded control characters? ^M are not the embedded control characters. It's just the way mcedit represents \r's (carriage return character). So if you run dos2unix on the file or search and replace \r's (ASCII 13) with it should do the trick. I guess there've been numerous requests to add an option to not show \r's in the editor, however I don't remember whether they made their way to the Trac or not. Your best bet would be to search the Trac and 1) If such a ticket exists, vote for it 2) If it does not, then create it. OK, here is a vote. If those things are in the file, I prefer to see them, thanks. There are occasions when those DOS control characters can really get in the way, and to have a situation where the problem is hidden so that nobody can see exactly what the problem is makes the problem even worse. For example, sometimes one gets some C code from some other place, and somewhere along the way those ^M characters have been stuck on every line, when it is not good at all to have them lurking there. In such situations, the extra control characters are then removable by running the file through dos2unix, for example, and one had better do that. At the same time, I can see that someone else has a different problem and needs not to see them. I can understand his problem, and I sympathize. But please do not try to solve his problem by screwing things up for others. Try to think of another way around his problem, instead. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 10 Mar 2010, Yury V. Zaytsev wrote: On Wed, 2010-03-10 at 16:21 -0600, Theodore Kilgore wrote: At the same time, I can see that someone else has a different problem and needs not to see them. I can understand his problem, and I sympathize. But please do not try to solve his problem by screwing things up for others. Try to think of another way around his problem, instead. I didn't suggest to screw things up for anyone. There've been some discussions on adding an option which would be disabled by default to not to show them, but I don't remember whether they made it to the Trac or not... Ah. Yes, if an option were available which can work that way, it would take care of the problem. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Bug in internal viewer in mc 4.7.1
On Sat, 6 Mar 2010, Reynir Stefansson wrote: If I start a search *at* the beginning of a file and it proves futile, why would I want to search again *from* the beginning? Indeed. For that matter, why would I want to continue a search after finding one or more occurrences of the search string, and then have it automatically loop back to the top of the file and find the first occurrence a second time? I would find it more logical, understandable, and actually useful if search would start at the top of the file, progress downward as the search for the same string is repeated, and quit when it reaches the bottom of the file. It appears to me from several recent uses that it is in fact looping around to the top of the file, which is a bit strange. I am aware that some other search functionality acts this way, for example in Firefox it does loop around. But Midnight Commander is not Firefox and is not used for the same purposes. BTW, whoever fixed the bug about persistence of a search from one file to another does get my thanks! The latest version of MC that I got now will keep the same search instead of forcing one to re-type it every time. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Sync file on write?
On Sun, 27 Dec 2009, Paul Hartman wrote: Hi, I have a USB device and write speed is terrible when I copy more than 1 file to it (it is mounted in async mode). If I copy just one file and sync, speed is 17MB/sec, if I copy more than 1 file the speed drops well below 2MB/sec. This does not happen on MS Windows so I think it's some side-effect of linux i/o flushing creating multiple write-streams or something like this. Anyway, I'm trying to work-around this and wonder if there is a way I can tell MC to sync/fsync (whatever means ensure file is written to disk physically) after each file? If it would apply only to writes into this device that would be even better :) thanks paul Paul, I have no idea of the cause of this. I am not a specialist in Midnight Commander to any extent whatsoever. I do know a bit more about USB, but I have never delved very much into questions of speed. Keeping the above disclaimers in mind, it does appear to me that there is a simple test which might help to localize the problem. Can you set up a situation in which the slowdown occurs in Midnight Commander, but it is possible to move the same files from the same source location to the same destination using command-line tools only? And run a time comparison under both circumstances? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Sync file on write?
On Sun, 27 Dec 2009, Paul Hartman wrote: On Sun, Dec 27, 2009 at 4:30 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Sun, 27 Dec 2009, Paul Hartman wrote: Hi, I have a USB device and write speed is terrible when I copy more than 1 file to it (it is mounted in async mode). If I copy just one file and sync, speed is 17MB/sec, if I copy more than 1 file the speed drops well below 2MB/sec. This does not happen on MS Windows so I think it's some side-effect of linux i/o flushing creating multiple write-streams or something like this. Anyway, I'm trying to work-around this and wonder if there is a way I can tell MC to sync/fsync (whatever means ensure file is written to disk physically) after each file? If it would apply only to writes into this device that would be even better :) thanks paul Paul, I have no idea of the cause of this. I am not a specialist in Midnight Commander to any extent whatsoever. I do know a bit more about USB, but I have never delved very much into questions of speed. Keeping the above disclaimers in mind, it does appear to me that there is a simple test which might help to localize the problem. Can you set up a situation in which the slowdown occurs in Midnight Commander, but it is possible to move the same files from the same source location to the same destination using command-line tools only? And run a time comparison under both circumstances? Theodore Kilgore Hi, Sorry if I wasn't clear, the problem isn't caused by MC and I don't think MC has anything to do with it, but it is simply my tool of choice for everyday working. It happens if I use cp from command-line or copy files from within MC or using GUI tools. In other words, this is slow: cp file1 file2 file3 /mnt/usb; sync this is fast: cp file1 /mnt/usb; sync cp file2 /mnt/usb; sync cp file3 /mnt/usb; sync So that's why I was curious if there's any kind of after file command or option to make it sync to disk after every file. Interesting. So, what you are saying is, it is possible to change things on the command line so that it works fast. But if one uses the obvious construction of the command there is a slowdown. So if there is a problem with using Midnight Commander the problem is that, underneath, MC is using the usual tools in the usual and obvious way instead of clevering itself around the problem. Which I would tend to agree is not a shortcoming of Midnight Commander, per se. It is after all one of the things that I use, too, as a tool of choice for everyday working, or else one would not find me subscribed to this list! Quite seriously, why don't you bring this question to the attention of the people on this list over here: usb-stor...@lists.one-eyed-alien.net I think some of them might find that your experience raises an interesting question or two. Me, I also wonder exactly what is behind the problem. Come to think of it, though, what happens if you are not copying to or from a USB flash drive? Do similar things also occur if you are copying between two internal hard disks, or from one place on the disk to another? If that is the case, then this is not a USB storage problem after all, is it? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: How to change the defaults for file highlighting?
On Sun, 29 Nov 2009, Yury V. Zaytsev wrote: On Sun, 2009-11-29 at 12:35 -0600, Theodore Kilgore wrote: So from what I understand you have now made this more permanent by providing a tie-in to the ini file? If so, then that's great. We can all be happy. Yes, from now on you should be able to specify a default of your liking in the ini-file. Yuri, Thanks. Now if someone can specify exactly which code version this is and exactly where to get it? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: How to change the defaults for file highlighting? (fwd)
Oops. I didn't reply to the list. Fixed, now. -- Forwarded message -- Date: Sun, 29 Nov 2009 22:44:02 +0100 From: Yury V. Zaytsev y...@shurup.com To: Theodore Kilgore kilg...@banach.math.auburn.edu Subject: Re: How to change the defaults for file highlighting? On Sun, 2009-11-29 at 15:52 -0600, Theodore Kilgore wrote: Sorry, that is not exactly what I meant. I meant where do I get it? Which version, precisely? An rc version? The main development tree? OK with me whichever one it is. Just point me in the right direction. I guess it should be in -pre4 tarball already, but, of course, in latest master git branch as well. The thing is, we all have to specialize. I am more or less a consumer of what you are producing, though, I hope, a somewnat informed one. I am no better informed than you, I'm not a coder, but rather a packager. I've just searched the trac, git and the source code to gather this information for you. -- Sincerely yours, Yury V. Zaytsev ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: How to change the defaults for file highlighting?
On Sun, 29 Nov 2009, Yury V. Zaytsev wrote:
On Sun, 2009-11-29 at 13:39 -0600, Theodore Kilgore wrote:
Thanks. Now if someone can specify exactly which code version this is and
exactly where to get it?
[Midnight-Commander]
select_flags = ...
/* selection flags */
typedef enum {
SELECT_FILES_ONLY = 1 0,
SELECT_MATCH_CASE = 1 1,
SELECT_SHELL_PATTERNS = 1 2
} select_flags_t;
I guess I am not out of the woods, yet. Two things:
1. I updated the git tree, re-compiled, and re-installed. No problem about
that. But then I looked in my ini file, and I see no such option as
select_flags =
The only thing which comes up when searching the file for select is
editor_persistent_selections=1
which would seem quite irrelevant.
OK, so I thought perhaps extreme measures ought to be tried. I downloaded
a clean copy of the git tree, and I did make uninstall on the old one and
did make install on the new one. Then, on trying to make it work, I got an
error message, that /usr/libexec/mc/mc-wrapper.sh can not be found. So
apparently there is some funny business with the installer not putting a
crucial file where it is supposed to be.
Fortunately, I have a Slackware tarball of an older version which works,
so I am not left entirely without one of my favorite programs.
In any event, I could never find out how to enable the specific feature we
have been discussing. Finding the lines in the code which you quoted
earlier were not a big help in that regard.
Thus, not much progress, I am sorry to say.
Theodore Kilgore
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc
How to change the defaults for file highlighting?
Until very recently in the history of MC, file highlighting with Keypad-Plus highlighted only files. Now this behavior has been changed. A dialog box comes up which has a couple of useful features and one feature which from my perspective is both useless and irritating, especially since I became used to the opposite behavior for the previous ten years of constant desktop use of MC. This one [ ] Files only Since it has been decided that a dialog for this feature has to be there, is there any configuration option by which one can change the default choice to be [x] Files only instead of [ ] Files only ? If there is such an option, I have not succeeded in finding it. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mc 4.7.0pre3 support for .tlz archives
(follow-up) On Wed, 28 Oct 2009, Theodore Kilgore wrote: On Wed, 28 Oct 2009, Helmut Hullen wrote: Hallo, Theodore, Du meintest am 27.10.09 zum Thema Re: mc 4.7.0pre3 support for .tlz archives: Does anyone happen to know if similar procedures will open a Slackware .txz file or not? Slackware 13's mc works fine with .txz packages. I am running Slackware-current right now, as I said. And the mc package which is installed is mc-20090714_git-i486-1.txz, dated July 14. It will _not_ open a txz file out of the box. So, are you saying it can be thus configured in the extension file? Strange. Does installpkg work with *.txz packages (it should, of course). Viele Gruesse! Helmut Of course it does. But the question from here is about how to set up MC to do the kinds of things with .txz files which it can do with .tgz files. These include at least the following: 1. F3 shows the directory structure inside the tarball. 2. Enter opens up the filesystem of the tarball, and such things can be done as to view what is in them, to copy individual files or subdirectories out of the tarball, and such. 3. F2 followed by x will extract the contents and so on. As I said, these things may very well be possible to set up. But none of them currently work. Theodore Kilgore Helmut, Thanks, I found the problem. The difficulty is that one's own local mc.ext file (which my $HOME/.mc directory contains under the name bindings) is not overwritten when one does an upgrade, but instead is kept. That one's own local bindings file is kept around is perhaps a good thing. But it is not an unmixed blessing. The results are bad if support for some new file format such as .txz gets missed. OTOH, the results of keeping the bindings file intact are good if one has had to edit the file in order to replace applications which are not on one's machine with applications which are present and do the same functionality. For example, I have to replace gqview with something else in order to view images and to do various other workarounds, too. I would hate for my workarounds and customizations to get blown away every time I upgrade Midnight Commander, because I depend on them. So, thanks for pointing out that the support for .txz and such is already generally available. I guess what this points up is the need for more up-to-date and readily accessible documentation. But that is a problem that we all have to deal with, who produce software. I guess I have no answers. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mc 4.7.0pre3 support for .tlz archives
On Wed, 28 Oct 2009, Helmut Hullen wrote: Hallo, Theodore, Du meintest am 27.10.09 zum Thema Re: mc 4.7.0pre3 support for .tlz archives: Does anyone happen to know if similar procedures will open a Slackware .txz file or not? Slackware 13's mc works fine with .txz packages. I am running Slackware-current right now, as I said. And the mc package which is installed is mc-20090714_git-i486-1.txz, dated July 14. It will _not_ open a txz file out of the box. So, are you saying it can be thus configured in the extension file? Strange. Does installpkg work with *.txz packages (it should, of course). Viele Gruesse! Helmut Of course it does. But the question from here is about how to set up MC to do the kinds of things with .txz files which it can do with .tgz files. These include at least the following: 1. F3 shows the directory structure inside the tarball. 2. Enter opens up the filesystem of the tarball, and such things can be done as to view what is in them, to copy individual files or subdirectories out of the tarball, and such. 3. F2 followed by x will extract the contents and so on. As I said, these things may very well be possible to set up. But none of them currently work. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mc 4.7.0pre3 support for .tlz archives
On Tue, 27 Oct 2009, /dev/rob0 wrote: On Tuesday 27 October 2009 15:16:57 Theodore Kilgore wrote: Does anyone happen to know if similar procedures will open a Slackware .txz file or not? Slackware 13's mc works fine with .txz packages. Sorry, this is on my list of things to look into, but I am also rather busy trying to hold my end up over here and I simply have not had time to do much in that direction. I found it rather simple to upgrade everything on a 12.2 system using the 13.0 Slackbuild scripts. pkgtools itself can be upgradepkg'ed on older systems, but you also need xz. Oh, now that I think of it, I recall that I just installpkg'ed the slackware64 xz package on my slamd64-12.2 system. I didn't try that with mc; right now I just ssh to a 13.0 host if I want to look inside any txz/tlz packages. :) -- I am running Slackware-current right now, as I said. And the mc package which is installed is mc-20090714_git-i486-1.txz, dated July 14. It will _not_ open a txz file out of the box. So, are you saying it can be thus configured in the extension file? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mc 4.7.0pre3 support for .tlz archives
On Tue, 27 Oct 2009, Helmut Hullen wrote:
Hallo, Theodore,
Du meintest am 27.10.09 zum Thema Re: mc 4.7.0pre3 support for .tlz archives:
After a bit of a hunt, I found this in /etc/mc/mc.ext
# .tar.lzma, .tlz
regex/\.t(ar\.lzma|lz)$
Open=%cd %p#utar
View=%view{ascii} lzma -dc %f 2/dev/null | tar tvvf -
Does anyone happen to know if similar procedures will open a
Slackware ..txz file or not?
mc-20090714_git_i486-1.txz
(Slackware-current, ap)
works fine with *.txz packages.
OK, that's nice. How to implement such a pleasant feature? Because as a
matter of fact it does not work over here.
Theodore Kilgore
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc
Re: Mc Digest, Vol 63, Issue 1
On Sun, 5 Jul 2009, chris glur wrote: -- The F4 (search and replace) routine is not working as it used to do. ... snip.. ( ) proMpt on replace ( ) replace All - Yes I've only started to use that lately. It can be a very handy thing. For my version the 2 toggles [via mouse] are independant, although the concepts are not: if all are to be replaced, you can't be prompted ? Exactly. Why *can't* you be prompted if you want to be? Suppose you know you have 20 to 30 specimens of what you want to search/replace in a piece of code. Suppose you know that somewhere in the middle of that code if you do the particular replacement blindly, it will cause problems. All one wants to do is to be able to look at the occurrences one at a time and decide on each occasion. It seems that functionality is gone now. - Search is not preserved during one mc session from one file to the next (this also is the case if you opened the files with F4 (edit) as well as with F3 (view)). --- Is a 'session' from boot to logout ? No, one VT or one xterm, say. I mean, log in or open the xterm, start mc inside of it. That is what I mean by one session. I would assume that if one closes mc and opens it again then any such settings as what to search for would be gone bye-bye? How many mc's would you have running, for a session of 3 days and 3+ 3+ 3 = 9 hours ? Eek. I usually do not run the computer for three days, except for my office machine which is a server. And I do not walk off from that one and leave myself logged in. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Problems with search functionality.
I wrote the message below a couple of weeks ago and did not get around to sending it. Since it is still relevant, I send it along with some other issues. - The F4 (search and replace) routine is not working as it used to do. One was (and still one is) presented with a dialog menu which asks various things you want to do. Two of these were (and still are) ( ) proMpt on replace ( ) replace All When running previous versions, I used to be able to tick *both* of these choices. Now I can choose only one of them. Any attempt to choose both toggles off the one selected first in order to enable the second. :-( If this has already been noticed and fixed and I should get a more up-to-date version, then please let me know. Theodore Kilgore --- For some reason, I did not get around to sending this back when I wrote it. The problems related to the git version distributed in Slackware-current as mc-20090514_git-i486-1 and seem to have been perpetuated in the currently-distributed mc-20090621_git-i486-1 package. I also have my own git tree for mc. Upon update and recompilation and reinstallation yesterday evening, it showed the same symptoms. In addition to what is described above about the behavior of F4 search-and-replace functionality while editing with the internal editor, there are problems with search while viewing a file with option F3. The problems about searching include: Search is not preserved during one mc session from one file to the next (this also is the case if you opened the files with F4 (edit) as well as with F3 (view)). If you want to search for the same thing in several files, you need to enter the searched-for each time, by hand, in the search window every time that you open another file. That is, when you closed the first file, you lost any record of what you were searching for in it, so when you open the second file and want to search in it for the same thing you need to re-type what you are searching for. This forgetfulness used not to happen, and it is therefore an unaccustomed behavior and an irritating inconvenience. If this was accidental, then I hope it is repaired. If the change was deliberate, then might I ask why it was done? Also, to my great amazement and total surprise, I noticed something else which appears to me to be a new and retrograde behavior. I think that one can easily imagine wanting to search the same file for two different things. That is why it is so nice to be able to use F3 (view) and then F7 to search for, say, foo and then to use / to search for bar. What did I find now? That if I tell F4 to search for foo then / is also searching for foo and if I open / and ask to search for bar then F4 will no longer search for foo the next time I open it, but now F4 is also searching for bar! In other words, F4 search and / search no longer are separate but now are linked together. I hope very much that this is unintended behavior, because it appears to me to be a bug which impairs the functionality of an old, heavily used, and well loved product. Is there any reason for these problems, based in some radical revision of design philosopy, or are these items merely bugs as I hope they are? During several attempts to remove and reinstall various versions, another problem was unearthed. This one relates to the functioning or non-functioning of the option mc -P (exit from Midnight Commander in $PWD). There is a script file which needs to be activated. The documentation (for example, the man page) says -P file, --printwd=file Print the last working directory to the specified file. This option is not meant to be used directly. Instead, it's used from a special shell script that automatically changes the cur- rent directory of the shell to the last directory the Midnight Commander was in. Source the file /usr/share/mc/bin/mc.sh (bash and zsh users) or /usr/share/mc/bin/mc.csh (tcsh users) respec- tively to define mc as an alias to the appropriate shell script. The problem? There is no longer any such file as /usr/share/mc/bin/mc.* Indeed, there is not any directory /usr/share/mc/bin. After some searching around, I found the file. It is now in /usr/libexec/mc. Since this change is not documented, it is a bit confusing. Also, for the first time in years I had to add a line in my .profile file which turns on the ability of mc to be exited in $PWD instead of going back to some other place on exit. Is this feature supposed to continue to exist without such intervention? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Mc Digest, Vol 62, Issue 3
On Sun, 14 Jun 2009, chris glur wrote: Search 'hot-list' ..yes... Theodore Kilgore was describing: view/F3 anf edit/F4 both have have search file facilities, which have mutually diferent behavious. And seem inconsisitent ? Actually, Chris, I was not complaining about the fact that different keys can be used for doing searches, depending on whether one is Viewing or Editing. In any event, the use of those keys is at this point ancient, time-honored, and hallowed by tradition. No problem there. Now, since that was not the problem, here again is a description of the problem: I used to be able to search a file for something, then search another file for the *same string* and I did not need to re-enter the string when I opened the second file and wanted to search it. Now if I open the second file and hit the same search key, then the contents of the search request did not get saved for potential re-use. This is not old behavior. It used not to be thus. It is new behavior, which un-does something which used to be done right. I did make one mistake in describing the MC version, which may have caused confusion: I forgot that I was running the git source, and what was the reason for that. There is no such Slackware package, as far as I know, named mc-20090514_git except for the one which was locally created, right here. And now I am not using it any more, either, but the problems I described are still present. Yesterday I did git pull and re-compiled and re-installed to see if the problem I described just above has been fixed. I am running the most up-to-date Midnight Commander code that it is possible for me to run. The problem described above has not been fixed. What was the reason why I have the git tree over here? Well, I wanted to look into the VirtualFileSystem stuff and see if I could understand it. (No luck with that, unfortunately) Why? Well, because it seems that LZM and LZMA compression are replacing Gzip and Bzip in a lot of applications. Slackware, my favorite distro, has for example quit using tgz (tar and gzip) packages and has switched over to a new package format txz (tar and lzm compress). Boy, it sure would be nice to be able to open one of those just like it is possible to open a gzipped or bz2'ed tarball and look inside at it just like it was an ordinary directory. Boy, with this new package format, I feel all of a sudden blind because I can not open this package format with MC. Also there are several live distros which are using LZMA compression for big pieces of the filesystem, and are decompressing the stuff on the fly upon boot and mounting the pieces in a union file system. Boy, it sure would be nice to be able to open one of those compressed files, just like one can open a tarball, by hitting Enter. Boy, it sure would be nice at least to be able to see the directory structure of one of these things (or of a compressed Slackware package, for that matter) by just hitting F3. Well, I posted about this topic, it seems to me a couple of months ago. I pointed out that I am somewhat inexperienced with the way that the Midnight Commander code is put together, and therefore I might not be considered much of a helper, but I was also willing to put in time and energy to help, if I could. There were no responses to that post. So that is one of the reasons why I got a copy of the git tree. The other reason is that I was trying to figure out how that the --- stuff for tabbing is working in the editor. As I said in the last post to which you are replying, Chris, there are some problems with that. It is a really clever idea, and useful, too, if one is writing code. But something bad is happening with those -- thingies if one is using the mouse to copy code from one window to another. Namely, they are supposed to be a reflection of invisible characters, but when the mouse is thus used they literally become visible characters which are part of what is copied. Examples are given below. Theodore Kilgore do sub-tasks once only, and then just 'recall' them == Chris Glur. On 6/12/09, mc-requ...@gnome.org mc-requ...@gnome.org wrote: Send Mc mailing list submissions to mc@gnome.org To subscribe or unsubscribe via the World Wide Web, visit http://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. two questions about Slackware's mc-20090514_git (Theodore Kilgore) -- Message: 1 Date: Thu, 11 Jun 2009 21:25:21 -0500 (CDT) From: Theodore Kilgore kilg...@banach.math.auburn.edu Subject: two questions about Slackware's mc-20090514_git To: mc@gnome.org Message-ID
two questions about Slackware's mc-20090514_git
First one: There is some behavior about searching, to which I am not accustomed. Namely, when one uses F3 to view then / or F7 allows one to search. That is, of course, as usual. If one is editing a file with F4, then again F7 is used for doing a search. That is, of course, also as usual. But what seems to me to be new is that if I do a search, then close the file, and want to open either it or another file in the same directory and do another search for the same thing, now the contents to be searched for are gone and need to be re-entered in the search window. I could just swear that the content of the search used to be persistent, and now it is volatile. Now, even if one is opening the same file again, that which was being searched for has disappeared. I think it was much more convenient the other way. Second one: Again we have the feature in the editor that tabs are marked thus: --err_code = reg_w(gspca_dev, 11); --if (err_code 0) return err_code; This is not a bad thing if one is doing some kernel coding and has to obey the rules. It certainly does distinguish tabs from spaces. But look what it did when I used the mouse to copy it over here! Since some kind of meta-characters are used, why exactly do they have to be seen and copied thus by the mouse? Even worse, when I create a new file called codesample.txt and use the mouse to copy over the same three lines, now I literally have the arrow characters in the file, not tabs. But of course they are supposed to be tabs, not arrow characters. So it was OK to move the snippet of code over, but now every line has to be edited by hand. Ouch. Well, one might think that I was stupid and what I really ought to do is to use F3 instead of having opened it with F4. But if I do that then at the beginning of each line I have spaces instead of tabs. So, as far as having to edit each line after copying, the result is equally unpleasant. Interestingly, if I use less to open the file to be copied from, and copy into a file which was opened by mcedit, then, upon checking, it appears the tabs do get preserved. But no arrow symbols appear even though the tabbing has survived the mouse-copy operation. Weird. Also inconsistent. Therefore, the question boils down to the following: Is it somehow possible to mark tabs (that is nice for coding, obviously) but when one copies using the mouse from one file to another, the tabs are preserved, and appropriate marking for them is used or introduced, but the marking for them (if it was already present) is not transformed into actual characters, which then need to be manually removed from the copied text? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
for the wish list: support for reading LZM and LZMA compressed formats
Specifically: Slax and perhaps some other live distros are using LZM-compressed files along with squashfs, and are mounting them as loop devices during the boot process. It would be really nice to be able to read the contents through MC. Also, it seems that Slackware (in slackware-current) has just made a move from the old, time-honored tgz format to a new format which is called txz and the ChangeLog says: Fri May 8 18:49:03 CDT 2009 Hello folks! This batch of updates includes the newly released KDE 4.2.3, but more noticeably it marks the first departure from the use of gzip for compressing Slackware packages. Instead, we will be using xz, based on the LZMA compression algorithm. xz offers better compression than even bzip2, but still offers good extraction performance (about 3 times better than bzip2 and not much slower than gzip in our testing). Since support for bzip2 has long been requested, support for bzip2 and the original lzma format has also been added (why not?), but this is purely in the interest of completeness -- we think most people will probably want to use either the original .tgz or the new .txz compression wrappers. The actual Slackware package format (which consists of the layout within the package envelope) has not changed, but this is the first support within Slackware's package tools for using alternate compression algorithms. --- I would be glad to help, to the best of my ability. However, I have tried to look into the existing code for things like tar.gz support and I can not quite grasp how it has been done. Too much C for doing hardware support and not enough C++ for doing application stuff is no doubt the problem on my part. Thus, I could in practical terms probably not be of much use in the project. If anyone knows more about how to do this kind of thing and thinks I can help anyway, please let me know. I really would like to see it get done. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: annoyances which seem to arise from Unicode
On Sun, 19 Apr 2009, Russell Shaw wrote: Theodore Kilgore wrote: I wrote in some time ago about the problem of some key bindings not working properly in an xterm. Namely, the Cntrl and Alt key behavior changes from what it is in the terminal. The Alt key bindings for MC cease to work and instead are used to print funny characters on the command line, and one has to use Cntrl instead of Alt. Thus, as one example, Alt-s for search down the directory listing now prints a Hungarian long o (single stroke on top of the o) and one has to use Cntrl-s instead. Alt-o for other panel now prints some other funny character. Cntrl-o has the behavior which ought to be done by Alt-o, and the normal behavior of Cntrl-o (send MC into the background) is inoperative. There are partial cures for this, of course. It is possible to create a file called .Xdefaults and put into that file the single line XTerm*metaSendsEscape: true and the problem is cured, in part. By in part I mean exactly that an ordinary user now can use MC in a normal manner in the xterm. There are however two difficulties which remain, and perhaps someone knows a way to overcome them: 1. If one is doing any real business, such as running a compiler to install something, then one has to do something like open a window and run su and become root in that window. After one has done this, the .Xresources entry becomes inoperative in that window, and the described uncooperative behavior takes over again. 1 a. One might think that, well, root also should have a copy of the .Xdefaults file. So to anticipate this suggestion let me point out right now that it does not help. To be sure, it will help if one starts X as root, but not if one has started X as a user and then has opened an xterm and switched over to be root in that xterm. In this event, the root user's copy of the .Xdefaults file is obviously either not read, or is inoperative. 2. If one has two machines (for example, home and office) and has the same userid on both and if one does something like ssh (other machine), then again the .Xdefaults file is ignored. Again, it does not matter if one has a copy of the .Xdefaults file, with identical contents, on both machines. Clearly, it does not get read when one makes a connection in from the outside, using ssh. Any suggestions? Have you tried ~/.Xresources? In mine (debian) i have: !Make Alt-o send ESC-o in mc, instead of i with daeresis. XTerm*eightBitInput: true XTerm*altSendsEscape: true XTerm*metaSendsEscape: true Well, I believe in the minimalist, incremental approach whenever possible. So I decided to try these things one at a time to see what happens. Indeed, the addition of the one line XTerm*metaSendsEscape: true in $HOME/.Xresources does make the problem to go away, which is associated with using su to log in as root in one of the open xterms. This still leaves one to figure out what to do about the problem when one logs into another machine. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Mc Digest, Vol 60, Issue 7
On Wed, 22 Apr 2009, chris glur wrote: On Sun, 19 Apr 2009 00:49:40 -0500 (CDT) Theodore Kilgore wrote: and switched over to be root in that xterm. In this event, the root user's copy of the .Xdefaults file is obviously either not read, or is inoperative. My /root/.Xdefaults has got:-- ... xterm*scrollKey: on xterm*VT100.Translations: #override\n\ KeyBackSpace: string(0x7F)\n\ KeyDelete: string(\033[3~)\n\ KeyHome: string(\033[1~)\n\ KeyEnd: string(\033[4~) KeyPressPrior : scroll-back(1,page)\n\ KeyPressNext : scroll-forw(1,page) ... So, does that mean that if I can find the 'code' for eg. alt/F12, I can make that a hot key for bash ? Hi, Chris, While I do not know the answer to this with absolute certainty, I suspect that such a thing is possible. If I understand your meaning, you want to bind F12 to do something, whenever you press it? You can do that with the standard keyboard utilities. I used to have F12 configured to turn on midnight commander whenever I hit it. This worked, of course, both in a VT and also in an xterm. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
annoyances which seem to arise from Unicode
I wrote in some time ago about the problem of some key bindings not working properly in an xterm. Namely, the Cntrl and Alt key behavior changes from what it is in the terminal. The Alt key bindings for MC cease to work and instead are used to print funny characters on the command line, and one has to use Cntrl instead of Alt. Thus, as one example, Alt-s for search down the directory listing now prints a Hungarian long o (single stroke on top of the o) and one has to use Cntrl-s instead. Alt-o for other panel now prints some other funny character. Cntrl-o has the behavior which ought to be done by Alt-o, and the normal behavior of Cntrl-o (send MC into the background) is inoperative. There are partial cures for this, of course. It is possible to create a file called .Xdefaults and put into that file the single line XTerm*metaSendsEscape: true and the problem is cured, in part. By in part I mean exactly that an ordinary user now can use MC in a normal manner in the xterm. There are however two difficulties which remain, and perhaps someone knows a way to overcome them: 1. If one is doing any real business, such as running a compiler to install something, then one has to do something like open a window and run su and become root in that window. After one has done this, the .Xresources entry becomes inoperative in that window, and the described uncooperative behavior takes over again. 1 a. One might think that, well, root also should have a copy of the .Xdefaults file. So to anticipate this suggestion let me point out right now that it does not help. To be sure, it will help if one starts X as root, but not if one has started X as a user and then has opened an xterm and switched over to be root in that xterm. In this event, the root user's copy of the .Xdefaults file is obviously either not read, or is inoperative. 2. If one has two machines (for example, home and office) and has the same userid on both and if one does something like ssh (other machine), then again the .Xdefaults file is ignored. Again, it does not matter if one has a copy of the .Xdefaults file, with identical contents, on both machines. Clearly, it does not get read when one makes a connection in from the outside, using ssh. Any suggestions? Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
