Re: reporting of issues
On Sun, 29 Mar 2015 09:52:46 +0200 Frank Dietrich wrote: I have a quick question: Is it enough to report an issue on https://github.com/MidnightCommander/mc/issues We (developers) don't use github as issue tracker. or should it be reported anywhere else also? Please report any issue here: https://www.midnight-commander.org/wiki/NewTicket Registration is reguired. Please use search before create new ticket. Please try recent mc release and don't report issues for old versions. -- Andrew ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Idea for new feature - discuss
MC has three config options for what to do after executing files by pressing return with the selection on them: 1 Close the shell every time, returning to MC 2 Leave the window open every time, press return to... return 3 Close the window only on dumb terminals (what?) Number one leaves you unable to see the output of a command. So you type ls and it's kind of useless. Or any other command or script that has output you need to see. Number two works for those things where you need to see output, but if you don't, and there are things you routinely execute that do good things for you that simply need to be done on command (like turning on house lights, my particular thang) then it eventually becomes a bit of annoyance that it doesn't just get done. Now, I may be missing something buried in that dumb terminal option, but it seems to me that this would be a nice solution: You know how the F4 editor keeps track of what line you're on in which file? That's *lovely*. Well, how about modifying option two so that if you press return, it does what it always did, that is, close the shell and return. But if you press something else, perhaps ESC or whatever, from then on, when that command is run, the shell closes when the run is done. This implies you'd need an operation to remove the close status in case the cat stepped on the selected key at the wrong time, but that doesn't seem like a high hurdle, lots of room in the menus. Another approach would be an option to pause only if the command has output other than CR and LF, which doesn't require saving file names anywhere, but I think that might be a little unsatisfactory as if a command might create output or not, you might get a little uncertain if you saw what you thought you saw. Number three... I use the usual terminal types. Are they dumb? I have no idea. I don't see anything in the OS X shell preferences to variably designate the terminal as dumb or not based on what's executing, so I'm guessing this can't do what I'm thinking. Is it useful to anyone? If not, perhaps it could be the pause only if command produces output option instead. So, anyone? Feasibility problems? Good? Bad? Stupid? Selfish? Did I completely miss or misunderstand a feature? --Ben ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Have STREQ(a,b)?
I see many `if (strcmp (a, b) == 0)` in the code. Wouldn't it be nice if we create a macro and then do `if (STREQ (a,b))` instead? (Not that it bothers me much. I ask this mainly to verify that my subscription works and that I can post here ;-) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Idea for new feature - discuss
I agree. What I did was check Never on Pause after run and put reads in the menu/ext files where I knew I would want the pause. Something like this: + t r ! t t @ Do something on the current file CMD=%{Enter command} $CMD ./%0f read -e -n1 -p'Hit a key... ' Otherwise, if I'm going to type a command that I want to see the output, like make, I hit CTRL-O right before I type to go into terminal mode. On Sun, 29 Mar 2015 08:12:12 -0700, Ben 2blkb...@nemontel.net wrote: MC has three config options for what to do after executing files by pressing return with the selection on them: 1 Close the shell every time, returning to MC 2 Leave the window open every time, press return to... return 3 Close the window only on dumb terminals (what?) Number one leaves you unable to see the output of a command. So you type ls and it's kind of useless. Or any other command or script that has output you need to see. Number two works for those things where you need to see output, but if you don't, and there are things you routinely execute that do good things for you that simply need to be done on command (like turning on house lights, my particular thang) then it eventually becomes a bit of annoyance that it doesn't just get done. Now, I may be missing something buried in that dumb terminal option, but it seems to me that this would be a nice solution: You know how the F4 editor keeps track of what line you're on in which file? That's *lovely*. Well, how about modifying option two so that if you press return, it does what it always did, that is, close the shell and return. But if you press something else, perhaps ESC or whatever, from then on, when that command is run, the shell closes when the run is done. This implies you'd need an operation to remove the close status in case the cat stepped on the selected key at the wrong time, but that doesn't seem like a high hurdle, lots of room in the menus. Another approach would be an option to pause only if the command has output other than CR and LF, which doesn't require saving file names anywhere, but I think that might be a little unsatisfactory as if a command might create output or not, you might get a little uncertain if you saw what you thought you saw. Number three... I use the usual terminal types. Are they dumb? I have no idea. I don't see anything in the OS X shell preferences to variably designate the terminal as dumb or not based on what's executing, so I'm guessing this can't do what I'm thinking. Is it useful to anyone? If not, perhaps it could be the pause only if command produces output option instead. So, anyone? Feasibility problems? Good? Bad? Stupid? Selfish? Did I completely miss or misunderstand a feature? --Ben -- Peace and Cheer ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: Idea for new feature - discuss
I agree. What I did was check Never on Pause after run and put reads in the menu/ext file Oho, that's *very* clever, thank you! On Sun, Mar 29, 2015 at 10:14 AM, Mike Smithson mdooli...@gmail.com wrote: I agree. What I did was check Never on Pause after run and put reads in the menu/ext files where I knew I would want the pause. Something like this: + t r ! t t @ Do something on the current file CMD=%{Enter command} $CMD ./%0f read -e -n1 -p'Hit a key... ' Otherwise, if I'm going to type a command that I want to see the output, like make, I hit CTRL-O right before I type to go into terminal mode. On Sun, 29 Mar 2015 08:12:12 -0700, Ben 2blkb...@nemontel.net wrote: MC has three config options for what to do after executing files by pressing return with the selection on them: 1 Close the shell every time, returning to MC 2 Leave the window open every time, press return to... return 3 Close the window only on dumb terminals (what?) Number one leaves you unable to see the output of a command. So you type ls and it's kind of useless. Or any other command or script that has output you need to see. Number two works for those things where you need to see output, but if you don't, and there are things you routinely execute that do good things for you that simply need to be done on command (like turning on house lights, my particular thang) then it eventually becomes a bit of annoyance that it doesn't just get done. Now, I may be missing something buried in that dumb terminal option, but it seems to me that this would be a nice solution: You know how the F4 editor keeps track of what line you're on in which file? That's *lovely*. Well, how about modifying option two so that if you press return, it does what it always did, that is, close the shell and return. But if you press something else, perhaps ESC or whatever, from then on, when that command is run, the shell closes when the run is done. This implies you'd need an operation to remove the close status in case the cat stepped on the selected key at the wrong time, but that doesn't seem like a high hurdle, lots of room in the menus. Another approach would be an option to pause only if the command has output other than CR and LF, which doesn't require saving file names anywhere, but I think that might be a little unsatisfactory as if a command might create output or not, you might get a little uncertain if you saw what you thought you saw. Number three... I use the usual terminal types. Are they dumb? I have no idea. I don't see anything in the OS X shell preferences to variably designate the terminal as dumb or not based on what's executing, so I'm guessing this can't do what I'm thinking. Is it useful to anyone? If not, perhaps it could be the pause only if command produces output option instead. So, anyone? Feasibility problems? Good? Bad? Stupid? Selfish? Did I completely miss or misunderstand a feature? --Ben -- Peace and Cheer ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: Have STREQ(a,b)?
On Sun, 2015-03-29 at 18:18 +0300, Mooffie wrote: I see many `if (strcmp (a, b) == 0)` in the code. Wouldn't it be nice if we create a macro and then do `if (STREQ (a,b))` instead? Nope, because there is no point in that beyond obfuscating the code. (Not that it bothers me much. I ask this mainly to verify that my subscription works and that I can post here ;-) That was clever :-) -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel