lotabout/skim

Windows support

sophiajt opened this issue ยท 11 comments

Is there interesting in adding Windows support, by chance? With more recent libraries, like crossterm, and the new tui libraries, there's more available to build on than when #25 was originally asked.

@jonathandturner I am actually trying to use crossterm for window's support. But for now there are some blocking issues:

What about termwiz which is also portable across multiple OS including Windows. It is used in wezterm which is another gpu accelerated terminal written in rust.

It has BufferedTerminal for optimal writes to terminal so it only writes deltas as well as first class support for Widgets.

@prabirshrestha Thanks for point out termwiz, I'll have a look.

I was super excited to have a library that offers advanced fuzzy search. Not a binary, a library that I can embed as well in my applications.
Windows support would be really nice to have! Anything I can do to help? ๐Ÿค”

@lotabout - are there any updates on skim supporting Windows?

I was using skim as a library for a little application I'm building, and absolutely loved it. Just found out now though that it doesn't run on Windows, which is a platform I want to support. I'll probably have to call out to fzf instead.

I would be willing to help you try and support Windows, although sadly I don't know much about working with terminals. I would imagine the new Windows Terminal product would make it easier to support?

heatseeker (another fuzzy filter written in Rust) uses the Windows API to write to the console. This should be a good starting point to understand how to do it or how to use termwiz.

rnag commented

I would definitely to some length be interested in Windows support, in case that were ever to be a thing. I'm using a Windows 11 64-bit PC and currently rocking a Powershell console (which doesn't support emojis either, which is a bummer), so I think it would be cool to see sk supporting Windows if possible.

Tbh I'm planning to use this in another project I'm still exploring, so likely in my case just envisioning this as a cargo dependency rather than a binary such as sk; though a binary for Windows would also be a neat idea, of course.

Edit: that project I mentioned can be found here.

If possible, I'd like to see this done in a way that doesn't rely on ConPTY, which would both make it unusable on Windows 7-8.1 (and Windows 10 systems somehow still without 1809), and can be a significant performance bottleneck due to the Win32 API translation required for applications outputting escape sequences directly, which is necessary to remain compatible with existing Win32 applications. Furthermore, relying on ConPTY may impact the supported escape sequences independently from the console emulator support; this is at least one reason why few Windows terminals properly support the mouse. I don't believe mouse support is of particular concern for skim, but perhaps some other escape sequences may prove problematic.
My experience as an end user is that programs using crossterm, compared to those using pancurses (and by extension, cursive), are often unusable without winpty, hobbled even with winpty, and in some cases, can even manage to be less usable in something like mintty (with or without winpty) than in plain cmd.exe
One example of crossterm vs pancurses is git-interactive-rebase-tool, which switched from using pancurses to crossterm between versions 1.2.1 and 2.0.0. From 2.0.0 onward, on my old Windows 7 laptop, it has output raw escape sequences when using winpty, and ignores the terminal window size and user inputs in mintty without winpty. Version 1.2.1 continues to work fine on that machine, using winpty. I can't actually say definitively that this is crossterm's fault, but I've had far more trouble using programs built with crossterm than with pancurses.

@lotabout any chance?

pa-0 commented

FYI: @rnag,

(Off-topic, I know, and 2 years late but at any rate...)

The author of the PowerShell module, Terminal-Icons, hasn't pulled this commit yet, but I believe that is their intention... FWIW I use this in module PowerShell, and IMO it's awesome.

In the meantime, here is the link to a branch with added emoji support. Hope that helps!