Julia: bundle Julia with a better terminal on Windows?

[lindahua]

+1

[tkelman]

That looks like a custom configuration wrapping up conemu, clink, and (optionally) msysgit. Clink is mostly readline, which we don't need any more. mintty might be an easier/smaller alternative to conemu.

[StefanKarpinski]

Yes, I think that's the deal. Since I don't use Windows myself, I'm somewhat uninformed about these tools, but I'd be more interested in making sure the experience is as nice as possible than minimizing the dependency size. Mintty just doesn't seem to look or feel as nice as cmder.

[tkelman]

I'm quite happy with mintty as used by Cygwin and MSYS2 (though there's still a bug making Julia not very usable inside mintty, I should check whether that's true in conemu), I don't see too much need for console tabs. There's some discussion of these and other alternatives in #6795

Any bugs that happen with whatever we choose would be harder to properly report or fix if we go with something that is a fork-of-fork-of-fork (or wrapper of wrapper of wrapper). Babun is another similar one of these projects that looks shiny, but is really just a custom configured version of Cygwin.

[quinnj]

Here's a crazy mastermind plan. Let's build a repl and/or IJulia notebook frontend for LightTable and ship with that!
But seriously, the more I've been poking around with LightTable, the more I can envision a proper "Julia IDE" being all baked in to a nice Julia plugin. It has all the extensibility to allow something like RStudio or MatLab IDE, but even better because you can do inline plots, or something notebook-ish where the program execution is "graph-based" instead of repl line-by-line. I think Mike's GSoC is a great start in getting the fundamentals in place, but there's a ton of potential there.

Anyway, I digress. I think mintty wounds like a good option here.

[tkelman]

I went through and tried a few of these options. cmder indeed looks decent.

With Console2 I was able to manually set it up to boot Julia (adding a Julia "tab" under the Settings - there's an xml config file so this could be automated) then running it as Console.exe -t Julia. Console2 didn't fix unicode display issues though. The default text select behavior is pretty awful, you hold left shift then click and drag. Holding a key to select can be omg-carpal-tunnel uncomfortable on a laptop.

I couldn't get cmder to start up Julia directly, but starting it manually worked okay, and displayed simple unicode properly. Cmder depends on the MSVC runtime dll's, was there a license concern in the particular terms under which you can redistribute those? The default selection behavior here was also left-shift (or right-clicking the icon, going to edit and switching to mark mode, same as in the default Windows console), but I found how to change it to not require simultaneous key+mouse.

ConEmu has some really annoying default behaviors, wanting to save its configuration in the registry by default, popping up a confirmation dialog every time I close it, etc. Was easy to start it directly in Julia, and simple unicode worked.

Mintty will take a little bit of work, but be the lightest and easiest option for users in the end. Some of the current issues with mintty are related to bigger libuv problems that will hopefully get fixed together. There's some code somewhere that tests specifically for Cygwin and MSYS2 named pipes, which I think would need to be checked and modified to work with the standalone download of mintty. We could maybe use MSYS2's version of mintty, but then we'd need msys-2.0.dll which is about 4x bigger than the msys-1.0.dll that we currently include as part of msysgit.

None of these options look to compile particularly easily with MinGW, and I wouldn't want to try cross-compiling. But just downloading the release binary should be good enough for these.

[StefanKarpinski]

@ihnorton, over here you said:

+1 for mintty for now. Based on my own experiences, I would be strongly opposed to packaging conemu.

can you elaborate on why over here?

[ihnorton]

@StefanKarpinski basically because every time I have tried it, too many things are just _off_. I don't remember all of the issues, but very clearly remember the worst one: it does bad things with subprocesses and makes spawning vastly slower than it already is on Windows.

noop.bat: @echo off

 julia> @time for i in 1:1000
       open(`noop.bat`,"r")
       end

time in seconds, two trials each:

    default console: 1.30,1.31
    cmder: 53.0, 61.6 (actually restarted twice more and got similar times)

In fact, my mouse starts freezing when running this test code under cmder - but there is no such problem under default Julia console.

[ihnorton]

See here for part of the reason why: https://code.google.com/p/conemu-maximus5/wiki/ConEmuHk
and from the FAQ:

Q. mingw/bash/git works slow in ConEmu.
A. In rare cases on some configurations users may notice lags while executing commands in ConEmu tab. This may be when many child processes are created while command execution. I you are so unlucky - just uncheck "Inject ConEmuHk" on Features page. I'm still looking for the cause of the problem.

This "feature" can be disabled, but bad spawn performance has been a known issue for several years. It is concerning that such a broken feature is enabled by default (and as I said, this is only the worst issue).

@tkelman:

Cmder depends on the MSVC runtime dll's, was there a license concern in the particular terms under which you can redistribute those?

Right, they can't be redistributed with GPL software. Now, technically, we wouldn't be linking it from Julia. I don't know if that changes anything.

[jhasse]

+1 for mintty. I'm using MSYS2 + Julia anyway and it works fine :)

[tkelman]

Using mintty from MSYS2 essentially works now, as long as you also include stty.exe, msys-2.0.dll, msys-intl-8.dll, and msys-iconv-2.dll. And you need to explicitly set HOME=%HOMEDRIVE%%HOMEPATH% before starting, otherwise mintty tries to set HOME to wherever it's located.

I also tried with MSYS1's version of mintty since we already have msys-1.0.dll with msysgit, but that didn't quite work. It seems in MSYS1 mintty, uv_pipe_getsockname(pipe, NULL, &len) in jl_uv.c returns 0.

[ihnorton]

mintty seems like the least-bad option. Just beware that support for shelling out to things using the Windows console API may be spotty. Pick your poison I guess, but this seems ok to me, in exchange for better "everything else".

(Have you tried something like git diff - does the pager work?)

[tkelman]

No, does not look like the pager works, but that might just be because we're using a version of less from msysgit, which doesn't work with mintty properly. Inside a full MSYS2 or Cygwin installation, less works fine from Julia (calling that environment's version of less). Tried just copying over MSYS2 less, and the dll's it depends on (ncurses and, hah, pcre), but that seemed to stack dump for some reason...

[pao]

@tkelman I believe I've had success with the version of less from gnuwin32, though it's not at all up to date.

[tkelman]

Will give it a try. Might not be that hard to just write a pager in pure Julia, would it?

[vtjnash]

i think lighttable/sublime/ijulia integration is going to be the way to go here. but that's a bigger question of how to bundle packages effectively (perhaps 8745 will help with that)

[tkelman]

I'm still intending to work on mintty for the purposes of the basic REPL. Juno is immature and not to my personal liking yet, IJulia depends on Python in an unsatisfying way. Improving the usability of the basic REPL is still something I plan on doing. That work is blocked on libgit2 however, since we'll need to make fairly substantial changes to the windows packaging when we remove command-line git.

[tkelman]

I just discovered the Powershell ISE. It's actually really nice, as long as you're using version 3.0 or newer. Julia doesn't start inside it at the moment, I get

julia.exe : ERROR: `convert` has no method matching convert(::Type{TTY}, ::Pipe)
At line:1 char:49

but that might be fixable. If so, maybe we should add a shortcut to start Julia inside it.

[tkelman]

Looks like similar to mintty, the Powershell ISE uses pipes for stdout and stderr, except stdin is a normal tty. The pipes for stdout and stderr do not have names as far as I can tell, both the uv_pipe_getsockname calls in jl_ispty return 0. If I skip the first early return and make jl_ispty return 1 when len == 0 after the second call to uv_pipe_getsockname, then Julia can start but it's completely unresponsive. And it doesn't seem to recognize color codes either. Judging by http://blogs.msdn.com/b/powershell/archive/2009/02/04/console-application-non-support-in-the-ise.aspx it might not be possible, but oh well, was worth trying.

[ncnc]

FWIW, I tried a fork of Console2 called ConsoleZ. Changing the defaults I get a reasonably sane copy-paste behavior (select with left mouse button), but similar to Console2 the unicode issues remain.

[StefanKarpinski]

We still need to ship with a better terminal emulator on Windows. Watching people struggle with cmd.exe is awful – Julia needs to provide a better default experience out of the box.

[IainNZ]

I agree, if the details can be hammered out. Although IJulia is certainly smoothing over this, at least in Julia classes I've been involved in over the last month.

(A higher priority would be anything to speed up Pkg operations, which seem extra slow on Windows.)

[tkelman]

As I said in December https://github.com/JuliaLang/julia/issues/7267#issuecomment-67761899, I will work on incorporating mintty. But not until we get rid of command-line git, since this will all require pretty significant rewriting of how the Windows binary builds get put together. Can we get moving on the libgit2 transition?

[StefanKarpinski]

Right, thanks @tkelman – I mainly wanted to reopen the issue since it's still unresolved.

[davidanthoff]

I like the plan with mintty, but I think it would be good if this was not the default if Julia is installed on a Win10 system. Win10 comes with a major overhaul over the console that probably solves all of the current issues, and I feel Julia should just adhere to the (then) good system default. Current Win10 RTM target seems to be June/summer, so certainly before Julia 0.5, and that kind of means that 0.4 will be the version that people will use on Win10.

[tkelman]

@davidanthoff yeah I have been meaning to try out the finally-not-crappy console in Win10 (and still confused about them skipping 9). The approach I think I'll take here is get mintty built and included in the binaries, and install a separate shortcut for starting Julia inside it. I don't want to do anything too complicated with detecting Windows versions when 7 and 8 are going to be around and what most Windows users will stay on for some time. Judging by traffic on the Cygwin mailing list, they're keeping up with changes in the prereleases and making sure mintty and other bits and pieces will continue to work.

[davidanthoff]

@tkelman That would certainly work. On the other hand, I like sensible defaults and am not a huge fan if new users have to make choices they don't understand when they first want to start julia. The vast majority of users will have no clue what mintty refers to, so when they see two shortcuts to start julia, and one is called something like JuliaMintty they will have no clue what that they should do. Maybe the installer could detect the version of windows, and then create an appropriate default shortcut? On the other hand, I agree, this shouldn't become a super complicated project, so if there is no easy way to achieve this, your suggestion might still be the best one.

[nalimilan]

Installing two shortcuts on all versions while most users shouldn't use the console (on anything < 10) doesn't sounds great to me. Better use the same console everywhere for now, and maybe one day detect Windows 10 to use the default console there. Currently the user base is not using Windows 10, so that should not be the main focus.

[tkelman]

The shortcut also isn't strictly necessary. If Windows 10 users want to run Julia in the standard console instead of mintty, then they should be able to just double-click bin/julia.exe.

[davidanthoff]

@tkelman Yes, if there is still some way to start julia without mintty then all is good, no need for a shortcut.

[tkelman]

So technically I think we're going to have to use a copy of mintty from either Cygwin or MSYS2, along with a few other files listed above https://github.com/JuliaLang/julia/issues/7267#issuecomment-49097410. The MSYS1 version of mintty doesn't do the same named pipes stuff that we expect, so would be much more difficult to support.

Once this http://midipix.org/ gets released I'll probably have a look at it and see whether there's any advantage to building mintty against that new posix layer (musl on win32... interesting combination).

[ViralBShah]

Is there something we can do for now to make the Windows experience better in the shorter term, until midipix is released?

[StefanKarpinski]

Let's make the midipix thing a separate issue and keep this focused on shipping with mintty, which I think we should do posthaste.

[MikeInnes]

One thing I've been thinking about recently is using Blink.jl + VT100.js (the JuliaBox emulator) as a terminal. Since Blink does all the plumbing it's basically just a case of hooking up the js terminal stdin/stdout to the REPL and bundling it with Julia. (Some JS terminals even support graphical output.)

Plus, that paves the way to shipping Julia with things like nice standalone profile viewers, data frame view/edit windows etc (which may or may not be in the works...).

The main caveat is the dependency on AtomShell, but that could be removed with a little effort.

Just another option, anyway.

[ihnorton]

To quote a wise master: Let's make the Blink thing a separate issue and keep this focused on shipping with mintty, which I think we should do post haste..

+1. I'll work on it. It should be reasonable to just package up what we need and include that in the windows build, and change NSIS to create the appropriate link.

[tkelman]

I'm very hesitant to bundle mintty until after we've removed command-line git. The problem, again, is the MSYS1 mintty will not work for us, but command-line git relies on msys-1.0.dll. Shipping two different incompatible posix layers (msys-1.0.dll for git, msys-2.0.dll for mintty) sounds like asking for trouble.

[ViralBShah]

If not mintty, can we ship cmder?

[ViralBShah]

I am certainly expecting Blink to become the longer term solution. Let's discuss it elsewhere though, independent of this issue, which is quite critical.

[tkelman]

See above for a number of arguments against cmder.

On Blink, I'd be very strongly against making AtomShell a dependency of base Julia.

[tkelman]

the midipix thing a separate issue and keep this focused on shipping with minty

Actually I was planning on using midipix to build mintty, or at least trying to. Unlike with MSYS2 or Cygwin, that should ideally allow us to statically link whichever pieces of the posix layer are necessary into mintty.exe. Parts of midipix are publicly viewable at http://git.midipix.org/, but it doesn't look usable or documented yet.

[ViralBShah]

So, does this mean there is no solution that is better than using the Windows command prompt?

[tkelman]

We can try with MSYS2's mintty (or Cygwin's, they should be nearly identical). Just modifying the shortcut won't work, since starting Julia in mintty sets the HOME environment variable to something strange, preventing the repl history file from loading or packages working properly. Making a julia.bat file with the following

@echo off
set HOME=%HOMEDRIVE%%HOMEPATH%
start %~dp0\bin\mintty.exe -h error %~dp0\bin\julia.exe
exit

seems to work, but flashes open a cmd window temporarily. Not sure how to get rid of that, msys2's batch files have the same problem.

[tkelman]

Oh, thank god, the Git-for-Windows developers finally came to their senses and will be releasing 2.x based on MSYS2 instead of MSYS1: https://github.com/git-for-windows/git/issues/25

So we should get mintty for free, just have to wait to replace our command-line git with an updated version.

[ihnorton]

I have a semi-working hack using mintty from msys2. To get rid of the background console window requires two things:

• cygwin-console-helper
• mintty must be in a path ending in usr/bin/ (:confused:)

Setup looks like this:

Then I made a shortcut in Julia-... with the following target:
C:\opt\Julia-0.4.0-dev-ee316f2197\mtty\usr\bin\mintty.exe ./env HOME=%HOMEDRIVE%%HOMEPATH% ..\..\..\bin\julia.exe

That shortcut starts Julia correctly and basics appear to work, except (so far) that the PowerShell download command doesn't work.

[tkelman]

• mintty must be in a path ending in usr/bin/ (:confused:)

what the?

the PowerShell download command doesn't work

Any sign of an error, or silent freeze, or ?
(for context - https://github.com/JuliaLang/BinDeps.jl/pull/124)

[ViralBShah]

Exciting progress, despite the weirdnesses.

[ihnorton]

what the?

I'm stumped. Starting it from the msys install path does not pop up a console window, so I knew it _had_ to be possible and tried some variations until finding that usr/bin/ worked.

Any sign of an error, or silent freeze, or ?

Not that I could see. I'm guessing it is an issue with console i/o handles.

[tkelman]

Not that I could see. I'm guessing it is an issue with console i/o handles.

Hmm. I can shell out to powershell from Julia running inside Cygwin's mintty, I wonder what the difference is?

[ViralBShah]

Is there something I can try out? I have been working with a few users on Windows for the past few days, and really feel sorry for inflicting our current solution.

I should be able to give some useful feedback on mintty and perhaps even ask a few others to try it out and observe them, but I would need a build I can download.

[ihnorton]

@tkelman

Hmm. I can shell out to powershell from Julia running inside Cygwin's mintty, I wonder what the difference is?

But can you use it? I can shell out to powershell from both msys2 or cygwin mintty, but the prompt is not displayed and when I exit, Julia has received all _input_. I'm using whatever is the default powershell in Windows 7 (given as "Copyright 2009")

The other, probably related, issue is that the git pager doesn't work.

[tkelman]

@ViralBShah

Is there something I can try out? I have been working with a few users on Windows for the past few days, and really feel sorry for inflicting our current solution.

Install MSYS2 separately, but not MSYS2's copy of git (since that will break the package manager, until we replace shelling out with libgit2). Open an msys2 terminal and start Julia within that.

@ihnorton

But can you use it?

No but I shouldn't need to use it interactively, I'm only trying to run script commands that don't prompt for user input.

The other, probably related, issue is that the git pager doesn't work.

The MSYS2-based Git-for-Windows looks like it will be released imminently. I'd rather we try using that. (libgit2 would of course be orders of magnitude better, but also more work to switch to)

[ihnorton]

No but I shouldn't need to use it interactively, I'm only trying to run script commands that don't prompt for user input.

I tried adding -Noninteractive to the powershell download command in bindeps, but that didn't help. Procmon tells me that the download is running to completion, then one of the threads exits and the process apparently never returns.

[ihnorton]

@tkelman the git-for-windows msys2 preview looks very nice. Have you seen a release plan/schedule anywhere?

Cross-linking https://github.com/git-for-windows/git/issues/74 (for my own future reference, I know you commented there).

[tkelman]

Dunno. They've got preview builds of the sdk up, but I haven't played with it much yet. Was tempted to help them set up appveyor, but been a bit busy.

[ViralBShah]

If we are planning to do this for 0.4, what is the solution - doesn't seem like it has settled? Also, this can easily be done in the 0.4.x release. It is important, but not breaking in any way.

[tkelman]

So there are a few things we can do here. If we try replacing our bundled command-line git with the new msys2-based git 2.x, we could just use the mintty included there. I haven't tested this much, but we'd need to check carefully that the folder structure isn't too different (and it will make the binaries quite a bit bigger than git 1.x) and Pkg still works properly.

I've held off on doing that because #11196 looks like it's actually pretty close to working, but will need libgit2 to release v0.23 in order for us to have https on Windows without needing to deal with openssl. If we switch to git 2.x now just to start using mintty, then we'll need to undo a lot of that work and re-do all the testing when we switch to libgit2.

[davidanthoff]

Just for context, we now know that Win10 will be released 7/31, so maybe even before julia 0.4. It will be a free upgrade for almost anyone, and MS is clearly pushing it hard onto machines, more like service packs in the past (for example all current Windows machines are now already asking people via Windows Update to opt-in to the update on 7/31).

So from my point of view, if resources a scarce, I'm still not convinced that shipping a julia packaged better console is a high priority, when Windows will just have a fine one in a few weeks, and people on older Windows versions can just use Console2 or something like that. Not saying that it wouldn't be nice to have one, but to me there seems a very long list of other things that are higher priority for 0.4.

Feel free to just ignore this comment, though ;)

[PallHaraldsson]

@tkelman:

Cmder depends on the MSVC runtime dll's, was there a license concern in the particular terms under which you can redistribute those?

Right, they can't be redistributed with GPL software. Now, technically, we wouldn't be linking it from Julia. I don't know if that changes anything.

I read this far. I tried looking up to see if MSVC is pre-installed in Windows.. Seems MSVC is still redistributable, but do you need a newish version for cmder to work? If MSVC is installed, in supported by Julia, Windows system then you can distribute Cmder (or whatever) and Julia (including GPLed libraries) under GPL's "System Libraries exception".

Not if you need a newer version of MSVC than is installed you can upgrade that afterwards or install it in older versions of Windows that may not have one.

This is only a terminal program will it really need a new version - for security sakes?

If there is not MSVC, you can fall back on no terminal until MSVC is installed. That is not disallowed by the GPL.

[tkelman]

If we're going to go to the trouble of bundling a better terminal program with Julia, we should use one that could be enabled by default.

Regarding Windows 10, never underestimate Windows users' reluctance to upgrade their OS. In terms of bandwidth, hard disk space, and time setting things up, from what I've seen people would usually rather wait until they buy a new computer to upgrade rather than upgrading existing machines. Though I have seen the "Get Windows 10" message popping up - have yet to figure out how to make it go away.

[pao]

Though I have seen the "Get Windows 10" message popping up - have yet to figure out how to make it go away.

There's probably a group policy to disable it completely (we don't have it on our work computers) but you should be able to hide it with the "Customize..." option in the system tray popout menu.

[wildart]

PowerShell is the way to go. It is mature, extendable, and Microsoft invested in it a lot. It would be nice to have better integration with it.

[jhasse]

PowerShell or cmd doesn't make a difference as they both use about the same terminal window. Both will feature new stuff like text reflow in Windows 10 AFAIK.

[tkelman]

@pao thanks I'm dumb, I haven't touched that customize button in at least a few years

@wildart there's actually a discussion on making the shell mode go through powershell, at least optionally, over in #11478

Powershell itself isn't actually a "better terminal" though, it's a better shell interpreter. The Powershell ISE is a really nice terminal with intellisense etc, but from my experiments with it I couldn't find a way to run a non-powershell interactive repl program through it.

[PallHaraldsson]

@tkelman: "If we're going to go to the trouble of bundling a better terminal program with Julia, we should use one that could be enabled by default." yes, if this was a response to me then I saw assuming you could enable cmder or whatever for Windows. Maybe not for the oldest versions, say Windows XP, that is kind of not supported by Julia (officially) anyway.. [I'm not sure where the supported line would be..] Getting same as now on older, and if you want, actually being able to enable on all the older platforms by downloading a redistributable seems ok? Are there actually many Julia programmers running on XP? It's not like the couldn't use it or run julia programs.

[tkelman]

Was in response to https://github.com/JuliaLang/julia/issues/7267#issuecomment-110402050 - currently Julia does not depend on an MSVC runtime library any newer than the one that is pre-installed on Windows. We cannot distribute a newer MSVC runtime library bundled with GPL software, based on my understanding of the licenses. If enabling the better terminal requires manually installing a separate newer MSVC runtime library, I don't think that's a good direction to go in.

As I mentioned early on in this issue, cmder bundles several things that we don't need. If we want to look into some ConEmu-based solution, it would be convenient if there were a way to extract just cmder's default configurations around ConEmu so we don't have to do as much work to customize ConEmu to make it bearable, but avoid using the rest of cmder which depends on MSVC runtime libraries and unnecessary components like clink.

[ViralBShah]

What about with a GPL free distribution? Seems like we are getting awfully close. It would be nice not too have that restriction though.

[tkelman]

conemu is bsd-3, mintty is gpl (and relies on a gpl cygwin / msys2 dll, unless midipix ends up working eventually), cmder is MIT but bundles clink which is gpl. We'd need to configure the hell out of conemu to make it decent, and need to keep a close eye on the performance issues mentioned above.

[PallHaraldsson]

"cmder is MIT but bundles clink which is gpl."

Since it bundles GPL software, can I assume they do not bundle Microsoft's
proprietary redistributable that would be GPL-incompatible as a
combination? That is it is, already installed in (most versions) of Windows
falling under GPL's "System LIbrary" exception.

I wouldn't worry too much about the Julia distribution being completely
GPL-free for whatever terminal (only, if you wish, system libraries
callable from Julia). This is a feature easily disable and replaceable and
would not make Julia "GPL viral".

[There is a possibilty that cmder would however use clink (that I'm not
sure what is) as a separate process ("at arms length"/though a well defined
API) as "mere aggregation", which is what Julia would do and then be free
of GPL's restrictions and be bundling a redistributable.. Julia does (or
will do?) similarly with libgit2, that is GPL.. (while explictily allowing
static linking).]

[tkelman]

It looks like cmder's combination of clink plus the msvc runtime libraries might be violating the gpl and/or the microsoft redistribution terms. Not sure.

[twadleigh]

Today I deleted the Git directory from a binary installation, dropped in the latest portable Git, and gave it a little spin. It's early to be definitive, but it seems:

1. the new git works as a drop-in replacement for the old git; and
2. the mintty operates successfully with julia.

So hopefully we can close this one in the next few days.

[vtjnash]

great! would be good to change this in the makefiles soon so that people can start testing with it (and figure out the best way to modify the startup to actually use mintty).

https://github.com/git-for-windows/git/wiki/FAQ#some-native-console-programs-dont-work-when-run-from-git-bash-how-to-fix-it

[davidanthoff]

I assume that at this point things like that will be delayed until 0.4.1, so that 0.4.0 at some point stands a chance of getting released? This does strike me as a change that will require some testing, and with the small number of Windows testers, it would probably be better to not have this in 0.4.0, simply because of the potential of problems and the chance that this might delay a 0.4.0 release further.

Also, note that the current git setup on windows actually offers an option in the UI whether one wants to use mintty or the native console.

[tkelman]

Yeah, basic tests are promising, but would really want to be much more thorough about testing that everything still works properly across a whole bunch of use cases in packages before pulling the trigger with that. And we're going to have to do the same set of testing all over again for libgit2, at which point we'll be taking command-line git out of the binaries making much of the first set of testing work redundant.

[davidanthoff]

Plus, this strikes me as something you need to test across different releases of windows, across x86 and x64 etc....

[musm]

I've been using Julia with powershell and from powershell within ConEmu. Haven't had any issues, so I'm not sure why this is so necessary. I would guess that most Windows users would gravitate towards using an IDE for Julia. The subset that use a terminal would probably have something sensible already configured (either conemu, console2, etc) and would run Julia directly from the exe, without bothering with a bundled terminal IMO. I think time would be better spend with developing some sort matlabish IDE.

[StefanKarpinski]

My observations of Windows users have led me to believe that this is not the case.

[tkelman]

IDE (or, really, smart editor integration) development will be proceeding outside of base for some time, and the REPL isn't going anywhere.

The currently bundled version of git that we use is always 32 bit since we only ever shell out to it, but it would likely be a good idea to use the now-available 64 bit Git build in the 64 bit binaries of Julia, in order to use libcurl and other git dependency libraries via ccall. I'm on the fence whether the makefile tweaks and testing work involved there is worth trying to get onto the 0.4.x series. If someone wants to prepare a PR we can easily build test binaries from the branch.

[twadleigh]

In retrospect it was hasty for me to suggest swapping out the distributed Git as part of solving this problem. For one thing, as @tkelman suggests, it is way too optimistic to assume it will just work. For another, it unnecessarily conflates git-related issues with the terminal on windows issue. Both have their complications and it only makes the thing more complicated to require that they be solved in lock step. Probably the single biggest reason it is a bad idea, though, is that they have different life cycles. Watchmaker willing, we will be moving to a libgit2 based solution for git soon (hopefully, in my lifetime). The need for a not-totally-sh*tty terminal on windows will persist long after.

Still, I think it's worth considering using the msys2 version of mintty as a near-term solution. We'd just bundle it independently of git. Yes, it would mean we'd need to ship the largish msys-2.0.dll, but that seems to me like a relatively small price to pay. (Besides, the binaries will get significantly smaller once we move to libgit2, right?)

I've done a little playing around with a stand-alone mintty and julia. I haven't seen any issues yet except that we might want/need to patch it to use cmd as the default shell instead of bash.

[tkelman]

Either the msys2 version of mintty or the cygwin version of mintty should be broadly equivalent. We don't really need msys path mangling, so I'd favor whichever is easier to obtain and use. I'm planning on handling this along with removing command-line git from the binaries once libgit2 is in place.

[twadleigh]

@tkelman, happy to help in any way.

[tkelman]

I believe we need stty.exe along with mintty.exe and either cygwin1.dll or msys-2.0.dll. stty.exe links to cygintl-8.dll (or msys-intl-8.dll) and that links to cygiconv-2.dll (or msys-iconv-2.dll), I haven't gone digging yet to find which packages to pull each of those files from. MSYS2 annoyingly hosts their package binaries on sourceforge, though I think they're in the process of migrating somewhere else. Cygwin is mirrored by MIT at http://mirrors.mit.edu/cygwin/ which has been very reliable in my experience.

edit:
little bit of ini parsing from http://mirrors.mit.edu/cygwin/x86_64/setup.bz2 to get the latest version numbers of everything, then
http://mirrors.mit.edu/cygwin/x86_64/release/mintty/ for mintty.exe
http://mirrors.mit.edu/cygwin/x86_64/release/cygwin/ for cygwin1.dll
http://mirrors.mit.edu/cygwin/x86_64/release/coreutils/ for stty.exe
http://mirrors.mit.edu/cygwin/x86_64/release/gettext/libintl8/ for cygintl-8.dll
http://mirrors.mit.edu/cygwin/x86_64/release/libiconv/libiconv2/ for cygiconv-2.dll

[twadleigh]

Just mintty + DLLs doesn't work. mintty wants bash. I'll see if there is an easy way to patch mintty to ween it off bash.

EDIT: setting HOME=%USERDRIVE%%USERPROFILE% and SHELL=cmd has gotten me a little further (mintty will use cmd by default, and julia won't complain about not finding my history file), but shelling out of julia is still broken for me.

EDIT 2: When I run mintty c:\path\to\julia.exe with the cygwin version, I get two windows: one empty window, and one with julia. With the msys2 version, I just get one window.

EDIT 3: Just re-read the thread and saw the HOME tweak. Going through a .bat file to set the HOME variable, both the msys and cygwin versions pop up two windows. Sigh.

[tkelman]

ah right, forgot about the cygwin-console-helper thing from https://github.com/JuliaLang/julia/issues/7267#issuecomment-84674766

[twadleigh]

@tkelman, I glossed over that one because at first read I thought the /usr/bin had to be absolute, figuring that would make it a non-starter for any viable candidate solution.

I have my version of that hack working now. I had to move the env HOME=... in front of the call to mintty so that it could find the home directory in order to save its settings. I'm attempting to put together a PR now.

[twadleigh]

12879 is now minimally functional except that julia will error out when double clicking the shortcuts unless the working directory for the shortcut is mintty\usr\bin. The problem is that julia is expecting stty on the path. I tried extending the path with another call to env but (1) I couldn't get it to work quite right (with the cygwin executables), and (2) it made the shortcut command line too long, anyway.

Might a patch to base be in order? It looks like all the calls to stty are in Terminal.jl in windows-specific blocks.

[vtjnash]

I would drop the patch into:
https://github.com/JuliaLang/julia/blob/master/contrib/windows/juliarc.jl
that's where such hacks have tended to live until they find their way into base or can be resolved in some other way

[twadleigh]

@vtjnash, :+1:

[twadleigh]

BTW, I've noticed that the cygwin version of mintty that I'm using in #12879 does the temporary flashing of second window thing, whereas the msys2 version installed on my machine does not. It doesn't bother me that much, but if it bothers a critical mass of users, we might want to move to the msys version.

[tkelman]

We could ask the mintty devs about the issue. It was recently adopted by a new maintainer who's been much more active about it.

[twadleigh]

I've been dogfooding #12879 and I've come across a few issues. I'll mention them here, as I'm not really sure how to track issues associated with a PR.

Mostly things work, including Pkg, BinDeps and WinRPM. However, when trying Pkg.add("ImageView"), things seemed to hang while downloading ImageMagick. I killed and restarted with Pkg.build("ImageView"). It moved along but then hung again when downloading innounp. I killed and called Pkg.build again, and it completed without complaint.

Also, it seems that two mintty processes are running while the terminal is open. One of them, I presume, is the one that gets swallowed up by cygwin-console-helper. This isn't a problem per se, just a little unintuitive.

Further, Ctrl+C while running a subprocess kills mintty rather than the subprocess, returning to julia. For instance, trying to interrupt IJulia.notebook() closed the terminal but left a zombie python process going.

[tkelman]

You might be hitting the same powershell issue that @ihnorton was seeing? What version of Windows?

Could you clear out the bindeps downloads from Images.jl, delete :powershell from https://github.com/JuliaLang/BinDeps.jl/blob/5cf51cbea127ec5fd498efa14602c648dd75e52d/src/BinDeps.jl#L49, and try again?

[stevengj]

@twadleigh, can you report issues specific to #12879 on that PR, and maybe add to-do checkboxes as needed? Otherwise anyone looking at that PR sees only completed checkboxes and "This is basically working for me at this point," which may give a misleading impression of how merge-ready it is.

[twadleigh]

@tkelman I'm running Windows 7 Professional. I deleted Images, removed :powershell, and tried again. It worked fine. So we can chalk that one up to a BinDeps issue. I presume it is already filed.

@stevengj I'll update #12879 to reflect the remaining issues and will continue any discussion there.

[tkelman]

So we can chalk that one up to a BinDeps issue. I presume it is already filed.

I agree with the diagnosis, but no that has not been reported before. In a new issue at BinDeps, I'd be curious to know if it's only an issue when running Julia within mintty, or if you can reproduce from just normal julia.exe.

[twadleigh]

@tkelman: Ah, I misunderstood. Yes, I verified that it is an issue specific to mintty-wrapped julia. I'll open an issue at BinDeps.jl.

[tkelman]

In 0.4.1, you can start Git/git-bash.exe then run `cygpath -m $PWD/../bin/julia`. Maybe we should just document this.

[ViralBShah]

Can't we make it the default, if it is clearly better?

[tkelman]

Not quite yet, until https://github.com/JuliaLang/BinDeps.jl/issues/167 gets resolved.

[davidanthoff]

This reports on the latest updates to the native windows command prompt. Probably the main news is that they seem to be keen to get their VT control sequence implementation in shape.

[musm]

I don't think Julia should ship with a terminal on Windows. With alternatives such as vs-code and juno (which address the core issue here), it doesn't seem to offer much to ship and maintain a terminal with julia on windows.

[tkelman]

They're okay for users who want an IDE or heavyweight editor, but cygwin's mintty is a much better terminal experience than the windows default and worth adding to our install. A modernized version of https://github.com/JuliaLang/julia/pull/12879 is somewhere low on my to-do list, I've got some repackaging code in a repo that takes just the parts of cygwin we need. Not urgent since it's a nice-to-have, but we should still eventually do it.

[ViralBShah]

I routinely continue to see Windows users suffering with the Windows terminal and Julia.

[davidanthoff]

Tabs are coming for the built in terminal on Windows with the next Win 10 release in the fall...

[simonbyrne]

I think we need to do something about this: cmd.exe really does give a sub-par experience on Windows. Two comments I've come across in the last 24 hours:

• "I like the quickness of testing in terminal as a beginner. If any Julia devs are reading, please integrate ctrl+v in the terminal. A language that’s part of the petaflops top 3 should be able to copy paste like all other apps"
• "Thanks, works also with Emojis, even tho Windows cmd.exe can't display most of them correctly in 2018"

[davidanthoff]

I actually don't understand why copy-paste doesn't work. When I start either PowerShell or the old cmd.exe on a recent Windows, things like Ctrl+v just work out of the box. They just don't work in julia... So say I start a PowerShell instance, copy-paste works. Then I start julia from within that PowerShell instance, and then copy-paste doesn't work anymore (in julia). As soon as I stop julia, copy-paste works again in PowerShell.

Also, there is a lot of new stuff coming with the fall Windows update: https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/. Might some of that help?

Tabs, though, they took out of the next release. My understanding is it might come later, still.

[simonbyrne]

That's interesting: Ctrl-c for copy works as well.

Do you know how this is handled? Is it simply a matter of adding a Ctrl-v binding to the Julia REPL?

[vtjnash]

If paste is fixed, it's still undocumented (https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences). The new ConPty stuff is good since we'll no longer need to wait for MS to fix this, and can instead wait for someone to port MinTTY / ConEmu / Console2 / etc. to the new API and add support there.

[davidanthoff]

Do you know how this is handled? Is it simply a matter of adding a Ctrl-v binding to the Julia REPL?

I have no idea...

But I also found this. It is not clear to me whether that only applies to WSL, or whether that will work broadly for all cmdline apps... I think that will probably also show up with the next fall Windows release.

[mintty]

A native build on cygwin would facilitate seamless integration in a "real" terminal emulator, but: #28891.

[braamvandyk]

Light at the end of the tunnel, which may or may not be an oncoming train:

https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/

[mintty]

Note that does not give you a terminal immediately; the conpty will need to be integrated into cygwin first, which is the runtime environment for mintty, before the benefit is established.
A simple port to cygwin (should be some basic debugging of the Makefile, as Julia is available for Linux) would facilitate seamless usage of mintty already.

[vtjnash]

Might some of that help?

I strongly doubt it—we immediately take the console out of dumb/readline mode to be able to access features beyond basic text output. In the past, that's always disabled all of the new features too. (which makes sense, since they would conflict with and break our integration features).

I'm quite interested in the bottom of the screenshot though:

It's apparently gotten UTF-8 support! What a big step up from UCS-2. Yay, that'll be more convenient and helpful.

[StefanKarpinski]

This came up in a recent "first impressions" thread on Discourse:

https://discourse.julialang.org/t/first-impressions/22318

Using git bash from https://gitforwindows.org was suggested and seems like a fine option.

[stevengj]

It looks like gitforwindows is just using mintty? See their FAQ.

[braamvandyk]

It is. Running Julia inside Git bash (Mintty) is a pleasant experience. There is also a feature request open on Juno to run the console inside Mintty instead of the default console. It puts to bed most, if not all of the issues experienced with the Windows console.

[stevengj]

@braamvandyk, my point is that this is equivalent to bundling Julia with mintty, which was discussed extensively above, and seems like it has nothing to do with gitforwindows.org

I agree that mintty seems like a nice option, vastly superior to the Windows console!

[stevengj]

(An orthogonal issue is bundling Julia with a better shell mode; see #23703)

[davidanthoff]

Do we know what the current issues with the windows console are? Is it just that some Unicode characters are not shown properly? I think that was the only thing mentioned in that discourse thread?

If so, which ones would that be? Because at least the ones I tried seem to work just fine?

The other issue that I'm aware of is copy/paste support. I don't understand what is going on there, but it is worth pointing out that it works just fine in the normal windows command line, and then only in julia it stops working. Maybe it would be worth figuring out why that is the case first?

[davidanthoff]

Another option is this:

if we managed to configure the shortcut file that points to the julia executable with that option enabled by default through the installer, it would probably solve the copy/paste problem.

That option works inside the julia REPL.

[musm]

I echo @davidanthoff , I think most of the issues are just related to Unicode characters and pasting. What else does mintty provide that provides a more pleasant experience? FWIW I've used julia with conemu and find it fine other than pasting and unicode characters (it's hard to find a good font, and conemu doesn't implement fallback characters)

It seems that the pasting issue be resolved by taking advantage of the new conpty on windows

[KristofferC]

Colors don't work properly unless you run WSL and the linux julia (both screenshots in cmd.exe):

Also no bracket paste is very annoying.

[musm]

I believe all those should be fixable by leverage conpty instead of winpty

[davidanthoff]

Just for reference, this mentions that they now support 24-bit colors (presumably only for conpty apps, though), and this explains how one can tap into the conpty stuff.

[StefanKarpinski]

Arguing about this is why we never solve this problem...

[davidanthoff]

The color thing is certainly a problem on the julia/libuv side. I just played around with the win console API, and was able to generate this in a normal julia command line window on Windows:

I've opened another issue here that describes what I found so far. But I think for the discussion here it means that currently julia is just not hooking properly into the full console support that Windows is currently offering in Windows 10, and that at least some of these pain points could probably be addressed by fixing that.

[braamvandyk]

Do we know what the current issues with the windows console are? Is it just that some Unicode characters are not shown properly? I think that was the only thing mentioned in that discourse thread?

This discussion lists some of the characters, but there is probably entire blocks that do not display.

Shell mode also works in Mintty, which is certainly not the case in the Windows console.

[StefanKarpinski]

While https://github.com/JuliaLang/julia/issues/31491 gets sorted out and we hope that at some point in the future Microsoft and libuv will clean up their acts and we can get sane default terminal behavior on Windows some day, can we maybe consider shipping Julia with a terminal that actually works on widely used versions of Windows today? If we'd done this in 2014 instead of deciding that we shouldn't because this was about to be fixed, think of how much pain and suffering of Windows users could have been saved.

[stevengj]

For example, apparently the Windows console still does not properly support fallback fonts for rendering Unicode characters that are not available in the current font? As of Feb 14, 2019, they are still "working on it".

In mintty this was fixed in 2016 (mintty/mintty#573), by using Microsoft's own Uniscribe libraries no less.

[ViralBShah]

We really should ship mintty here.

[niclasmattsson]

I'm all for mintty if it works well, but does it? I haven't played with it myself, but reading their issue #56 doesn't give me a warm fuzzy feeling. Back in 2015 they specifically warned against using it for interactive programs like the Python REPL, but maybe some of those issues have been resolved by now. Lately they seem to be waiting on Windows ConPTY improvements just like we are. Anyway, you gotta love the tags on that issue: Difficulty-Insane and Priority-None. :)

Is there a good summary of all the Windows console problems somewhere? The only one that really annoys me is the lack of font fallback (so e.g. the vertical ellipses in rand(40,40) almost never renders). On the other hand I have CTRL-C working perfectly as both SIGINT and copy, something I never got to work well in the other consoles I've experimented with.

[twadleigh]

I made an arguably feeble attempt to get julia and mintty to play nice some while back in #12879. I seem to recall that I stalled out when it looked like the next step would have involved finding a way to patch mintty. That's when I decided the issue grew beyond a scope to which I was comfortable devoting effort.

I'm sure many, many things have changed between late 2015 and now, but the thread and work on that half-baked PR are probably still a good reference for someone who wants to make this happen.

[vtjnash]

mintty is what the windows developers of Julia (e.g. me) generally use and support. While their issue 56 hasn't seen any particular action upstream, note that we already "solved" most of those problems in Julia (for instance, see my comment in that issue). OTOH, copy(paste) is ctrl(shift)-insert there and I don't think I ever bothered to make CTRL-C non-fatal.

[mintty]

I've followed this discussion loosely and commented before. I think if you really want this integration, you'd better fix #28891 first. That would give you seamless integration, no quirky workarounds needed.

[davidanthoff]

Another piece of news from MS about the future of the terminal on windows is here. Short summary: "Windows Terminal" is Microsoft's own new terminal. It is open source and one can compile it now and test it. In the summer of 2019 they will ship a beta via the windows store, and the final release will ship in winter of 2019 in the store (at least that is their plan). They also include a new (open source) font specifically for the console.

The feature list generally reads as if it would solve most (all?) issues that we have been fighting with, at least to me it reads as the final missing piece in the whole renovation of the windows console experience.

It would be interesting to see how well julia works with this. I suspect that minimally #31491 will need to be fixed on the julia side for things to work smoothly.

It is not clear to me what Windows versions this will run on. Latest Windows 10 only, or broader support? Not clear to me.

[ViralBShah]

Looks like we were waiting for this: https://www.theverge.com/2019/5/6/18527870/microsoft-windows-terminal-command-line-tool

Seems like @davidanthoff just posted the same thing!

[KristofferC]

Non reblogger link: https://devblogs.microsoft.com/commandline/introducing-windows-terminal/

[musm]

Another reason I think we should just close this issue. I really don't think Julia should be responsible for shipping a 'usable terminal'.

There are several actionable items mentioned in this thread that are possible to fix that will greatly improve the terminal experience.

Actionable

• [ ] 256 color support, fixable by improving passing of VT sequences in libuv, see https://github.com/JuliaLang/libuv/pull/2 https://github.com/JuliaLang/julia/issues/31491 . There are some issues with libuv here that need to be ironed out (@vtjnash is the most knowledge person regarding the problems here)

• [ ] More usable shell mode https://github.com/JuliaLang/julia/pull/31490

External

• [ ] Font fall backs and emoji support (fixed by new windows terminal). Note mintty does not support this feature and afaik no terminal on windows fixes this.
• [ ] Nicer terminal features such as bracketed paste mode etc. Presumably fixed by improving passing of VT sequences in combination with the new windows terminal.

[mintty]

Font fall backs and emoji support (fixed by new windows terminal). Note mintty does not support this ...

Mintty provides Windows-handled font fallback and supports emojis, including emoji sequences and emoji display preference style.

[musm]

@mintty It doesn't seem to allow me to specify the font fallback chain ?

[mintty]

No, that's configurable in the Windows registry :(

[stevengj]

It sounds like it will be years before the new Windows Terminal (currently in "very early alpha") is installed on most Windows machines. In the meantime if we just took the extra 1% of space required to ship mintty, we could have a solution now.

I really don't think Julia should be responsible for shipping a 'usable terminal'.

Then most Windows users will continue to have a poor experience with the Julia REPL for years to come. What is the problem with shipping mintty, other than the development effort required to integrate it smoothly?

[mintty]

Why don't you spend the small effort to fix the build problem on cygwin (mentioned above)?
I'd offer to maintain a cygwin package for Julia if desired.
That would enable anyone to run Julia in mintty without any integration hassles.

[ViralBShah]

We absolutely should ship mintty. There is no reason not to.

[stevengj]

@mintty, that's a great offer, but I don't think we want to require Windows users to install Cygwin to get a usable terminal; we'd greatly prefer to ship a minimal mintty build as a standalone terminal with Julia. Since we only need it to run Julia we can use the stty hacks mentioned above, which already work, to avoid the need for a cygwin build (#24128).

[musm]

I think it would be great to fix Mintty to make it compatible with Julia. But I think Mintty should only ship with JuliaPro, not with Julia; for the same reason, that Juno is not included in the standard Julia installer.

Julia's purpose is not to ship a 'usable' terminal (I put usable in quotes, because the current terminal experience is usable, in fact I use it regularly/daily and don't have all the complaints people make). The terminal experience is no better/worse than Python and they don't ship with a 'usable terminal'. My major complaints with the terminal are pretty much all fixable by improving Julia, and are not fixed by shipping Mintty (see https://github.com/JuliaLang/julia/issues/7267#issuecomment-490134045).

It sounds like it will be years before the new Windows Terminal (currently in "very early alpha") is installed on most Windows machines. In the meantime if we just took the extra 1% of space required to ship mintty, we could have a solution now.

I think it's exaggerated to claim it will take years for them to finish the new terminal. According to MSFT in mid-June an official preview build will land in the MSFT app store. And by their track record with WSL they have been rapidly improving the console, since they started to work on it.

In summary it would be great to fix Mintty with Julia and to ship it with the user friendly JuliaPro distribution, but shipping Mintty does not solve all of our problems.

[mintty]

@musm: The incompatibility addressed is about interworking of raw input, character set handling, and signal handling, at the pty interface. It's a mismatch of POSIX and Windows concepts and there's nothing to fix about it. However, the new Windows ConPTY API may provide an opportunity for a workaround. A patch for cygwin is currently under construction and may be included in one of the next cygwin releases.

@stevengj: I understand that you don't want to "go cygwin" for this aim, but the build bug should be fixed anyway, as it's hardly understandable that a package that builds on Linux does not build on cygwin.

[braamvandyk]

I think it's exaggerated to claim it will take years for them to finish the new terminal.

Sure, in an environment where you have full control over your Windows version, that would be reasonable. In corporate environments, users are often 2-3 versions behind, so add another year or two from MS shipping the new terminal until Windows users in corporate environments get their hands on it. Our SAP system still requires IE11, for heaven's sake. Won't even run on Edge, leave alone Chrome. From my point of view, Julia shipping with Mintty out of the box would be awesome.

[stevengj]

Julia's purpose is not to ship a 'usable' terminal.

How would shipping a decent terminal detract from Julia's purpose? It seems pretty clear that a better terminal would avoid a lot of user problems that have detracted from Julia on Windows, judging by the number of complaints over the years. I don't understand what your objection is, other than to deny that there is a problem.

And I didn't say it would take years for Microsoft to "finish" a better terminal, I said it would take years for it to be "installed on most Windows machines", which I think is obviously true even if we restrict ourselves to scientific/developer users. First it has to be finished, then it has to be installed by default on a Windows release, then it you have to wait for most users to upgrade.

My major complaints with the terminal are pretty much all fixable by improving Julia

You can't fix the lack of support for font fallbacks this way, for example.

[davidanthoff]

There seem to be two distinct work packages here: a) shipping a terminal with julia and b) fixing https://github.com/JuliaLang/julia/issues/31491 (i.e. get julia to properly interact with the console API on modern Windows systems).

I think addressing both would be great, but with limit resources I would hope that we can fix b) first. I think it will have the bigger payoff: it will fix these things in the integrated terminals in VS Code (certainly) and Juno (I think), it will mean that julia behaves properly in many excellent currently shipping third-party terminals, and it means it will work properly on the upcoming Windows Terminal. Also, I think fixing bugs before adding features is nice :)

For a), I think the main question is whether someone steps up and does it. If it does happen, I think it would be important that it is somehow optional. For example there might be two startmenu options, one for the Mintty terminal, one without etc.

[stevengj]

I don't think anyone is opposed to fixing libuv terminal bugs/limitations on Windows. And you're right that ultimately it depends on someone stepping up to do the work. But I think the needless naysaying here will discourage people from working on this — why does advocating for #31491 have to go along with pooh-poohing work on shipping a better terminal?

If it does happen, I think it would be important that it is somehow optional.

You can already launch Julia in whatever terminal you want. Why do we need a second console option in the start menu or for double-clicking?

[davidanthoff]

why does advocating for #31491 have to go along with pooh-poohing work on shipping a better terminal?

That was not my intention at all, as I just wrote, I think shipping a better terminal would great. My sense is, though, that both projects right now would require time from @vtjnash, and if that is so, I would be much more interested in seeing the libuv problems fixed :) Of course, @vtjnash will do what he wants in any case, so just take this as a priority list from one user ;)

If it does happen, I think it would be important that it is somehow optional.

You can already launch Julia in whatever terminal you want. Why do we need a second console option in the start menu or for double-clicking?

Actually, that was not well put by me. What I really mean is that I would want the normal julia shortcut in the start menu to start julia in the Windows Terminal on systems that have it (once it ships), not in mintty. I don't know how this will work out in terms of timing of releases, but from the info we have right now it seems not unreasonable to assume that julia 1.3 and the Windows Terminal will ship roughly at the same time (end of the year?), and then it would be nice if things worked out of the box for users that have Windows Terminal.

[ViralBShah]

From my limited understanding of the topic discussing with @vtjnash a few days ago, the two projects are indeed related. It is not sufficient to bundle mintty, but the libuv patches are necessary to use mintty. In fact, IIRC, he said that mintty itself may need some patches. Without these patches, apparently, nothing apart from julia will be able to write to the terminal (so shell, ccall, etc.).

Of course the work to package mintty as part of Julia can certainly continue in anticipation of the libuv work and mintty patches.

[vtjnash]

I think I left you with the wrong impression of several things. There are improvements needed to libuv to support the new conhost features (not mintty), so that other programs can write to the terminal without messing up julia. To replicate my normal dev environment, for mintty, we just need to modify the distribution code copy over the stty.exe binary already present during the build. Longer term, we could consider improving efficiency by porting their new https://github.com/rprichard/wslbridge to Win32 (maybe this is https://github.com/rprichard/winpty already?) and adding support for that, or adding ConPty support to mintty (~https://github.com/mintty/mintty/issues/804~) and adding the same aforementioned features to libuv.

[davidanthoff]

First preview of the new Windows Terminal is released in the Windows store, see here.

[stevengj]

@davidanthoff, great! Now we just have to wait another few years for it to be present by default on most Windows machines. In the meantime, can we ship something?

[ViralBShah]

Is it simply an issue of downloading and including the mintty in our binaries and perhaps changing a .bat startup file? Very few people seem to be familiar with the Julia windows build. Perhaps only @musm and @staticfloat.

[stevengj]

Someday we will look back and wonder why we spent a decade with crippled Unicode display on most Windows machines in order to save 1% in the download size by not bundling mintty…

[nalimilan]

Now if we want braille display of sparse matrices and that the Windows console is broken (https://github.com/JuliaLang/julia/pull/33821#issuecomment-559596284), that's a strong argument to finally ship Mintty...

[ViralBShah]

I think the only thing preventing this at this point is someone submitting a PR.

[davidanthoff]

I think it would still be great if we could _also_ fix the way julia interacts with the console API on Windows. Right now certain things that are all fixed in modern versions of Windows still don't work properly because Julia is not using the APIs properly.

[stevengj]

Unfortunately there are only a few people who put together Windows Julia releases who can practically make this PR.

It also doesn’t help encourage a PR if literally every time this issue comes up a bunch of people jump up to say that Microsoft will fix this Real Soon Now and anyway we should work on some other issue first and by the way shipping our own terminal would be some unspeakable but inexplicable faux pas.

[davidanthoff]

we should work on some other issue first

I specifically (and very much on purpose) did _not_ say that :) Nor any of the other things you mention in your second paragraph.

[stevengj]

Notwithstanding remarks like "Windows will just have a fine one in a few weeks", "with limit[ed] resources I would hope that we can fix b) first", and "it would be good if this was not the default", @davidanthoff, it is certainly true that there have much more disparaging remarks about shipping mintty from others; I wasn't intending to single you out.

[mintty]

Cygwin 3.1.0 has been released with ConPTY support. This means that mintty can likely be used unpatched.

[ViralBShah]

@mintty Is there a standalone binary that we can bundle with the Julia install?

[mintty]

No, someone will have to build it based on cygwin 3.1.0, and bundle the cygwin DLL with it.

[ViralBShah]

While this was not easy at all, thanks to @vtjnash I have a working set of binaries that I have uploaded to https://github.com/JuliaLang/mintty-julia

Please try it out by starting path-to-mintty\mintty path-to-julia\julia. It seems to pretty much work. I tried UnicodePlots and ProgressMeter. I think the right thing to do is to ship it as part of the windows distribution of Julia and set things up so that double-clicking Julia automatically loads in mintty.

These lines kill the extra console that seems to open up for me.

julia> ccall("GetConsoleWindow", stdcall, Ptr{Cvoid}, ())
Ptr{Nothing} @0x00000000001b0090

julia> ccall(("ShowWindow","user32"), stdcall, Cint, (Ptr{Cvoid}, Cint), ans, 0)

24

It would be great to have folks try this out, and help with making it part of the julia installer.

[davidanthoff]

Great!

Works on my system (same thing with the extra console that needs to be killed with your code). I'm on the latest Windows 10.

Could the default font be made bigger? It started out with a font size of 9pt, which looked not good.

Where are the settings for this stored? Probably in the registry somewhere? In a Julia specific location? I think that would be better than shared with other mintty installations? And we should make sure the installer deletes these settings at uninstall time.

I think it also doesn't look great in Task Manager, this is what I get after starting it:

Would be nicer if there was a top-level entry for Julia, like there is today when Julia is started via the shortcut:

[davidanthoff]

Oh, and just noticed one more thing: It would also be nice if the icon (both in the window and in the taskbar) were the Julia icon, not the Mintty icon.

Just out of curiosity (I don't think this is important): does this support tabs?

And another (not super important) idea: could we make the copy/paste default keybindings the same that are used by Windows Terminal? That would be Ctrl+Shift+C and Ctrl+Shift+V.

[vtjnash]

I think that's coming in the next patch release https://github.com/mintty/mintty/issues/8?

[ViralBShah]

I think it can have a .minttyrc file somewhere to save the defaults.

Eventually, we somehow need to set things up to prevent the console window from opening, rather than opening and immediately closing, which would be an annoying flash every time you start Julia.

[ViralBShah]

@musm You seem to know most about the windows installation process. Would you have some time to help integrate mintty into the windows installer?

[ViralBShah]

Perhaps the DejaVu fonts also need to be installed and used in mintty by default in order to have the best experience with unicode, at least on Windows 7.

https://github.com/JuliaLang/julia/blob/master/doc/build/windows.md

Perhaps Windows 10 does better on this front.

[cserteGT3]

I love the idea, and gave it a try. Here is what I've experienced:

• I tried to change working directory within julia with cd() but it failed.
• Ctrl+C doesn't interrupt the running function but kills julia.
• Printing larger amount of texts (e.g. shell> git status in a git directory) feels slower, than doing the same from command line.
• I am happy, that finally I can see the icon of the pinned packages (⚲)
• And I agree that bigger font should be set as default.

cd() fails

When I simply start julia, it works:

C:\Users\cstamas\Documents\GIT\mintty-julia>julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\mintty-julia"

julia> cd(raw"C:\Users\cstamas\Documents\GIT\JuDocPlottest")

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\JuDocPlottest"

julia>  

And with the command:

C:\Users\cstamas\Documents\GIT\mintty-julia>mintty.exe -ha julia

I get:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\mintty-julia"

julia> cd(raw"C:\Users\cstamas\Documents\GIT\JuDocPlottest")

julia> ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

Thw following command throws the same error:

C:\Users\cstamas\Documents\GIT\mintty-julia>mintty.exe --dir C:\Users\cstamas\Documents\GIT\JuDocPlottest\ -ha julia

Result:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

I'm not sure what happens, because I can't start mintty from an other folder:

C:\Users\cstamas\Documents\GIT\JuDocPlottest>C:\Users\cstamas\Documents\GIT\mintty-julia\mintty.exe -ha julia

Results in:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

Ctrl+C kills julia

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> using JuDoc

julia> serve()
Activating environment at `C:\Users\cstamas\Documents\GIT\JuDocPlottest\Project.toml`
→ Initial full pass...
┌ Warning: I found an {{insert ...}} block and tried to insert 'C:\Users\cstamas\Documents\GIT\JuDocPlottest\src\_html_parts\..\..\assets\menu7\test\plotly1.html' but I couldn't find the file. Ignoring.
└ @ JuDoc C:\Users\cstamas\.julia\packages\JuDoc\Q8uS7\src\converter\html_functions.jl:60
→ Starting the server...
✓ LiveServer listening on http://localhost:8000/ ...
  (use CTRL+C to shut down)
julia: Interrupt.

[aviks]

If you want a more native experience, the new Windows Terminal is installable from the Windows Store.

It does not do emojis yet (meant to be coming soon), but other unicode works well. UnicodePlots works. Actually, even emojis work if you connect to a linux shell (via WSL or SSH). Been using it for the past few months, and havent missed my OSX Terminal.

[ViralBShah]

I didn't realize it was available through the app store. Should this be simply documented - so people can get the windows terminal from the app store or download mintty from our site?

[ViralBShah]

Apparently Windows 7 EOLed couple of days ago: https://support.microsoft.com/en-us/help/4057281/windows-7-support-ended-on-january-14-2020

[timholy]

@aviks, dumb question: does this make ;ls work as those of us with ingrained Linux habits expect? If so, do you just install Windows Terminal and then start julia from its prompt?

[ViralBShah]

I think you literally just get the terminal. So shell mode probably won't do anything. But you can install WSL and Ubuntu or something to get all of that.

[aviks]

Yes, this is basically just the terminal emulator (and console host). It's still running a windows shell inside (either Cmd or PS), and so shell builtins do not work, as per this old issue: https://github.com/JuliaLang/julia/issues/6316

If you did want a linux shell, then WSL is pretty easy to use (I use it a lot) -- but that is of course, an additional layer.

[ViralBShah]

Apparently you need Windows 10 1903 update for the Terminal, which was released May 2019. Seems like an automatic update so almost everyone on Windows 10 should have it.

https://github.com/microsoft/terminal#prerequisites

[PetrKryslUCSD]

Was the idea of bundling Git bash with Julia abandoned? It would solve both the problem of a decent terminal, and also the underlying functionality of the shell.

[visr]

almost everyone on Windows 10 should have it

Not quite yet, unfortunately. Many businesses are slow to update. In this report from October 2019 about 40% uses older builds: https://reports.adduplex.com/#/r/2019-10

As mentioned above in https://github.com/JuliaLang/julia/issues/7267#issuecomment-505099197:

Now we just have to wait another few years for it to be present by default on most Windows machines. In the meantime, can we ship something?

[davidanthoff]

I finally figured out how to get a precise OS split from our VS Code telemetry data, I'll report back once I've put it into a more usable format. That should give us a good idea how many folks are on what version of Windows.

[ViralBShah]

The main issue, as in the case of the Braille pattern spy plot, is that we need 100% coverage on all supported platforms.

[PetrKryslUCSD]

How does the mintty by itself address the deficient "shell" mode on Windows. It does not, or am I wrong?

[ViralBShah]

This issue is about addressing a deficient terminal, not the deficient shell.

[PetrKryslUCSD]

Yes, but why not think about both at the same time? There is a solution...

[davidanthoff]

Here is the user split we have for the VS Code extension, I think for something like the last 90 days or so (not entirely sure about the time window):

[ViralBShah]

Yes, but why not think about both at the same time? There is a solution...

Maybe separate issue? I feel this is already late and we should get it in. Replace with a better thing later whenever it is ready.

[StefanKarpinski]

It seems good to me to go ahead with shipping mintty; people don't have to use it, but at least it's a good out-of-the-box experience. Should have been done years ago, but better late than never.

[PetrKryslUCSD]

It will be an improvement, that is clear.

On Thu, Jan 16, 2020, 4:51 PM Stefan Karpinski [e-mail]
wrote:

It seems good to me to go ahead with shipping mintty; people don't have to
use it, but at least it's a good out-of-the-box experience. Should have
been done years ago, but better late than never.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/7267?email_source=notifications&email_token=ACLGGWBWIMVNME772K5KVQDQ6D6KDA5CNFSM4AQRFZ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJGCMUI#issuecomment-575415889,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACLGGWCHSZ3HAHZTZNSHYNDQ6D6KDANCNFSM4AQRFZ6A
.

[jebej]

For me ctrl-c does not kill the terminal, and ctrl-d works properly.
cd does not work and makes mintty/julia crash.

It seems that preferences also cannot be saved to disk, with mintty complaining about a non-existent .minttyrc file, even though I created it manually. Maybe this is a general filesystem issue.

FYI the mintty version is 3.0.2, which is not the latest one.

[jebej]

In addition, I do not get any issues when I use the version shipped with MSYS2, so these are probably compilation troubles.

[ViralBShah]

I am guessing the ctrl-c is going to mintty instead of to Julia. Perhaps there is a way to change these defaults. I had to use a mintty that @vtjnash provided me. The latest binaries did not seem to work for me.

[oif2003]

I noticed the mintty binary you provided leaves an extra blank "mintty.exe" window open when starting julia via the command line with "mintty %julia path%julia.exe". If I send ctrl+c to that blank window, it interrupts code running in julia without closing out mintty.exe. This is not the behavior I get on mintty 2.9.5. At least as a crappy work around we can easily hide the extra window, intercept ctrl+c while julia REPL is the active window and redirect it to the hidden mintty.exe window.

[oif2003]

One catch though, ctrl+c sent while julia is not executing code will result in it exiting.

EDIT:
It appears that the byte at memory location 0x1004AA3C8 stores julia's execution state. 1 = ready, 0 = busy. This is for 64bit julia.exe.

EDIT2: The address is for Mintty.exe that is hosting julia.exe.
I have made two scripts based on my previous post. One using Mintty 3.0.2, which crashes on cd(). The other using Mintty 2.9.5. The latter does not crash on cd(), and instead of sending keystrokes, it sends SIGINT directly to julia.exe via Windows API.

[aminya]

I found this new cross-platform and customizable Terminal recently. It supports

• Hyperlinks
• Image
• Mouse support
• ...
  https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

It supports Linux, Windows, macOS, and even a web browser!
Watch a demo here:

[davidanthoff]

Windows Terminal 1.0 shipped today.

[ViralBShah]

Windows Terminal is the thing to use. However, the issue is that it seems to require a much more recent version of Windows than what we support. Is it possible to ship Windows Terminal (no idea how easy it is) and fallback to the cmd if it doesn't start?

Does winget solve all these problems for us somehow?

[StefanKarpinski]

Can we just close this issue already? We’re clearly never going to do anything about it.

[aminya]

Windows Terminal is not a terminal itself. It is a terminal manager and it uses other terminals. If we want to use a Microsoft Terminal, we should use PowerShell Core.

What I suggested here is a real terminal with mouse and image support.
https://github.com/JuliaLang/julia/issues/7267#issuecomment-583810189

[musm]

Can we just close this issue already? We’re clearly never going to do anything about it.

100% Please do so. Nothing productive has come out of this discussion.

[aminya]

Can we just close this issue already? We’re clearly never going to do anything about it.

100% Please do so. Nothing productive has come out of this discussion.

This issue is not solved yet. There is an unsubscribe button for opting out of the notifications.

[PetrKryslUCSD]

Most (all?) of the issues with the inadequate access to the operating system facilities through the shell mode can be solved by running the editor from within Git bash. For instance be VS code, Atom, Sublime Text. All would start Julia in a capable terminal emulator, with the expected Linux commands working in the shell mode. In my opinion, adding support for the Windows Terminal will add nothing but complexity.

[StefanKarpinski]

There is an unsubscribe button for opting out of the notifications.

Good point. This is officially the first Julia issue I’ve ever unsubscribed from. Someone send me a hologram when this issue gets ~resolved~ closed without doing anything in 2026 👋🏼

[ViralBShah]

I did install Git-Bash and simply use that.

[musm]

Windows Terminal is not a terminal itself. It is a terminal manager and it uses other terminals. If we want to use a Microsoft Terminal, we should use PowerShell Core.

What I suggested here is a real terminal with mouse and image support.
#7267 (comment)

This is not true. PowerShell Core, or now simply PowerShell (as of version 7), is a _shell_, just like cmd, pwsh, and bash are. On the other hand, Windows Terminal is a _console or terminal_, just like the myriad other terminals that are available, including MinTTY, ConEmu etc.

[aminya]

I am referring to the GUI of the terminal/console/shell. I am not concerned with the name. Julia already has a REPL with its rules, and using it from CMD is similar to using it from PowerShell. The good reason to use something new is to add some GUI features.

Windows Terminal does not add much GUI features, and it needs a shell (like CMD or PowerShell) to be called from inside it.

[stevengj]

Then can we stop worrying about Unicode rendering problems for people using the Windows Console?

For example, can we merge #33821 and tell Windows users who don't like seeing sparse matrices displayed as ?????? to download a better terminal?

Or do we continue to limit our display capabilities to the low bar set by the Windows console for the next 5-10 years, until the Windows Terminal is the default on all supported Windows systems? (We currently support the 11-year old Windows 7. How long will it be until we drop support for all Windows systems that don't ship with Windows Terminal?)

[musm]

For example, can we merge #33821 and tell Windows users who don't like seeing sparse matrices displayed as ?????? to download a better terminal?

IMO, some may disagree, but I think this is a perfectly reasonable approach, since it allows us to innovate. We can add Windows 7, to "supported", but not all functionality in terms of rendering fonts may be available by default without installing a better terminal, to the platform list.

While Windows 10 remains fully supported and we add a link the new Windows Terminal. For example, that PR renders perfectly with the new Terminal, since it also includes a decent font with ligatures.

[ViralBShah]

I think we should merge and move on. Given the ample number of options, we should not consider this our problem. I would also consider that a reasonable way to close this issue - in that we won't ship a terminal (we don't ship one on any OS).

[stevengj]

Okay.

(There have always been better terminals available for Windows, so I expect that the release of the Windows Terminal won't really resolve anything for several years, until it becomes the default — it won't stop the endless stream of complaints about Unicode rendering in Windows. Most Windows users still won't know how run Julia in a better terminal. But if we officially give up on out-of-the-box experience and say "get a better terminal," I guess that is one way to answer those questions.)

[ViralBShah]

Yes there have been better terminals available, but it somehow feels to me that it is much simpler today than even a year ago to install them.

To avoid the complaints - is there a way to test if a "good" terminal is being used so that a warning can be issued?

[ViralBShah]

A lot of windows users also use Juno/vs-code nowadays which probably do ok with Unicode display.

[ViralBShah]

Just like the other OSes, we will now expect users to "bring your own terminal". Once Windows Terminal is more widespread, hopefully we can detect it and start Julia using that, etc.

Documentation is updated about Terminals, and we have also updated the Downloads page to require Windows 10.