[st] a real (I think) feature request

[John A. Grahor]

I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where line
editing can happen locally and what one types is only sent to the tty when
one hits return (or some other key).

I use ssh to connect to hosts with very slow, high latency satellite links.
It is exceedingly painful to type on a link like this and there's no way to
put ssh into a line mode as can be done with telnet.

[Sebastian A. Liem]

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Or better; 9term:s hold mode, I would like this too.

I would recommend taking a look at 9term in plan9port.

-- Sebasti

[Anonymous]

Post by Sebastian A. Liem

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Or better; 9term:s hold mode, I would like this too.
I would recommend taking a look at 9term in plan9port.
-- Sebasti

Something like this can be done on linux with C-s and C-q.

[Anonymous]

there's no way to put ssh into a line mode as can be done with
telnet.

Looks like it is problem of ssh, not terminal emulator.

[Anselm R Garbe]

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).
I use ssh to connect to hosts with very slow, high latency satellite links.
 It is exceedingly painful to type on a link like this and there's no way to
put ssh into a line mode as can be done with telnet.

Can't you do something like this (connecting with ssh to the satellite
for just a command):

ssh ***@sat 'cat >> /some/file.txt' < file.txt

This can be extended with the use of ed of course.

Kind regards,
Anselm

[Moritz Wilhelmy]

Post by Anselm R Garbe
Can't you do something like this (connecting with ssh to the satellite

Isn't it "ssh ***@foo cat '>>' /some/file.txt < file.txt"?

Regards
Moritz

[Anselm R Garbe]

Post by Anselm R Garbe
Can't you do something like this (connecting with ssh to the satellite

No.

Kind regards,
Anselm

[Kris Maglione]

Post by Anselm R Garbe
Can't you do something like this (connecting with ssh to the satellite

It actually doesn't make a difference. ssh just concatenates its
arguments into a single string and passes them to the shell.

[John Yates]

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Two decades ago I fell in love with Apollo Computer's solution to this
problem. A terminal window was broken into two "panes":

1) an editable input pane
2) a read-only transcript pane

The two panes were separated by a full window horizontal line or rule.
The input pane never shrank to less than one line but could also
steal lines from the transcript pane until it grew to a specified
fraction of the input window (typically 1/4). The input pane had two
modes of operation with an icon on the title bar to indicating which
mode was in effect. I cannot recall the actual names so let me just
call them "connected mode" and "disconnected mode". In

In connected mode type ahead hung around in the input pane until a
program running in under that terminal window issued a read from
stdin. When that happened a single line of input (i.e. up to a
newline) was passed from the input pane to the requesting program.
That input line disappeared from the input pane, the program's prompt
(if any) appeared in the transcript followed by the input line just
delivered. In essence the input pane was simply a visible
representation of unconsumed type-ahead.

In disconnected mode type ahead input again hung around in the input
pane. This time though when a program running in the terminal window
requested input its prompt would appear in the transcript pane but no
user supplied input would be delivered until the input pane reverted
to connected mode. At that point the oldest input line would
disappear from the input pane and would reappear following the prompt
in the transcript pane.

What made this mechanism so pleasant to use was that all text areas in
the screen (editing buffers, input panes, and output transcripts)
shared a common set of editing key bindings, similar to vi or emacs.
A very common idiom was to list a directory, switch the input pane to
disconnected mode, copy the directory listing to the input pane,
modify that copy of the listing using some regular expression
substitutions to turn it into one or more commands on each file, and
revert the input pane to connected mode. Obviously in any *nix
environment one can do the same thing by redirecting the output from
ls to a file, open that file in an editor, modifying it, saving it,
and finally sourcing the edited file in one's shell. The input pane
mechanism simply made such operations faster and more intuitive: no
inventing a file name, no opening a separate editor, no issuing a
source command to one's shell.

/john

[hiro]

From the length of your description I would guess this solution would

be pretty complicated to implement.

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Two decades ago I fell in love with Apollo Computer's solution to this
1) an editable input pane
2) a read-only transcript pane
The two panes were separated by a full window horizontal line or rule.
 The input pane never shrank to less than one line but could also
steal lines from the transcript pane until it grew to a specified
fraction of the input window (typically 1/4).  The input pane had two
modes of operation with an icon on the title bar to indicating which
mode was in effect.  I cannot recall the actual names so let me just
call them "connected mode" and "disconnected mode".  In
In connected mode type ahead hung around in the input pane until a
program running in under that terminal window issued a read from
stdin.  When that happened a single line of input (i.e. up to a
newline) was passed from the input pane to the requesting program.
That input line disappeared from the input pane, the program's prompt
(if any) appeared in the transcript followed by the input line just
delivered.  In essence the input pane was simply a visible
representation of unconsumed type-ahead.
In disconnected mode type ahead input again hung around in the input
pane.  This time though when a program running in the terminal window
requested input its prompt would appear in the transcript pane but no
user supplied input would be delivered until the input pane reverted
to connected mode.  At that point the oldest input line would
disappear from the input pane and would reappear following the prompt
in the transcript pane.
What made this mechanism so pleasant to use was that all text areas in
the screen (editing buffers, input panes, and output transcripts)
shared a common set of editing key bindings, similar to vi or emacs.
A very common idiom was to list a directory, switch the input pane to
disconnected mode, copy the directory listing to the input pane,
modify that copy of the listing using some regular expression
substitutions to turn it into one or more commands on each file, and
revert the input pane to connected mode.  Obviously in any *nix
environment one can do the same thing by redirecting the output from
ls to a file, open that file in an editor, modifying it, saving it,
and finally sourcing the edited file in one's shell.  The input pane
mechanism simply made such operations faster and more intuitive: no
inventing a file name, no opening a separate editor, no issuing a
source command to one's shell.
/john

[Robert C Corsaro]

It reminds me of your typical IRC client. transcript above and one line
of command at the bottom.

From the length of your description I would guess this solution would
be pretty complicated to implement.

Post by John Yates

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Two decades ago I fell in love with Apollo Computer's solution to this
1) an editable input pane
2) a read-only transcript pane
The two panes were separated by a full window horizontal line or rule.
The input pane never shrank to less than one line but could also
steal lines from the transcript pane until it grew to a specified
fraction of the input window (typically 1/4). The input pane had two
modes of operation with an icon on the title bar to indicating which
mode was in effect. I cannot recall the actual names so let me just
call them "connected mode" and "disconnected mode". In
In connected mode type ahead hung around in the input pane until a
program running in under that terminal window issued a read from
stdin. When that happened a single line of input (i.e. up to a
newline) was passed from the input pane to the requesting program.
That input line disappeared from the input pane, the program's prompt
(if any) appeared in the transcript followed by the input line just
delivered. In essence the input pane was simply a visible
representation of unconsumed type-ahead.
In disconnected mode type ahead input again hung around in the input
pane. This time though when a program running in the terminal window
requested input its prompt would appear in the transcript pane but no
user supplied input would be delivered until the input pane reverted
to connected mode. At that point the oldest input line would
disappear from the input pane and would reappear following the prompt
in the transcript pane.
What made this mechanism so pleasant to use was that all text areas in
the screen (editing buffers, input panes, and output transcripts)
shared a common set of editing key bindings, similar to vi or emacs.
A very common idiom was to list a directory, switch the input pane to
disconnected mode, copy the directory listing to the input pane,
modify that copy of the listing using some regular expression
substitutions to turn it into one or more commands on each file, and
revert the input pane to connected mode. Obviously in any *nix
environment one can do the same thing by redirecting the output from
ls to a file, open that file in an editor, modifying it, saving it,
and finally sourcing the edited file in one's shell. The input pane
mechanism simply made such operations faster and more intuitive: no
inventing a file name, no opening a separate editor, no issuing a
source command to one's shell.
/john

[pancake]

i remember that scrollz was implemented in this way. splitting the logic
of the
interface (prompt+readonly scrollable text area) in a separate program
managing the stdio/out/err of another application.

i would love to see this usable for ii or many other shell applications

Post by Robert C Corsaro
It reminds me of your typical IRC client. transcript above and one
line of command at the bottom.

From the length of your description I would guess this solution would
be pretty complicated to implement.

Post by John Yates

Post by John A. Grahor
I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
line editing can happen locally and what one types is only sent to the tty
when one hits return (or some other key).

Two decades ago I fell in love with Apollo Computer's solution to this
1) an editable input pane
2) a read-only transcript pane
The two panes were separated by a full window horizontal line or rule.
The input pane never shrank to less than one line but could also
steal lines from the transcript pane until it grew to a specified
fraction of the input window (typically 1/4). The input pane had two
modes of operation with an icon on the title bar to indicating which
mode was in effect. I cannot recall the actual names so let me just
call them "connected mode" and "disconnected mode". In
In connected mode type ahead hung around in the input pane until a
program running in under that terminal window issued a read from
stdin. When that happened a single line of input (i.e. up to a
newline) was passed from the input pane to the requesting program.
That input line disappeared from the input pane, the program's prompt
(if any) appeared in the transcript followed by the input line just
delivered. In essence the input pane was simply a visible
representation of unconsumed type-ahead.
In disconnected mode type ahead input again hung around in the input
pane. This time though when a program running in the terminal window
requested input its prompt would appear in the transcript pane but no
user supplied input would be delivered until the input pane reverted
to connected mode. At that point the oldest input line would
disappear from the input pane and would reappear following the prompt
in the transcript pane.
What made this mechanism so pleasant to use was that all text areas in
the screen (editing buffers, input panes, and output transcripts)
shared a common set of editing key bindings, similar to vi or emacs.
A very common idiom was to list a directory, switch the input pane to
disconnected mode, copy the directory listing to the input pane,
modify that copy of the listing using some regular expression
substitutions to turn it into one or more commands on each file, and
revert the input pane to connected mode. Obviously in any *nix
environment one can do the same thing by redirecting the output from
ls to a file, open that file in an editor, modifying it, saving it,
and finally sourcing the edited file in one's shell. The input pane
mechanism simply made such operations faster and more intuitive: no
inventing a file name, no opening a separate editor, no issuing a
source command to one's shell.
/john

[Kris Maglione]

Post by John Yates
What made this mechanism so pleasant to use was that all text areas in
the screen (editing buffers, input panes, and output transcripts)
shared a common set of editing key bindings, similar to vi or emacs.
A very common idiom was to list a directory, switch the input pane to
disconnected mode, copy the directory listing to the input pane,
modify that copy of the listing using some regular expression
substitutions to turn it into one or more commands on each file, and
revert the input pane to connected mode. Obviously in any *nix
environment one can do the same thing by redirecting the output from
ls to a file, open that file in an editor, modifying it, saving it,
and finally sourcing the edited file in one's shell. The input pane
mechanism simply made such operations faster and more intuitive: no
inventing a file name, no opening a separate editor, no issuing a
source command to one's shell.

This actually isn't especially difficult to do in vim or some
other editor. In vim alone, for instance, you can do something
like,

:r !ls
:v/\.js/d|s/^/rm /
:w !sh

Most shells let you edit your commandline with an editor, too.
For instance, FreeBSD's sh(1) allows this with <Esc>v by
default, in vi mode. There's an edit-command-line script for
zsh, and I assume something similar for bash.

You can almost do the same with 9term's hold mode, but you'd
have to use sed or awk. You can definately do it with acme's
win(1) somewhat more easily, though.

[Sven Guckes]

Post by Kris Maglione

Post by John Yates
What made this mechanism so pleasant to use was that all
text areas in the screen (editing buffers, input panes,
and output transcripts) shared a common set of editing key
bindings, similar to vi or emacs. A very common idiom was
to list a directory, switch the input pane to disconnected
mode, copy the directory listing to the input pane, modify
that copy of the listing using some regular expression
substitutions to turn it into one or more commands on
each file, and revert the input pane to connected mode.
Obviously in any *nix environment one can do the same thing
by redirecting the output from ls to a file, open that file
in an editor, modifying it, saving it, and finally sourcing
the edited file in one's shell. The input pane mechanism
no inventing a file name, no opening a separate editor,
no issuing a source command to one's shell.

This actually isn't especially difficult to do
in vim or some other editor. In vim alone,
for instance, you can do something like,
:r !ls
:v/\.js/d|s/^/rm /
:w !sh

i have used these command so often that i keep wondering
how else you can survive the day without many workarounds. ;-)

for those who havent used vi much,
here is a breakdown of the commands:

:r !ls
reads (:r) into buffer via a shell (!)
the output of a list (ls) command.

:v/\.js/d|s/^/rm /
:v for all non-matching lines
applied to contents ".js"
d delete
| command separator
s substitute
^ the beginning of the line
rm with "rm " (inserting it)

:w write
!sh to a shell calling a shell

the last one is a little redundant,
but, hey, it gets the job done.

there you should have your list of "rm" commands
applied to all non-js files, execute by a shell.

mind you, the commands all apply to basic vi -
so *all* vi clones support this. nothing fancy.

the zsh people would do the removal
using patterns with *exeptions8
which requires "extended globbing":

% setopt extendedglob
% rm *(.)~*.js

the pattern works like this:
*(.) all files
~ except
*.js files ending in ".js"

see also:
% man zshexpn
/FILENAME GENERATION
/Glob Operators

x~y
(Requires EXTENDED_GLOB to be set.)
Match anything that matches the
pattern x but does not match y. ..
Multiple patterns can be excluded by ‘foo~bar~baz’.

i am pretty sure some of you would
ask for "multiple exclusions". ;-)

Post by Kris Maglione
Most shells let you edit your commandline with an editor,
too. For instance, FreeBSD's sh(1) allows this with <Esc>v
by default, in vi mode. There's an edit-command-line
script for zsh, and I assume something similar for bash.

within zsh, you can edit the last command using the "fc" builtin.
and you can use your favourite editor by setting FCEDIT:

% FCEDIT=vim
% fc

the fc command is quite powerful. read all about it
with "man zshbuiltins" and "/SHELL BUILTIN COMMANDS"
(where "/foo" is the search command which not only exits
in vi but also within "less" and "more" as pagers, too).

Sven

[Anselm R Garbe]

Post by Kris Maglione

Post by John Yates
What made this mechanism so pleasant to use was that all
text areas in the screen (editing buffers, input panes,
and output transcripts) shared a common set of editing key
bindings, similar to vi or emacs.  A very common idiom was
to list a directory, switch the input pane to disconnected
mode, copy the directory listing to the input pane, modify
that copy of the listing using some regular expression
substitutions to turn it into one or more commands on
each file, and revert the input pane to connected mode.
Obviously in any *nix environment one can do the same thing
by redirecting the output from ls to a file, open that file
in an editor, modifying it, saving it, and finally sourcing
the edited file in one's shell.  The input pane mechanism
no inventing a file name, no opening a separate editor,
no issuing a source command to one's shell.

This actually isn't especially difficult to do
in vim or some other editor. In vim alone,
for instance, you can do something like,
    :r !ls
    :v/\.js/d|s/^/rm /
    :w !sh

Should also work with ed:

r !ls
v/\.js d
g//s/^/echo /
w !sh

Kind regards,
Anselm

[Uriel]

Post by Anselm R Garbe

 [... snip]

r !ls
v/\.js d
g//s/^/echo /
w !sh
Kind regards,
Anselm

More evidence that Unix software has not progressed much in the last
forty years.

But I'm sure that in a few years they will try to present us this
stuff as "amazing gnome-edit magic".


uriel

[Enno Boland (Gottox)]

amazing punchcard magic.

Post by Uriel

Post by Anselm R Garbe

 [... snip]

r !ls
v/\.js d
g//s/^/echo /
w !sh
Kind regards,
Anselm

More evidence that Unix software has not progressed much in the last
forty years.
But I'm sure that in a few years they will try to present us this
stuff as "amazing gnome-edit magic".
uriel

[Jacob Todd]

Post by Uriel

Post by Anselm R Garbe

 [... snip]

r !ls
v/\.js d
g//s/^/echo /
w !sh
Kind regards,
Anselm

More evidence that Unix software has not progressed much in the last
forty years.
But I'm sure that in a few years they will try to present us this
stuff as "amazing gnome-edit magic".
uriel

No one uses ed (hopefully), so it doesn't really prove anything other than GNU
and whoever else is maintaining an ed clone are stuck in the dark ages.

[Mark Edgar]

Post by Jacob Todd
No one uses ed (hopefully)

Nonsense. It still has its place in:

* scripted/batch editing
* editing files on embedded systems or for system recovery
* blind users (see edbrowse)

Besides, those who ignore the past ...

-Mark

[Kris Maglione]

Post by Jacob Todd

Post by Uriel

Post by Anselm R Garbe

 [... snip]

r !ls
v/\.js d
g//s/^/echo /
w !sh
Kind regards,
Anselm

More evidence that Unix software has not progressed much in the last
forty years.
But I'm sure that in a few years they will try to present us this
stuff as "amazing gnome-edit magic".
uriel

No one uses ed (hopefully), so it doesn't really prove anything other than GNU
and whoever else is maintaining an ed clone are stuck in the dark ages.

Clone? Don't be absurd. Heirloom, Plan 9, and most of the BSDs
still provide the original ed.

[Uriel]

Post by Jacob Todd

Post by Uriel

Post by Anselm R Garbe

 [... snip]

r !ls
v/\.js d
g//s/^/echo /
w !sh
Kind regards,
Anselm

More evidence that Unix software has not progressed much in the last
forty years.
But I'm sure that in a few years they will try to present us this
stuff as "amazing gnome-edit magic".
uriel

No one uses ed (hopefully),

I use ed almost every day, it is by far the fastest way to to small
edits, by the time vi starts up, I have typed /foo\n c\n bar\n .\n
wq\n

Plus as others have noted it can be scripted.

And here is the thing about ed, I know (or used to anyway) every
command and feature inside-out by heart, while *nobody* knows what 1%
of the vim options do! Recently I was stuck on windows with a
improperly built vim that was using DOS line endings by default, it
was fucking hell to figure out that the right option to solve the
problem was to use the *ffs* setting! There are about a dozen slightly
different flags all of which affect how line endings are set! For
Fucks Sake!

uriel

Post by Jacob Todd
so it doesn't really prove anything other than GNU
and whoever else is maintaining an ed clone are stuck in the dark ages.
--
Jake Todd
// If it isn't broke, tweak it!

[Anselm R Garbe]

Post by Uriel
I use ed almost every day, it is by far the fastest way to to small
edits, by the time vi starts up, I have typed /foo\n c\n bar\n .\n
wq\n

Get a faster computer ;) vim starts for me without any delay (but I
got proper hardware, which might be the reason).

Post by Uriel
And here is the thing about ed, I know (or used to anyway) every
command and feature inside-out by heart, while *nobody* knows what 1%
of the vim options do! Recently I was stuck on windows with a
improperly built vim that was using DOS line endings by default, it
was fucking hell to figure out that the right option to solve the
problem was to use the *ffs* setting! There are about a dozen slightly
different flags all of which affect how line endings are set! For
Fucks Sake!

Yes it's a shame. I think a suckless editor would simply be some kind
of a viewer that integrates the real ed. In a sense vi done right.

Kind regards,
Anselm

[Kris Maglione]

Post by Anselm R Garbe

Post by Uriel
And here is the thing about ed, I know (or used to anyway) every
command and feature inside-out by heart, while *nobody* knows what 1%
of the vim options do! Recently I was stuck on windows with a
improperly built vim that was using DOS line endings by default, it
was fucking hell to figure out that the right option to solve the
problem was to use the *ffs* setting! There are about a dozen slightly
different flags all of which affect how line endings are set! For
Fucks Sake!

Yes it's a shame. I think a suckless editor would simply be some kind
of a viewer that integrates the real ed. In a sense vi done right.

It's called Sam.

[Anselm R Garbe]

Post by Kris Maglione

Post by Anselm R Garbe

Post by Uriel
And here is the thing about ed, I know (or used to anyway) every
command and feature inside-out by heart, while *nobody* knows what 1%
of the vim options do! Recently I was stuck on windows with a
improperly built vim that was using DOS line endings by default, it
was fucking hell to figure out that the right option to solve the
problem was to use the *ffs* setting! There are about a dozen slightly
different flags all of which affect how line endings are set! For
Fucks Sake!

Yes it's a shame. I think a suckless editor would simply be some kind
of a viewer that integrates the real ed. In a sense vi done right.

It's called Sam.

Sam sucks less, but it's unusable without a mouse and there is room
for a less sucking editor ;)

Kind regards,
Anselm

[markus schnalke]

Post by Kris Maglione

Post by Anselm R Garbe
Yes it's a shame. I think a suckless editor would simply be some kind
of a viewer that integrates the real ed. In a sense vi done right.

It's called Sam.

The problem with sam is that it depends on a graphical display. If
there is none available it's just like ed (with some extensions).

As ed lives everywhere, while sam does not, I rather user ed.


meillo

[Kris Maglione]

Post by markus schnalke

Post by Kris Maglione

Post by Anselm R Garbe
Yes it's a shame. I think a suckless editor would simply be some kind
of a viewer that integrates the real ed. In a sense vi done right.

It's called Sam.

The problem with sam is that it depends on a graphical display. If
there is none available it's just like ed (with some extensions).
As ed lives everywhere, while sam does not, I rather user ed.

Sam has a documented protocol. It doesn't rely on a graphical
display at all (although it does work rather nicely with a
remote sam and a local graphical samterm). A curses client could
easily be written. It still wouldn't be as efficient over the
network as the graphical client, though.

The main benefit of sam over ed is structural regexps, and
filewise rather than linewise regexps. ed can be a pain in the
ass in that regard at times. Even if sam doesn't live
everywhere, I prefer it where it's available.

[markus schnalke]

Post by Jacob Todd
No one uses ed (hopefully)

I use ed regularly too. (At least several times a week.)


btw: GNU's version of ed sucks. We all expected that already, aren't
we. But Heirloom ed is nice and deals well with UTF-8.


meillo