GNOME.org
 

Re: mc Digest, Vol 129, Issue 5

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, mc-request gnome org <mc-request 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-request gnome org

You can reach the person managing the list at
      mc-owner gnome org

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 <2blkbelt nemontel net>
To: mc gnome org
Subject: Idea for new feature - discuss
Message-ID:
      <CANv=BrpTYGKiGnGqkbRa9wiEx=Kkm2FBupAO1T0KqZ=RPJqL6w 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" <mdooligan gmail com>
To: Ben <2blkbelt nemontel net>, mc gnome org
Subject: Re: Idea for new feature - discuss
Message-ID: <op xv9opoawi2bjwi timberwolf electromag net>
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 <2blkbelt 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


------------------------------

Message: 3
Date: Sun, 29 Mar 2015 10:50:32 -0600
From: Ben <2blkbelt nemontel net>
To: Mike Smithson <mdooligan gmail com>, mc gnome org
Subject: Re: Idea for new feature - discuss
Message-ID:
      <CANv=BroNz6xXyhQyuoeLE-+7eo2oFQVH1DAYmhftNKo+QWntQw 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 <mdooligan 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 <2blkbelt 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


-------------- 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
**********************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]