Try a 2-dim-matrix to arrange the various combinations. English prose is less suitable for science. This is not US-TV.
== Chris Glur. On 3/30/15, [email protected] <[email protected]> wrote: > Send mc mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mc digest..." > > > Today's Topics: > > 1. Idea for new feature - discuss (Ben) > 2. Re: Idea for new feature - discuss (Mike Smithson) > 3. Re: Idea for new feature - discuss (Ben) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 29 Mar 2015 09:12:12 -0600 > From: Ben <[email protected]> > To: [email protected] > Subject: Idea for new feature - discuss > Message-ID: > <CANv=BrpTYGKiGnGqkbRa9wiEx=Kkm2FBupAO1T0KqZ=rpjq...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://mail.gnome.org/archives/mc/attachments/20150329/6340e9ef/attachment.html> > > ------------------------------ > > Message: 2 > Date: Sun, 29 Mar 2015 09:14:02 -0700 > From: "Mike Smithson" <[email protected]> > To: Ben <[email protected]>, [email protected] > Subject: Re: Idea for new feature - discuss > Message-ID: <[email protected]> > Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 > > 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 <[email protected]> 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 > > > ------------------------------ > > Message: 3 > Date: Sun, 29 Mar 2015 10:50:32 -0600 > From: Ben <[email protected]> > To: Mike Smithson <[email protected]>, [email protected] > Subject: Re: Idea for new feature - discuss > Message-ID: > <CANv=bronz6xxyhqyuoele-+7eo2ofqvh1daymhftnko+qwn...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > >> 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 <[email protected]> > 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 <[email protected]> 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 >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://mail.gnome.org/archives/mc/attachments/20150329/26d1f994/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mc mailing list > https://mail.gnome.org/mailman/listinfo/mc > > > ------------------------------ > > End of mc Digest, Vol 129, Issue 5 > ********************************** > _______________________________________________ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
