Netocrat wrote:
James Vega wrote:
[...]
A quick search of the list archives didn't turn
up where this was previously discussed
It was a part of the long and rambling thread "A response to fish and
some suggestions". This url references the culminating post in the
subthread and quotes all relevant parts of the conversation
(attributions are missing - Axel is quoted in opposition to the idea
and I'm quoted suggesting and supporting it):
http://sourceforge.net/mailarchive/message.php?msg_id=12834360
I missed another fork - this exchange is between myself and Axel - his
final response is to postpone the discussion ... which is where we
arrive at the current thread. The message on Sourceforge's archive
(http://sourceforge.net/mailarchive/message.php?msg_id=12837055) is
truncated before the relevant part, so here it is from my own archive
with messageid <[EMAIL PROTECTED]> on 3rd
Sept 2005:
I wrote:
* pressing return doesn't scroll one line and present a new prompt. Why
is it important that it do this? To easily distinguish between an
inactive and a hung shell.
Axel responded:
But not scrolling saves screen real estate. It's a tradeoff.
I responded:
It's also a choice the user makes - if they want to save screen real
estate they don't press return...
Axel responded:
Good point. Though I sometimes find myself pressing enter ten times
in a row while waiting for a program that has gotten stuck, and when
the program finally dies, the screen becomes full with prompts when
I'm not using fish.
Axel wrote:
There are many other characters you can press to check if the shell is
alive, such as pressing tab, to get a nice flashing screen... ;-D
I responded:
It's also useful for scrolling up previous output. I suppose it's what
I'm used to, but it makes more sense to me. I don't know how other
people feel.
Axel responded:
If you mean to add a distinct separator between commands, that is one
of the nice things about a colored prompt. It provides a nice visual
separator even if you didn't explicitly create one, and it doern't
take up too much space.
I responded:
I also meant things like scrolling up output so that when alt-tabbing
between terminals it isn't partially blocked by a window whose output
I'm comparing it with.
Axel responded:
If you want to see information in one window that is blocked by
another window, I suggest you do one of the following:
* Move the window that is blocked
* Move the blocking window
* Resize the window that is blocked
* Resize the window that is blocking
* Make the blocking window transparent
* Make the blocked window 'always on top'
If you can't do 1-4 because of screen real estate issues, you can do
one of the following:
* Buy a larger monitor.
* Use dual head
* Use smaller fonts
I have provided you with 14 different solutions to the problem, none
of which need special support from the shell! ;-)
I responded:
OK. You've provided lots of solutions, but I would still find the
original the easiest in some situations because I wouldn't have to take
my fingers off the keyboard. I haven't seen a solid reason for not
allowing it. By the way, I can understand if you feel like responding
"Look, I'm the developer, this is the way I want to do it and it's a
minor issue so just drop it." For minor things like this I certainly
wouldn't take offence if that's how you were to respond.
I've just seen Philip's response which I support, especially the part
about not feeling in control of the shell.
Axel responded:
Well, maybe we could postpone this a bit at least.
--
http://members.dodo.com.au/~netocrat
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
