Community
Participate
Working Groups
It would be interesting to be able and embed the Terminal Widget as a Console in the Eclipse Console view (by creating a bridge between the Terminal Widget and IConsole). With a custom kind of Terminal Launcher, this would allow showing Terminal Views in the Console view which might simplify some perspective setup. But what would be even more interesting, is have the Terminal Widget be an implementation of the Debug Console, such that arbitrary Launches (debuggees) could have a choice between writing to the normal Console, or the Terminal-Console. This would allow for easier debugging of programs that require a Terminal. "External Tool" kind of Launches could also benefit from the ability to have its I/O in a Terminal widget. It might be necessary to put a hook into Platform/Debug in order to allow Launches (or "External Tools" debuggees) select a particular kind of Console. Another problem might be how to handle Terminal Resizing when the widget is embedded in a Console; especially given the fact that multiple Console views can show the same Terminal in different sizes in one perspective. When this request is implemented, the Terminal implementation of IConsole should be available as official API such that extenders can programmatically open a Terminal in the console view.
Created attachment 112381 [details] Project set for some experimental code that implements a terminal as an IConsole Coincidentally, I started working on something like that last year. At that time, I had never heard of the DSDP/TM project, and only when I tried submitting my idea to tigris.org someone there suggested to contribute to DSDP/TM rather than starting my own very similar project. My approach doesn't actually replace the console's original UI controls but implements an IConsolePageParticipant and directly manipulates the console's TextConsoleViewer, as well as the viewer's IDocument and its StyledText control. My implementation is just a proof of concept, but basically it's possible to make the existing console UI behave like a terminal if one intercepts the right events, etc. However, the code is "hacky" in some aspects, as it makes assumptions about the internal structure of other objects. For example, it just assumes that the control returned by TextConsolePage.getControl() is a StyledText, which it happens to be, but essentially the code relies on an implementation detail here. You'll find plenty of magic casts in my code that all happen to work at runtime, but will fail if some internals are changed at some point in the future. The interesting source code with regards to bug 242373 is probably in package net.sf.eshell.console and partially in net.sf.eshell.process. The plug-in actually uses its own launch configuration type with custom IProcess and IProcessFactory implementations. That part actually worked pretty well, and defining a new launch configuration type for terminal-based launches is probably also a good idea for bug 196337. Anyway, feel free to study, try, and reuse my code. I only implemented cursor-up and some simple backspace processing. To get terminal semantics, you will need to use something like the ptyalize executable (https://bugs.eclipse.org/bugs/attachment.cgi?id=110783).
P.S.: "eshell" is obviously a misnomer as the plug-in doesn't actually provide a shell of any kind. Also, I just used the "net.sf" package prefix tentatively; the code was never submitted to SourceForge.
Many thanks Mirko! Given your insight, I'm actually very interested in how the Platform could be improved to support such improved Consoles in a clean manner. Given that the kind of Console Renderer that you'd want to have is not necessarily dependent on the Launch only, but likely also dependent on the kind of application you launch, I'd think it would be interesting to have e.g. an org.eclipse.debug.ui.consoleRenderer extension point. Then, on every Launch's "General" tab that deals with the Console handling, the user could be presented a selectable list of console renderers. This would open exciting possibilities, e.g. * Have some apps run in a Terminal * Other apps which print tracing info with filename:lineno kind of output provide a console with clickable hyperlinks to navigate into those files * Remote apps provide their console through a custom contributed channel If that sounds reasonable to you, we should probably search for such a bug on the Platform/Debug component, or file a new bug for it. Of course, other ideas for such functionality are welcome too!
I think that's a great idea! I'm currently in the process of cleaning up the original hack in my LocalTerminalProcess class for bug 196337. With an extension point and API as you suggested none of the hacky business would be necessary at all. Right now, the ProcessConsoleManager allocates a console for every IProcess that has a non-null IStreamsProxy and whose process attributes indicate that console output should be captured. I already indicated in my earlier commentary in the LocalTerminalProcess class that is not a good method of determining whether a console is necessary. This information should be read from the launch configuration attributes and should not be based on whether or not the IStreamsProxy is null. To take this idea further, just as you suggested, the launch configuration would not only contain information about whether or not a console should be allocated but actually a console renderer attribute that states specifically what kind of console, terminal, or other rendering device should be opened. Right now, the launch configurations for external tool launches already contain two attributes relating to the allocation of consoles: - DebugPlugin.ATTR_CAPTURE_OUTPUT - IDebugUIConstants.ATTR_CAPTURE_IN_CONSOLE There should be an additional attribute that specifies which console renderer is to be used, and the ProcessConsoleManager should only allocate a standard console if this new attribute is not set or has a default value.
(In reply to comment #4) > There should be an additional attribute that specifies which console renderer > is to be used, and the ProcessConsoleManager should only allocate a standard > console if this new attribute is not set or has a default value. Or the specified renderer is not installed in the current Eclipse -- note that Launch Configurations can be shared in a Team, and not every Team member may have the renderer specified in the Launch. I guess the standard renderer should be used in that case, with a warning logged. I find it interesting that Java Launches do provide some customized rendering, that is stacktraces are rendered in a form that has "hyperlink" like behavior for navigating into the editor. Do you know how that's done?
(In reply to comment #5) > I find it interesting that Java Launches do provide some customized rendering, > that is stacktraces are rendered in a form that has "hyperlink" like behavior > for navigating into the editor. Do you know how that's done? I'm not sure what the exact mechanism is. The IConsole interface has an addLink(...) method, which, I assume, is used to achieve the hyperlink decorations. Probably, you can find out by setting a breakpoint in one of those methods. Those hyperlinks were the original reason why my eshell project attempted to reuse as much as possible of the existing UI elements, rather than creating a new UI element.
+1 for this. Bug 112948 will get fixed too if this is fixed :)
I see lot of useful discussion in for this feature. So, is this finally implemented. In latest Eclipse Help Documentation, I don't see any Eclipse ConsoleRenderer Extension Point. This is very much required feature. Current console implementations used for Debug/External Tools do not show the prompt. Please let me know if there is some way to get the prompt. Even cursor is not very well positioned. However Terminal view from TM project is very well implemented supporting proper unix commandline. It shows the prompt and handles input/output correctly. So, is their plan to make this Terminal view in main stream. which can be reused by other clients
We don't currently have any committers working on this, but would consider contributions in the form of patches. Mirko: attached project set points to a CVS repo that doesn't seem to exist any more, do you still have the code and could you attach it ? -----ERROR from Import PSF------ The following errors occurred while importing projects. Some projects may not be loaded. Could not connect to :pserver:anonymous@cvs.eclipsemail.org:/srv/www/vhosts/eclipsemail.org/private/CVSROOT: Cannot locate host: cvs.eclipsemail.org cvs.eclipsemail.org
(In reply to comment #9) > Mirko: attached project set points to a CVS repo that doesn't seem to exist any > more, do you still have the code and could you attach it ? Hm, I abandoned that repository about 2 years ago... Let me see if I can reactivate it or if I still have the source code somewhere else. I'll get back to you...
Created attachment 213957 [details] Original sources for IConsole experiment I pulled the original sources from my old Sun box. I haven't looked at them, but they were written for Eclipse 3.4 and might not compile without modifications. Let me know if you have any questions (I'll answer, if I can remember...).
The Terminal component of the Eclipse Ecosystem has a new home. The Terminal is now part of the Eclipse CDT project[1]. This change means a new Git repo[2], P2 site[3] and Bugzilla component. The terminal will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well. The marketplace entry[4] had not been updated in a few years. It will once again install the latest release of the terminal on the latest release of the whole IDE (currently 2020-03). If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment. [1] https://wiki.eclipse.org/CDT/User/NewIn911 [2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the terminal directory) [3] current release is 9.11 - P2 site https://download.eclipse.org/tools/cdt/releases/9.11/ [4] https://marketplace.eclipse.org/content/tm-terminal (This comment was added to all open terminal bugs along with changing the Product/component pair to CDT/terminal.)
