Live data from Hacker News

Atom 1.0

blog.atom.io

441–450 of 459 posts

Re: Atom 1.0

#441
post #275

Broke the default font, ugh! Anyone know how to get the old font back?

Just add Inconsolata to your Font Family in Settings. If you want the old font size and line height too, set those to 16px and 1.3, respectively.

thank you!

Re: Atom 1.0

#442
post #334

Earlier quoted context omitted.

I would have switched off of Emacs for some things ages ago if not for the broken behavior of the TAB key when editing text in what seems like every other editor . No, I do not ever want to insert a \t literal. Never. Ever. And if I do, I can do it with a more ponderous key sequence. But I never do. On the other hand, I need to indent a line to the correct tab stop perhaps a BILLION TIMES A DAY. Emacs has the benefit…

> Emacs has the benefit of decades of Huffman coding for its keystrokes, and I appreciate that. Huffman coding, emacs, keystrokes, ... what?

The most commonly used functions in Emacs are assigned to the shortest key bindings.

Re: Atom 1.0

#443

Earlier quoted context omitted.

Yeah this is crazy. I regularly work with log files in the 100mb to 300mb range which open perfectly fine in Vim/Sublime. If I had to invest time in learning Atom I'd have to multitask between editors for certain use-cases. Maybe if they could switch to a light-weight read-only type of text "viewer" for large files, that would even work. But I really do need to open big files on a weekly basis.

Do you really want to open log files in a code editor? It's not unreasonable to say that these are two different classes of programs, with different basic requirements.

Atom is a text editor and logs are text files that may need to be edited. It's not unreasonable to expect a text editor to be able to open the various text files littered through a system, and it obviously is a problem to a lot of people. I know that for me personally, I sometimes end up wanting to mangle logs in ways where grep falls short and stream editing with sed or awk is either more cumbersome than using the various tools at my disposal in vim, or just beyond my understanding of these tools.

I can open larger files with emacs, nano, vim, nvi, ed etc., so I think that it's fair to say that the limited buffer size plaguing Atom is a solved problem generally. Somehow it has a built-in package manager, but falls short of ed on very basic text editing facilities.

Re: Atom 1.0

#444
post #442

Earlier quoted context omitted.

> Emacs has the benefit of decades of Huffman coding for its keystrokes, and I appreciate that. Huffman coding, emacs, keystrokes, ... what?

The most commonly used functions in Emacs are assigned to the shortest key bindings.

Ah, that totally flew over my head. Thanks!

Re: Atom 1.0

#445
post #199

Earlier quoted context omitted.

You have felt it is easy to install, debug, and write vim plugins? As a vim user, I am super curious how?

Installing and managing plugins at least is pretty easy with pathogen and vundle.

And for writing: https://github.com/google/vim-maktaba

Re: Atom 1.0

#446
post #428

Earlier quoted context omitted.

Sorry for side-jacking this comment - but which version of Sublime, may I ask, and what OS? I'm using Sublime 2 on OS X and large files + regular expressions are generally a cause for pain. Do you have any default settings changed like disabled document preview or similar? The only thing I generally feel is a champ at regular expressions + insanely large files on OS X is TextWrangler/BBEdit. In fact, I keep TextWrang…

Any update on this long-past inquiry of the future status of Sublime Text? https://news.ycombinator.com/item?id=7565213

Since that post development has picked back up:

http://www.sublimetext.com/3dev

Re: Atom 1.0

#447
post #348

Congrats to the team for reaching this important milestone. I'm a Sublime license holder, but I use Atom as much as I can, because the more open source can win, the better. However, yesterday I was doing some complex regex's (porting a random sql dump file into a seeds.rb), and Atom kept dying, whereas Sublime was pretty much instantaneous. I'm not doing the usual "Atom is slow" drum beating, but saying some underton…

I just tried it on a 14MB file to confirm, and Atom can open files larger than 2MB. (I also scrolled through the whole file just to make sure Atom wasn't cheating somehow, and it seemed to be working fine.)

Thanks - that must be new, as the last beta I can remember (within the last week or so) didn't crash, but tossed up a dialog saying it had a hard-limit. Now it just gives the the warning that it'll be unresponsive.

Opening up a decent sized development.log did cause it to throw random errors however.

Re: Atom 1.0

#448
post #242

Earlier quoted context omitted.

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.

Have been using Firefox since beta, hardware hasn't always been exactly latest and greatest and I really don't get this whole Firefox is bloated meme.

Try Chrome for a month and you'll get it. I'm switching back to Firefox, but believe me, the argument holds weight.

Re: Atom 1.0

#449
post #224

Earlier quoted context omitted.

You should check out Neovim. The native scripting language is Lua, and it's a fork of the vim codebase so still fast and commands all work identically. It's still early, but I am monitoring (and supporting) the project closely.

Also, one of Neovim's banner features is asynchronous job control, which greyrest complained about.

I can't wait until we don't have to run it in a terminal though.

Re: Atom 1.0

#450

Earlier quoted context omitted.

I just tried it on a 35MB log file and it gave me an alert that said it was gonna be sluggish, then took about 20s to actually open the file I requested (I could navigate to other tabs in the meantime but there was no indication that anything was happening), and then once the file appeared, it took another 20s to become responsive. Searching for a string which appeared in the second line of the file took over 30s, pr…

Now try to do the same thing in Sublime 3. You can even try with ~2GB and it will be quick and responsive.

Just opened a ~800MB log file on Sublime Text 3 (running in OSX), wow, it's really fast and responsive.
Post reply on HN