Find file
Fetching contributors…
Cannot retrieve contributors at this time
415 lines (338 sloc) 22.1 KB
Bugs
----
* Can we cause Terminator to be offered in "Preferred Applications" on Linux?
At the moment, users have to choose "Custom" and enter our details.
It looks like we need something like this in "/usr/share/gnome-control-center/gnome-default-applications.xml":
+ <terminal>
+ <name>Terminator</name>
+ <executable>terminator</executable>
+ <command>terminator</command>
+ <icon-name>terminator</icon-name>
+ <exec-flag>-e</exec-flag>
+ </terminal>
GNOME being GNOME, there's no reasonable way for applications to add/remove themselves as they're installed/removed, because that would be too sensible.
Interestingly: https://bugs.launchpad.net/gnome-control-center/+bug/184635
Which turns out to be a different terminal emulator called Terminator:
https://bugs.launchpad.net/gnome-control-center/+bug/184635
So it looks like this will resolve itself in GNOME 2.21, but that we might have confusion surrounding our name.
Lucky that our package is "org.jessies.terminator"; that should keep us out of trouble.
* We're using the WiX installer to create registry keys like those suggested by http://www.burgaud.com/open-command-window-here/.
That causes the .msi to fail Orca's ICE33 validation check.
No-one seems to have ever used WiX to generate associations with Directory and Drive, only with new and generally bogus file types. This was one of my unsuccessful attempts:
<Extension Id='OpenHere_Directory' Advertise='yes' ContentType='Folder'>
<Verb Id='OpenHere_Directory_Verb' Sequence='10' Argument='[projectResources]bin\\$(env.MACHINE_PROJECT_NAME)" --working-directory "%L"' Command='Open $(env.HUMAN_PROJECT_NAME) Here' />
</Extension>
* The selection is cleared a little over-zealously when text changes: if
the text changes are above the selection, the selection is still changed
even if the selection contents were not changed.
* If you double-click or triple-click select, and then shift-click to extend
the selection, our behavior is undesirable. I wouldn't like to swear I know
exactly what the right behavior is, but ours is without question wrong.
* car: notes on the following bugs:
I've been having problems with vi, bash, tcsh, long lines. All hosts
used have up to date copies of terminator.tic in the appropriate
system-wide location. You can assume that I've checked all of these
on a local OS X box, a remote Debian box (jessies.org,) a remote
Solaris 8 box, a remote Solaris 10 box and a remote FreeBSD 6.0 box
and that any platform not mentioned did not display the bug. You can
also assume that other terminal emulators I've used (xterm, PuTTY,
Terminal) have not shown these bugs to my memory, but I've made only
a cursory effort to verify this. Logged in over ssh to remote
hosts. I'm reporting these because they're interfering with my
work.
* car: "Problem 1"
First, deleting a line from vi. This is demonstrable on remote
Solaris 8 and 10 machines, and remote FreeBSD 6.0.
Open terminator.tic, scroll so that no long lines are visible (to
prevent confusion with what is potentially a different bug,) cursor
in this example is on the third from bottom line:
http://www-users.york.ac.uk/~car7/terminator/vi%20dd%200.png
Type 'dd' to delete the current line. Instead of the current line
disappearing and lines below shifting up one, the whole screen shifts
up one line:
http://www-users.york.ac.uk/~car7/terminator/vi%20dd%201.png
Type 'u' to undo 'dd'. Old line is reinserted where it was removed,
lines below shuffle down. But lines above cursor position are still
displaced:
http://www-users.york.ac.uk/~car7/terminator/vi%20dd%202.png
Use Ctrl-l to redraw, display is as it should be:
http://www-users.york.ac.uk/~car7/terminator/vi%20dd%203.png
enh's notes:
looks like it could be the "cud" and "cuu" sequences, but
remove those from the terminfo and the behavior's still wrong.
'dd' on the middle line (from 'M') of bkmakeall with Solaris vi:
2005-12-28T14:24:24.378-0800 Terminator: Processing escape sequence "[1M"
2005-12-28T14:24:24.378-0800 Terminator: Processing escape sequence "[18B"
2005-12-28T14:24:24.378-0800 Terminator: Processing escape sequence "[K"
2005-12-28T14:24:24.378-0800 Terminator: Processing escape sequence "[18A"
2005-12-28T14:24:24.379-0800 Terminator: Processing line "mail_raw_log="
2005-12-28T14:24:24.379-0800 Terminator: Processing special char "CR"
with Linux vim:
2005-12-28T14:30:58.438-0800 Terminator: Processing escape sequence "[?25l"
2005-12-28T14:30:58.438-0800 Terminator: Processing escape sequence "[20;39r"
2005-12-28T14:30:58.438-0800 Terminator: Processing escape sequence "[39;1H"
2005-12-28T14:30:58.438-0800 Terminator: Processing escape sequence "[1;40r"
2005-12-28T14:30:58.439-0800 Terminator: Processing escape sequence "[39;1H"
2005-12-28T14:30:58.439-0800 Terminator: Processing escape sequence "[40;1H"
2005-12-28T14:30:58.439-0800 Terminator: Processing escape sequence "[K"
2005-12-28T14:30:58.439-0800 Terminator: Processing escape sequence "[40;63H"
2005-12-28T14:30:58.439-0800 Terminator: Processing escape sequence "[10C"
2005-12-28T14:30:58.440-0800 Terminator: Processing escape sequence "]2;bkmakeall + (~/Projects/misc/tools/scripts) - VIM\u0007"
2005-12-28T14:30:58.449-0800 Terminator: Processing escape sequence "[20;1H"
2005-12-28T14:30:58.449-0800 Terminator: Processing escape sequence "[?25h"
2005-12-28T14:30:58.449-0800 Terminator: Processing special char "CR"
2005-12-28T14:30:58.449-0800 Terminator: Processing special char "LF"
2005-12-28T14:30:58.449-0800 Terminator: Processing line "mail_raw_log="
2005-12-28T14:30:58.450-0800 Terminator: Processing line "19,1"
2005-12-28T14:30:58.450-0800 Terminator: Processing line "Top"
* car: "Problem 2"
On remote Solaris 8 and 10 boxes, vi has trouble with wrapping long
lines. Shown here are the same file, opened in vi:
http://www-users.york.ac.uk/~car7/terminator/vi%20terminator.tic.png
And the same file opened with head:
http://www-users.york.ac.uk/~car7/terminator/head%20terminator.tic.png
enh's notes:
this one's weird; it really does look like Solaris vi is going
out of its way to do the wrong thing with all those extra CR LF sequences.
solaris:
2005-12-28T15:13:52.434-0800 Terminator: Processing line "#{ Sample crontab"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "CR"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "LF"
2005-12-28T15:13:52.434-0800 Terminator: Processing line "05 02 * * * for r in misc docs marlin stingray; do cd \$HOME/work/\$r; ../misc/t"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "CR"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "LF"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "CR"
2005-12-28T15:13:52.434-0800 Terminator: Processing special char "LF"
2005-12-28T15:13:52.435-0800 Terminator: Processing line "ools/scripts/bkmakeall; done"
2005-12-28T15:13:52.435-0800 Terminator: Processing special char "CR"
2005-12-28T15:13:52.435-0800 Terminator: Processing special char "LF"
2005-12-28T15:13:52.435-0800 Terminator: Processing line "#}"
linux:
2005-12-28T15:15:12.252-0800 Terminator: Processing line "#{ Sample crontab"
2005-12-28T15:15:12.252-0800 Terminator: Processing special char "CR"
2005-12-28T15:15:12.252-0800 Terminator: Processing special char "LF"
2005-12-28T15:15:12.252-0800 Terminator: Processing line "05 02 * * * for r in misc docs marlin stingray; do cd \$HOME/work/\$r; ../misc/t"
2005-12-28T15:15:12.253-0800 Terminator: Processing line "ools/scripts/bkmakeall; done"
2005-12-28T15:15:12.253-0800 Terminator: Processing special char "CR"
2005-12-28T15:15:12.253-0800 Terminator: Processing special char "LF"
2005-12-28T15:15:12.260-0800 Terminator: Processing line "#}"
* car: "Problem 3"
Another vi redraw problem, this time when scrolling. Ctrl-f and Ctrl-
b do not demonstrate this problem. Again, using vi on remote
Solaris 8, Solaris 10, FreeBSD 6.0. Open random file with
indentation. Scroll up and down with the cursor in column zero, all
is well. Scroll up and down with the cursor in column 7, random bits
of text to the left of the cursor don't get drawn. When I say
"random" I do pretty much mean it. I can't see any rhyme or reason.
It's not like text to the right of the cursor is always safe, or that
the same bits of text disappear. There's no pattern that I can see,
though that doesn't mean that there isn't a pattern there:
http://www-users.york.ac.uk/~car7/terminator/vi%20pre%20C-l.png
Hitting Ctrl-l redraws and everything looks just dandy:
http://www-users.york.ac.uk/~car7/terminator/vi%20post%20C-l.png
Moving the input cursor left to right over the missing text causes it
to be redrawn. Right to left does not.
enh's notes:
i couldn't reproduce this, either with a '\t'-indented file or
a ' '-indented file. more information needed. (i don't doubt there is a
problem, because i remember seeing something like it in the short time i
ran Solaris at home.)
* car: "Problem 5"
Finally, scrolling through tcsh command history on any platform
tested can result in text being mistakenly drawn at the bottom of the
screen. Just start tcsh, type one command, scroll up until you get
bell for no more, down until you get bell for no more, repeat and lo:
http://www-users.york.ac.uk/~car7/terminator/tcsh%20command%20history.png
enh's notes:
we've already agreed that this can't be reproduced as described. i've
learned nothing further.
* car: "when I have multiple rows of tabs on the XP LAF, should a top-row
tab's activity indicator overlap the highlight on the top of the tab below?"
I didn't realize this wouldn't be clipped. Nor did it occur to me that
non-front tabs have different dimensions than front tabs. It would be nice
to make the indicator more scalable, but at current DPIs, it's already about
as small as it can conveniently be. Unless anyone has a cunning plan (that's
practical and doesn't involve turnips), I think that's just something for
the to-do list, waiting for high-DPI displays. (Or we could just switch to
a binary activity indicator. I'm not really sure how useful the current
cleverer solution actually is.)
* mad: We don't meet the Debian Policy's command line requirements for an x-terminal-emulator.
When we've fixed that, here's the code to offer ourselves:
update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/terminator 50
update-alternatives --auto x-terminal-emulator
Configuration
-------------
* Should allow the user to specify a log filename per tab, on the command line.
Mail chrisa@bluearc.com when this is done, because he wants to use it.
* car: "Not so long ago, when I was a SuSE/konsole user, and even back when I
was a student using xwsh, I'd have a few different default sets, for
different tasks, like tailing log files or ftping the output of xfig
over to the AIX box I was writing my troff on. It'd be cool to have
terminator recognize the title of my window (set by me opening a "New
Command") and say "hey, dude's tailing query.log again, best drop the
font size to 8 points and the terminal width to 132 characters." You'd
only have to recognize it once, when the window is created, and that way
you could even have your different defaults for different shells, if you
were that way inclined. Doesn't sound like rocket science, but then
again it does sound a bit "green courier on black." PuTTY does allow
you to do the same thing, in a roundabout way." Several people I know use
terminals in this kind of way, with (effectively) per-title settings.
Personally, the only interest I've ever had for it was in distinguishing
local and remote windows. I can't think how to do any of this without making
the existing configuration problems worse, though.
Security
--------
* On Mac OS, we should probably do what Terminal does to subvert keystroke
logging (http://www.cocoadev.com/index.pl?SecureKeyboardEntry). There's
also a good post on the alluded-to problems Apple warns about:
http://rentzsch.com/macosx/terminalSecureKeyboardEntry
Performance
-----------
* Our sideways-scrolling performance is weak when we have long lines. We don't
take the clip rectangle into account to try to avoid work, and ask
Graphics.drawString to render really long lines. On Mac OS, at least, this
isn't a very good idea; even with a monospaced font, it seems to assume
you've done the clipping yourself. [This seems mainly to be a problem for
VNC users, not real people.]
RFEs
----
* Our double-click selection may be pretty clever in situations where xterm
and rxvt aren't, but it doesn't work as well in situations they're good at:
numbers in situations such as "offset=1234,length=5678". No-one does IP
addresses well, that I've seen. [I take that back; Apple's Terminal does a
pretty much perfect job. It has bracket matching, too.]
Add bracket-matching double-click selection. This and better double-click
selection are hard because we don't have anything that lets us iterate over
the model as if it were a String. That would be the right way to implement
this stuff; a TerminalModel.asCharSequence method.
2006-09-12 Elias Naur asked for user-customizable stop characters (aka word
separators). Specifically, he wanted to add '.' for Vim-editing-Java use.
* We should be able to "Copy With Styles" so we can paste color output into
a mailer or whatever, and preserve the formatting. Presumably we can put
HTML data on the clipboard? [See elliotth's blog for details.]
* the absence of system wide C-`/C-~ functionality would make cycling through
windows even more useful on Linux, so maybe we should support alt-` and
alt-~ there? The obvious problem with this is that on Linux it's likely that
you have several different Terminator processes, and you'd want to cycle
through all the Terminator windows regardless of process. This is probably
best done by the window manager.
* There are some interesting features and bugs mentioned on the Konsole
ChangeLog page: http://konsole.kde.org/changelog.php
* car makes an argument for not having window-modal confirmation like Terminal
does: "Where Terminal gets it wrong, though, is that it blocks input to the
terminal while it's asking me to confirm. Canceling the shutdown so
that I can hit ^:wq and then starting the shutdown again is a pain".
The extended AWT modality API in Java 6 should let us address this, though
it's not easy to use while we have to maintain compatibility with Java 5.
* Before using Terminator, I used rxvt, so I'd have done the same as Phil and
used rxvt's terminfo. I was recently looking at the state of rxvt, before
submitting a Debian bug. It's pretty moribund, as far as releasing is concerned.
rxvt's terminfo is quite different in some versions to the version Phil copied.
gnome-terminal (which has relatively clear source) emulates xterm. Terminal.app
emulates xterm-color. We can't be xterm because we don't have auto-margin
but we could work better if you set TERM=xterm. When we go through the
terminfo, we should abandon rxvt compatibility and switch to xterm.
If we got this sorted out, then we could submit our termcap to Cygwin
and so side-step cgf's reluctance to use terminfo, stated here:
http://www.cygwin.com/ml/cygwin/2000-05/msg01012.html
We could probably move towards this by responding to xterm's capabilities
as well as those rxvt ones that we currently advertise.
If we can support both sets, then we can advertise xterm's and deprecate rxvt's.
TERM=xterm less ~/.profile and see that the window doesn't clear for an example.
* Simon Pamies [s.pamies@banality.de] isn't the only user to have suggested
some way of saving a file which can be loaded to start a new Terminator window
with several New Command Tabs, each with its own bgcolor and name.
Colored backgrounds to distinguish different sorts of window, in particular,
seems popular.
* Andy Bushell [andrew.bushell@imperial.ac.uk] suggests an "anti-idle" feature
that writes ASCII NUL on the connection at a fixed interval to stop sshd (say)
from closing the connection.
* Stuart Bell suggests that if the terminal is a non-integer multiple of the
line height, "spare" space should be at the bottom of the terminal. This
would mean that clear(1) in such a situation would not leave a partial line
visible at the top (which isn't inarguably wrong, but is ugly, and he at
least thought it was a bug).
* If there were any great demand for reinstatement of ixon, we could freeze our
output. We'd want to provide some visual indication of what we'd done and
how to undo it. We can't provide such an indication if we implement this in terms
of ixon, because we can't read the ixon state from the tty driver.
* 2006-11-02, car said: the list of processes thrown up is handy, although
apparently edit counts as "ruby" ;) I know why, but there might be other
situations where I didn't know what a process was doing, or couldn't
remember what was backgrounded, and it seems to me that that's the
point of this functionality. The amount of information displayed on
that warning is right, I'm just wondering if it would be much work to
make each processes clickable, and show some more information? A
plain dialog with a representation of the tree of processes rooted at
the process clicked? Or the full commandline of the process? Throw
it at Activity Monitor? :)
* Transparency.
I've looked in to transparency on Windows, and it's not realistic until there's support in Java.
People have tried JNI and no-one claims to have it working well enough that I think we could use it.
Linux users are starting to have compositing X11 servers, but it's still too broken for us to adopt.
Everything is too flaky for use, but Java applications are particularly unusable at the moment.
Also, I haven't seen any developer documentation about how we should use this stuff.
There are three approaches on Mac OS (not counting JNI), each with their own advantages and disadvantages.
* Mouse events. I only know of Vim and Midnight Commander that actually use
this stuff. Midnight Commander has hard-coded checks for various terminal
emulators and no way for the user to override it, so even if we did support
the same XTerm sequences, mc(1) wouldn't use them.
I don't know about Vim; going on past experience, it probably has a
hard-coded list but a setting for the user to override it with.
The only program I'd be likely to use mouse support in would be whiptail(1),
but it doesn't have mouse support at all.
* Ability to restart a command that terminates. If I get kicked off a TELNET
session in Bash, I can hit up-arrow return. If, though, I'd devoted a tab
to telnet(1), I have to create a new tab. It might be nice to add a little
"Run Again" button to the terminal when its process exits.
* Some kind of built-in log browsing/searching. Using grep(1) from within Terminator
causes trouble as the newly logged matches are themselves found.
* "You have <count> log files from <date> to <date> taking up <bytes> on disk."
* date/name-based search. (date-based is awkward because we only have *start* dates in filenames. we could use mtime to work out when the session ended, but people who keep a few terminals for a long time won't be much helped.)
* content-based search.
* "Remove All" / "Remove Old" (older than given date? 6 months?)
* Log timestamps seem to be requested relatively frequently. Either the ability
to manually ask to write a specific mark to the log or automatic timestamping
of every line. Proposed uses include:
* knowing exactly when something was done.
* being able to merge multiple logs to know what order events from different
logs occurred in.
* 2007-04-27 chrisa says:
I quite like the little circular "activity monitor" that you've added
to the top of the tabs (that you're not looking at) in terminator.
One minor comment - my preference would be for them to completely
disappear after N minutes of inactivity (rather than when you select
the tab).
For my purposes, I'd probably choose something like 1 minute for the
timeout.
Tab-related
-----------
* On Mac OS, Safari-style tabs would be much better than the usual Aqua ones
for our purposes. They take up significantly less space, and don't require
a border. We'd have to implement them ourselves, though.
There are two choices: we could use a UI delegate (there are a couple of
nice examples at http://blog.elevenworks.com/?p=5), or we could implement
our own component. The former is easier, but the latter is perhaps the
better idea. Other than improving appearance (and taking less space), it
would be good to offer more sensible behavior when the combined width of
the tab labels exceeds the window width (Safari, like most systems' tool
bars, adds a ">>" button to show a menu of the other tabs), and we could
offer arbitrary components in tab "ears" ahead of Java 6 (so we could
show that there's output occurring on a background tab, say).
I just noticed that Safari's tab abbreviation is intelligent in that it
won't repeat any prefix that appears on another tab. I haven't fully
characterized the behavior, but it certainly works pretty well. Of course,
we're a lot less likely to have tab titles containing separate words.
I wonder if -- in the absence of any way to get bash to interpret its $PS1
escapes so we can put them in the window title -- it's worth writing our
own program to set the window title?
* On Mac OS, if you resize a Terminator window, it flashes white as it
seemingly fills the background before we do. if you force the LAF to be
Metal, it works. so it's something to do with the Aqua LAF. it's not fixed
by calling setOpaque(true) in JTerminalPane's constructor. (It looks as if
the problem is that ComponentUI.update fills a component with the background
color, and our JPanel's background color -- thanks to Mac OS' JTabbedPane --
has to be the SystemColor for a panel. We work around this
for the single-terminal case, but the real solution is going to be
writing our own JTabbedPane UI delegate that's more like Safari's, and
doesn't rely on transparency.)