[Terminal] Enhancements (mostly easy)

[humdinger]

This is hrev28717.

I have a few suggestions to make Terminal more enduser friendly.

1. See tip: ​http://betips.net/1997/09/09/customize-bash-keybindings

I propose to add these lines to inputrc:

Control-f: kill-word
"\e[1~": beginning-of-line
"\e[4~": end-of-line

Which will activate HOME and END keys and deletes the word to the right of the cursor with CRTL+F. The other lines in that tip refer to international characters which is blocked by another old ticket already, #215.

2. The title tab of Terminal's settings panel should be named like the menu item envoking it: "Terminal Preferences".

3. The colors in the dropdown menu in that panel should be renamed to be more enduser friendly:

• Text
• Background
• Cursor
• Text under Cursor
• Selected Text
• Selected Background

4. If there is more than one Tab in a Terminal window, ALT+W should only close the current Tab, not the whole window with all the tabbed sessions. That's what ALT+Q is for.

5. Only the current Tab should be light grey. The others should be darker to have the active one stand out.

6. Instead of "Shell 1,2,3" name each Tab "Alt+1, 2, 3" to remind people of the switching shortcuts. This should take in account the Menu preference setting if anybody uses "CONTROL" instead of "ALT".

7. A bit more complicated: Have a double-click on the "Alt+1,2,3" Tab-label enter editing mode to rename a Tab.

8. Tabbed-Terminals that are busy could show a little icon in the tab that gets removed when the prompt's back.

9. I'd appreciate to have a checkbox in the "Terminal Preferences" panel called "Automatic coloring of new tabs". This will open every new tab with a different nicely(!) colored profile.

The Tab color should reflect each background color.

I think I better stop now... :) I have to admit that I'm not the world's heaviest shell user, but these are the things I'd find being useful without imposing too much on our weathered shell denizens.

[Adek336]

10. Remember window position and size between runs.

[axeld]

1. The home and end keys work as expected. Why should Control-F delete any word? Where does that come from? I would rather like to see Ctrl-Left/Right to move the cursor to the previous/next word.

2. & 3. Agreed.

4. Actually, Alt-Q is not for closing the window, but the application.

5. It should use the same BTabView as everyone else, and its look is not final yet, anyway.

6. I don't like this. While it's good to be able to switch to tabs directly, switching using Alt-Left/Right should be promoted to the menu instead (or even the whole list). What if you have more than 9 shells?

7. Sure.

8. Define busy. Not sure the Terminal knows about this stuff, anyway.

9. For what? That doesn't sound useful to me at all.

10. Position I'd agree, the size is already saved when you save the current settings.

[humdinger]

1. It came from that BeTip I mentioned. I guess it's some kind of "standard" like the Ctrl+W to delete the word to the left of the cursor.

The "Ctrl-Left/Right to move the cursor to the previous/next word" would be perfect. I'd love to have that in every text related widget system wide. From Terminal to editor to renaming a file. I even thought there was a ticket for that for years, but I obviously remember wrong...

4. OK, close every Terminal window with all its tabs with Alt-Q, but have Alt-W close only the current tab (or the last remaining window, if there's no tab any more).

6. You're right, lose the Alt+nr. and use Alt-cursor instead.

8. Busy is whenever there's no blinking cursor accepting the next command. :)

9. Well, so every new tab has automatically another color. That way, I can quickly see (maybe by rapidly cycling through the open tabs with Alt-cursor left/right) where I am. Connect in my mind e.g. green=project1, blue=project2, red=project3.

[mmadia]

umccullough uploaded the patch for me, as I experienced difficulty.

This patch implements sections 2) and 3).

In regards to 8), that would be a very nice feature. Is it possible to somehow monitor the program for some type of control release or return value?

[umccullough]

Patch to fix #2 and #3 (attaching for mmadia)

[umccullough]

For some reason the patch doesn't show the diff in Trac - but you can download "original format" to see it

[rossi]

Patch for #10

Terminal now remembers the last position (based on when it was closed) including its workspace.

In case you don't want to open in the previously remebered workspace, hold down the OPTION key will starting Terminal.

It remembers the position for ALL Terminal windows (Rene ;-)

While testing the patch, I discovered the following bug:

​http://dev.haiku-os.org/ticket/3372

However I also tested with a clean install of my previous image (hrev29005) and it exposes the same bug, with the patch applied. Therefore not related to my work and I could figure out the issue yet.

Cheers, Rossi

[rossi]

Revised patch for 10.

Changed the default behaviour from open in previous workspace to open in current workspace. If you want the Terminal to open in the workspace it was last closed, press the Windows (OPTION) key.

Attachment updated to the revised patch.

[rossi]

Patch Rev. 2

[humdinger]

Since the Terminal got some attention lately (Hi, rossi :) ) here's another easy enhancement:

-> A keyboard shortcut to open a Tracker window of the current directory.

I know you could create a script with "/boot/beos/system/Tracker ." to do the same, but maybe this could be a Terminal feature that could be extended in the future. Like this:

With Auckland's Stack&Tile it'd be really cool if you could stack the opened Tracker window behind the Terminal and keep the Tracker window's displayed directory in sync with the Terminal. It could be argued, that the Terminal could then also be sync'ed with the Tracker window. Maybe best to try out various implementations to see what fits best when actually working with it.

[stippi]

Haiku has the almighty "open" command. "open ." will already open the cwd in Tracker. I know this wouldn't integrate the Stack&Tile feature...

[humdinger]

Applied Urias' patch "terminalPrefColorNames.diff" with a few additions in hrev32205. No idea why it wasn't applied sooner... :)

[umccullough]

Replying to humdinger:

Applied Urias' patch "terminalPrefColorNames.diff" with a few additions in hrev32205. No idea why it wasn't applied sooner... :)

Thanks :)

Just to clarify, it was Matt's patch, but he was having upload troubles so he pasted it in IRC for me to upload instead ;)

[humdinger]

Here's another variation on (9) (You see, I'm still a fan of "colour coding" different Terminal sessions):

• Quickly change the colours of the current Terminal session/tab (which aren't saved, next Terminal will be launched with the usual settings) with a menu "Settings|Change colors ALT+R".

Those colours could be generated with a clever algorithm to assure high contrast. OTOH, I'd prefer a fixed list of, say, 5 hand chosen combinations. This would have the advantage that you could easily cycle thru them and get back to your defaults.

If anyone is interested, I could provide a few "themes" to choose from.

[pulkomandy]

8. ​http://www.macosxhints.com/dlfiles/preexec.bash.txt combined with escape sequences to set the tab title could do the trick. (the escape sequence already work)

Note it is possible to do it easily with zsh, which has precmd() and preexec() functions natively.

[pulkomandy]

9. ​http://www.steike.com/code/xterm-colors/

I can add the needed escape sequences so you can use this in bash profile. This is not really something that should go inside the terminal application itself.

[pulkomandy]

Applied rossi patch in hrev38192. This fixes 10.

[diver]

Waiting for number 4 :-)

[bonefish]

• 4 is done.
• 6 you can do yourself by setting the tab title pattern in the settings respectively. I find the (now) current default more useful, though.
• 7 is done.
• 8 can be implemented only with the shell's help I guess. I haven't checked what Adrien has done in this respect. Personally I don't find this feature interesting enough to implement it, but if someone else feels like implementing it and it doesn't get in the way...
• 9 is something I can only frown upon. ;-)

[humdinger]

Thanks for all your work on Terminal, Ingo!
I think 8) is also kinda solved, because after your recent changes, the tab says "bash" when not being busy, which then states the currently running app. Instead of "bash" it could also just say "--" IMO.
Yeah, 9) is a bit on the playful side. It made more sense when the tabs still were non-descript to have some sort of colour-coding. I'd be content closing that one, too.

Which would leave the CTRL+F thing of 1). I do see some sense in that. If you have CTRL+W to kill what's left of the cursor, why not CTRL+F for the stuff on the right...

[bonefish]

Replying to humdinger:

I think 8) is also kinda solved, because after your recent changes, the tab says "bash" when not being busy, which then states the currently running app. Instead of "bash" it could also just say "--" IMO.

Did that in hrev39528. When the shell is active, it doesn't mean one has a prompt, though (e.g. try "while true; do echo; done").

Yeah, 9) is a bit on the playful side. It made more sense when the tabs still were non-descript to have some sort of colour-coding. I'd be content closing that one, too.

*phew* ;-)

Which would leave the CTRL+F thing of 1). I do see some sense in that. If you have CTRL+W to kill what's left of the cursor, why not CTRL+F for the stuff on the right...

I believe Ctrl-F is mapped to "move cursor forward" by the termcap xterm entry (guess what Ctrl-B does! :-)). We could override that, of course, but I'm kind of reluctant doing such a thing. Does any distribution of a UNIXish system use such an override?

[humdinger]

Can't find anything regarding CTRL+F killing the word to the right... I guess it's better not to brew our on keybindings in bash. What do you say we mark this ticket as fixed then?

[diver]

How about showing process name that is still running while closing a tab?
e.g. "A process "ssh" is still running. If you close the Terminal/tab? this process will be killed."

[bonefish]

Replying to humdinger:

Can't find anything regarding CTRL+F killing the word to the right... I guess it's better not to brew our on keybindings in bash. What do you say we mark this ticket as fixed then?

Fine by me.

Replying to diver:

How about showing process name that is still running while closing a tab?
e.g. "A process "ssh" is still running. If you close the Terminal/tab? this process will be killed."

Yes, I already thought about that, too. The change is rather simple, but since one would probably want a list of *all* running non-shell processes when closing a window with several tabs and didn't know how to present that to the user (we don't have locale API support to insert such a list properly into a sentence) I refrained from touching that at all. Maybe better open a new ticket.