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

101–110 of 120 posts

Re: Atom 1.29

#101

Post by giancarlostoro »

ElCapitanMarkla wrote: post #56
giancarlostoro wrote: post #37

Earlier quoted context omitted.

I have to do it all the time cause I want to develop on a VM that matches the target platform for my project. Usually involves figuring out how to debug things. My solution is to install VS Code on remote system and use X forwarding depending on project. I also use PyCharm Pro so in such case I use Vagrant and it does its thing but it syncs awfully as OP mentions so debugging can become extremely painful idk why JetB…

This is my scenario at the mo, I've tried syncing the code dirs between the VM and my local machine but I haven't found a nice solution for that. My current solution is just SSH/Vim but I think I'd like to go back to a graphical editor. I like Vim but sometimes it's a hassle on the big projects.

I use Vagrant w/ VirtualBox and setup shared folders, but it's not as nice when you want to debug or execute code. PyCharm Pro has great support for Vagrant though it sucks at updating certain things on the server end.

Re: Atom 1.29

#102

Post by dkhenry »

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 have been swayed from using the CLI by emacs and magit. There are so many nice things like staging portions of a changeset, and the ability to get a quick visual diff of the changes before they are committed is really really nice. As to why they would work on it, the two main reasons I keep going back to emacs from Atom and VS Code is magit, and the ability to run in a console. to me Atom and VS Code are fast enough for my day to day work

Re: Atom 1.29

#103

Post by spicyj »

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…

At Facebook most of our thousands of web devs use Nuclide for remote editing on a repo with hundreds of thousands (or millions) of files and it works as advertised. We don’t use NFS though; all the repo checkouts are on disk on the remote machine.

Re: Atom 1.29

#104

Post by redisman »

paulddraper wrote: post #81
saagarjha wrote: post #7

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.

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.

Re: Atom 1.29

#105

Post by redisman »

nurettin wrote: post #54
saagarjha wrote: post #7

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.

I'm 99% sure this is just terminology lifted from games. Just means it runs at a constant fast rate.

Re: Atom 1.29

#106

Post by mikhailt »

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.

At work, we use Git to store our docs (markdown) and Atom feels natural to write MD files in and to push updates. Most casual users understand what push and pull is but they are not really that comfortable to use git commands via CLI.

Re: Atom 1.29

#107

Post by statictype »

akuji1993 wrote: post #51
Lordarminius wrote: post #36

Earlier quoted context omitted.

Emmet.

I get why people use it, I just don't have any use case for it. I'd rather write my code myself instead. Just a personal preference though.

I don't find the code generation stuff that useful but I found it useful for its text manipulation features - like selecting all text within 2 nodes, editing a start and end tag at once.

Re: Atom 1.29

#108

Post by dvlsg »

Smotko wrote: post #95
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 felt the same way as you do, I used the git CLI directly and could never use a git GUI. But then I figured out that Atom's git integration is actually quite neat and I started using it mostly to do `git add -i` as it makes staging files or parts of files really easy. I still don't trust it with pushing/pulling, switching branches etc. so I still drop to the command line for those, but the atom git integration is in…

I agree. I use the command line for everything but staging, and I often only stage parts of files while discarding a few leftover pieces I forgot about. I use sourcetree, but the concept is the same. GUI git is really nice for staging parts of changes. And then I usually commit via the GUI too, since I'm in there anyways.

Re: Atom 1.29

#109

Post by JohnBooty »

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 mostly feel the same. I don't like to customize my editor too much because:

1. That adds a lot of friction if you want to try out another editor 2. When it breaks, fixing things is not always easy. There are millions of git CLI users; you are probably the only one with your particular editor setup. 3. When I'm pairing with another developer, I don't want to be helpless when using their machine because they don't have the same intricate editor setup as me (or vice-versa)

There are a few things I use a Git GUI for, like staging/discarding chunks, or getting a nice graphical diff.

Re: Atom 1.29

#110

Post by Lordarminius »

akuji1993 wrote: post #51
Lordarminius wrote: post #36

Earlier quoted context omitted.

Emmet.

I get why people use it, I just don't have any use case for it. I'd rather write my code myself instead. Just a personal preference though.

To each his preference, I suppose. But I definitely could imagine a far more difficult life without Emmet.
Post reply on HN