Hacker News Reader

Comment by hsbauauvhabzb | Hacker News Reader

I like eMacs but I feel the whole workflow is wrong. Buffers are a stacked tiled window manager inside your window manager. Your browser is a tabbed window manager, and many other applications are also window managers. I wish any sub buffer of any application was for all intents and purposes a dedicated window, so the WM can take care of the rest. Maybe it’s an adjustment that I could make in my workflow, but a global solution would have been nice. Too late now I guess though.

View on HN

You can configure Emacs to open each buffer in a new frame — ie “window” and manage them with your window manager

Exactly. I share the view that it doesn't make sense to effectively have two window managers running (one in my WM and one in Emacs) with different philosophies and shortcuts. But, and in a more general sense this is the great thing about Emacs, if you don't like its default behaviour you just change it.

EXWM + Qutebrowser can work like that. The individual tabs of Qutebrowser become Emacs buffers.

I've used the no-tabs extension also for firefox when I used sway to integrate firefox into the WM. You can modify the userchrome to hide the tab bar completely. It worked really nicely, and should also work with exwm.

Doesn’t emacs slow down on really long files? I mean like 8,000 lines

My "main" org file is 21k lines, it's no problem at all. My laptop is from 2017 or something.

I do sometimes work on files that are 300k lines (don't ask), and while it's mostly fine, once in a while I'll try to use some less common operation that's not very optimized and have to abort it (e.g. don't try to magit-blame that file). But stuff like searching, scrolling, editing, syntax highlighting are all fast.

If I have to open files >100M I sometimes open them in `fundamental-mode`, which turns off syntax highlighting.

For truly large files (gigabytes), there is the `vlf` (Very Large File) package, which doesn't load it all into memory at once, but still lets you search, scroll and even M-x occur (sort of like grep, but more integrated and editable).

Note that this is on Emacs 31 (there have been some major perf improvements in the last three or so releases, and more is coming with the new garbage collector)

In earlier days there were issues with very long lines; these have partly been mitigated in later releases; on the one hand by faster internals, but also a new builtin package `so-long` that can notice very long lines, default 10k bytes, where Emacs probably should give up syntax highlighting etc. to remain snappy.

I finally made the switch to vim when I was working on a really large frontend template that consisted of the same massive repeated block where a small portion of each was different based on a condition.

There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.

Not these days. Native Compilation made emacs a faster and there have been a lot of other changes. In fundamental-mode, emacs can handle really large files. When opening files literally, it's even faster. I have this 104k line org-mode file and it's reasonably responsive. Reverting it takes a while, but the UI does not hang while the buffer is being formatted according to the mode.

I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.

I’ll bite, wtf is your org file?

It's three months of text I need to refile.

In general, no... but also maybe yes. It's usually fine, but you may get extra unlucky in specific situations with specific major modes.

I've always found line length the biggest problem. Emacs has never done a fantastic job of handling long lines. If truncated, you can't see most of the content; if not truncated, the performance gets worse with length, and visual-line-mode (essential for dealing with non-truncated long lines IMO) doesn't make it any better.

Performance with large numbers of mostly shortish lines is ok. I've had no serious problems loading 2+ GByte log files (average line length <200 chars) in literal mode. The general performance suggests that Emacs isn't really tuned for editing enormous files, but I've never found things so bad as to be worth switching text editor over.

No, but that’s not really relevant, my point is more that all buffers should be windows across all applications.

Emacs for me gets slow when syntax highlighting is on and I navigate to a very long line, text-mode does not have highlighting or the slowness. Most emacs slowness is caused by bad plugins, which if you report may be fixed by developers.

Reply on news.ycombinator.com