The Terminal used to "re-use" icons from org.eclipse.ui.console -
this did not work any more when that plugin changed .gif icons
to .png for better HiDPI support. Copying icons into the terminal
view plugin resolves the problem for all Eclipse versions.
Collect the list of connection types that support the command shell
service and pass that to the RemoteConnectionWidget so that you can
select which one you want.
Also adds a fix to the connection manager that was closing the
terminal of read returned 0 bytes. That's generally not an end of
file condition, especially with Serial Ports. There ugliness to them
where you can't close the port while it's blocked on the read, which
means it needs to return once in a while.
Fix setting of title and force new to match the other delegates.
Change-Id: I6b78d789ca28284379d8f1136062ec180e1a8f5c
Signed-off-by: Doug Schaefer <dschaefer@blackberry.com>
Added the menu contributions to
popup:org.eclipse.jdt.ui.PackageExplorer?before=group.edit additionally
to the ProjectExplorer contributions.
Change-Id: I1438057d82389c332c3678a3568bf0706497b49f
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
There are two versions of RSEInitJob.waitForCompletion:
waitForCompletion()
waitForCompletion(int phase)
The waitForCompletion() version ensures that the job has been scheduled
before waiting for it, but not the waitForCompletion(int phase)
version. Therefore, if the waitForCompletion(int phase) version is
called first, the calling thread can end up waiting for the completion
of a job that has never been started.
I got in this situation by disabling the auto-start of the RSE UI plugin
(in Window, Preferences, General, Startup and Shutdown). Trying to
create a remote launch in CDT calls waitForCompletion(int phase),
therefore freezing the entire Eclipse. When the auto-start of the RSE
UI plugin is enabled, the waitForCompletion() version is called during
the initialization of that plugin, so the problem did not appear.
The suggested fix is simple, just move the code that ensures the job has
been scheduled from waitForCompletion() to waitForCompletion(int phase),
so that the job can be scheduled by both versions (since the former is
implemented by calling the later).
Change-Id: I9f6e5f948c3dbf1be60ddf04af5adbdfcaf3a7eb
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Added auto-detection of Git installations on Windows
Change-Id: I42702126ffb550dd8b289a45ee552d5095a1a615
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Added external executables to the terminal combobox on the Open Terminal
Dialog (Ctrl+Alt+Shift+T)
Change-Id: Ia9d9a3959fd95b666c4a1ad4474b519103297920
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Moved the code and all related configurations regarding showin from
o.e.tm.terminal.connector.local to o.e.tm.terminal.view.ui
Change-Id: If548ae729173c6127f7cf918aa2f783cd6cb3961
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Introduced an ISourceProvider to check if external executables are
configured. Renamed the Terminal context menu "Show In" to "Show in
Local Terminal". Extended the visibleWhen check so that the "Show in
Local Terminal" menu is only visible in the context menu if an external
executable is configured. Otherwise it is possible to open the Terminal
via the inclusion of the command in the default "Show In" menu.
Change-Id: I618b2352a8973d6591cf9e673dc4eb01aeec072e
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
When TM Terminal sees this:
ESC [ 5 n
It replies indicating that the terminal is OK:
ESC [ 0 n
This escape sequence is documented here:
8.3.35 DSR - DEVICE STATUS REPORT. Page 40.
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf
Motivation: I'd like to switch winpty from using DSR(6) to DSR(5) as its
ESC flushing command. When winpty sees a bare ESC, it can either
synthesize a VK_ESCAPE keypress or wait to see if the ESC was part of some
other escape sequence. It tries to deal with this by generating a DSR(6),
which should flush out the remaining bytes of the sequence, if there are
any. DSR(6) is suboptimal, though, because the reply collides with the
sequence some terminals use for F3 with a modifier:
ESC [ nn ; nn R
DSR(5) generates a DSR(0) reply, which does not have the same problem.
DSR(5) is supported by all the terminal emulators I tested, including
xterm, rxvt, rxvt-unicode, gnome-terminal, konsole, putty, mintty,
OS X's Terminal.app, and IntelliJ/jediterm.
Signed-off-by: Ryan Prichard <ryan.prichard@gmail.com>
