Live data from Hacker News

Atom 1.29

blog.atom.io

81–90 of 120 posts

Re: Atom 1.29

#81

I see a GIF of someone going deleting a couple lines of code, with a meter showing that the application is maintaining 60 FPS. Was this not something Atom could do before? It seems to me that the bare minimum should be maintaining 60 FPS while performing basic editing tasks…is there some nuance here I'm missing?

> bare minimum should be maintaining 60 FPS

Yours would be a nice world to live in.

I've seen IntelliJ and Eclipse both crawl when doing "basic editing tasks". Hell, Vim does it too if your line length is long.

Re: Atom 1.29

#82
post #15

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

The one reason I'm still using Atom is because of the remote editing experience with Nuclide + Watchman server-side. No other editor that I've tried comes even close (the connection drops, files get out of sync, new files don't show up, etc, etc) Given the huge number of people who work on remote servers, I find it surprising that proper solutions are still so hard to find. A "file system provider API" for VSCode is…

I've got a couple co-workers who feel the same. I've always just used ssh/vim in such cases, but apparently the remote-editing experience on VSCode isn't nearly as good as that of Atom for some reason. Otherwise, I really love VSCode, the only thing it lacks for me now is the ability to separate tabs into different instances/windows but that's more of an electron issue. I've pretty much stopped using jetbrain's products in favor of it.

Re: Atom 1.29

#83
post #9

Honest question: can someone explain why everyone loves emoji these days, especially with regards to 'modern' programming communities such as those around JS and Rust? Is it just a celebration of the fact that we have Unicode support everywhere now?

> can someone explain why everyone loves emoji these days

What do you have against emojis? I'm hoping I can set my hostname to all emoji characters (UTF-8) so that other workstations on the network will show my hostname as those emoji characters.

Re: Atom 1.29

#84

> ensuring that parsing can never impact the frame rate. This is exciting. Anyone has feedback anout how it actually impact performance?

I've been using 1.29 for a while in the beta with the new tree-sitter syntaxes, and i've noticed some changes.

It's not groundbreaking, but folding is definately better and more responsive, and using tons of cursors (which often happens from using a plugin that gives me sublime-style click-and-drag to place cursors ability) is improved by a noticeable amount.

The new parsers do regress when it comes to opening minified files though, so a 300kb file with the whole file "on one line" will drop the editor to 1fps (interestingly it only happens when something syntax highlighted is on the screen, so if I'm scrolling through a minified file and hit a large enough string that's not highlighted, the FPS picks back up to 60!), but opening 500mb+ logfiles isn't really an issue any more (meaning as long as there are linebreaks at reasonable points, and you don't mind waiting a second for it to open, it's pretty consistently fast). I'm not sure if that was the tree-sitter parser or other updates made in the last year, but at some point it stopped slowing down with "logfile" style large files.

Please keep in mind I have an... absurd... amount of plugins installed. I use this editor to do heavy javascript/flow development, as well as python and go and a bit of PHP, with a ton of "nice to have" plugins like automatic test runners, coverage reporters, "intellisense" style IDE stuff, and more for each language. It's also running on a pretty beefy 8-core 32GB machine. so interpret my experience through that lens.

Re: Atom 1.29

#85
post #65

I wish I could use Atom but I work with very large files at time and it is very slow at some tasks (like selecting all selections of text and editing them all at once), forcing me to use Sublime Text. Can some kind user tell me if this latest version performs better now?

Please don't take this the wrong way, but what do you need to do in very large files that requires a fancier editor?

I know people will give me shit for this, but this is one of the reasons why I like to have multiple tools for multiple use cases.

Atom is for development. It's for programming in source files and being basically an IDE that I have a lot of control and customization over.

When I need to work with long logfiles or hunt through large compiled text files, I use something like Sublime. And if the files get absurdly large (like 5GB+) I start reaching for CLI tools.

I completely understand that many don't want to work like that, and if it works for you then that's awesome! But I like my tools to be good at what they do, and if that means tradeoffs in areas that other tools are good at, then it's fine with me.

Even if Atom could never open a file over 100kb, I'd still use it daily, because it's plugin ecosystem, customization, and the ease that you can write very custom plugins for it is unparalleled. And if atom ever starts giving those things up to be able to open larger files, i'm going to be quite upset.

Re: Atom 1.29

#86

> ensuring that parsing can never impact the frame rate. This is exciting. Anyone has feedback anout how it actually impact performance?

I've been using 1.29 for a while in the beta with the new tree-sitter syntaxes, and i've noticed some changes. It's not groundbreaking, but folding is definately better and more responsive, and using tons of cursors (which often happens from using a plugin that gives me sublime-style click-and-drag to place cursors ability) is improved by a noticeable amount. The new parsers do regress when it comes to opening minifi…

Cool, I'll try again today, and try to update this thread.

Re: Atom 1.29

#87

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

Similar history with Atom, but I haven't looked back after switching to spacemacs :)

Re: Atom 1.29

#89
post #52

It's crazy that so fewer editors can fold code blocks in a compact manner, so that it hides line returns that are inside curly braces (might be a little trickier with python) including the ones which are just after and before those braces. So far only visual studio (not code) can do it properly, and one which name I forget. I posted issues everywhere about it. I'm still disappointed, or it might be difficult to imple…

Don't vim foldmethods do this?

Re: Atom 1.29

#90
post #52

It's crazy that so fewer editors can fold code blocks in a compact manner, so that it hides line returns that are inside curly braces (might be a little trickier with python) including the ones which are just after and before those braces. So far only visual studio (not code) can do it properly, and one which name I forget. I posted issues everywhere about it. I'm still disappointed, or it might be difficult to imple…

Scintilla (and scintilla-based editors) do this when `fold.compact` is set.
Post reply on HN