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

211–220 of 236 posts

Re: VS Code Roadmap 2018

#211

Post by phaedrix »

fasquoika wrote: post #189
pritambaral wrote: post #139

Earlier quoted context omitted.

> It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year I thought only the vim users used that refrain. vim users are also unlikely to switch to a different editor.

Vim users used to, but now that emacs has a decent text editor[0], they can't. [0]: https://github.com/emacs-evil/evil

or even better - https://github.com/syl20bnr/spacemacs

Re: VS Code Roadmap 2018

#212

Post by c-smile »

Just in case (Sciter's author is here):

This is prototype I've made to give an idea of how the same thing could be done in Sciter: https://sciter.com/htmlcss-desktop-ui-solutions-distribution...

In general it is expected that such thing can be done in 5% of VS Code distribution size.

Sciter draws things faster than Electron as e.g. on Windows it uses DirectX directly. Electron uses Skia that is mostly CPU based rasterizer.

Yet to make syntax highlighting I've introduced "marked runs" - https://sciter.com/tokenizer-mark-syntax-colorizer/

That allows to do syntax highlighting without change of DOM. In VS Code, in order to make things at least somehow moving, they were forced to implement sliding window editing - DOM represents not full text but only viewable portion. That creates a lot of problems and significant portion of Code is the fight with limitations of browser's DOM.

Re: VS Code Roadmap 2018

#213

Post by phaedrix »

iaml wrote: post #26
pbiggar wrote: post #20

Earlier quoted context omitted.

Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files. So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (no…

iterm has terrible latency, you should try using alacritty - way faster.

Unfortunatley Alacritty has the same issues:

From Alacritty's FAQ: Q: "macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty."

Re: VS Code Roadmap 2018

#214

Post by crispinb »

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…

> What's wrong with using vim or emacs and being happy rest of your career?

I agree with your basic notion -- it takes quite some time to be really fluent with serious IDEs and editors, so changing is inefficient.

But just one editor/IDE doesn't work for everyone. If you favour a GUI-only editor like Sublime Text, for example, then you probably need to also know a console-based one. Or if like me you prefer a heavy IDE for most project work, you probably need to be fluent with a lightweight editor.

For me IntelliJ IDEA + emacs covers all the bases. I'll look briefly at new tools to keep familiar with the landscape, but I'd rather invest the time it would take to learn them into something which will improve my skills in something more useful to the craft than just more tools that do essentially the same things.

Re: VS Code Roadmap 2018

#215

Post by maccard »

theresistor wrote: post #164
maccard wrote: post #135

Earlier quoted context omitted.

I just started visual studio code on my workstation, and it took 9 seconds to display a window, followed by 2 more seconds before populating it with an empty document. Sublime was sub second startup

My low-end MacBook opens it in less than 2 seconds.

I've just tried it on a gaming PC (i7, installed on an NVM SSD.) 4 second startup compared to instant for Sublime.

Even still 2 seconds is too long for quick edits.

Re: VS Code Roadmap 2018

#216

Post by maccard »

Zyst wrote: post #144
maccard wrote: post #135

Earlier quoted context omitted.

I just started visual studio code on my workstation, and it took 9 seconds to display a window, followed by 2 more seconds before populating it with an empty document. Sublime was sub second startup

I've always had sub second startup times. With text rendered within the first 1.5-2 at most. Time to "Actual interactivity" usually takes around 3-5 seconds, but that's mostly due to my plugins. I could start typing per-se, just not in Vim mode. I mostly leave the editor permanently open on the project I'm working on, so I guess I don't really notice it much either way. And using the integrated terminal to change one…

> I mostly leave the editor permanently open on the project I'm working on

I leave Visual Studio permanently open, but I use sublime for quick edits/viewing/changes (e.g. opening a remote file on perforce, or modifying a config file), so even 2 seconds to interactivity is just too long.

Re: VS Code Roadmap 2018

#217

Post by Already__Taken »

sambeau wrote: post #166
Already__Taken wrote: post #54

Earlier quoted context omitted.

shift+alt click seems to behave just like sublime does, I left sublime a long time ago, I'm not sure what you're trying to describe there? Do you mean because it selects the rectangle? Just hit an arrow key.

Last I tried you couldn't scrape down the right side of the ragged edge. I'll try it out again as maybe it's fixed. I also found the 'extra' cursors too faint previously. Hopefully that's been improved too. I'll give it a go as there's so much to like about it.

Ah I see what you mean.

I wouldn't call that a problem per-se. It draws a cursor where there it text to draw one. This makes sense to me as I can edit a column of values and not pick up already empty columns.

To do what you want I'd just multi-cursor the start of all the lines and hit end. Usually ctrl+arrow over word boundaries gets anywhere I need after that.

Anything fancier still I've just written a regex instead.

Could certainly be a preference option to enable blank lines on multiple cursors. it would have to fill the white space.

Re: VS Code Roadmap 2018

#218

Post by Already__Taken »

sambeau wrote: post #170
sambeau wrote: post #166

Earlier quoted context omitted.

Last I tried you couldn't scrape down the right side of the ragged edge. I'll try it out again as maybe it's fixed. I also found the 'extra' cursors too faint previously. Hopefully that's been improved too. I'll give it a go as there's so much to like about it.

I've tried it and there is still a problem: the cursors draw from wherever the previous cursor was. This makes it impossible to draw a line of cursors vertically through your text without first placing a single cursor at either the top of the bottom of where you want to draw the line. So instead of click-drag (with a modifier key) you have to click-click-drag (with a modifier key).

I do find the click-click drag annoying too.

Re: VS Code Roadmap 2018

#219

Post by Vinnl »

deburo wrote: post #200
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.

The most compelling feature to me is that it can give different variables a different colour.

Re: VS Code Roadmap 2018

#220

Post by Vinnl »

teh_klev wrote: post #98
Vinnl wrote: post #80

Earlier quoted context omitted.

Not OP, but my browser is open pretty much all the time, and pinning tabs ensures they don't get lost.

So today I just learned you can pin tabs :)

Next lesson: you can switch to the n'th tab using Alt+ (or perhaps a different modifier key depending on browser and OS). Since pinned tabs appear on the left-hand side, that means you'll always have e.g. Alt+1 for email, Alt+2 for calendar, etc.

(Nice and related is that you can do Super+ for window switching in at least Windows and Ubuntu.)

Post reply on HN