For anyone wondering, Python indentation of new lines inside lists, tuples, etc. is still broken (https://github.com/atom/language-python/issues/22). However, it looks like hitting tab at least allows you to manually indent the line, which is a passable bridge until it works properly. Auto-indent will completely remove any manual indentation, however, which seems like something that should be fixed.
Atom 1.0
241–250 of 459 posts
Re: Atom 1.0
#242Earlier quoted context omitted.
"The cycle of bloat doesn't always take hold" Don't recall claiming everything is under the "cycle of bloat". The fact that I gave specific examples was a pretty big clue that it's not all equal.... and jQuery isn't in any of them, either. Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
The problem is you haven't given a single example of any software that fits the model, and people are continuing to provide counter-examples. I can make lists too, if that's all we're doing. 1. Get a cat. 2. Cat requires playtime or they ruin your stuff and can be annoying. 3. Repeat 1 and 2 a few times. 4. You are a crazy cat man.
Firefox is a pretty solid example. Started slim as hell, gradually pulled plugins in until it was more bloated than IE and everyone moved to Chrome. They realized the problem and have started pulling back (although you could argue the opposite with the new integrations), but it still stands as an example.
Re: Atom 1.0
#243A lot of people complain about the slowness of the Dom/JavaScript backend, but I see a lot of potential for some really cool things, like integrated juPyter notebooks, semi wysiwyg rendering of latex and markdown and maybe drawing rendering trees or other creative things.
Honestly, its not slow anymore between their React integration and this: http://blog.atom.io/2015/06/16/optimizing-an-important-atom-... . Feels ~95% native.
They dropped React a while ago.
Re: Atom 1.0
#244Earlier quoted context omitted.
I disagree with your characterization. Take jQuery for example. 1. Small, fast and minimal. 2. Easy to create plugins. 3. Budding ecosystem and explosion of plugins. 4. Conflicts ensued and some plugins got pulled into the core project. Eventually, the growth of jQuery tapered off as the project stabilized. Not only did the size taper off, it got smaller as well. After nearly 10 years, we're talking about a payload o…
Jquery is a lot of things but minimal isn't really accurate. Combining a DOM manipulation library with an AJAX library and a Promises/Deferred library is and has been a pain point for me. Also some of those size reductions have been at the cost of features (in particular by reducing the target browser set) Its a great project. I use it a lot but I'm not sure its a counterpoint to bloat.
> I use it a lot but I'm not sure its a counterpoint to bloat.
You're missing my point. I'm not claiming jQuery is not bloated, what I'm claiming is jQuery hasn't bloated (grown) a lot since it was first introduced. It started out as a single one-stop-shop library to handle DOM manipulation, AJAX and event handling and the scope/size of the project hasn't really grown beyond that.
Re: Atom 1.0
#245Just downloaded and opened Atom for the first time, and I have to admit the look and feel is amazing! Fantastic job to all those involved! However, one thing that stands out to me, the file size of Atom.app is 203MB!! How in the world can a text editor be that large? Compare that with MacVim, which is about 27MB.
It's possibly more fair to compare it with an IDE, not simply a text editor. WebStorm as a download is 131 MB. Not as big, but in a similar class. edit: And the full WebStorm app is 293.5 MB
If you want a better comparison, Sublime Text's installed size is 1/10th of the size of Atom at 23 MB.
Re: Atom 1.0
#246How do anyone run tox from atom editor?
Re: Atom 1.0
#247Earlier quoted context omitted.
Welcome to what I've felt with Emacs since I first used it. Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...
Yes. I keep trying to like Atom because I want to have native WebView buffers while I'm editing. Every time I try it, I end up wondering how anyone can be comfortable using it. I'm not sure how much of that is due to instability that will be fixed over time, and how much is because I'm coming from Emacs. Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it bu…
I've got the same problem with both Atom and LightTable. They have potential; they are just 30-years too young for me.
Emacs has much more commands for simple text manipulation than any other editor (ofc, excluding Vim). No editor that I know of implements all the Emacs commands for even simple things. For example for marking and navigation in a text (mark-, backward-, forward-). Indentation and newline behavior, searching and replacing in a file (search- and replace-*; also occur-mode). And more.
I'm sure all editors will, sooner or later, get most or all of those, but using them right now would be inconvenient. I don't want to have to record macros to deal with such simple things!
And then of course is a matter of Emacs plugin ecosystem. It is enormous and includes some neat stuff, like Magit, Org, Helm, Undo-Tree, multiple cursors, Paredit, Minimap, Speedbar and so on. Some of those are "outside of scope" of the new editors, but some would be very welcome in them. I suspect that they will appear in time, but right now I wouldn't have access to them at all if I used some other, new editor. (By the way, in my experience as both Emacs and Vim user, these two are interchangeable in terms of available plugins. Emacs seems to have a little more of them, probably because Elisp sucks a little bit less than VimL)
Re: Atom 1.0
#248what's up with name reuse these days. atom (the syndication format) may be on the verge of becoming obsolete, but it's also forgotten and irrelevant already to warrant a name reuse?
I guess you'll have to use that cognitive decision machine on top of your neck to distinguish the two. I know that's 1 second of compute time but unfortunately it's the only known method.
Re: Atom 1.0
#249I tried atom, the only thing I liked about it was design and color scheme, the rest are superior in sublime text, so I just went ahead and created a theme/color scheme for sublime which matches atom (1). Atom is laggy, even basic file navigation using arrows can be slow sometimes (and I have a latest retine macbook pro).
But the biggest issue for me is a battery usage, it reduces my battery usage on RMBP15 by 2 hours compared to sublime text, I am mostly working from remote places and having a good battery usage is vital for me.
[1] - https://www.evernote.com/shard/s21/sh/cc73487c-08c9-4937-ac6...
Re: Atom 1.0
#250I've gotta say, honestly, I'm preferring Visual Studio Code over Atom simply due to the fact that it seems MUCH more stable and lightweight. Atom is very visually appealing, and I'm a fan of the project, in general, but it constantly freezes up and crashes on me. I think I'll be sticking with VS Code & Sublime.
Funny, as VS Code is based on Atom.