Hacker News Reader

Comment by arca_vorago | Hacker News Reader

I am a huge emacs fan, but there is a reason I still use vi/vim, and gasp, even nano regularly. It's on just about everything and is quick and simple.

Also, at first I wondered why vi wasn't on there, but for those of you who thought the same, nvi is berkely vi (TIL).

I like that emacs performs in the middle of the road in most of these cases, because it shows stability but room for improvement. Dissapointed with the large file results, but they are useful. (using vi on big files from now, it's a problem I run into more and more)

View on HN

Emacs is much worse with long lines than it is with large files, and the test here uses 1,000 char lines. I'm not even sure I'd dare open a file that consisted of merely a single one of those.

However I've had no difficulty using it to view 3GByte files with 80-column lines. I don't have one handy to try but I did quickly load a 450MByte text file (6m lines, most 76 chars) and it took about 3 seconds to load.

1000 char lines are common for latex. I tend to let the text editor do wrapping on my paragraphs.

yeah, emacs long line performance is in a really sad state. i find it can be quite handy to output really long lines in log files ("hey, here's all the game state at at tick N"), which i end up having to view either with command line tools or in sublime :-/.

i dream of an editor with the flexibility of emacs that but the bug-freeness and speed of sublime. :)

What I've typically done: output things as groups of lines, separated by blank lines, then use C-<up> (backward-paragraph) and C-<down> (forward-paragraph) to move between the blank lines.

Also an option: C-x [ (backward-page) and C-x ] (forward-page) to move between occurrences of ^L (ASCII 12 - you can enter it in a buffer with C-q C-l).

That's a neat hack, though I'd still rather just use long lines -- it's easier, and it plays nicely with tools like grep.

Come on emacs, other editors can handle them! :)

I haven't had any problems loading multiple gigabyte log files, either. For really big files, there's even an Elisp "hack" to make it work better: https://www.emacswiki.org/emacs/vlf.el

I also have the following function in my .zshrc to disable "word wrap", specifically for when I need to read large log files that may have very long lines:

    emacsr () {
            emacs -nw "$1" --eval '(progn (setq buffer-read-only t) (setq truncate-lines t))'
    }

I haven't noticed if it makes loading the files much faster (the lines aren't that long), but definitely makes it easier to read them in a terminal.

For what it's worth, the real scourge with emacs seems to be people's bloaty config files. I have a fairly small .emacs with maybe five packages to load, takes about 1.2 seconds to open (and finish displaying) on my mac, about .2 seconds on my linux workstation. The editor itself actually starts up much quicker, about 110ms on my mac, 40ms on my workstation. Also, generally I use emacs daemon, so I don't really need to start it up at any point.

I don't tend to open files in excess of 100MiB, or do more than about 20k replaces in a file interactively, so I never really notice latency on operations.

Some people have been configuring their emacs for 20 years. They don't work in the same level as you - don't just write off as bloaty config :P

Its actually awesome - I only stopped because my wrists..

Did you swap caps lock and ctl?

Yes - I suspect the "worst offender" shortcut for me is alt-tabbing.

But fear not, not everyone has those issues. Mine diminish if I go to the gym...

I don't care how long my Emacs takes to boot up (currently probably a whole bunch of wall-clock seconds what with all my config files being tangled from Org mode or whatever), since i only start it once every few days or even weeks (when i reboot the kernel, haha i mean host computer, usually).

The importance is that things like 'magit-status be instantaneously snappy to open, which currently leaves a lot to be desired.

Slow emacs start times are very solvable with some smart lisping. Basically, don't '(require)' anything directly, instead make it load lazily when you invoke a particular mode. So set up lots of hooks. Moving your settings into the Customize system lets you do a lot of this for free. After I converted my 10+ year old .emacs into customize and lazy hooks it sped up from roughly 8 to 10 seconds to under a second.

And I also use emacsclient, which make it just instant.

I think emacs in practice would give different results than this as you'd typically use it with server mode.

There's also addon tools like vlfi if you're editing very large files on a regular basis.

I'd be more interested in ~200MB instead of 3 GB as I find myself more frequently opening log files and XML exports in the 100-500MB range.

Not that different; Emacs without complex ~/.emacs.d/init.el loads quite quickly (in unscientific testing on my dev VM with a cold cache, 214ms for "emacs -nw -Q -e 'kill-emacs'").

Just jumping on the Emacs bandwagon here to Ask HN: does anyone have tips and tricks for profiling my real-world Emacs setup? Between perhaps a too-large .git repository, and all my loaded extensions, and perhaps spellchecking or font-lock, i'm sometimes not sure what's causing latency, and while i couldn't go back to Vim feature-wise, i do miss its speed.

There is a profiler built into Emacs that will help:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...

https://www.emacswiki.org/emacs/EmacsNativeProfiler

Also, ESUP for profiling your startup time:

https://github.com/jschaf/esup

There's also a second profiler in Emacs, ELP, which can be used for testing individual functions:

https://www.emacswiki.org/emacs/EmacsLispProfiler

Awesome, thanks for the pointers! I feel silly for not RTFM.

It's all right -- I used Emacs for ten years before I learned there was a profiler! The FM is quite large. :)

Reply on news.ycombinator.com