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

VS Code Roadmap 2018

github.com

Post reply on HN
Print view View original

191–200 of 236 posts

Re: VS Code Roadmap 2018

#191

Post by SiVal »

vanderZwan wrote: post #74
SiVal wrote: post #52

I'd love to have an editor scripting language in VS Code that would be a lighter-weight way to create an editing macro than building an extension. Despite the annoying scripting languages, both vim and emacs get a lot of their power and popularity by enabling users to easily add little, custom editing features that they can then bind to keystrokes. Not a macro recorder, but a real scripting language in which cursors,…

Given that it's an Electron app, wouldn't it suffice to use plain JavaScript (or TypeScript, given that part of the editor's raison d'être ), and add a few extra "built-in" modules specific to the VS Code environment?

Yes, I think that would be just fine as long as the modules encapsulated the "native" functionality of the editor. As long as developers could easily orchestrate and build on top of existing editor (& built-in git, terminal, extension, etc.) functionality without having to reimplement it from basic JS string processing, JS (incl. but not requiring TS) would seem the logical choice.

Re: VS Code Roadmap 2018

#192

Post by Shorel »

abritinthebay wrote: post #132
balefrost wrote: post #89

Earlier quoted context omitted.

One very specific performance metric is startup time, and Sublime beats the pants off VSCode in that department. Creating new top-level windows in VSCode is also annoyingly slow compared to Sublime (presumably because it's spinning up a new browser context). Other than that, it seems snappy enough.

Sure, Sublime is practically instant whereas VSCode takes... maybe slightly more than half a second on my machine. It’s noticeable but is it really that much of an issue?

Opening big files, opening lots of files, doing search and replace in open files, and my favourite, use thousands of parallel cursors to thousands of simultaneous edits in a single file, they are all noticeable slower in VSCode.

Damn, I love me them multiple cursors.

Re: VS Code Roadmap 2018

#193

Post by Shorel »

jeffisabelle wrote: post #115
manyxcxi wrote: post #76

Earlier quoted context omitted.

> I’m not monogamous with my code editors I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them. I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode. I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS…

> I’ve always wondered why some people seem so married to a single editor. I'm thinking exactly opposite. I wonder why people change their IDE's/Editors so much between Eclipse/Visual Studio/IntelliJ or between notepad++/sublime-text/atom/VScode/coda/text-mate etc. What's wrong with using vim or emacs and being happy rest of your career? It's funny so many of my colleagues kid me by saying "emacs is a great operating…

I used EditPlus for over 8 years until SublimeText appeared, and have been using it for the last five years.

I think your point applies to current users of Atom/VSCode, but for me Sublime has stood the test of time, again and again.

Re: VS Code Roadmap 2018

#194

Post by Shorel »

ssijak wrote: post #3

As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.

Quoting myself:

>If there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.

>It's the rolling coal of computers.

Re: VS Code Roadmap 2018

#195

Post by SippinLean »

mrweasel wrote: post #48

Has configuration become any better? I tried using VS Code for both Go and Python and all the magical stuff you needed to add to JSON files in weird places became a show stopper. I simply cannot figure out how it ties together and or figure out what my configuration options are.

I don't remember that ever being the case. The settings are in settings.json, that's "how it ties together."

It opens alongside the default settings file, that's a searchable list of "what my configuration options are."

Clicking the name of the property in the default settings file copies it to your personal file with the value you select. It's even easier than Sublime to configure.

Re: VS Code Roadmap 2018

#196

Post by mikewhy »

and0 wrote: post #187
mikewhy wrote: post #167

Earlier quoted context omitted.

Pinned tabs still get closed with Ctrl/Cmd+Shift+W, which is a bit of a drag. I make SSB apps for my most used websites, for me it's much faster than: - switch to chrome - switch to chrome window with pinned tab - switch to pinned tab

SSB?

"Single-site browser", or "site specific browser".

Basically a very thin wrapper over the systems web view.

Re: VS Code Roadmap 2018

#197

Post by segmondy »

balefrost wrote: post #89
Vinnl wrote: post #79

Earlier quoted context omitted.

> some don't like the electron-based thing/performance It's mostly not liking Electron-based, performance is very reasonable for VSCode, I think. As for the end-game: it's most likely luring you into Azure. Tight integration with a proper editor/IDE might give it an edge over competitors.

One very specific performance metric is startup time, and Sublime beats the pants off VSCode in that department. Creating new top-level windows in VSCode is also annoyingly slow compared to Sublime (presumably because it's spinning up a new browser context). Other than that, it seems snappy enough.

I just opened a new window with 9 file tabs, and it opened in 3 seconds. I'm using a 2012 quad i5 desktop with non SSD drives. I suspect with SSD, it will be 1-2 seconds.

Re: VS Code Roadmap 2018

#198

Post by segmondy »

I have 22 years of daily vi experience. VS Code is the only visual editor that I can stomach outside of vim. I have tried sublime, eclipse and hated them. Tried emacs many occasions, but just couldn't be bothered to learn all those shortcuts.

Re: VS Code Roadmap 2018

#200

Post by deburo »

Vinnl wrote: post #84

It's (unfortunately but understandably) marked as a stretch goal, but semantic colouring sounds really nice. I first came across the idea in this post about KDevelop: https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from...

What's the main idea behind this?

EDIT: oh, instead of defining a color scheme with regexes (which kinda sucks), you would define colors based on the semantics given by the language service. That would be extremely nice indeed.

Post reply on HN