The pending pane feature is really an improvement, because I found myself closing tabs way too often.
Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
31–40 of 176 posts
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#32Lack of MRU tab switching and preview tabs are two reasons I haven't switched from sublime. Glad they are listening to requests.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#33I don't really want more features for Atom. I just want it to be faster. Right now it's incredibly sluggish compared to e.g. Sublime. Is there any hope on this front, or are the performance issues intrinsic?
Sublime is written in C++ while Atom is written in JavaScript. Atom is going to be slow by design. Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?
Given that VSCode is fast on the same Electron core also written in JavaScript, I think it's a lazy approach to simply dismiss it as, "Must be JavaScript! Case closed!"
And, there have been editors written in a variety of higher level languages for decades, many that are slower than JavaScript, that aren't (as) slow as Atom. There's more to it than language choice.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#34I have been ignoring the Atom hype because "geeze a programmers editor written as a big blob of JavaScript on my desktop that sounds like a dumb idea". Then I tried it and it's wonderful and magical.
We actually forked Atom and built an email app. It's worked surprisingly well!
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#35I don't really want more features for Atom. I just want it to be faster. Right now it's incredibly sluggish compared to e.g. Sublime. Is there any hope on this front, or are the performance issues intrinsic?
Sublime is written in C++ while Atom is written in JavaScript. Atom is going to be slow by design. Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?
See, I thought that too until I actually tries out Brackets and VS Code and realized that no, it really is just Atom being slow.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#36I really wish there was a way to use Atom in client/server mode. I'd like to leave a headless session running on my home Linux server and be able to attach to it from work. Right now, I use SSHFS to mount the remote directory so I can edit locally, but it leaves a lot to be desired. Considering that Atom is all just Node and Chromium under the hood, it's surprising that there's no way to run at is as a server.
Check out nuclide.io. It's built on top of atom by Facebook. I haven't tried it, but one of its features is remote development using client/server.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#37The new features and updates are great, but the one thing holding me back from using it is the fact it is extremely slow and laden with performance issues. Anyone who has ever attempted to open a file with a lot of lines of code will attest to the fact that Atom has issues. Ironically, Microsoft's open source Visual Studio Code editor is based in part of some aspects of Atom and it has exceptional performance and is…
Define "a lot of lines". I have used Atom almost every day for the last couple of years now. Startup and opening files of, say, 5mb or larger sucks. But I've never had an issue with opening typical file sizes.
I switched to Atom mostly because of the plugins but I still keep sublime installed for the rare occasions I need to open a large file.
Now I'll admin there have been a few times when I haven't closed Atom for weeks and it'll act a little slow while typing (which can be really frustrating) but closing it and reopening it always fixes it (I'm assuming some memory leak is the culprit).
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#38The new features and updates are great, but the one thing holding me back from using it is the fact it is extremely slow and laden with performance issues. Anyone who has ever attempted to open a file with a lot of lines of code will attest to the fact that Atom has issues. Ironically, Microsoft's open source Visual Studio Code editor is based in part of some aspects of Atom and it has exceptional performance and is…
I've been trying to work out what makes VSC so much faster than Atom. Whatever magic Microsoft did really needs to make it back upstream because it'll make using Electron-based apps much less frustrating.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#39It just locks up my MBP until I eventually close it just like atom 1.5 did. I've never understood the point of this editor, however to be fair, I've never been able to use it without severe performance issues. I can run 8+ instances of jetbrains without even breaking a sweat but running atom out of the box is a non-start.
Re: Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API
#40Earlier quoted context omitted.
I see this comment every time an Atom post gets on HN. Are you sure it's not just your computer specs? If Atom continually makes the HN front page then many people must be using it just fine and like it? Personally I'm not sure why we need another text editor of all things, but hey its made in javascript which is hip at the moment.
It is certainly slower than Sublime, and is so on well-speced machines. I have machines with i7s, 16gb of ram, and an SSD, and atom still chokes when dealing with large amounts of data. Try multiple selections on large text files and watch it grind to a halt. Certainly people are falling in love with Atom. It is open source ("hackable editor", as they say at Github), and of course this leads to a much quicker develop…
And Sublime is sometimes slower than VS2015 or even Notepad++ on a similar kind of machine.
Can we convince companies to work on making things run faster instead of just making the hardware faster instead?