Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sublime Merge

sublimemerge.com

Post reply on HN
Print view View original

91–97 of 97 posts

Re: Sublime Merge

#91

Post by lsllc »

ben-schaaf wrote: post #88
lsllc wrote: post #71

Long time Sublime user, both Sublime Text and Sublime Merge. I started back with ST2, ST3 and I have ST4 and have use Merge since it was released. These days I now mostly use nvim+lazyvim for coding but I do continue to use Sublime Merge as my primary git environment. @ben-schaaf I'd love to see tree-sitter+LSP come to Sublime Text, as well as telescope+rg+fzf style fuzzy search. I find the lazyvim+telescope integrat…

There's well supported LSP plugins for Sublime Text, and also a working tree sitter plugin. If that's what you're looking for I suggest giving those a try.

I haven't looked at package control in a while, I'll take a look! Thanks

Re: Sublime Merge

#92

Post by ben-schaaf »

dgellow wrote: post #90
ben-schaaf wrote: post #32

Earlier quoted context omitted.

The GUI framework we use for ST and SM is fully custom. We use GTK, Cocoa and Win32 for platform integration and custom software/OpenGL rendering (with a little help from Skis).

Thanks! Not open source I presume? Would be interested to learn more

t's interface is unstable, undocumented and it tightly integrates with the rest of our codebase; even if it was open source it would not be usable to anyone.

Re: Sublime Merge

#95

Post by the_gipsy »

ben-schaaf wrote: post #50
the_gipsy wrote: post #38

> Commit Faster - Stage Files, Hunks and Lines with no waiting - Sublime Merge is really, really fast. Fast as opposed to what? What could possibly be slow here? It's just local git operations.

`git add` can be quite slow when handling large files, in large repositories, with a large index or on slow platforms. For instance this optimization in git brought the runtime of `git add .` on Windows with 200k files from 6s to 3s: https://github.com/git/git/commit/d1664e73ad96aa08735bf81d48... . 100ms let alone 3s is much too long a wait, so Sublime Merge predicts the outcome of staging and presents that immediate…

I've never noticed a delay in my life.

So, "predicts outcome", what does that even mean? I know the outcome of `git add` is... the file being added. And it has to run the command in the end anyway.

Re: Sublime Merge

#96

Post by dgellow »

ben-schaaf wrote: post #92
dgellow wrote: post #90

Earlier quoted context omitted.

Thanks! Not open source I presume? Would be interested to learn more

t's interface is unstable, undocumented and it tightly integrates with the rest of our codebase; even if it was open source it would not be usable to anyone.

Noted, I appreciate the response. In any case, congrats, it works really, really well

Re: Sublime Merge

#97

Post by ben-schaaf »

the_gipsy wrote: post #95
ben-schaaf wrote: post #50

Earlier quoted context omitted.

`git add` can be quite slow when handling large files, in large repositories, with a large index or on slow platforms. For instance this optimization in git brought the runtime of `git add .` on Windows with 200k files from 6s to 3s: https://github.com/git/git/commit/d1664e73ad96aa08735bf81d48... . 100ms let alone 3s is much too long a wait, so Sublime Merge predicts the outcome of staging and presents that immediate…

I've never noticed a delay in my life. So, "predicts outcome", what does that even mean? I know the outcome of `git add` is... the file being added. And it has to run the command in the end anyway.

It means that the outcome is shown immediately on the next rendered frame instead of waiting for the command to complete, then reading the index and updating the UI from that. You knowing the outcome is exactly the point; the UI needs to be responsive immediately because you're not waiting to find out what happens.

As an example: Lets say it takes 200ms to run `git add` and then another 100ms to read the index; you want to stage 3 files. You click the first stage button, nothing happens and you move to click the next stage button, now the UI updates and removes that first file shifting what you're about to click on. This behavior was extremely annoying when it came up in testing.

With prediction here's what happens instead: You click the first stage button, immediately the UI updates removing that file, you move to click the 2nd which again is immediately removed. Transparently in the background `git add` is run and we confirm the end the result is as predicted.

Post reply on HN