Introducing Block Decorations | Hacker News Reader

Introducing Block Decorations

blog.atom.io

94 pointsas-cii36 comments

I've been wanting this feature ever since I watched a video of TempleOS, which featured images in source code (everything is in "DolDoc" format: http://www.codersnotes.com/notes/a-constructive-look-at-temp...). I'd love to be able to drop in diagrams, screen shots, and scribbles into the source code of my personal projects!

Yeah, I actually started on a package that would render comments as markdown, allowing you to create 'notebook'-style source code. I gave up when exploring the API and not finding a good way to replace lines with (possibly variably-height) content.

There's also the problem that Atom doesn't have any debuggers worth speaking of so far. That could change now.

I'll have a look into this. Sounds great anyway.

I find Atom very interesting, but the performance always drives me away from using it. Have recent versions improved? Anyone using it full time?

I've recently started using more, but I still have to turn to sublime fairly often due to speed (dealing with larger projects, bigger data files, more complex regex searching).

That being said, the performance has been getting steadily better, enough to the point I can do most of my coding in it without noticing a problem. I'd suggest giving it another go and see how it does for you! It's quite a joy to hack on.

Can you give an example of 'more complex regex searching'? I thought the JS regex engine would be at par with whatever sublime uses.

Not the parent, but the JS regex engine is less powerful than what Sublime uses (PCRE?), lacking among other things atomic groups, possessive quantifiers and lookbehind.

I don't have issues in terms of expressiveness, but in terms of performance. Complex/expensive regexs that run quite quickly in sublime take a long time on atom, especially on large documents.

Perhaps this is an abuse of the tool, but I find its convenient to do these sorts of things in a text editor where I can watch my regexs highlight it's selections in real time.

I tried installing it recently and adding on the facebook react extention, and whilst installing it completely broke.

Restarting made it end up in the same install cycle as before.

Atom fixes what is broken in Sublime, but has it's own issues that are currently far worse.

Facebook have their own "ide" - Nuclide. Many of their plugins break Atom when used standalone.

To make that clearer: Nuclide is to Ubuntu as Atom is to Debian. You can use Debian packages on Ubuntu, but Ubuntu packages are really unlikely to work on Debian.

It actually has. Atom became unusable for me, but the most recent version fixed a bug involving the .git file. It's not sublime fast, but it's enough that I enjoy using it now.

I use it regularly for editing the front-end portion of our project. Granted it's not the biggest project (36 folders and 158 total files.) but it performs quite well. I have some problems using git from the command line as atom seems to lock random files from time to time. I really have no complaints. I enjoy using it and find the community packages that are available quite useful.

I've been using Atom full-time for about a year, after switching from Sublime. I'm happy with it as an editor, and like the momentum behind the plugins ecosystem. Performance has been completely adequate, and I've seen none of the issues that always seem to crop up whenever Atom is mentioned on HN. There may be a platform difference - I use it on OSX, but friends of mine on Linux have been less satisfied.

I do still resort to vim on the command-line for some things, but as a "daily driver" code editor, Atom has been excellent.

Just echoing your platform difference comment.

I've noticed that the editor, with my load of plugins, comes up relatively quick on OSX (~4 seconds from launching, equally as long to open a new window), and roughly twice as slow on Windows (~8 seconds from click, ~3 seconds to open a window)

But, when I'm using it, I'm basically living in the app, so the startup time is really a moot point IMO.

It's still kind of bad. Just try opening up a minified JS (or any kind of large file) file and watch your Atom become unresponsive for 5 minutes.

I just downloaded the latest minified production release of ember.js and it took Atom less than a second to open it on my Machine (2014 rMBP).

Opening it up and trying to edit it/move around are two different things. Try to scroll to the end of it. You'll break Atom either the line will just randomly stop or you'll freeze your Atom.

Sure but that's not a common use-case and won't affect people who want to use Atom as a day-to-day code editor.

But it is a use-case. I always have to keep Sublime Text around for the times I need it.

I wish Atom would prevent me from opening such files, as an option. I sometimes accidentally open large minified files and have to wait.

People always complain about performance, but you just have to be conscious when using it. Don't open a massive file and you should be fine.

I've been using Atom full time for about a year and a half now. I've never noticed performance issues though, so I've always been curious about where these complaints come from.

I just ran a find over the project I've been working on full time, and the largest file, by a long shot, is 8kb, and a little under 100 lines. That's just an autogenerated enum of the HTTP status codes though, so it isn't indicative of real code.

In the vast majority of cases, all of my files are less than 4kb, and hover around 40 lines or so. Atom handles this use case just fine, and I'm hard pressed to think of a situation where I'd run into performance concerns. The entire process itself is using less than 80mb of RAM, and 0.2% of my CPU. A single tab of Chrome is worse than that.

What are people doing with their text editor that they need blazing speed?

Your codebase is very modular and wonderful but for other projects, large files (100kb+) are not uncommon. For those projects, "clean up your code before using my product" is not an acceptable answer.

This seems like a tragedy of the commons: those projects only exist in the state they're in because some products exist which allow you to work with them despite their flaws. Whereas, if nothing worked with 100kb+ source files, the projects would change.

What are people doing with their text editor that they need blazing speed?

I admit the answer that immediately comes to mind is: "uh, editing text?" But to be more serious --

My own coding projects rarely have files with more than 300-400 lines, but the coding projects I'm working on aren't always my own, and my own projects involving text files aren't always coding. If I have reason to load a 3000-line source code file, I don't expect my editor to choke. (I've done this on occasion.) If I have reason to load a 603K, 7300-paragraph Markdown file, I don't expect my editor to choke on that, either. (For somewhat obscure reasons, I'm doing that weekly, and yes, I'm making edits as I go.)

In (very!) limited testing just now with both those cases, Atom 1.4 seemed to do just fine, for the record.

Opening log files? Having a generic text editing component that can scale to showing 75k logs makes it easy to build great visual tooling on top of that.

Yeah I really like a lot of Atom packages and there's a lot of cools stuff coming out for it. It starts out kinda slow and sometimes it takes a bit to highlight syntax (less than a second but still), but otherwise I like it.

It has improved but it still has pain points, it's good to have backups. Had to revert to enact for dealing diffs and git commits.

I love Atom and it's growing ecosystem. I hate that it's much slower (especially startup time) compared to Sublime Text and that it's using often tremendous amounts of resources. I also still wonder: Why CSON and CoffeeScript... in 2016?!

I've never done it, but id assume the effort to do a rewrite would be tremendous.

Not really, it would be tedious, but idiomatic coffeescript can be converted to idiomatic javascript basically on a line-for-line basis. Also the compiler really does produce readable code (though unmistakeably computer-generated), so the process might even be sped by reducing it to just tidying up compiler output.

It's a task that could easily be spread across any number of human translators, too.

The main limiting factor is the quality of the test suite, which dictates how quickly typos could be found.

Along those lines, it would be wonderful if someone would write a coffeescript implementation that output clean, idiomatic ES6 rather than ES5!

You can try https://github.com/decaffeinate/decaffeinate. It's basic but gets some work done.

Pretty sure they're moving to ES6 these days: https://github.com/atom/toggle-quotes/pull/26#issuecomment-1...

> Why CSON and CoffeeScript... in 2016?!

All new code is ES6: https://twitter.com/nathansobo/status/670047510258253828

Wow ! This is great ! I guess packages ala ipython notebook are coming soon :)

Reply on news.ycombinator.com