Does plugging in a third party code completion engine really make this an IDE? Do I get cross file variable/method/class name refactoring? Do I get runtime code debugging including stack inspection and breakpoints? Do I get test suite integration?
Atom itself is a text editor, not a code editor, which is why I'm asking if this set of functionality crosses that distinction line. If Atom is capable of being a true IDE (code editor) then that would be big news.
I agree. The difference between an IDE and a text editor is absolutely not that an IDE has more advanced editing capabilities (e.g., code completion). In fact, it's quite the opposite, in that most programmers' text editors provide far more sophisticated editing capabilities than a typical IDE. What sets the IDE apart is right in the name: integrated development environment. That is, everything you need for development all rolled up into a single integrated environment (hopefully, this is obvious). So, an IDE ought to provide not just editing capabilities, but facilities for managing, configuring, building, running, testing, debugging, etc.
Can't upvote this comment enough. I have just started learning rust and the lack of debugging options are telling. I know it is early days for rust, but for some, this would be show stopper from picking up the language.
I don't have any experience programming rust. So, how do Mozilla devs create something like servo?
I know, you can get quite far with a text editor and something like gdb, but after using Visual Studio for far too long, falling back to the commandline gets kinda.. old?
A lot of Firefox developers don't use Visual Studio for debugging, even though it's an option. Some of us just prefer command line debuggers.
That said, it would definitely be nice to support Visual Studio debugging, and we're in a position to benefit from all the hard work upstream LLVM is doing to support it.
Seeing as I don't leave the editor to test, compile, run, and, of course, write code, it's an IDE for me. You get syntax highlighting, linting, code completion, definition lookup, and cargo integration, but that still doesn't make it a code editor in your book?
It doesn't have all the features of IDEA but I don't draw the line there.
> but that still doesn't make it a code editor in your book?
The GP isn't saying this isn't a code editor. The GP is making a distinction between a code editor and an integrated development environment. The GP's definition of IDE is integrating editing, building, testing, debugging, etc.
> Atom itself is a text editor, not a code editor, which is why I'm asking if this set of functionality crosses that distinction line. If Atom is capable of being a true IDE (code editor) then that would be big news.
And like I said, I consider Atom a rust IDE for the mentioned reasons
From what I've gathered so far, IDEs are suppose to be like crack. If you get them addicted to your stuff, you'll be able to convert them to paying customers for other things down the road. Considering the resources that GitHub and Microsoft are throwing at atom and vscode, I do buy into this premise a bit.
I'm as baffled as you are, but I'm definitely not their target audience, as I'm content with vim and a terminal. If somebody can point me to some research papers on this, I would love to learn more about this phenomenon.
Can this (or any) Rust IDE jump to definitions, do project-wide code refactoring, or highlight incorrect parameter types? These are the three big things I really want in an IDE, and without them I'll probably stick to Vim (as I'm more productive there); the features I mentioned are kind of a tipping point between editor/IDE use for me.
(It doesn't look like any of these are supported based on the advertised features, but maybe I didn't read closely enough.)
Allegedly, Racer supports jumping to definitions, but in my experience with the Vim plugin, it's not particularly reliable, e.g. in the way ctags is. What I found most frustrating was that it seemed to look for a definition in the current buffer, failing that it looked in the standard library, and failing that it just did a substring search in the current buffer. It was practically worthless to me once my projects grew beyond a single module.
The Rust developers themselves (particularly Niko Matsakis) have been using ctags since long before Racer existed. You can see their ctags definition file at https://github.com/rust-lang/rust/blob/master/src/etc/ctags.... , and you can run `make TAGS.emacs` or `make TAGS.vi` from within the Rust repo to generate them for the stdlib.
Maybe you should file a bug, although it sounds like you never even set it up. I say this because it worked with all std and third party modules I've used in any project.
The plugin ecosystem seems to be really flourishing in Atom, the Go plugin was great and quite excited to see this.
I try Atom every couple of months but never last long before heading back to my terminal. I'm assuming it's only a matter of time though before it's polished and fast enough that we'll see a lot of converts.
I'm the same .. I keep wanting to switch to Atom from ST3, because all the cool kids are doing it, but every time I make the attempt I'm thwarted by the feeling that its just not a very well-written application if it can't handle my 500-line files without hitting swap - on a system with 16gigs of RAM and plenty of cores free.
It may be that its worth the effort - I wouldn't know. But the feeling that I'm not actually improving things by moving to an editor that can't handle big files is just too prevalent.
So I inevitable switch back to ST3 and go back to work, every single time. Sorry Atom guys, its just not working for me.
As much as I hate the idea of basically bundling Chrome with the application to get it to run, since this is essentially Chrome then wouldn't it be able to utilize WebAssembly in the future instead of the JavaScript engine?
I don't think JS is the bottleneck. I think one of the bottlenecks is algorithms - because Visual Studio Code is much faster than Atom on the same node/electron platform. The other main bottleneck might be that the browser DOM is used for rendering, which is super flexible but probably not as fast as a more dedicated text editor GUI toolkit.
I'm also convinced it's the syntax highlighting in atom that contributed to a massive amount of its "sluggishness".
It uses regex with some off-the-wall engine that they chose because it supports just about every encoding under the sun. Many of the language syntax packages I looked at could easily improve their regex performance.
Plus when you open a file as "plain text" or disable the syntax highlighting package much of the sluggishness goes away.
I'd love to dive in and try and fix it myself but I won't have time to for a few months. The code itself isn't horrible just a little undocumented.
I think Sublime Text, Atom and now also VS Code use Oniguruma as their regex engine. Atom and code even use the same implementation (node-oniguruma) and the syntax highlighting definitions for the languages are often also the same - because they were ported from TextMate to Sublime and then to Atom and Code. So even if the engine is not perfect and the defined regexes might not be optimal for some languages - it still would not explain why Atom is slower than Code.
My personal guess is that is because Code might use a more stream-like processing of the source files and does not have the whole files in memory (it also works with really big files - which Atom does not support) and that this does work better
You are probably right about the streaming system. It's interesting that atom doesn't do it that way (seeing as how streams are such an useful part of "server-side" javascript)
Like I said at one point i'd really like to dive into this stuff and spend some time trying to figure out exactly what the problem is (and maybe help find a way to fix it).
Main thing that's kept me from using it is lack of good support for remote editing. Once it's got something that it'll fit the way I want to use it much nicer.
What I use on OSX is "ExpanDrive", it's a nicely polished paid app that lets you mount sshfs drives system wide (your server only needs to support ssh access). With that you can manipulate remote files with whatever local program you have, it's fully transparent.
I've tried a few of those on windows but they all seem to have terrible latency, I think they're constantly reconnecting to the server whenever an operation happens.
On OSX it works well enough for me to work directly on the server if I have LAN connection or good internet with low latency. If the connection is shaky I'm working locally, sync with Rsync and use ExpanDrive to check on result files. But yes, it's a question of managing your expectations.
That's largely the way I do it, but I have to use windows at my current job, so a good terminal isn't really present. putty does ok but it's cumbersome compared to openssh, and cygwin makes it better to use but terminals aren't very good. My current setup is ConEMU and cygwin.
Trying to get permission to setup some kind of VM on the machine, (likely VB) so I can use what I'm used to.
I tried Nuclide but unfortunately it doesn't play well with the custom build-time include paths that we have. They are available as environment variables on the coding environment but Nuclide can't make use of them.
There's a remote-sftp package that allows a bit of this. But I've only used it for light fixes and config file changes on servers, never for real full remote development.
I do enjoy using Atom as an everyday editor for ECMAScript / React apps, where the convention is to have many very small files. ES6 + Hasklig font + Ligatures make for a particularly visually-pleasing coding experience.
Unfortunately, Atom has severe performance issues with files that are anything above "tiny". For example, a 500-line XML file will lock Atom up for many seconds, to several minutes, while it's inefficient little ECMAScript parsing engine tries to chew through it. I build the latest version almost daily in anticipation of improvements in this area!
This is what prevents my adopting this otherwise lovely, vibrant, flexible editor for all my tasks.
A real IDE like IntelliJ has no problems with applying various tooling (parsing, validation, de-bugging of XSLT, etc etc) to a 15,000-line XML file.
In the longer term, I do hope that somebody is addressing this - which I think is literally the only thing that Atom has going against it.
Atom doesn't have debugging capabilities - if you really wanted an IDE for rust on this kind of stack you should probably be using VSCode - they have debugging UI and are even adding GDB integration.
"Makes precompilation and show error while coding." -- some parts of the web page may be in need of a little proofreading ;) but that's less relevant. keep up the good work!
You used this website template (http://html5up.net/hyperspace) which has a Creative Commons 3.0 license, and you scrubbed the author's name and attribution from the template. Please respect the license! http://html5up.net/license
Attribution is a fine line; removing the attribution from where it was in the template and plastering "All Rights Reserved" copyright over it is a very clear violation of the creative commons license.
In some situations, it's difficult to place attribution along with the media, but in this case, it's not - it's a webpage - and having the attribution be in the source code is not really acceptable, because it's not reasonably accessible for someone looking for it.
If you look at that page and only that page, what leads you to believe that this is built of off a CC-BY work? Nothing. Sure, you can add "for copyright and license information, visit this link" in the footer, with a link to the github readme page that has the attribution, but removing it all together and only leaving scraps of it in the source code is just careless, reckless misuse of the original author's work.
He's not selling a website or a template though. The "All Rights Reserved" refers to the product, ie. Tokamak, which he indeed owns.
He didn't obfuscate the source, and indeed the attribution is the very first thing you see in the source (and when it comes to HTML, the source IS the website). And while he didn't comply 100% with the 'default' CC license (which reads that you should state the changes made), he did comply 100% with the 'rules' given by the author. He gave credit, and linked to the website, as well as the specific licensing terms given by the author.
Tl;dr - since he's not selling a template, the copyright at the bottom obviously refers to his own product and not the web template. The attribution is in the correct spot, at the top of the source.
What are the norms for attribution when it comes to software? You include a LICENSE file if you're distributing the source, or you display it in your software (like iPhones and Androids).
What are the norms for attribution when it comes to images, videos? The footer. A bar over the bottom of the image. A CC logo. Anything visibly displayed along side the image.
What are the norms of attribution when it comes to website design? The footer, or an About page.
The point is that attribution is made as accessible as possible. It's what keeps the Creative Commons community strong! Deleting the template author's attribution section and relegating it to the SOURCE CODE of the website means that anyone who doesn't know what the source code is (a lot of people) don't know that "hey, this is a template that I can use too!" The attribution is _missing_. It needs to be present with the work, i.e. the web page, and hey, how do you do that? You put the link in the footer, where it was before you deleted it.
Legally speaking, the source code IS the website. There is no difference. If I were to open up the website in a plain text editor, what would I see? It's the same as for any other program - the license resides in the code, not the 'output'.
As for the website template and CC license, it's not an image or a video. It's a collection of CSS, Js and HTML. It's code.
I'd argue that maybe the template should have a code license like the GPL, and not a CC license. And while I'm aware that the CC license is common for website templates, I'm also sure you could convince most courts that it's not an 'image or video'.
Anyhow, I'm sure this could be solved if the creator of the template asked for a little more recognition. Not dragging this guy through the mud for something that's irrelevant to what he actually created. He's not trying to pass off the website as his own, only the actual project itself, which IS his!!!
The template author is selling an attribution free version of his template - if you click download it will say:
"Need an attribution-free version?
Check out Pixelarity, my latest and greatest side project that offers attribution-free usage of all of my templates, exclusive new templates, and support (from me) for just $19."
The license says to "keep intact" all copyright notices. My layman's assumption would be that means scrubbing is a violation. It also says a lot of words that seem to come down to "if you put your copyright notice in, then their attribution has to be at least as prominent."
All said, though, it's sketchy practice no matter what the license says literally. A main purpose of CC is to give you a license that can be followed common-sensibly. Playing "lawyer' with the wording isn't reciprocating the goodwill of the author.
I disagree--dual-licensing is absolutely a thing, as is white-labeling. The author is putting a price on hiding his involvement. Why is that not a valid thing to do?
Not really, unless you assume "тока" to be a phonetic simplification of "только" (which is acceptable as a colloquialism or if you're transcribing someone's slurred speech). Otherwise, it translates as toroidal chamber with magnetic coils (a magnetic plasma confinement device, https://en.wikipedia.org/wiki/Tokamak)
"Тока" is a misspelling of "только" which you frequently encounter because in fast speech, that "ль" doesn't get pronounced.
Sometimes, it's deliberate; the writer is going for the effect of transcribing colloquial speech - like in English, you might write "innit" instead of "isn't it" to render a casual spoken conversation.
And sometimes, it's a sign of a illiteracy - like in English, when people write "should of" instead of "should have" because it sounds the same and they don't know any better.
Given that the tagline for the project is "Fusion Reactor for Rust," I'd guess that the project's name is designed to read to English speakers as "Tokamak" while maintaining a "Russian flavor."
EDIT: Not being a Russian speaker, I completely misunderstood this comment -- I apologize for my blithe ignorance.
Atom itself is a text editor, not a code editor, which is why I'm asking if this set of functionality crosses that distinction line. If Atom is capable of being a true IDE (code editor) then that would be big news.