The fact that VS Code's version isn't ready yet, and Atom's is makes me think that Microsoft wanted to respond to Atom's announcement. But I honestly have no idea if that's the case. Just pure speculation.
Edit: Atom's announcement was yesterday. Microsoft's was today. That further fuels my speculative hunch. :)
Or it's based on some paired programming hype/growth/buzz that happened months ago and both decided to implement it as an option. I mean it takes a while to implement complex feature sets like this, so maybe some trend in the industry got people in both communities trying to implement this at the same time?
It's not exactly groundbreaking. SubEthaedit did it years ago.
That's why I've been using Atom instead. Since 1.17 or so it got quite usable and it's getting better with every iteration. Nowhere near as fast as Sublime Text but usable for daily coding. I disabled the git plugin because we're using fossil. I hope it doesn't become an IDE like VS Code. At least they made the IDE packages separate.
Regarding fossil, do you use fossil for tickets and self-hosting? How well do fossil tickets work compared to Github issues? Do you use any custom themes for fossil tickets?
We used tickets somewhat and we are self hosting through a nginx proxy in order to log the http activity and proxy over https. The ticketing has markdown support. We use a custom theme, not for tickets but for the whole repo. Fossil tickets are only used internally, we use osticket regular ticketing.
There is also a service for hosting fossil repos called Chisel, but it's nowhere near as useful as Github.
VS Code is trying hard to be an IDE for all languages. If you use pure VS code without extensions, it quite snappy. But as you start adding more and more extensions, it starts slowing down and that too quite fast.
This is true, but its still very snappy for an electron app.
After adding around 10+ plugins on Atom it not only became slower but it started crashing or having internal errors.
With VS code I have 17 plugins installed and it still feels light enough. Personally I disable most plugins until I need them and I think most people should do the same considering how easy it is to disable a plugin.
I have all my language specific plugins disabled until I need to use them.
Does/would a high-end (e.g., Xeon-class) processor and/or a boatload of RAM help keep Code's performance snappy?
FWIW, I run my Code install quite light since my "duties and responsibilities", ahem, only require a few languages/data types, ergo, I am not pushing it hard at all.
FTR, I have a (licensed) install of Sublime, which I confess is snappier than Code, but the difference is so small I use whichever one is better for the task at hand and any difference dissappears under the pressure of an outage enforced deadline :-D
this is only true if we're strictly talking editing text wihtout any plugin functionality. As soon as you add code completion features vim shows its age, the Ale extension for async linting for example feels very sluggish on a few only slightly dated laptops I tried out and frequently grills the cpu.
I also noticed ALE was very slow with JavaScript so changed it to run on save only.
However Neovim’s plug-in architecture is a big improvement. I’m running Deoplete (which provides intellisense like functionality) on the same machine, and it is basically instant. There are GIFs at the bottom of the repo:
That VS Code is not Emacs-like, that’s my problem with it.
In my experience nothing beats Emacs at editing text. Vim has better shortcuts, but Emacs is just smart about everything.
My problem with Emacs is that it’s showing its age, it’s hard to configure and you have to learn an old and obscure LISP dialect for it. On the other hand I’ve heard that VS Code plugins are a joy to develop, MS apparently did a good job at that.
But Emacs? Yes please, I want that — plus to be honest, in 20 years from now Emacs will still be around, whereas I have my doubts about these fancy new editors.
> you have to learn an old and obscure LISP dialect for it
As someone who is glancingly familiar with emacs (I have only ever written one elisp function, that too with help) it's a really stupid question, but couldn't emacs have bindings for lua or python or something? That would increase the number of people who can program for it and customize it.
> in 20 years from now Emacs will still be around
I think the real risk for emacs is, over the years, slowly losing the pool of people who care enough to contribute to it -- not just core developers, but also people who write packages, themes, etc. I already see a lot of developers who think Atom / VSCode / Sublime Text is "good enough". You may choose to discount Sublime because it's closed source (I do despite loving it otherwise), but VSCode and Atom are open-source and browser technology is only going to get better.
Elisp would still a better much better language than python or Ruby (for emacs), especially now that lexical binding is becoming standard. Emacs people would like to move to scheme, if anything. (even RMS wishes emacs would move to scheme.)
Emacs is a lisp; there's a very small and tiny layer of C at the bottom and everything else is a tower of lisp. You can interact with it with other languages, via many different means, but in the process you lose the joy and power of working in a live lisp environment.
> there's a very small and tiny layer of C at the bottom [...]
That layer of C is hardly "tiny." Everything from font drivers to process management to a lisp interpreter to window and buffer code, to overlays, and a lot more.
There's 1,262,537 lines of elisp in 25.3, compared to 291,203 lines of C and C headers. While there is a fair amount of C code to do what you mentioned, much of the C is definitions for the core lisp language with 1,483 DEFUN statements in it.
But yah, not tiny, sure. I'm looking forward to it being replaced via the REmacs project.
(Several years of realtime editing experience reporting in)
Plain text CRDT and OT systems are often mutually adaptable. Even if they aren't directly compatible, with a bit of work it'll probably be possible to adapt from one realtime editing protocol to the other.
Of course, in the medium to long term having a standard for OT/CRDT operations that works in a lot of source code editors would be fantastic.
I guess that when users make the habit of using the free tool, then the company that provides it can easily embed other convenience habits that could
potentially lead to a future sale.
Both Microsoft and Github have commercial products to sell at a later stage, VSCode has now integrations with Azure, I don't know about Github integrations on Atom but the potential is there.
When the user is using your free tool you are one step closer to provide something additional that is so convenient that is hard to say no, even if is paid.
Ballmer's Law: "Developers, developers, developers." If you want to be a platform vendor, you need to have developers. Lose the developers and you lose the business.
Microsoft has been a platform vendor for a long time. VSCode is part of their argument for why they should continue to be one.
What I'm interested in is whether Live Code Share is a free service.... feels like it might be a paid service. Or limited free then pay? Not sure. It's also for visual studio.
Also be interesting if someone makes a teletype plugin for VSCode :)
This reminds me of that rant from last week about how computers are less functional these days than they were in the 80's. The reason is that the Amiga had cooperative document editing way back when. (Sorry, can't remember the programs that supported it.)
/Some version of AmigaDOS also had truly relative timestamps. So you might see a file last accessed "Christmas, 1991."
Interestingly enough, this feature is the primary reason behind Atom itself existing. We saw the first internal demo of "Atom" (I believe it was "Thunderhorse" at the time) 6-7 years ago, and the main idea was real-time collaboration on code. That sorta took a backseat for awhile as GitHub started to recognize that a collaborative editor was pretty swell in its own right, but glad to see that it's finally all come full circle.
This one single feature could potentially have the largest impact on my workflow in 2018. As much as I love async task management. Real-time collaboration with remote team members should be fascinating ;)
I guess the next step would be something along the lines of Google Wave where you could playback the "conversations" and see the learning process develop.
Even as the author, I think web-based IDEs have pretty limited utility, but it is a great showcase for the power of our API. We (my co-founder and I) built this in about 10 days.
Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption this behemoth requires.
Yeah, someone complains about the resource usage in every Atom post.
I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it.
As time goes on the resource usage becomes less of a problem. My 4 year old laptop has 16GB of RAM and I don't really worry about it. I'll get 32GB or 64GB in my next computer. I never liked quibbling over memory. My time is much more important to me and I want the best tools. I also want them to swim in RAM.
For certain definitions of 'high-end', maybe. You've been able to configure workstation-class laptops with 64 gb for a few years now.
And most mid- high-end laptops will happily accept 32GB, again going back a few years.
(Broadwell removed the density limitation that made 16GB DIMMs a no-go; anything that takes DDR4 should support 16GB SODIMMs, excepting the very low end Atom, Celeron etc.)
You really aren't. Atom runs fine on a Macbook Air. There are definitely performance issues, but we're addressing them; it's just that our team is small and our initial goal at launch was to produce the most hackable text editor possible.
I had to drop Atom when it began launching white flashes when scrolling on a 2011 MBA. I saw that this was a recurring problem. Is that an issue that is being addressed?
Personally I don't mind RAM usage that much. I'm more concerned about excessive CPU usage resulting in unnecessary battery drain on my laptop or annoying fan-spinning.
Atom for me consistently sits at 0-0.1% (mostly 0) CPU usage when idling. You may want to investigate some of the extensions you're using if the numbers are different for you.
It was the lag (and at the time, struggling to open "large" files) that stopped me giving it more than a cursory check a year or so ago. No idea if it's worth looking into again? Would be hard to beat sublimes snappiness doing almost any task.
Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today.
I wonder why do those people even care.
The only time I look at my resource usage is when apps start to behave funny. Or when it's an app that I am developing. Other than that, why should one care?
One argument could be made that they are using memory wastefully. Not sure that's the case. The baseline memory consumption is higher, so what? It's a tradeoff. It's easier to build a better editor using browser-based tools, as much as I like Elisp. Over time Atom and VSCode will close the gap.
Now, if there is a memory leak, or memory increases non-linearly with the workload, than it could be a problem. VI and Emacs are pretty great with large files (Emacs not so great with long lines), browser-based editors usually do not work as well. But there is no reason they shouldn't, it just takes engineering effort.
"Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today. I wonder why do those people even care."
Well, because if an application you're using is constantly swapping, it'll slow that application down to a crawl. This was especially true back in the day when disk was slow (and expensive.. as was RAM).
People today are used to being awash in resources. RAM is fast, plentiful, and cheap. Disks are relatively fast and cheap.
You have to imagine what it was like to live in a resource-constrained environment where you actually had to care about how much memory and disk you used, and how you were using it. These decisions had severe, immediately apparent practical consequences.
What I meant to say was that "eight megabytes" sounds silly today. Who cares if an app uses 8MB today? The extrapolation is that it will be the same for Atom or other editors (I'd argue that it already is).
I created my first programs with a computer which had exactly 28815 bytes free when it booted up (out of a possible 64k). If you plugged in a floppy drive, the free memory dropped further.
"I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it."
The thing is, this was in fact a valid critique of Emacs back in the day, and it cost Emacs users. I know I stopped using it back then partially because of its resource use (and because it was a lot slower than vi and because of its finger-twisting keyboard shortcuts).
If Emacs was as light on resources as vi was back then, it would have more users today.
I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump:
In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations.
1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter.
2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box.
3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements).
4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
What are the current plans about Coffeescript? I just looked at the code on Github, it says 85% Javascript, 12% Coffeescript. Is the plan to port the 12% to JS6? (and hopefully not Typescript)
Great work with Atom editor. I successfully conviced my friends to move from VSC to Atom on macOS.
Thanks! Yeah all of the CoffeeScript in atom/atom should be gone in a few months probably. We use plain JS now.
It'll probably take a while before there's no more CoffeeScript in the entire Atom org. We're gradually converting the code to JS as we come upon it for other reasons.
On the Atom.io website https://atom.io/ it reads "A hackable text editor for the 21st Century". Well I can code in JavaScript 5 and 6. I love love it when a project sticks to web standard, and not have to worry about slangs I don't care about.
> Typescript is great at catching bugs
The same with JavaScript. Google Closure compiler and anyway most IDEs "understand" JavaScript too and catch bugs. JavaScript is dynamically typed not typeless.
I was surprised to see someone who cared what style of javascript a program is written in, especially if they aren't an active contributor. Maybe you are?
It's like having Leonard Cohen transpiled to Justin Bieber. Now look at it from the Justin Bieber fans point of view, why would they listen to Leonard Cohen in order to hear Justin Bieber ? Even though research says Leonard Cohen makes better music! From Leonard Cohen fan's point of view it doesn't matter as they only hear Leonard Cohen, not Justin.
I've been using Atom since 2015 and it's only getting better on each new version.
I tried going back to Sublime which has objectively much better performance but that doesn't make the whole experience better. It's like sitting in a Formula 1 car with no cushion and no AC.
As did I, but I just couldn't get over how slow it was.
Startup time on windows was rough, meaning I had to remove it as a default editor almost immediately for most filetypes. Worse off, opening large files would grind Atom to a halt and usually lock the editor up.
Beyond the performance, I thought it was a great text editor. The problem is I just have no use for a slow-to-start editor when I can just DL vscode and get the same features with considerably better performance.
I love Floobits also. Works great in those I've tested: IntelliJ, Atom, and Emacs. But what is still missing in many of these peer programming solutions is the ability to leave for a few moments (or a few days) then return and do a playback of what your peer(s) did while you were gone.
Apparently the protocol can be implemented by any editor, so hopefully we'll end up in a glorious future where this works in lots of browsers (including VSCode, who just announced their own version of this)
“participants all keep their own custom key bindings, packages, and themes.”
what happens when two different people editing the same document have two different settings for # spaces per tab character? whose takes precedence? (Or would there be a possibility of inconsistent spacing depending on who is adding a tab?)
I would guess that tab -> spaces happens locally, and then the spaces are what's sent over the wire. So it would be whoever inserted the tab. (What other possibility could there be?)
The document isn't "using" anything, since a document is a passive object. Unless you have something like vim modelines where you configure it at the top of the file like `/* vim: set tabstop=8:softtabstop=8:shiftwidth=8:noexpandtab */
`, the document itself doesn't know anything about how things _should_ be (which is the important part).
an opened document inside an editor is absolutely aware of this, and this is what you're collaborating on. almost all IDEs support EditorConfig, which makes standardizing on things like that across teams trivial.
If it is displayed spaces per tab character, then there is no conflict in the file but the appearance should be different to different viewers.
If it is space characters replacing a tab keypress, then the spaces in the document should reflect the conversion ratio of the user that typed the tab.
i prefer this over floobits in that i don't need a floobits account, just a github account, which pretty much all devs will already have. it would be nice if there was a way to do this without needing the github account though.
Atom’s detriment with this post is that there’s 4 paragraphs of text before I can even see what this feature looks like, and even then it’s gifs on how to install the feature.
I have never tried real time collaboration. What scenarios are there when you need real time collab. I know technical interviewers prefer this. Do you think it causes distraction when you have 2 people writing code on a same file. I would rather one finish and then do my stuff.
Ever been to a hackathon? It's hard to coordinate over Git when you're just getting started on a codebase and there's barely anything for the 3 other people to work on. I've used Cloud9 for this very successfully in the past.
Am I the only one who finds it ironic that the development teams behind the top two open source editors introduce support for collaborative editing on the dame day, apparently unaware that they were both working on the same thing, and there being no evidence of collaboration between the two?
On-topic, I remember recently Uber and Lyft were working on a similar feature, and both knew about the other but neither knew that the other knew. I wish I could remember what the feature was.
Not sure if there's been a way to integrate separate emacs processes, but it has always been possible to launch a new frame (emacs speak for window) displaying the same buffer, and given network transparency in X, have it displayed on any remote computer running X.
I just stopped sharing the document. I was just running it over crappy cafe wife for 2.5 hours, max ~20 people, always 5 to 10... performance seemed fantastic - didn't tax my lappy at all. Very impressed!
[Re-shared it at 28e6c3b4-754c-44ef-9406-869604db9db5 - it would be good if you could keep a UUID somehow, but I guess that's unfeasible]
229 comments
[ 0.26 ms ] story [ 235 ms ] threadEdit: Atom's announcement was yesterday. Microsoft's was today. That further fuels my speculative hunch. :)
Which makes me curious, does Github know what Microsoft is going to announce at their conference, or did Microsoft knew what Github is building?
[1] https://en.wikipedia.org/wiki/Multiple_discovery
It's not exactly groundbreaking. SubEthaedit did it years ago.
Just had a déjà vu with Microsoft's NetPC, announced just after Sun Microsystem's Network Computers.
That said, I do like VS Code very much. Gave Atom a try, but it felt sluggish and its add-ons were very fragile.
There is also a service for hosting fossil repos called Chisel, but it's nowhere near as useful as Github.
http://chiselapp.com/
After adding around 10+ plugins on Atom it not only became slower but it started crashing or having internal errors.
With VS code I have 17 plugins installed and it still feels light enough. Personally I disable most plugins until I need them and I think most people should do the same considering how easy it is to disable a plugin.
I have all my language specific plugins disabled until I need to use them.
Does/would a high-end (e.g., Xeon-class) processor and/or a boatload of RAM help keep Code's performance snappy?
FWIW, I run my Code install quite light since my "duties and responsibilities", ahem, only require a few languages/data types, ergo, I am not pushing it hard at all.
FTR, I have a (licensed) install of Sublime, which I confess is snappier than Code, but the difference is so small I use whichever one is better for the task at hand and any difference dissappears under the pressure of an outage enforced deadline :-D
this is only true if we're strictly talking editing text wihtout any plugin functionality. As soon as you add code completion features vim shows its age, the Ale extension for async linting for example feels very sluggish on a few only slightly dated laptops I tried out and frequently grills the cpu.
However Neovim’s plug-in architecture is a big improvement. I’m running Deoplete (which provides intellisense like functionality) on the same machine, and it is basically instant. There are GIFs at the bottom of the repo:
https://github.com/Shougo/deoplete.nvim
In my experience nothing beats Emacs at editing text. Vim has better shortcuts, but Emacs is just smart about everything.
My problem with Emacs is that it’s showing its age, it’s hard to configure and you have to learn an old and obscure LISP dialect for it. On the other hand I’ve heard that VS Code plugins are a joy to develop, MS apparently did a good job at that.
But Emacs? Yes please, I want that — plus to be honest, in 20 years from now Emacs will still be around, whereas I have my doubts about these fancy new editors.
As someone who is glancingly familiar with emacs (I have only ever written one elisp function, that too with help) it's a really stupid question, but couldn't emacs have bindings for lua or python or something? That would increase the number of people who can program for it and customize it.
> in 20 years from now Emacs will still be around
I think the real risk for emacs is, over the years, slowly losing the pool of people who care enough to contribute to it -- not just core developers, but also people who write packages, themes, etc. I already see a lot of developers who think Atom / VSCode / Sublime Text is "good enough". You may choose to discount Sublime because it's closed source (I do despite loving it otherwise), but VSCode and Atom are open-source and browser technology is only going to get better.
That layer of C is hardly "tiny." Everything from font drivers to process management to a lisp interpreter to window and buffer code, to overlays, and a lot more.
But yah, not tiny, sure. I'm looking forward to it being replaced via the REmacs project.
https://github.com/Wilfred/remacs
It can, and here is an example: https://blag.bcc32.com/ecaml-getting-started/2017/11/05/emac...
And here is a better link I guess: http://diobla.info/blog-archive/modules-tut.html
Plain text CRDT and OT systems are often mutually adaptable. Even if they aren't directly compatible, with a bit of work it'll probably be possible to adapt from one realtime editing protocol to the other.
Of course, in the medium to long term having a standard for OT/CRDT operations that works in a lot of source code editors would be fantastic.
Both Microsoft and Github have commercial products to sell at a later stage, VSCode has now integrations with Azure, I don't know about Github integrations on Atom but the potential is there.
When the user is using your free tool you are one step closer to provide something additional that is so convenient that is hard to say no, even if is paid.
Microsoft has been a platform vendor for a long time. VSCode is part of their argument for why they should continue to be one.
Also be interesting if someone makes a teletype plugin for VSCode :)
/Some version of AmigaDOS also had truly relative timestamps. So you might see a file last accessed "Christmas, 1991."
Interestingly enough, this feature is the primary reason behind Atom itself existing. We saw the first internal demo of "Atom" (I believe it was "Thunderhorse" at the time) 6-7 years ago, and the main idea was real-time collaboration on code. That sorta took a backseat for awhile as GitHub started to recognize that a collaborative editor was pretty swell in its own right, but glad to see that it's finally all come full circle.
Even as the author, I think web-based IDEs have pretty limited utility, but it is a great showcase for the power of our API. We (my co-founder and I) built this in about 10 days.
I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it.
As time goes on the resource usage becomes less of a problem. My 4 year old laptop has 16GB of RAM and I don't really worry about it. I'll get 32GB or 64GB in my next computer. I never liked quibbling over memory. My time is much more important to me and I want the best tools. I also want them to swim in RAM.
Even now the highest end laptops have same 16GB RAM. Sad state of affairs :(
And most mid- high-end laptops will happily accept 32GB, again going back a few years.
(Broadwell removed the density limitation that made 16GB DIMMs a no-go; anything that takes DDR4 should support 16GB SODIMMs, excepting the very low end Atom, Celeron etc.)
That's what I think, and the reason I use SublimeText.
Yet vim is still more popular today by a wide margin. :)
It's not just about memory usage; it's about lag. Atom felt laggy to me. I also value my time, and I can't stand waiting for my editor.
But try VSCode. I do not notice any lag on the Mac.
I still prefer Emacs due to the maturity of its packages. But I have used VSCode for a month and I have no complaints about the performance.
I wonder why do those people even care.
The only time I look at my resource usage is when apps start to behave funny. Or when it's an app that I am developing. Other than that, why should one care?
One argument could be made that they are using memory wastefully. Not sure that's the case. The baseline memory consumption is higher, so what? It's a tradeoff. It's easier to build a better editor using browser-based tools, as much as I like Elisp. Over time Atom and VSCode will close the gap.
Now, if there is a memory leak, or memory increases non-linearly with the workload, than it could be a problem. VI and Emacs are pretty great with large files (Emacs not so great with long lines), browser-based editors usually do not work as well. But there is no reason they shouldn't, it just takes engineering effort.
Well, because if an application you're using is constantly swapping, it'll slow that application down to a crawl. This was especially true back in the day when disk was slow (and expensive.. as was RAM).
People today are used to being awash in resources. RAM is fast, plentiful, and cheap. Disks are relatively fast and cheap.
You have to imagine what it was like to live in a resource-constrained environment where you actually had to care about how much memory and disk you used, and how you were using it. These decisions had severe, immediately apparent practical consequences.
What I meant to say was that "eight megabytes" sounds silly today. Who cares if an app uses 8MB today? The extrapolation is that it will be the same for Atom or other editors (I'd argue that it already is).
I created my first programs with a computer which had exactly 28815 bytes free when it booted up (out of a possible 64k). If you plugged in a floppy drive, the free memory dropped further.
So, I do understand resource constraints.
Btw,
The thing is, this was in fact a valid critique of Emacs back in the day, and it cost Emacs users. I know I stopped using it back then partially because of its resource use (and because it was a lot slower than vi and because of its finger-twisting keyboard shortcuts).
If Emacs was as light on resources as vi was back then, it would have more users today.
In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations.
1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter.
2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box.
3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements).
4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
Great work with Atom editor. I successfully conviced my friends to move from VSC to Atom on macOS.
It'll probably take a while before there's no more CoffeeScript in the entire Atom org. We're gradually converting the code to JS as we come upon it for other reasons.
On the Atom.io website https://atom.io/ it reads "A hackable text editor for the 21st Century". Well I can code in JavaScript 5 and 6. I love love it when a project sticks to web standard, and not have to worry about slangs I don't care about.
> Typescript is great at catching bugs
The same with JavaScript. Google Closure compiler and anyway most IDEs "understand" JavaScript too and catch bugs. JavaScript is dynamically typed not typeless.
I've been using Atom since 2015 and it's only getting better on each new version.
I tried going back to Sublime which has objectively much better performance but that doesn't make the whole experience better. It's like sitting in a Formula 1 car with no cushion and no AC.
Startup time on windows was rough, meaning I had to remove it as a default editor almost immediately for most filetypes. Worse off, opening large files would grind Atom to a halt and usually lock the editor up.
Beyond the performance, I thought it was a great text editor. The problem is I just have no use for a slow-to-start editor when I can just DL vscode and get the same features with considerably better performance.
I'd like to explore whether Teletype can be used across editors in a similar manner.
Floobits has plugins for all major editors, including Vim and IntelliJ, as well as Google Hangouts.
https://floobits.com/
Disclosure: I used Floobits a few times and think it’s awesome 10/10
Please enlighten us to how you got it to work at all. I use neovim.
Edit: can in the future, not now. So we'll see
what happens when two different people editing the same document have two different settings for # spaces per tab character? whose takes precedence? (Or would there be a possibility of inconsistent spacing depending on who is adding a tab?)
If it is space characters replacing a tab keypress, then the spaces in the document should reflect the conversion ratio of the user that typed the tab.
[1] https://teletype.atom.io/
Subtle.
On-topic, I remember recently Uber and Lyft were working on a similar feature, and both knew about the other but neither knew that the other knew. I wish I could remember what the feature was.
I must have missed the announcements for vim and Notepad++.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Em...
Although if you're doing remote editing you probably want to use Tramp.
https://www.gnu.org/software/tramp/
Edit: it's still working great even with 15+ people - very slick!
Also, here's the madness in repo form - https://github.com/mrspeaker/teletest
[Re-shared it at 28e6c3b4-754c-44ef-9406-869604db9db5 - it would be good if you could keep a UUID somehow, but I guess that's unfeasible]
Or do you mean targeting web games, much like was discussed in this HN post: https://news.ycombinator.com/item?id=13264952
Really cool stuff !
https://code.visualstudio.com/blogs/2017/11/15/live-share