Live data from Hacker News

Atom 1.29

blog.atom.io

61–70 of 120 posts

Re: Atom 1.29

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

They convey emotions and add a touch of lightheartedness and fun. It's all about a healthy balance. You can still have constructive discussions about complex topics, with emojis, without giving up the Professional Adult™ card.

Re: Atom 1.29

#62
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 spent a lot of time trying to get a proper remote-editing/incremental sync setup working. That sounds really interesting to me.

How many files are you able to handle, remotely, with Nuclide/Watchman?

Does it work if the remote files are on an NFS share (i.e. spotty inotify/fanotify support) mounted onto the server you're SSHing into (no, the NFS share cannot be mounted directly on the workstation)?

How many file-change events (on your workstation or on the remote) can this system successfully sync/handle in a short time? If there is, say, a 250k file alteration that happens due to checking out a branch, is there an indication that it detected the changes and is making progress syncing them, or does that necessitate a manual sync?

Context: I've worked in environments where local editing and manual sync got really annoying: for compliance/regulatory reasons, certain tools, e.g. source control, were only available on the remote server, so having all code on my laptop and manually syncing to the remote got quite tedious. Even better, the significant (i.e. I might conceivably need to open them/run tests that touch them) number of source files in the remote repo was in the tens of millions. I wasn't able to get any incremental sync/change-detection systems working successfully: on my workstation (OSX), large changes would overflow the fsnotify kqueue, no matter what wrapper around it I used. On the remote, watching was either unavailable (due to the age of the Linux server) or prone to failures in the event of large changes in files (e.g. checking out a new branch).

I've spent a lot of time mucking about with lsyncd, unison, and lots of other tools, and eventually gave up with the conclusion that directory-diffing is too slow given slow remote filesystems, and change notification systems aren't up to the task of managing bulk changes across a huge repo. Watchman sounds really promising here; I'd love to hear more about your experiences with it.

Re: Atom 1.29

#63

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?

Not sure why you think an editor should refresh it's view port 60 times per second while idle.

It's not exactly about refreshing 60 times per second, but actually, not hanging the main thread for more than 16ms at a time. That means it _could_ do 60fps if the user performs actions fast enough, not that it will actually update 60 times per second while idle.

Re: Atom 1.29

#64
post #34

Earlier quoted context omitted.

I agree that they are unprofessional. As far as I can determine, some people feel that they make a project or community seem more inclusive or welcoming - goals which I definitely consider worthwhile. But I don't personally feel that they are helpful in this persuit. Who are you trying to be inclusive of, seven year olds?

Outside of your friend group, most of us have been using smileys and emoticons in day-to-day chat for years - the presence of rich emoticons used to set messenger platforms aside from each other - and emojis are simply the latest generation of that. They’re primarily useful for providing some emotional context to some text - and whether displaying emotion is professional or not is really down to personal preference.

Maybe I'm just a robot, but by and large I don't believe that log or commit messages require emotional context. (I do use emoji for some messaging, Slack specifically.)

Re: Atom 1.29

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

Re: Atom 1.29

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

User-interface is still very laggy compared to Emacs but it opened large files much better than I expected, though it disabled syntax coloring for larger files and scrolling is really slow. I wonder how this compares to VS Code and Oni which are also built in Electron..

Re: Atom 1.29

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

User-interface is still very laggy compared to Emacs but it opened large files much better than I expected, though it disabled syntax coloring for larger files and scrolling is really slow. I wonder how this compares to VS Code and Oni which are also built in Electron..

I've tested it myself as well. It is still as laggy as I remember, such a shame. I really want a simple graphical editor that can color the files that have been modified in Git.

Re: Atom 1.29

#68
post #33
post #28

Earlier quoted context omitted.

I find the whole trend very childish and unprofessional. Why? Because emojis don't convey much meaning and borders on child-talk, worst yet, they're very vague and so makes for very poor and unprofessional form of communication.

I am baffled by your assertion that they convey little meaning. Do facial expressions also convey little meaning? To me the combination of both gives a hell of a lot more to base interpretation of tone on.

The issue I have with emojis is that they are rendered different on different fonts/devices, and because of this they can convey a different meaning.

Re: Atom 1.29

#69
post #33

Earlier quoted context omitted.

I am baffled by your assertion that they convey little meaning. Do facial expressions also convey little meaning? To me the combination of both gives a hell of a lot more to base interpretation of tone on.

The issue I have with emojis is that they are rendered different on different fonts/devices, and because of this they can convey a different meaning.

And text is read wildly differently depending on the readers's culture, mood, font, and how well they know the language.

Communication is messy as hell, and the fact that emoji's render differently doesn't add that much confusion in most cases (of course there are the odd watergun vs revolver emoji problems, but the worst offenders are slowly being brought into line)

Re: Atom 1.29

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

Would that the unicode support was indeed ubiquitous. Then you wouldn't need to parse the message for things like ":penguin:", you could just include the appropriate character/icon.
Post reply on HN