Re: Bug in internal viewer in mc 4.7.1
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??? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
I use mcedit constantly, running it on an OS X 10.5.8 terminal to numerous remote redhat 9 linux machines from within mc, and on occasion invoked as mcedit (which I presume, as per the docs, is just mc -e.). On occasion, I run into a file with ^M at the end of a line in MCEDIT. I can delete these one at a time if I position the cursor right on them. I have tried many things to attempt and use the F4 global search and replace, but nothing seems to work in the first field, the search field. I would leave the replace field empty, because I want them gone. Regular expressions - no. ^M, no. The format string replace... I don't even understand HOW you would use that to find a control character. %015, no. \015, no. \r, no. %13, no. %0D, no. 0x0D, no. [^M], no. There's a [^] field at the end of the line, but I can't seem to get to it with tab, and the mouse flat out does nothing in an mcedit pane. I've been to the documentation (hah!) and I've searched using Google. Nothing. I know I can use sed, etc., to do this, but I don't always have execute privileges in the directories I'm working in, because I'm in remotely via SSH in one pane - the filesystem is remote. Could someone take pity on me and tell me how it's supposed to work? Thanks. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
Hello Ben, On Wed, 10 Mar 2010 09:01:36 -0700 Ben 2blkb...@nemontel.net wrote: I use mcedit constantly, running it on an OS X 10.5.8 terminal to numerous remote redhat 9 linux machines from within mc, and on occasion invoked as mcedit (which I presume, as per the docs, is just mc -e.). On occasion, I run into a file with ^M at the end of a line in MCEDIT. I can delete these one at a time if I position the cursor right on them. I have tried many things to attempt and use the F4 global search and replace, but nothing seems to work in the first field, the search field. I would leave the replace field empty, because I want them gone. Regular expressions - no. ^M, no. The format string replace... I don't even understand HOW you would use that to find a control character. %015, no. \015, no. \r, no. %13, no. %0D, no. 0x0D, no. [^M], no. There's a [^] field at the end of the line, but I can't seem to get to it with tab, and the mouse flat out does nothing in an mcedit pane. I've been to the documentation (hah!) and I've searched using Google. Nothing. I know I can use sed, etc., to do this, but I don't always have execute privileges in the directories I'm working in, because I'm in remotely via SSH in one pane - the filesystem is remote. Could someone take pity on me and tell me how it's supposed to work? You can use \n and make sure you check the regular expression widget. At least it works w/ 4.7.1, even if mcedit completely freezes when you choose All in the confirm replace dialog. Regards, -- wwp signature.asc Description: PGP signature ___ 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, 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. -- Sincerely yours, Yury V. Zaytsev ___ 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, 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... -- Sincerely yours, Yury V. Zaytsev ___ 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
Alt+function keys and other keys
Hello, Following the bug I reported ( http://www.midnight-commander.org/ticket/2064 ), I've been trying different terminal emulators and combinations and wasn't able to get these keys (mostly function keys with Alt, Ctrl-Alt, Ctrl-Shift, Alt-Shift, Ctrl-Alt-Shift, also Home/End/PgUp/PgDown disturbances) to work on Midnight Commander. Upon pressing the key, mc will ignore it and print part of the escape sequence. I've been trying with the various terminal modes in Konsole (xterm XFree 4, xterm XFree 3, Linux, VT420PC, VT100, Solaris) with the correct TERM settings (as well as some which were slightly incorrect), as well as xterm with the default options, urxvt (TERM=rxvt-unicode) and some other terminal emulators I could find, with and without the configuration for learnt keys in ~/.mc/ini . I have been unable to get these keys to work in an X terminal. Do they work for any of you in any X terminal with any settings? If so, could you tell me which? I'm using mc from the Debian sid package: GNU Midnight Commander 4.7.0.1 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With internationalization support With multiple codepages support Data types: char 8 int 32 long 64 void * 64 off_t 64 ecs_char 8 Any tips? Thanks in advance. ~Miguel Pérez -- Antes de imprimir este correo electrónico, considera tu responsabilidad medioambiental. Please consider your environmental responsibility before printing this email. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Alt+function keys and other keys
On Wed, 2010-03-10 at 09:35 +0100, Miguel Pérez wrote: Following the bug I reported ( http://www.midnight-commander.org/ticket/2064 ), I've been trying different terminal emulators and combinations and wasn't able to get these keys (mostly function keys with Alt, Ctrl-Alt, Ctrl-Shift, Alt-Shift, Ctrl-Alt-Shift, also Home/End/PgUp/PgDown disturbances) to work on Midnight Commander. Thanks, I'm glad to see someone working on this. I use GNOME terminal on Fedora and I first noticed the problem with F12, when the Ctrl-pgup and Ctrl-pgdn stopped working (it turned out developers had switched that functionality to some other key bindings that don't work on GNOME terminal). The bug reports related to that incident are here: https://bugzilla.redhat.com/show_bug.cgi?id=551062 http://www.midnight-commander.org/ticket/1938 It seems like a good idea to see which terminals are the most commonly used and focus testing on those. My guess is the GNOME terminal and KDE Konsole terminals are at the top of the list since nearly every modern distro runs one of those two desktops. Maybe there needs to be a policy that key combination changes must be tested on mainline terminals before they are accepted in released versions of MC. -Steve ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Alt+function keys and other keys
On Wed, 2010-03-10 at 22:37 +0100, Yury V. Zaytsev wrote: On Wed, 2010-03-10 at 09:55 -0600, R. Steven Rainwater wrote: Maybe there needs to be a policy that key combination changes must be tested on mainline terminals before they are accepted in released versions of MC. The issue here is that xterm is considered to be the reference, and in fact in what concerns the PgUp / PgDown problem, it's a Gnome terminal bug that VTE maintainers are unwilling to fix. I agree the bug is in Gnome terminal but if we know it isn't going to be fixed, then intentionally using that key combination seems like an intentional choice to drop support for a high profile terminal. To me, it makes more sense to map the key combinations that work in the majority of widely used terminals and then select among those the ones to be used in MC. In other words, why not try to make MC work with the maximum number of terminals instead of intentionally breaking compatibility with some of them? The key combos can be remapped by the end user, so it should be possible to offer an MC that works out of the box for nearly everybody. Then, if a particular user really wants to use a key mapping that works only in his terminal and no others, he can manually change it without breaking things for everyone else. -Steve ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
