Atom 1.11(blog.atom.io)
blog.atom.io
Atom 1.11
http://blog.atom.io/2016/10/11/atom-1-11.html
125 comments
Thanks for reporting your tests. Saved me some time. Your English was good enough to get the point across without distractions. Good job!
Hey, Seeing your menubar item reminded of a software - Bartender[1]. I like it; you might.
It looks a bit like this - https://www.dropbox.com/s/vqjrz2wiwuxho4z/Screenshot%202016-...
1. https://www.macbartender.com/
It looks a bit like this - https://www.dropbox.com/s/vqjrz2wiwuxho4z/Screenshot%202016-...
1. https://www.macbartender.com/
Think it's broken still on Sierra :(
Works for me. If I remember correctly, they upgraded it for Sierra a while back.
Working for me on Macbook Air Sierra and hackintosh Sierra.
Working for me.
About 19 hours of battery life? Which macbook do you have?
No. It only lasts for 5.5 and 6.5 hours at 28% battery.
The machine was in sleep mode in day 1, but I forgot to put it to sleep mode before closing the screen (I hate this the most at OSX 10.10) in day 2. You can see that there is a little bit different between 2 charts.
This machine is MacBook Air 13" 2013. The battery goes down to 86% design capacity (7150 mAh) according to coconutBattery.app
The machine was in sleep mode in day 1, but I forgot to put it to sleep mode before closing the screen (I hate this the most at OSX 10.10) in day 2. You can see that there is a little bit different between 2 charts.
This machine is MacBook Air 13" 2013. The battery goes down to 86% design capacity (7150 mAh) according to coconutBattery.app
Why not teach the newbies on Emacs?
I'm only half joking. In its graphical incarnation, it's not exactly pretty, but fairly user-friendly, minus a few relatively easy-to-learn keyboard shortcuts. Within month it'll be second nature to them.
But I still wouldn't recommend it.
I'm only half joking. In its graphical incarnation, it's not exactly pretty, but fairly user-friendly, minus a few relatively easy-to-learn keyboard shortcuts. Within month it'll be second nature to them.
But I still wouldn't recommend it.
my major gripe with emacs and vim is that the keyboard shortcuts (out of the box) are completely alien. This really fucks with my muscle memory and actually slows me down. I'm sure this is fixable with complex config files, but that sorta defeats the purpose of emacs, where you should be able to edit files from the command line anywhere without messing about too much.
Vim is all about muscle memory, it just requires different memories than you have.
Spacemacs fixes a lot of the discoverability problems of Emacs and is generally more ergonomic.
I don't know anyone that learned it as a first editor (everyone already knew vim or emacs) but it seems like it could be a much better experience for someone new.
I don't know anyone that learned it as a first editor (everyone already knew vim or emacs) but it seems like it could be a much better experience for someone new.
Ah yes, spacemacs. Not a fan, myself (I like to know what my configs are doing), but some people swear by it.
Personally, I don't think it would be good to introduce the newbies to modal editing right off the bat. They'll most likely have to learn a whole new set of keyboard shortcuts. Don't make them learn a whole new editing paradigm, too: they'll have given up before you can say, "which mode am I in now?"
Personally, I don't think it would be good to introduce the newbies to modal editing right off the bat. They'll most likely have to learn a whole new set of keyboard shortcuts. Don't make them learn a whole new editing paradigm, too: they'll have given up before you can say, "which mode am I in now?"
I have crappy finger dexterity. Makes vim and emacs no fun.
That's... really unfortunate. Have you looked into customization to potentially make them usable for you? It's fine if you don't want to, but I'd hate to see somebody unable to use such useful tools due to a lack of finger dexterity.
No, I have not.
I took a career assessment test about 20 years ago through this organization => http://www.jocrf.org. They said I tested in the bottom 5% of all people they've tested for finger dexterity. My fingers are just clumsy. I knew it, and they provided some validation for that.
At this point, using Atom (or any GUI IDE) provides me with 80%+ of the functionality I need when coding. If I get to a point where my IDE mojo starts becoming a blocker for me, then I'll revisit optimizing my IDE skillz.
I took a career assessment test about 20 years ago through this organization => http://www.jocrf.org. They said I tested in the bottom 5% of all people they've tested for finger dexterity. My fingers are just clumsy. I knew it, and they provided some validation for that.
At this point, using Atom (or any GUI IDE) provides me with 80%+ of the functionality I need when coding. If I get to a point where my IDE mojo starts becoming a blocker for me, then I'll revisit optimizing my IDE skillz.
Well then, good for you. IMHO, Emacs is the best tool for my job, but if it doesn't work for you, and something else does, than use it.
My only issue with Emacs is the out of the box experience and given its pedigree, when looking at a videos from Genera or papers from Xerox PARC, there is always this idea that it could have been so much better.
Still nowadays, I only use it when I cannot use my favorite set of IDEs, usually Clojure or being in a space constrained place.
Still nowadays, I only use it when I cannot use my favorite set of IDEs, usually Clojure or being in a space constrained place.
However, the out of the box experience is pretty decent, and if you're focusing on the out of the box experience above all else, than you still don't understand what makes Emacs Emacs.
Then again, I never really got on with IDEs: Too complex, too hard to customize, too specific to one language (for the most part), too big a learning curve with not enough benefit.
Then again, I never really got on with IDEs: Too complex, too hard to customize, too specific to one language (for the most part), too big a learning curve with not enough benefit.
I sure do understand what makes Emacs Emacs.
It was the only thing that I somehow could use to try to get an IDE like experience during university days (comparing with my usual Amiga/Mac/Windows tools), on our UNIX environments, initially AIX and DG/UX workstations.
Eventually coupled with DDD for a sane debugging experience.
So VI vs Emacs? Definitely Emacs.
Emacs vs IDE? Only when I have to.
It was the only thing that I somehow could use to try to get an IDE like experience during university days (comparing with my usual Amiga/Mac/Windows tools), on our UNIX environments, initially AIX and DG/UX workstations.
Eventually coupled with DDD for a sane debugging experience.
So VI vs Emacs? Definitely Emacs.
Emacs vs IDE? Only when I have to.
...Which I could tell from how you phrased your comment. I was merely speaking generally, I assure you.
However, I must say that if I was asked the question "Emacs or IDE?" The answer would be "EMACS!" said rapidly and with great force. I never really understood why people like IDEs. Maybe I've just been using the wrong ones. It might have something to do with the fact that most of my IDE experiences is tied to Java, a language I find so unpleasant that I have to cleanse myself with Lisp, Python, Ruby, Haskell, Rust, or some other, equally pleasant language to get the bad taste out of my mouth after using it.
It also could be that the support for the Lisps in Emacs in unbelievably good. It's not as good as the Lispms or some of the proprietary IDEs, or so I've been told, but I can't afford either, and those only work with one dialect of Lisp, whereas Emacs works with all the popular ones and a few that aren't.
However, I must say that if I was asked the question "Emacs or IDE?" The answer would be "EMACS!" said rapidly and with great force. I never really understood why people like IDEs. Maybe I've just been using the wrong ones. It might have something to do with the fact that most of my IDE experiences is tied to Java, a language I find so unpleasant that I have to cleanse myself with Lisp, Python, Ruby, Haskell, Rust, or some other, equally pleasant language to get the bad taste out of my mouth after using it.
It also could be that the support for the Lisps in Emacs in unbelievably good. It's not as good as the Lispms or some of the proprietary IDEs, or so I've been told, but I can't afford either, and those only work with one dialect of Lisp, whereas Emacs works with all the popular ones and a few that aren't.
I got to use Turbo Pascal (MS-DOS and Windows), Delphi, Borland/Turbo C++, C++ Builder, Smalltalk, Oberon, Hypercard, Visual Basic, DevPac, Visual Objects, and a few others before Java was announced to the world.
The thing, is that Emacs doesn't offer many of the tools Lisp environments offer, is like trying to judge Smalltalk developer experience by using GNU Smalltalk instead of Squeak or Pharo.
The thing, is that Emacs doesn't offer many of the tools Lisp environments offer, is like trying to judge Smalltalk developer experience by using GNU Smalltalk instead of Squeak or Pharo.
Well, then, that would explain it. We have our tastes: there's nothing wrong with yours.
Your last sentence was a bit scrambled, but I gather you're saying that other Lisp development environments are superior to Emacs. That may be true, but most other Lisp environments are either in the Emacs family (Edwin, Hemlock), not superior to Emacs in any way (Dr Racket), or really expensive, so I know nothing about them (LispWorks, etc.).
So in conclusion, I'll take arguably inferior but really really good over allegedly superior but very very expensive.
Your last sentence was a bit scrambled, but I gather you're saying that other Lisp development environments are superior to Emacs. That may be true, but most other Lisp environments are either in the Emacs family (Edwin, Hemlock), not superior to Emacs in any way (Dr Racket), or really expensive, so I know nothing about them (LispWorks, etc.).
So in conclusion, I'll take arguably inferior but really really good over allegedly superior but very very expensive.
Symbolics Genera is so far ahead Emacs, it's not even funny. Even though it is unmaintained since 20 years.
Xerox Interlisp-D was similar mind-blowing.
Xerox Interlisp-D was similar mind-blowing.
So, are we talking about far ahead of emacs's default (which I can see), or heavily ahead of the heavily extended emacs most emacs users actually run (which I'm having trouble seeing, honestly). Either way, how so?
Regardless, I don't see myself using either or their descendants any time soon: Emacs is a very good environment, and I don't have several grand to spare.
Regardless, I don't see myself using either or their descendants any time soon: Emacs is a very good environment, and I don't have several grand to spare.
YOu can extend GNU Emacs as much as you want, it is always single threaded. For a start. The UI is interestng, but fucked in many ways. That's how it is.
If that's really your major issue with it...
Yes, the UI is awkward, but I've never really had any issues with it. It's functional.
Yes, Emacs isn't multithreaded. And yes, this can sometimes get annoying, although it's quite rare for me to actually have trouble with it. And slave processes, while expensive, are cheap enough.
In any case, threading support is on the todo list, so it may be done sometime this century.
Yes, the UI is awkward, but I've never really had any issues with it. It's functional.
Yes, Emacs isn't multithreaded. And yes, this can sometimes get annoying, although it's quite rare for me to actually have trouble with it. And slave processes, while expensive, are cheap enough.
In any case, threading support is on the todo list, so it may be done sometime this century.
> If that's really your major issue with it...
You seem to be misinterpreting me quite often. It's ONE issue. A development environment which is not multithreaded, is not very advanced.
> it's quite rare for me to actually have trouble with it.
No surprise: Blub paradox at work. Your tools limit your thought.
If my Lisp Machine would be single threaded, it would suck.
> Yes, the UI is awkward, but I've never really had any issues with it. It's functional.
Most Lisp-based development environment have much better UIs. For example in LispWorks or on a Lisp Machine the keychords are shorter. The Dynamic Windows UI of the Lisp Machine is still light-years ahead of anything GNU Emacs.
Here I made a demo how the documentation system works on the Symbolics. It uses Zmacs (the Emacs editor on the Lisp Machine, which Stallman used before he developed GNU Emacs) a component to write documentation records. This stuff had been developed in the mid-end 80s...
https://vimeo.com/83886950
Here Kalman Reti gives a demo of a Lisp Listener on the Symbolics and debugging mixed Lisp/C code:
https://www.youtube.com/watch?v=o4-YnLpLgtk
You seem to be misinterpreting me quite often. It's ONE issue. A development environment which is not multithreaded, is not very advanced.
> it's quite rare for me to actually have trouble with it.
No surprise: Blub paradox at work. Your tools limit your thought.
If my Lisp Machine would be single threaded, it would suck.
> Yes, the UI is awkward, but I've never really had any issues with it. It's functional.
Most Lisp-based development environment have much better UIs. For example in LispWorks or on a Lisp Machine the keychords are shorter. The Dynamic Windows UI of the Lisp Machine is still light-years ahead of anything GNU Emacs.
Here I made a demo how the documentation system works on the Symbolics. It uses Zmacs (the Emacs editor on the Lisp Machine, which Stallman used before he developed GNU Emacs) a component to write documentation records. This stuff had been developed in the mid-end 80s...
https://vimeo.com/83886950
Here Kalman Reti gives a demo of a Lisp Listener on the Symbolics and debugging mixed Lisp/C code:
https://www.youtube.com/watch?v=o4-YnLpLgtk
You can ergo emacs https://ergoemacs.github.io
Teach 'em how to get to CUA-mode then, which has all the familiar shortcuts.
I like Atom but I ditched it in favor of Visual Studio Code because it has per-project settings, something Atom still lacks. The only thing I really miss is the ternjs extension. Typescript's intellisense is nice but requires quite a bit of setup to actually work.
Tested both Atom and VSC for a couple of months before going back to Sublime Text. They're both really nice, but nothing beats Sublime's speed and customization.
Until Electron becomes more mature Atom will never compete on the desktop in terms of speed.
Although it could probably be argued now that Atom has a better plugin ecosystem in regards to your comments about customization.
Although it could probably be argued now that Atom has a better plugin ecosystem in regards to your comments about customization.
VS Code is based on Electron as well but manages to perform significantly better than Atom.
This
That's really interesting about tern vs intellisense.
I haven't really used VSCode much beyond a quick "check out", but the majority of comments I read are the opposite. That Intellisense "just works" and that tern very much suffers from the "open source documentation" issue...
Can you go into some more details about the pain points or some pro/cons of each?
I haven't really used VSCode much beyond a quick "check out", but the majority of comments I read are the opposite. That Intellisense "just works" and that tern very much suffers from the "open source documentation" issue...
Can you go into some more details about the pain points or some pro/cons of each?
My experience with atom-ternjs has been that you create the config file in your project root with any plugins/options you need and then you're good to go. You get autocomplete for any node modules you require and everything just sort of works.
VS Code's intellisense (which uses typescript for both js and ts files) however requires definition files for any dependencies to be installed separately (which may or may not exist/be up to date), requires you to explicitly exclude stuff like your node_modules folder otherwise it will simply stop working with no error message. This gets worse if you have multiple nested node/npm projects as is common with, for example, electron projects where you have to make sure you explicitly exclude the paths to any node_modules directories under the jsconfig.json root and you'll need separate jsconfig.json files for every project (which might be what you want, but isn't strictly required with tern like it is here). Another issue is that since vscode is clearly geared towards typescript, a variable's type is determined when it's declared and only then so something like "let app;" sets the app variable's type to "any" which it stays for the entire file no matter what object is assigned to it later.
There are some things I like, such as the ability to define JSON schemas and a number of the issues above don't apply when using typescript but when writing regular old javascript it's pretty lacking.
VS Code's intellisense (which uses typescript for both js and ts files) however requires definition files for any dependencies to be installed separately (which may or may not exist/be up to date), requires you to explicitly exclude stuff like your node_modules folder otherwise it will simply stop working with no error message. This gets worse if you have multiple nested node/npm projects as is common with, for example, electron projects where you have to make sure you explicitly exclude the paths to any node_modules directories under the jsconfig.json root and you'll need separate jsconfig.json files for every project (which might be what you want, but isn't strictly required with tern like it is here). Another issue is that since vscode is clearly geared towards typescript, a variable's type is determined when it's declared and only then so something like "let app;" sets the app variable's type to "any" which it stays for the entire file no matter what object is assigned to it later.
There are some things I like, such as the ability to define JSON schemas and a number of the issues above don't apply when using typescript but when writing regular old javascript it's pretty lacking.
I'm in the same boat. VS Code is also much faster in loading and scrolling, at least on Windows.
I use WebStorm for projects ( mainly TypeScript ) and Sublime Text for cases where I need to open huge files.
WebStorm is doing pretty well, except that I don't like the customization options ( they are 1/10 compared to Atom / Sublime ).
But kudos for Atom team, because they brought Electron, which is a huge game-changer.
WebStorm is doing pretty well, except that I don't like the customization options ( they are 1/10 compared to Atom / Sublime ).
But kudos for Atom team, because they brought Electron, which is a huge game-changer.
I have tried Sublime Text (coded with it for years), then Atom for just a few months until I found Jetbrains' products (due to using android studio) and simply found it better.
It's better because much of the features many people hope to have is built by the professional team and built-in. You don't have to waste a weekend to check 3 alternatives for every feature you want that may not be as good in the end as they are created by developers whose skill vary greatly.
I got tired of tuning the editor when things work out of the box and even better than properly equipped atom/sublime so I can actually get stuff done.
I hope these discussions include more of other non free apps than free vs free.
It's better because much of the features many people hope to have is built by the professional team and built-in. You don't have to waste a weekend to check 3 alternatives for every feature you want that may not be as good in the end as they are created by developers whose skill vary greatly.
I got tired of tuning the editor when things work out of the box and even better than properly equipped atom/sublime so I can actually get stuff done.
I hope these discussions include more of other non free apps than free vs free.
I liked Visual Studio Code but ditched it because it created .vscode folders all over my filesystem... is there a way to turn that off?
I also had this problem for some time: turns out C/C++ extension automatically created them for every directory that you open. I uninstalled it and it stopped.
Those .vscode files are where it stores the per-project settings that the poster you replied to said they really liked.
It shouldn't create .vscode folders unless it's storing project-specific launch configs, settings, tasks, or extensions in there.
I have not had this happen except if you pick project settings instead of user settings, i noticed it generated some files.
Outside of that, i havent had this happen. However, if it is simply annoying in your editor you can put them in .gitignore and either tell vscode to not list anything in the .gitignored list, or explicitly ignore files and folders by default.
Outside of that, i havent had this happen. However, if it is simply annoying in your editor you can put them in .gitignore and either tell vscode to not list anything in the .gitignored list, or explicitly ignore files and folders by default.
Only thing keeping me with Atom is Hydrogen[0], which lets me have all the things I like about jupyter notebooks without some of the things I don't like about jupyter notebooks.
I've tried VS Code and liked it - if anyone knows of an equivalent/replacement for Hydrogen in VS Code I'll make the switch.
[0] https://atom.io/packages/hydrogen
I've tried VS Code and liked it - if anyone knows of an equivalent/replacement for Hydrogen in VS Code I'll make the switch.
[0] https://atom.io/packages/hydrogen
Take a look at Python extension for VSCode[0]. Excerpt from feature section:
Scientific tools (Jupyter/IPython)
- Executing blocks of code (cells) in a Jupyter Kernel
- Managing kernels (restarting, stopping, interrupting and selecting different kernels)
- Viewing interactive graphs, HTML, SVG, laText output from Jupyter from within Visual Studio Code
[0]: https://github.com/DonJayamanne/pythonVSCode
Scientific tools (Jupyter/IPython)
- Executing blocks of code (cells) in a Jupyter Kernel
- Managing kernels (restarting, stopping, interrupting and selecting different kernels)
- Viewing interactive graphs, HTML, SVG, laText output from Jupyter from within Visual Studio Code
[0]: https://github.com/DonJayamanne/pythonVSCode
My atom crashes every time I try to open a huge text file (containing data of some sort). Other text editors handle them just fine.
This time they added a configuration option for the large file warning threshold. This isn't enough.
Anyone else have the same problem?
This time they added a configuration option for the large file warning threshold. This isn't enough.
Anyone else have the same problem?
When you code - use Atom.
When you need to edit data files or other huge files - don't use Atom.
When you need to edit data files or other huge files - don't use Atom.
This is a deal breaker for me. If other editors could handle remote filesystems as good as Atom I would have switched to something else perhaps VS Code. It is weird that Atom has been having this problem for so long and they don't seem to care about fixing it.
I used to have this problem with Atom a long time ago. It is slow for huge files. I switched to visual studio code for this reason, despite being on the same shell, vscode is way faster than atom
Yup, every time I accidentaly open a minified file, it hangs for a minute.
Especially problematic as things turn up in search results, so you click on them, then realize it's a build file and you can go get a coffee
That can be problematic for reasons other than size. Usually minified files will not contain any newlines, meaning that not only is the file rather large, it is effectively all on a single line.
I've seen things like vim have problems with files like that, I think mostly from trying to syntax highlight the visible region.
I've seen things like vim have problems with files like that, I think mostly from trying to syntax highlight the visible region.
I have the same problem, as I often need to inspect large text files resulting from experimental measurements or fluid dynamics simulations.
Use Atom for source code and another editor for large text files (such as logs).
They added an option at "Settings > Core" to "Warn before opening files larger than this number of megabytes". I don't use Atom at all, but after so much discussion about this issue I don't think there is a better solution. This clearly shows the difference in performance of a web-based text editor versus one built on top of a native UI library, but people prefer to sacrifice that performance for the nice interface and the extensibility, I suppose that many of these happy Atom users don't work on huge projects like some of us do, Atom works okay for what it offers.
I don't think "huge projects" factors into it at all, no reasonable source file should ever come anywhere close to the Atom file size limit. If you have 13MB source files you have more serious problems than your choice of text editor.
The kind of files that choke Atom are large data files that there are usually better/different tools for, that have very different requirements from code editing. And that has little to do with the relative huge-ness of your projects.
The kind of files that choke Atom are large data files that there are usually better/different tools for, that have very different requirements from code editing. And that has little to do with the relative huge-ness of your projects.
I regularly deal with this problem because my use case demands viewing huge JSON files of size > 20 MB with lines of text that can exceed tens of thousands of characters (WKB polygons). You can argue that Atom is not suited to this particular use-case (and I would agree), but what can we do to make it better? I'm very curious as to the specific aspects of Electron/Atom that make this kind of operation slow and would be willing to contribute to make it faster.
It's already been proven that Javascript can be fast for this kind of thing. So there is something in the infrastructure that can be improved.
It's already been proven that Javascript can be fast for this kind of thing. So there is something in the infrastructure that can be improved.
It's a text editor, not a source code editor. Log files can be that big, as well as a bunch of other things, like csv's.
It's not unusual to have things like compilers that generate big intermediate C files. Editors programmed using same technologies handled them just fine decades ago.
It's not only huge files that it's chocking on.
Last year I was working on a game demo under time constraints and to cut a corner I base64 encoded a bitmap font. Every time I opened that 32KB file it began to slow down because that one big line.
That being said I still use atom daily but not one big files or ones that contain big lines.
Last year I was working on a game demo under time constraints and to cut a corner I base64 encoded a bitmap font. Every time I opened that 32KB file it began to slow down because that one big line.
That being said I still use atom daily but not one big files or ones that contain big lines.
Visual studio code is a web based text editor is it not?
Specifically based on Electron, Atom's own framework: http://electron.atom.io/
What is VS Code doing differently to make it so performant? Is it simply less extendible?
My understanding is that the editor portion of it was created specifically for Visual Studio Online and it had a smart and dedicated team (acquire hire maybe?) working on it.
They have released the core part of VSCode as a node package called Monaco.
I used Atom for over a year then switched to Sublime Text because of Atom's inability to open large files and because of its slowness when doing things like highlighting as you type while using Find in a large file.
I think the problem is simply that their stack handicaps them severely in this respect. I need my text editor to be able to handle large files and to be extremely fast.
I think the problem is simply that their stack handicaps them severely in this respect. I need my text editor to be able to handle large files and to be extremely fast.
I switched to Atom this year and haven't looked back. I love the customization and it's been a breeze to work with.
I've got mixed feelings about Atom. I've been using it a bunch for python and markdown. Last I checked there was mediocre support for having smarter indentation behavior w/Python. And it does choke on very large files as reported by another HN commenter.
But on the bright side it's very clear and useful to have python lint output from pyflakes or similar. gvim+pyflakes is decent, but Atom's presentation feels more modern. Atom's markdown renderer is very convenient.
But on the bright side it's very clear and useful to have python lint output from pyflakes or similar. gvim+pyflakes is decent, but Atom's presentation feels more modern. Atom's markdown renderer is very convenient.
I haven't really used Atom much, but from the sound of it, Visual Studio Code should be a drop in replacement which has all your needs covered.
Python in VS Code is great. Best debugging experience I've had with python.
Disclaimer: Emacs user.
Python in VS Code is great. Best debugging experience I've had with python.
Disclaimer: Emacs user.
If anybody likes transparent backgrounds, I wrote up a quick guide on how to enable it for Atom: https://github.com/transcranial/atom-transparency
Despite the virtually guaranteed negativity toward Atom in any post about Atom on HN I'm a happy user and it works quite well for me.
I want to like Atom but I find the indentation problems make it unusable for code for me. I really wish the would focus on fixing that before adding more secondary features.
What indentation problems, out of curiosity?
It just isn't able get indentation right.
For example, just a random snip out of a random file:
For example, just a random snip out of a random file:
let tree = root.render({state: store.getState(), push: store.push})
let rootNode = createElement(tree)
let oldRootNode = document.getElementById('root')
oldRootNode.parentElement.replaceChild(rootNode, oldRootNode)
store.subscribe(() => {
let newTree = root.render({state: store.getState(), push: store.push})
let patches = diff(tree, newTree)
rootNode = patch(rootNode, patches)
tree = newTree
})
Hmm are you using a special plugin for this? I haven't had a single indentation issue with atom and I'm also writing JavaScript all day. The only issue I've seen is opening an older file that mixes tabs and spaces when ch sometimes makes it harder to read. Even the beautify plugin seems to work well for me.
Ops, you are right. That example was because of the "sane indentation" plugin, that I installed in the hope to get better indentation. Below is an example where plain Atom, without plugins, doesn't get indentation right (notice how it pushes "onEmailChange" under "login"):
const login = (email, password, remember) => a.chain(
submitting(true),
a.ajax({
request: {
url: '/api/sessions',
method: 'POST',
data: { email, password },
},
callback: (status, data) => (
a.chain(submitting(false),
a.setToken(data.token, remember),
a.setUserId(data.userId),
a.setAuth)),
})
)
const value) => {
push(emailChange(value))
}This is something you're copying and pasting in or you're simply writing it out? Also am I missing something or are you missing some syntax (callback has no starting brace)? Also if `const onEmailChange` shouldn't be pushed out then don't you need to end your const login sooner? I don't see where it's ended here.
Granted maybe this is just some truncated example? I hadn't run into weird spacing like this yet so maybe open a bug with something small with reproduction steps?
Granted maybe this is just some truncated example? I hadn't run into weird spacing like this yet so maybe open a bug with something small with reproduction steps?
It is something I am writing, then selecting-all and applying auto-indentation.
`onEmailChange` doesn't even have an open or close curly bracket, it is the indentation format that is confusing us. Below is the same code indented by VS.
Maybe my syntax is different than most, but I see problems like this all the time with Atom. The exact same files indent fine in VS.
Regarding filing a bug, I thought about it, but then I didn't think anybody would care about this.
`onEmailChange` doesn't even have an open or close curly bracket, it is the indentation format that is confusing us. Below is the same code indented by VS.
const login = (email, password, remember) => a.chain(
submitting(true),
a.ajax({
request: {
url: '/api/sessions',
method: 'POST',
data: { email, password },
},
callback: (status, data) => (
a.chain(submitting(false),
a.setToken(data.token, remember),
a.setUserId(data.userId),
a.setAuth)),
})
)
const value) => {
push(emailChange(value))
}
Maybe my syntax is different than most, but I see problems like this all the time with Atom. The exact same files indent fine in VS.
Regarding filing a bug, I thought about it, but then I didn't think anybody would care about this.
Hmm interesting. I tried typing out similar syntax but it seems to be indenting correctly. Then again I don't use much ES6 if at all. So not sure. I'm sure they would care though :)
e. g. when pasting content - Atom wont paste it at the same position your cursor is at, it pastes content at the very beginning of a line. Very annoying
Did you cut/copy the entire line? I've noticed that if you cut/copy the entire line then paste at the beginning of the line it gets the indentation right every time... even if the indentation is different in the two locations.
Been using Atom for a minute but probably am not taking advantage of it like I should. Any indispensable plugins I should check out?
The git integration is superb. The status shows on the UI just enough for me.
When I use Sublime, I miss `terminal-plus` so much. And `pigments` works better too.
Here's my complete package list:
When I use Sublime, I miss `terminal-plus` so much. And `pigments` works better too.
Here's my complete package list:
~/.atom/packages
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] // disabled, use source-preview instead
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]Code peek (https://atom.io/packages/code-peek) is pretty good, esp. for a package with very few DL's.
MiniMap - https://atom.io/packages/minimap
Project Manager - https://atom.io/packages/project-manager (this one is a must, IMHO)
Sublime Style Column Selection - https://atom.io/packages/Sublime-Style-Column-Selection
File Icons - https://atom.io/packages/file-icons
Sort Lines - https://atom.io/packages/sort-lines
...and a pile of linters is most of my setup.
Project Manager - https://atom.io/packages/project-manager (this one is a must, IMHO)
Sublime Style Column Selection - https://atom.io/packages/Sublime-Style-Column-Selection
File Icons - https://atom.io/packages/file-icons
Sort Lines - https://atom.io/packages/sort-lines
...and a pile of linters is most of my setup.
Very happy about the custom title bar option. It's really jarring for everything on-screen to be dark other than the title bar.
Even better would an option to disable native full-screen in macOS. Does anybody know if that is likely to ever happen?
Even better would an option to disable native full-screen in macOS. Does anybody know if that is likely to ever happen?
Why not simply use a dark theme for macOS itself?
I had to abandon Atom due to a bug which basically makes it impossible, on Windows, to un-maximise the Atom window [1].
This was a huge deal breaker for me, I hope it is fixed soon.
EDIT: I love Atom in general, it has some very convenient features, e.g. the git info integrated in the UI and the file sidebar options which are more complete than other editors; I did not mean to be overly negative with my comment and I'm sorry if it seemed that way.
[1] https://github.com/atom/atom/issues/10720
This was a huge deal breaker for me, I hope it is fixed soon.
EDIT: I love Atom in general, it has some very convenient features, e.g. the git info integrated in the UI and the file sidebar options which are more complete than other editors; I did not mean to be overly negative with my comment and I'm sorry if it seemed that way.
[1] https://github.com/atom/atom/issues/10720
And it still doesn't support non-US keyboards on Windows? :(
Can anyone use it to type characters including the AltGr modifier?
Can anyone use it to type characters including the AltGr modifier?
As mentioned in the linked document, this will be addressed in 1.12 (which is in beta now, and will be released in a month or so, assuming they meet their usual cadence).
> And it still doesn't support non-US keyboards on Windows? :(
A text editor which doesn't support keyboards after having been out for years?
Just ditch that thing for something this side of the millennium marker eh?
Emacs, Vim, VS Code or whatever. They all support keyboards and they're all open source too.
A text editor which doesn't support keyboards after having been out for years?
Just ditch that thing for something this side of the millennium marker eh?
Emacs, Vim, VS Code or whatever. They all support keyboards and they're all open source too.
> Just ditch that thing for something this side of the millennium marker eh?
AltGr worked fine in DOS editors like the Borland Turbo C 1.0 "IDE" from 1987.
AltGr worked fine in DOS editors like the Borland Turbo C 1.0 "IDE" from 1987.
It was an intentional stab at an absolutely mind-blowing lacking.
I thought the Emacs reference would give it away, but oh well.
I thought the Emacs reference would give it away, but oh well.
For those of you not in the know, the modified TECO would eventually become the first version of EMACS was built be RMS somewhere between '72-'74. GLS and RMS consolidated a collection of custom macros floating around the AI lab into the first real version of Emacs in '76, on ITS. This was radically different from the Emacs of today, but it was Emacs.
The first public release of GNU Emacs, the emacs which, along with its derivatives, is pretty much the only one in use today (save those oddballs using lispms, and the other oddballs using Hemlock derivatives), was released in 1984, and is 32 years old. The original emacs is 40 years old.
The first public release of GNU Emacs, the emacs which, along with its derivatives, is pretty much the only one in use today (save those oddballs using lispms, and the other oddballs using Hemlock derivatives), was released in 1984, and is 32 years old. The original emacs is 40 years old.
...and that's why my Emacs finger habits are about 40 years old. Scary.
I miss ITS and TWENEX every so often...
I miss ITS and TWENEX every so often...
Wow. I didn't think I'd see any old-timers around here. I'm not one, in case you're wondering.
If you want to scratch that ITS itch, you can emulate it, of course, or you can request an account on UP (http://up.update.uu.se).
If you want to know how to emulate ITS, or just want a refresher in how it works, I recommend http://its.victor.se/wiki/
If you want to scratch that ITS itch, you can emulate it, of course, or you can request an account on UP (http://up.update.uu.se).
If you want to know how to emulate ITS, or just want a refresher in how it works, I recommend http://its.victor.se/wiki/
Install keyboard-localization and then select your locale in the configuration of the addon. I've used that for months. Alternatively use the beta.
Why isn't Atom packaged in Debian yet?
Atom packages debs in their GitHub repo which work in Debian 8. There's no repo you can add to your sources that I am aware of, but you can manually download the deb from https://github.com/atom/atom/releases/tag/v1.11.0, run dpkg --install filename.deb, and get coding.
Atom has a large number of dependencies that need to be added to Debian as well. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747824.
This also does not help: https://github.com/atom/atom/issues/3926
The core team all use Macs, maybe? Anyway - there's an automated, maintained APT mirror/repo here: https://github.com/alanfranz/atom-text-editor-repository/blo...
One thing I love about Atom (could apply to other Electron editor) that I admit is very niche is that I can override color schemes using CSS. I just open it in dev mode, find the class of the syntax I want to color it myself, and fix it with CSS.
A lot of color schemes are imperfect and I'm weird so it bothers me a lot. With Atom I can fix them in a very short time and I don't need to learn anytihng new.
A lot of color schemes are imperfect and I'm weird so it bothers me a lot. With Atom I can fix them in a very short time and I don't need to learn anytihng new.
I really wish someone had cracked native vim support in a modern gui editor - I'm interested in using something like Atom but until I can do basic text editing with 100% native vim (for productivity and health reasons), I really can't make the switch.
Has there been any progress on this? Does neovim make this easier?
Has there been any progress on this? Does neovim make this easier?
I agree. I'm using Atom now since a few weeks, and really like it, but its vim-mode is really not great, and the development of vim-mode stalled. I have high hopes on neovim, but I think it will only play out in a few years from now. Until then, there's a lot of work to do.
I tried vim-mode too, but just trying to replicate vim is never going to work, it needs to be native. It took me about 10 seconds of editing to get blocked by an unsupported feature.
I love atom. I tried VS and went right back to Atom.
What I love about Atom and haven't been able to find in Sublime is the terminal-plus[1] plugin. I know about SublimeREPL, but just don't think it's as nice as terminal-plus. Any suggestions?
1. https://github.com/jeremyramin/terminal-plus
1. https://github.com/jeremyramin/terminal-plus
I really want to love Atom. Even with the least plugins enabled, it crashes pretty frequently for me. Then, I moved back to Sublime. I've done this ceremony about 3 times and I think it is time to just give up until some miracle happens in Atom's land.
Are there any Atom users around who used to use either Emacs or Vim and who might share a few things they feel Atom does better? I'm curious about these modern editors and sometimes wonder what they have to offer besides possibly being easier to learn.
Are we save to assume VSCode has supercede Atom?
P.S - Do VSCode team contribute back to Electron?
P.S - Do VSCode team contribute back to Electron?
I love Atom!
I have 15 years dev exp. Most other IDE have similar productivity to each other - Atom is a step up.
I have 15 years dev exp. Most other IDE have similar productivity to each other - Atom is a step up.
Do you finally have an uniform buffer model, so that text buffers get treated the same as other buffers/windows/whatever atom is calling them?
No?
Well, then, I'm still not using Atom: unlike many, I don't mind JS, but not having a uniform buffer model is a major regression from Emacs, and the features we're getting instead just don't cut it.
No?
Well, then, I'm still not using Atom: unlike many, I don't mind JS, but not having a uniform buffer model is a major regression from Emacs, and the features we're getting instead just don't cut it.
I remember when Emacs stood for “Eight Megabytes And Constantly Swapping”. And now Atom comes along... “Application To Overflow Memory”? In another 20 years, will Atom be considered “lightweight” the way Emacs is now? Will Atom even still be around? I'm fairly confident Emacs will still be around…
I've got 8 gigs of ram, I'd like to see it try: the problem isn't memory usage, it's weak, inconsistent abstractions.
Day 1: Atom and Google Chrome: https://mobile.twitter.com/Edditoria/status/7858488116043776...
Day 2: Sublime Text and Safari: https://mobile.twitter.com/Edditoria/status/7858488116043776...
I didn't disable any packages and extensions, because I need them for daily work. So the result represent what I actually need. I also intended to avoid activities other than coding and checking email.
In short, Sublime Text and Safari survive longer. But Atom and Chrome are usable, at least.
For me, I will continue to use Atom and Chrome. Because Atom is more direct and user-friendly to me, and I feel much better on Chrome Dev Tool (sorry but feel better than Firefox). Another reason is that I can show others who want to learn programming. The licence for ST is not cheap for them.
I know 2-days testing is not enough, so would try again if I can.
First time to comment here. Sorry for bad English.