On Fri, 20 May 2011 12:51:35 +0100
David Tweed <david.tw...@gmail.com> wrote:
> it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other (at least for almost all
> modern computing devices, I can see if you genuinely are using a
> 1970's dumb terminal you don't have the wiggle room for more). At the
> very least, it would be very productive to
I fully agree, David.
> 1. Have a terminal/shell combination that, upon resizing, actually
> redisplays text properly rather than just chops off stuff in
> vanished/newly visible space.
>
> 2. Had the _option_ for shell history to pop up in another window,
> rather than _only_ being available as a command output, so that it
> scrolls other stuff you've been doing off the screen.
>
> 3. Had more flexible context-sensitive cutting support. (Eg, let me
> somehow copy a sequence of commands text without including either the
> prompt or command output.)
If you do something like showing a time display for each prompt, but on
the right of the screen, this causes:
*) a bunch of needless space characters, as the terminal has no better
way to "push something to the right"
*) when you copypaste, you copy paste all empty spaces and the time
display. the timestamps should be optional, the space characters
should not be in there at all.
So 4) datetime info (and last exit code, etc) could all be made
available as data by the shell, but how and when to render it should be
up to the terminal.
>
> Obviously it's not clear what the best way to provide greater
> information flow between interactive shells and terminals, and it
> may/may not be that the Plan9 or emacs-shell approach is the way to
> go, but it'd be nice if there was some increase in terminal
> productivity in the coming years. (Of course, the other problem is
> it's a large number of shells and terminals to change
we could just write a new terminal-shell system that fixes all this,
that doesn't mean we need to fix all other shells and terminals out
there.
> and if
> additional "metadata" needs adding to commands that's a huge number of
> programs to change, so it's unlikely to happen...)
we could start with a few proof of concept apps. but this could be a
next step. I think modifying applications mostly to those programs
that want to draw images or use ncurses. We could scratch quite
some itches mentioned in this thread by only creating a new
shell/terminal system, without touching the actual apps.
Here are some more wishes / ideas:
5)I often want to treat output of a previous command as menu, to pick
something and use it in the command string of the next command.
and I do not necessarily know in advance I will do this.
For example:
Suppose I sometimes see a FooError and suspect one of my scripts is the
culprit.
I then do something like: grep -Rn FooError ~/scripts/
If this output tells me that indeed I have a script emitting a
FooError, and I want to edit that script at the location (line number)
grep reported, then I want to be able to type 'vim ' and then to get a
dmenu-like menu using the output of grep. In this case feeding the
literal output to dmenu would be fine, in other cases there could be
other output that should get stripped first.
When I picked the entry, it should add the right arguments for vim
('+<LineNo> <filename>')
In some cases grep might return nothing [useful], so I don't want to be
forced to see the menu if I don't want it (which means something like
'vim $(grep -Rn FooError ~/scripts | dmenu | sed/awk/blah)' is not an
option. And there's no reason to be restricted to only pick from the
last command. at some point I might want to get a menu listing output
from N commands earlier. Or I want to pick multiple entries from one
menu.
I don't think we need to modify applications like grep for this. Their
output can be parsed in a fairly straightforward and consistent way.
We do need a better shell/terminal system though.
6)non sucky rendering. I think applications should be able to have
pixel-precise control of what the output should be (other than maybe a
terminal-imposed resize factor, and also not _where_ it should be), to
i.e. render images in the terminal.
I think a fd to write something to like "here's an image, please
render it somewhere" is better than cls's suggestion of having apps
directly write to the terminal. I think the latter idea would get
messy quickly. It's as if X windows would draw themself to the screen
rather then having a window manager take care of it.
Dieter
