Live data from Hacker News

Atom 1.29

blog.atom.io

71–80 of 120 posts

Re: Atom 1.29

#71
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?

large files aside, Sublime's startup time is what's keeping me.

Re: Atom 1.29

#72

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?

I have seen changesets for Atom before that include something like "make typing faster and more responsive".

Re: Atom 1.29

#73
post #53

Earlier quoted context omitted.

I think the goal is adding a sense of lightheartedness and by humanizing code in general, which has historically had the perception of being dry.

Also if your coding guidelines can use emojis in commit message to mean a certain thing if you all have a common lookup and it becomes natural to see what a change affects. e.g. :bug: for fixing bugs

You can do that with plain ASCII, e.g. Github recognizes the phrase "Closes #123." in commit messages and autocloses that issue when the commit is merged into master. I've seen similar commit hooks in SVN over 10 yrs ago.

Re: Atom 1.29

#74
post #15

Earlier quoted context omitted.

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 am curious about your situation that causes you to edit files remotely. I've never had to edit files anywhere but my local file system. Are you developing or is it more of a devops/sysadmin kind of role?

One reason I use it is if I am working on an embedded device. Sometime I just want to go in and try a concept out that I couldn't just spin virtual machine up for.

Re: Atom 1.29

#75
> ensuring that parsing can never impact the frame rate.

This is exciting. Anyone has feedback anout how it actually impact performance?

Re: Atom 1.29

#77
post #48
post #44

Earlier quoted context omitted.

I never use emojis (I'm not even sure how people manage to input them on a keyboard, I assume they're using mobile devices?) but I try to avoid the kneejerk reaction of hating on them, they're mostly harmless. It's very tempting to go on a "back in my days we couldn't even put accents in commit messages" rant but in the end it doesn't really matter. If it makes writing commit messages more fun and it means that peopl…

> they're mostly harmless. I don't believe that, the confusion around the meaning of emojis are well established[0][1][2][3]. I strongly suspect that the confusion and vagueness is even more predominant in professional communications than personal. Please consider that everyday the likelihood of someone reading your code who is from a different culture or context is even higher, somethings might seem obvious to us, b…

Your first 3 links are all referencing the same University of Minnesota study. Your last link seems to be based on the writer’s observations (I did not find it linking or mentioning any study). I’m not even disagreeing with the fact that some emojis can be misunderstood (especially cross-culturally and when they are displayed very differently on devices) but you can’t just link 3 news stories covering the same study as if you’ve found a mountain of evidence to support your claims.

Re: Atom 1.29

#78

Will Atom and Visual Studio Code merge into one project now that Microsoft bought GitHub? Or at least stop sharing extensions? I would vote yes! I would love to see better GitHub integration in VS Code.

Have you seen the upcoming GitHub PR integration in VS Code: https://github.com/Microsoft/vscode-pull-request-github

Re: Atom 1.29

#79

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?

I have seen changesets for Atom before that include something like "make typing faster and more responsive".

Generally most of those changes are for when someone is using 25+ cursors at once, or are in very large documents that reflow a ton on every character.

Typing a single cursor in most documents was never really an issue in Atom. But when you layer on a ton of plugins that do all kinds of stuff, and add in some complicated grammars with larger documents and lots of cursors at once, then performance would start to suffer.

Re: Atom 1.29

#80
post #17

Earlier quoted context omitted.

The "future CEO of GitHub" said they will continue to develop and support both VSCode and Atom: https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman... HN discussion here: https://news.ycombinator.com/item?id=17258114

I just really hope they continue with this experiment: https://github.com/atom/xray . It's reducing Electrons job to the view / plugin layer and have most processing done in a Rust backend.

There's also a similar project hosted by Google, Xi, which seems significantly more promising than xray.

[1] https://github.com/google/xi-editor

Post reply on HN