61–70 of 115 posts
It seems to work but it does render certain ligatures incorrectly on OS X for me. For example, ligature and <- is rendered as </. Since it's a dev build, I'm sure it will take some ironing out before it hits the stable version but this is really promising!
Earlier quoted context omitted.
Iosevka is way too thin for me. I'm going to try out Hasklig (moving from Ubuntu Mono)
I've spent the last six months trying out new fonts (m0n0, hack, monoid, hasklig, fira code, mononoki, fixedsys excelsior, iosevka, source code pro, input...) Nothing cuts it, there's always that tiny thing that bothers me, and I'm back with Ubuntu Mono.
I think Sublime Text is very good but has fallen behind in terms of version control. I think Atom and VS Code are winning the war right now. Especially because the latter are free.
It seems to work but it does render certain ligatures incorrectly on OS X for me. For example, ligature and <- is rendered as </. Since it's a dev build, I'm sure it will take some ironing out before it hits the stable version but this is really promising!
I think Sublime Text is very good but has fallen behind in terms of version control. I think Atom and VS Code are winning the war right now. Especially because the latter are free.
Why do people need git support in an editor so much? Using git from the terminal is easy and you always know what is executed because you do it manually.
And to answer your question, probably for the same reason why people have moved on from Assembler to C to managed memory languages to JS and to today's JS frameworks, they want to avoid the "rough" parts by adding another layer of abstraction. For some people constantly going back to the terminal looks "rough", I guess.
I think Sublime Text is very good but has fallen behind in terms of version control. I think Atom and VS Code are winning the war right now. Especially because the latter are free.
I personally prefer version control in sublime with suitable plugins it's the debugging experience that I feel is lacking in sublime Vs vscode and atom Sublime does not have the concept of panels so any kind of debugger in sublime looks and handles really bad
Earlier quoted context omitted.
I can only speak for me as someone who really loves the aesthetics of code, but there's something super enjoyable about things like arrow functions rendering as actual arrows in Java / JavaScript. It's so clean!
Yeah, only that it does that without any context. Ligature mishaps are doubleplus-unclean.
Earlier quoted context omitted.
I personally prefer version control in sublime with suitable plugins it's the debugging experience that I feel is lacking in sublime Vs vscode and atom Sublime does not have the concept of panels so any kind of debugger in sublime looks and handles really bad
The Built-In Terminal in VSCode is something I would love to see in Sublime. For Ruby Coding this would be sufficient for me. For Go I currently prefer VSCode because of the debugging capabilities.
NIH syndrome of re-implementing everything under one roof is not really required, since we are heavily utilizing desktop environments for the past couple of decades, which allows you to put separate applications in one screen.
Honest question: Why would you want ligatures in plaintext? Especially in code, wouldn't that be weird as some people tend to manually align their code? Like, modular_raft = 10 spam = 20 The "ft" in modular_raft should convert to a ligature so (I assume) it will then take one character, instead of two. Then developers viewing that source would have different alignments, depending on whether they use Sublime 3 or not.…
It's not about those kind of ligatures -- but about special programming fonts with programming-oriented ligatures (think >= etc).
Those still can affect code alignment, but there are people who are against manual alignment anyway.
Earlier quoted context omitted.
The Built-In Terminal in VSCode is something I would love to see in Sublime. For Ruby Coding this would be sufficient for me. For Go I currently prefer VSCode because of the debugging capabilities.
Implementing a "Built-in Terminal" mindset is what is wrong with VSCode/Atom etc. You already have a terminal emulator installed in your system, and you can tile the windows if you want a terminal right under your editor. NIH syndrome of re-implementing everything under one roof is not really required, since we are heavily utilizing desktop environments for the past couple of decades, which allows you to put separate…
Electron is what is wrong with them -- if anything is.
Built-in terminal has nothing to do with it.
>NIH syndrome of re-implementing everything under one roof is not really required, since we are heavily utilizing desktop environments for the past couple of decades, which allows you to put separate applications in one screen.
That's less streamlined than having the editor directly cater to different needs. The "separate git terminal window" for example doesn't know anything about your open files and vice versa.