Live data from Hacker News

Introducing Atom-IDE

blog.atom.io

301–310 of 324 posts

Re: Introducing Atom-IDE

#301
post #173

Earlier quoted context omitted.

My vim process comes to a crawl if I forget to turn off syntax highlighting before opening large files. So I disagree.

That’s a broken highlight syntax file. The good ones don’t highlight text until it becomes visible in the buffer. You should bug it if it is reproducible in neovim. The team is highly responsive.

It happens with large javascript files (bundles). I use this:

https://github.com/othree/yajs.vim

And my color scheme is:

https://github.com/nanotech/jellybeans.vim

Not sure which is at fault (if either).

Re: Introducing Atom-IDE

#303

Earlier quoted context omitted.

Definitely. I wish they didn't do the autosave crap.

I will regret asking this, but why ? I don't even remember what it was like to code without autosave in IntelliJ. I will review the changeset before creating the PR anyway, so I don't see the downside of autosave.

Close editor by mistake, battery dies, go to lunch and forget what I was doing.

What is the upside? One less keystroke..?

Re: Introducing Atom-IDE

#304

Earlier quoted context omitted.

Switch-cost between what? Vim has worked pretty well for me for all programming languages I've used and on all platforms I've used. I reread grandparents comment and I'm a bit unsure what you are referring to exactly.

I'm just saying that you're hijacking the point (that using a single editor, rather than switching between IDEs, is useful) and replacing it with a competition for size and speed. Yes, vim and emacs are lighter. Does that devalue Atom's consistency? No. I say this as an avid Emacs user.

Ah, I understand now.

I guess my point was that since vim/emacs already exist and have advantages, that use case for atom seems a bit unnecessary, but of course in reality many people don't use vim/emacs due to the learning curve, so I suppose the point is irrelevant.

Re: Introducing Atom-IDE

#307
post #253

Earlier quoted context omitted.

They're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.

VS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false

Having that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.

Re: Introducing Atom-IDE

#308
post #165

Earlier quoted context omitted.

Learning Vim -- even the smallest subset of it -- will continue to pay off years into the future! Then you can combine it with existing Atom/Sublime/VSCode keymaps where need be and really have a nice fusion of functionality. (VSCode vim mode is A+ btw)

I gave VSCode's vim mode a shot a few months ago and found it nowhere near Atom's vim-mode-plus. Has it gotten better?

Well, I think it has (I'm one of the developers). Since the beginning of April there's been over 149 pull requests merged. It's definitely gotten better.

Re: Introducing Atom-IDE

#309
post #233

Earlier quoted context omitted.

And maybe importantly, you can use a personal license at work, on paid projects, etc. I've never been particularly bullish on Atom or Electron, but I think Jetbrains is going to be eating their lunch for awhile at least.

You have to buy a personal license yourself, your organization cannot pay for it. I just don't want to pay for work tools, my employer should do that and then it is the higher price.

That's fair. Personally, though I could get the business license and expense it, I choose to pay for it as a personal license because I use it personally as well, and I'd be happy to pay the individual license price either way.

Re: Introducing Atom-IDE

#310

Earlier quoted context omitted.

> we already have Emacs/Vim, with their million of extensions My experience is that Vim is hard to use when you start to add too many extensions. There are just too many shortcuts to remember, plugins may interact in unexpected ways, and things like contextual information don't look as nice as they could. It just feels very 'hacky' to try to use it as an IDE. I prefer to use more recent editors (first Sublime, but I'…

I've never gotten into Vim, but a friend said something that piqued my interest. Editing text is boring. Programming is fun. Vim makes text editing like programming.

I'm learning vim and I agree, even if there's no productivity gain (duh I'm new to it) it makes my work way more fun (I do have a contrived concept of fun though).
Post reply on HN