Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom 1.29

blog.atom.io

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Atom 1.29

#111

Post by nobleach »

mpolichette wrote: post #91

I don't understand the desire for all the git integration into the editor. I mean, it might make sense because Atom is owned by Github, but why otherwise? I feel like a lot of their resources are being put towards git integration instead of improving the editor and performance... which are some of the primary reasons people leave for VSCode. Maybe I'm the odd man out though, since I like to use CLI git directly.

Having used (and loved) both Magit in Emacs and Fugitive in Vim, I totally get it. It's simply a pleasant experience to not switch contexts too far away from my editor. I certainly don't mind performing Git-related tasks in my terminal, I just like the flow provided by Atom's Git integration. At this stage in the game, it's not perf that's holding me back. Both Atom and VSCode perform well enough to be a daily driver. For me it's Atom's far superior Vim mode that keeps me using it.

Re: Atom 1.29

#112

Post by CJST_ »

mpolichette wrote: post #91

I don't understand the desire for all the git integration into the editor. I mean, it might make sense because Atom is owned by Github, but why otherwise? I feel like a lot of their resources are being put towards git integration instead of improving the editor and performance... which are some of the primary reasons people leave for VSCode. Maybe I'm the odd man out though, since I like to use CLI git directly.

I'm still undecided on using the CLI exclusively. Although I always use the command line for anything complex, I do feel like my editor of choice (VSCode) provides a fair amount of value with its simple file staging GUI. It also does a good job of showing diffs between versions in-editor.

Re: Atom 1.29

#113

Post by paulddraper »

redisman wrote: post #104
paulddraper wrote: post #81

Earlier quoted context omitted.

> 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.

But IntelliJ and Eclipse (depending on the language) run compilers to do code checking right? Certainly too many text editors don't work very well with large text files which is a bit funny.

Yes, Intellij and Eclipse are IDEs, like Atom.

Re: Atom 1.29

#114

Post by toomanybeersies »

Klathmon wrote: post #69
toomanybeersies wrote: post #68

Earlier quoted context omitted.

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)

If I send a text message from Android to iPhone, the message is the same. Obviously there's cultural differences etc. but I can usually work with those if I know the person I'm sending a message to.

However, emojis can change when sending them from my Android phone to an iPhone, changing the meaning of the message inadvertently.

Re: Atom 1.29

#115

Post by mraison »

zbentley wrote: post #62
mraison wrote: 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'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…

I don't think I've reached the limit of how many files Nuclide/Watchman can handle, everything is perfectly smooth with very large codebases.

However, things don't work as well with an NFS share and I think you get an explicit warning when you try to do it.

Re: Atom 1.29

#116

Post by mraison »

math0ne wrote: post #92
mraison wrote: 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…

Can you explain a little more about the remote file editing workflow? Is there an article I can reference or something?

The official documentation is here: https://nuclide.io/docs/features/remote/

One of the steps is to install Watchman. If your remote server is on Linux, make sure to read that part of the docs: http://facebook.github.io/watchman/docs/install.html#linux-i... (In my case I just set the three settings to 999999)

Finally, you may need to create a .watchmanconfig file at the root of the folder you're working on.

Re: Atom 1.29

#117

Post by mraison »

kristiandupont wrote: post #27
mraison wrote: 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?

I'm developing. It's useful whenever I need to work on a machine with a specific environment and/or more bulky hardware than what's available on my laptop.

Re: Atom 1.29

#118

Post by ksec »

013a wrote: post #80
the_duke wrote: post #30

Earlier quoted context omitted.

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

So Xi, is basically like an OpenSourced Version of Sublime Text in Rust?

If that is case, why Google doesn't just acquire Sublime Text and open source it?

Edit: Turns out Xi was burned out of Fuchsia, the next generation Android. So I guess Xi is tool for testing concept in Fuchsia. And it doesn't look like Xi will be amiable for general usage in the next 2 to 3 years time.

Re: Atom 1.29

#119

Post by the_duke »

ksec wrote: post #118
013a wrote: post #80

Earlier quoted context omitted.

There's also a similar project hosted by Google, Xi, which seems significantly more promising than xray. [1] https://github.com/google/xi-editor

So Xi, is basically like an OpenSourced Version of Sublime Text in Rust? If that is case, why Google doesn't just acquire Sublime Text and open source it? Edit: Turns out Xi was burned out of Fuchsia, the next generation Android. So I guess Xi is tool for testing concept in Fuchsia. And it doesn't look like Xi will be amiable for general usage in the next 2 to 3 years time.

No Xi existed before Fuchsia became a thing.

It's a generic editor backend with an official GUI for OS X.

Re: Atom 1.29

#120

Post by the_duke »

013a wrote: post #80
the_duke wrote: post #30

Earlier quoted context omitted.

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

Yeah I've known about Xi for a long time, but it's moving very slowly and is just a hobby project of a Google engineer, nothing official.

Xray seems much more actively developed and actively managed by Atom developers.

Post reply on HN