I am looking for some kind of "Console View" like it is available for example in Eclipse.
Currently a terminal / shell opens when executing a script in Geany. In this shell one can see the process streams stdout and stderr and can write to stdin of the new process.
However, I would rather eliminate this new terminal window popping up and changing focus each time I launch a script in Geany. I think it is better to have the process communication (stdout, stdin, stderr) embedded in a view within Geany like it is done in many IDEs. The different streams could be colored e.g. stderr in red and stdin (input from the user) in green.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675
Menu->preferences->Execute programs in the VTE
The streams can't be coloured since the program may want to apply its own.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#issuecomment-145392321
Closed #675.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#event-426351379
Closed since its already implemented
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#issuecomment-145406149
This is actually what I was looking for. Problem is that it is not available on Windows. Any chance it will be available for Windows in the future? I think it is an important feature for a cross-platform IDE such as Geany.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#issuecomment-145470112
Unfortunately the library that provides the embedded terminal [libvte](https://github.com/GNOME/vte) is not available on Windows, see [here](https://bugzilla.gnome.org/show_bug.cgi?id=369310). No noise since 2010, no fixes since 2008, doesn't look likely soon.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#issuecomment-145484269
Re-opening with new title and "enhancement" label. It's even possible to do this without using libvte, by using the Win32 console API, but it's highly unlikely to be implemented by the core team, so if anyone is interested, they will likely have to provide the code themselves.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#issuecomment-145702896
Reopened #675.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/675#event-427419791
this would be THE feature to make Geany by FAR the best editor/ide/tool for learning and quick programming in the world. Everything else about it is simple, fast, and perfect. I, myself, would finally be able to uninstall DOZENS of (large) editors/ides if only i got a terminal from within geany on windows.
I cannot fathom why the devs would not make this a priority...........................
what a shame/missed opp....................
btw, the point of the embedded term would be to run things like ruby/python shells (maybe even a lisp repl...) to complement your coding. it wouldn't replace the 'pop out' console on execute (unless u want....i certainly wouldn't). imo, that of a beginner learning multiple langs, this would perfect a near perfect product.
Dear John,
As the library that provides the terminal does not run on windows Geany cannot provide it on windows. Please complain to the VTE project that provides that library. https://github.com/GNOME/vte
Thanks Lex
On 5 April 2017 at 02:43, John notifications@github.com wrote:
btw, the point of the embedded term would be to run things like ruby/python shells (maybe even a lisp repl...) to complement your coding. it wouldn't replace the 'pop out' console on execute (unless u want....i certainly wouldn't). imo, that of a beginner learning multiple langs, this would perfect a near perfect product.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/675#issuecomment-291559994, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxgTdrycsh60P3jGtVsaoYpGsmIq3fsks5rsnMjgaJpZM4GIo57 .
The Python REPL works on Windows with GeanyPy, but something more general would be much more work. It's probably unlikely VTE would ever support Windows either since it doesn't have TTYs and is so fundamentally different.
If anyone feels like implementing it, the most likely routes would be either scraping a hidde/offscreen Win32 Command Prompt window/console or trying to adapt Mintty which emulates a real terminal on Windows (the one that comes with msys2 IIRC).
@Dragaan please try to combine messages into one, each single comment here emails around 70 people, and at least one mailing list.
What about a ConEmu as embedded term, like it is done in the Git Extention project? Here is an example of this: https://github.com/gitextensions/conemu-inside Has anyone considered this option? There is no FAR required.
@osevoso that might be suitable if it's written in native code and uses standard C/C++ that can be compiled on non-MSVC compilers and non-Windows OS (the nightly builds are cross-compiled).
ConEmu does not appear to be a GTK widget and therefore can't be embedded into a GTK application like Geany.
@codebrainz, the author [says](https://github.com/Maximus5/ConEmu/blob/master/src/HowToBuild.md#how-to-buil...) that ConEmu can be a compiled with GnuC on MinGW, not only MSVC. But, I meaned this within the confines for Windows speсially, where is no embedded terminal; not for whole project.
@elextr, ok, I did not know that it's impossible to embed a window in a GTK widget; it seems that was a unlucky idea.
I see no reason one couldn't embed a native win32 window in a GTK+ app; just get it's `HWND` and reparent it into a GTK+ widget's `HWND`. It might be fiddly, but it should be completely do-able.
@codebrainz pull requests are welcome :)
(in reality, if it was so easy "somebody" would have done it, but AFAGCT it doesn't exist)
I never said it was easy, just possible.
@codebrainz, @elextr, If GTK's widgets window have a native Handle, then it is possible to delegate the embedding job to ConEmu himself. By the [docs](https://conemu.github.io/en/InsideParent.html):
The only thing you shall implement or provide is some child window, which ‘HWND’ you pass as ConEmu.exe switch -insidewnd 0xHWND when you run the terminal. HWND is hexadecimal window descriptor.
Well try it. If it actually does work, fine, if not some more thinking is needed.
Would really love this feature!! (guess I'll struggle on with notepad++ for now :(
It would be amazing if this could be implemented.
@duttaditya18 Pull requests are welcome.
Windows has introduced a "PseudoPTY" interface to make it easier to implement console clients. https://devblogs.microsoft.com/commandline/windows-command-line-introducing-...
It's used by the new Windows Terminal, but should be picked up by others like ConEmu, meaning everyone can ditch the old hack of using a hidden window.
At the same time,. they've improved ANSI support.
Win32 console API
_@codebrainz at https://github.com/geany/geany/issues/675#issuecomment-145702896_
"PseudoPTY" interface
_@ stuaxo at https://github.com/geany/geany/issues/675#issuecomment-625797056_
does anyone know how Jupyter, and vscode does it? both are browser based, so, maybe they've no similarity with here, but who knows.
both are browser based, so, maybe they've no similarity with here
Correct, Geany is not browser based, therefore no relevance.
"somebody" needs to find a library that exposes a GTK terminal widget on windows, preferably porting VTE so the API remains the same.
I also recently found one more application: java terminal widget [JediTerm] (used by [trolCommander]). It comes from JetBrains and is hosted [here] on github.
But I don't think that would work either...
[JediTerm]: https://www.opensourceagenda.com/projects/jediterm [here]: https://github.com/JetBrains/jediterm [trolCommander]: https://trolsoft.ru/en/soft/trolcommander#:~:text=programm%20based%20on-,Jed...
@yashpalgoyal1304
But I don't think that would work either...
Correct. Geany and GTK are not Java.
Just an aside for Windows users, has anybody tried Geany on WSL? IIUC thats a Ubuntu container that should "just work"?
Geany on WSL ... Reference
thanks @ elextr for the nudge.
One more idea, how about - providing the vte/libvte as an msys2 package (for the msys subsystem)? - the same `PKGBUILD` [package receipe] for providing lib/vte to arch linux can be a good starting point for that.
[package receipe]: https://www.msys2.org/wiki/Creating-Packages/
the msys subsystem of msys2 supports linux applications.
It provides a Unix-like environment, ... The msys subsystem provides an emulated mostly-POSIX-compliant environment ...
- [MSYS2-Intro]
[msys2-intro]: https://www.msys2.org/wiki/MSYS2-introduction/
First sentence on msys2 website (my emphasis):
MSYS2 is a collection of tools and libraries providing you with an easy-to-use environment for building, installing and running __native Windows software__.
Also google found https://github.com/msys2/MINGW-packages/issues/6929#issuecomment-1204687234
So I don't like your chances, if it was as easy as a recompile somebody would have done it by now, lots of things would use it, not just Geany.
To be clear (at least about my understanding, reality may be different :-)
Msys2 software still runs native on windows, so it can't use any facilities that windows doesn't provide, like ptys needed for libvte.
WSL is a full Linux distro running in a VM, so its software runs on Linux, so just about all Linux facilities are available, so a user level application like Geany should run. Speed would depend on the VM and the VGPU.
found one more vte - though in rust this time :(
[alacritty/vte](https://github.com/alacritty/vte) ( via: https://github.com/helix-editor/helix/issues/1976#issuecomment-1091074719 )
As alacritty/vte says itself, "not itself sufficient for writing a terminal emulator" and as the comment in helix says:
A fully functioning xterm environment is [a lot of work](https://github.com/zellij-org/zellij/tree/main/zellij-server/src) and slightly inefficient as pointed out by the comment above, we need to re-parse all possible terminal escape sequences and reinterpret them (https://github.com/alacritty/vte can help but that's just the parsing bits).
It might be easier if "somebody" used another read-only Scintilla widget with a lexer that interpreted escapes and highlighted text accordingly to make a VTE. The exact details are left as an exercise for the reader ;-)
used another read-only Scintilla widget with a lexer that interpreted escapes and highlighted text accordingly
The `errorlist` lexer used for SciTE's output pane has some code for interpreting a limited set of ANSI escape sequences which is enabled with the `lexer.errorlist.escape.sequences` setting along with setting styles 23, 24, and 40 to 55 for the basic and intense colours. It isn't enough for more complex applications but shows colours for simple cases. The escape sequences are still there in the text as style 23 which is `notvisible`.
Here is grep with the `--color=always` option like `grep --color=always --line-number GdkAtom *.h` 
Its not as useful as a real VTE.
Neat, thanks Neil, thats pretty much how I thought it could work. And that could also solve #3380 maybe by replacing the custom Geany GTK treeview code.
Its not as useful as a real VTE.
Sure, but its a start, and its as portable as Geany so it could be used on all platforms, and all would benefit from improvements.
Its unlikely that an embedded terminal in Geany will need to be good enough to run vi or emacs, but it probably needs to support GNU readline's escape sequences.
holly molly.. just stumbled upon this paragraph in [termite#readme] while searching for [dirs] this provided a many fold increase to my love for gtk too 🤣😘
[termite#readme]: https://github.com/thestinger/termite#readme [dirs]: https://alternativeto.net/browse/search/?q=dirs
https://github.com/thestinger/termite/blob/18de7682e983e6562a87c63a2814c5e39...
VTE is a terrible base for building a modern, fast and safe terminal emulator. It's slow, brittle and difficult to improve. VTE is treated as simply being the GNOME Terminal widget rather than a library truly intended to be useful to others.
They've gone out of the way to keep useful APIs private due to hostility towards implementing any kind of user interface beyond what they provide.
In 2012, we submitted a [tiny patch exposing the APIs needed for the keyboard text selection, hints mode and other features](https://bugzilla.gnome.org/show_bug.cgi?id=679658). Despite support from multiple other projects, the patch was rejected. It's now almost a decade later and no progress has been made. There is no implementation of these kinds of features in VTE and it's unlikely they'll be provided either internally or as flexible APIs.
This is the tip of the iceberg when it comes to their hostility towards other projects using VTE as a library. GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use.
The speed is much much better in the current release.
I had a read through that thread, I don't think the project was against the functionality, but wanted APIs internally for it, which included APIs for pausing output and keyboard control and selection from the keyboard.
So while the implementation in the patch may have been rejected, at least one current bug is open on the VTE gitlab
https://gitlab.gnome.org/GNOME/vte/-/issues/588
github-comments@lists.geany.org