Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


I find this to be a really tired discussion/response that pops up whenever new software comes around.

"X doesn't do Y" "Did you really want Y"?

Of course they do, they just complained about it.

> It's not unreasonable to say that these are two different classes of programs, with different basic requirements.

But it is reasonable to hold a piece of software up to standards set by the majority of other software in the same realm. Other text editors can open log files, this one probably should be able to, too.


> "X doesn't do Y" "Did you really want Y"?

> Of course they do, they just complained about it.

It's just a rhetorical way of saying "I don't understand why that is a problem", and a request for explanation. I would say that's a pretty reasonable response to "I found this is a problem".


I've been opening log files in either vi, notepad++, or sublime text for as long as I can remember. I've never had any issues accomplishing exactly what I needed. You insinuate that's a bad thing without providing any examples or solutions that are "better", so I can only assume your rationale is: My tool is awesome even though it doesn't fit your requirements, so you should change your requirements.


I definitely don't mean to insinuate it's a bad thing, but for me it is not a core requirement. Atom is supposed to be a code editor, and it's no hardship to use a different program for opening non-code text files. I actually find native text editors (I've tried Scratch and Gedit) don't work better than Atom for largish text files of a megabyte or thereabouts, so it's clearly a relatively common issue with editors which are built on the assumption you're going to be looking at smaller files. If the Atom devs manage to write the code which will allow these files to be handled, great, but in the meantime the program remains excellent for editing code.


I do not understand the need to separate a "code editor" from a text editor. What is code before it is interpreted or compiled? Text.

I do not object to the existence of Atom -- it scratches some people's itches, so that's fine -- but I do not buy "it's supposed to be a code editor" as enough of a justification for using it versus other text editors.


Not really, in my mind it should be the expectation that in 2015 we can use modern editing tools to open large files.

IMO the fact that vim is so versatile is part of the reason it has come so far.


A code editor that doubles as a text editor is major benefit, especially if you're needing to consume logs while testing.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: