Sublime Forum

Current changes under WSL don't show in Sublime Merge

#5

I am on Windows 11. I have been using Merged installed directly in WSL for about a month now as a workaround, but the GUI is just not nearly as pleasant to use.

0 Likes
#6

I don’t know if Win11 will let you do this, but WSL1 does support file change notifications and I’ve been using it for years without issue. It’s fine for command line operations, but obviously not going to help if you need Linux GUI apps.

0 Likes
#7

WSL 1 or 2 don’t support file notifications between Windows and Linux. File notifications work on both OSs individually.

0 Likes
#8

This is still my biggest issue with/request for Sublime Merge. Is there really no way currently to fix it? How does VS Code run just fine in Windows connected to WSL?

1 Like
#9

Could someone at Sublime look at VS Code does this and emulate it in Sublime Merge? Even the GitLens extension running in VS Code, which is running in Windows but connected to WSL, shows changes made to files in WSL just fine.

0 Likes
#10

I believe that VSC does this by implementing a custom server task that runs separately inside of WSL and communicates with the running VSC instance to tell it what’s going on.

You can get around this particular problem by running Sublime Merge directly inside of WSL though.

0 Likes
#11

I think you are right about that. And yes, I know that I can (see my 2/15 post above). That’s what I am doing, but the GUI isn’t nearly as nice to use. And perhaps if something similar to VS Code’s server were implemented for Merge, then Merge could also work over SSH connections, as VS Code does. I think VS Code may use the same server for WSL and SSH connections.

0 Likes
#12

Just out of curiosity (since I use Sublime and Merge both natively and in WSL), what changes in the UI for you that makes it not pleasant to use? Related to Linux windows behaving differently as far as window management is concerned?

0 Likes
#13

What I currently do is run a rsync script inside my VM (or in your case WSL) and sync in the changes from the host. That way, all changes are happening locally and gets copied to the vm.

1 Like
#14

I may implement that as a workaround. Could work for a separate host over SSH as well. Thanks for the suggestion!

0 Likes
#15

Largely the same things I see with any GUI running out of WSL. Windows scaling doesn’t get applied, snapping doesn’t work, resizing the window is often painful, no button to minimize (can click on the Taskbar icon), etc. Here is how the two look side by side on my monitor (4k, 175% scaling):

image
image.png3557×2091 427 KB

0 Likes
#16

Yep. Because WSL is using Linux. If you are familiar with Linux, you can probably configure the desktop/window manager (this is the one that controls the UI in Linux) inside WSL.

This is why I opted to “push in” the files to the VM instead of working inside WSL. I’d rather dual boot if I really want to use Linux as my dev env instead.

0 Likes
#17

I agree that Windows could be a lot smarter about how it merges these windows.

For what it’s worth, you can tweak the buttons that appear in the window caption (which solves one of the annoyances, but certainly not most of them).

tmartin:PCTERM:~> gsettings get org.gnome.desktop.wm.preferences button-layout
'appmenu:close'
tmartin:PCTERM:~> gsettings set org.gnome.desktop.wm.preferences button-layout ":minimize,maximize,close"
tmartin:PCTERM:~> gsettings get org.gnome.desktop.wm.preferences button-layout
':minimize,maximize,close'
0 Likes
#18

I don’t think this is true.
WSL adds inotify & filesystem change notification support - Windows Command Line (microsoft.com)

Can we please get support to run Merge in Windows for repos stored in WSL?

0 Likes
#19

inotify is for linux apps running inside wsl environment, only. It is unrelated with native windows filesystem notification APIs, which are required to inform native windows apps about changes of files within wsl.

I am not a developer at sublimehq, but to my understanding of things - as soon as WSL would start forwarding filesystem changes to native windows APIs, it would work without any changes needed in SM/ST.

0 Likes
#20

That article is from before WSL2. WSL nowadays is just a Linux VM with a couple integrations which doesn’t include filesystem notifications. If you use WSL1 filesystem notifications should work.

0 Likes
#21

Ok, that makes sense, thanks.

VS Code’s implementation works very well. I use it almost every day with VS Code running in Windows but my repo located in WSL or on a server accessed via SSH. There are good graphics showing how it works here:

Maybe Sublime could implement something like this? Being able to use Merge for a remote server would also be huge for us.

0 Likes
#22

For WSL, I usually rely on VSCode’s built-in Git support plus the Git Graph extension.

VSCode’s Git also suffers the same problem of ‘not reloading changes automatically’. Unlike SMerge it does have a consistent cross-platform GUI, no visual bugs, and wouldn’t suddenly force close or freeze on me.

I do have a SMerge license (just renewed today, too) but of late I’m relying on VSCode Git and LazyGit a lot more. I use SMerge when I need to commit specific hunks of text - VSCode isn’t very precise about that yet.

2 Likes
#23

I haven’t used VS Code to pull/push/commit/etc., but if I save a file in VS Code, git in WSL knows it was changed. If I change a file in WSL, the change is reflected in VS Code without me having to do anything. If I change a branch in WSL, the branch change shows up immediately in VS Code. When I say “VS Code” here, I mean VS Code running in Windows and connected to WSL with the WSL extension, as described in the first link here:

Sublime team, is there any reason the approach described there can’t be implemented for Sublime Merge?

0 Likes
#24

Sublime team, is there any reason the approach described there can’t be implemented for Sublime Merge?

Other than a large amount of work needed to separate all the IO so it can run on a separate executable and send it over the network, no there’s no reason it couldn’t be implemented the same way.

1 Like