Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Is Not Enough

project-mage.org

Post reply on HN
Print view View original

131–140 of 163 posts

Re: Emacs Is Not Enough

#131

Post by pjmlp »

some-mthfka wrote: post #40

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the Project's Philosophy/Homogeneity section in [1] The Power of Structure. I am proposing we need to really start considering a different para…

Ironically, "how we do C++" is exactly how Lucid Emacs came to be, based on their experience with Lisp Machines.

https://www.reddit.com/r/programming/comments/25r6pw/a_demo_...

Re: Emacs Is Not Enough

#132

Post by npsimons »

msla wrote: post #52
roenxi wrote: post #14

When reading this article, I think there is an interesting parallel to be made with Firefox. Emacs has questionable technical underpinnings. It is an old project; they've all learned a lot since the 1970s. ELisp wouldn't be built that way today, it wouldn't be written in C, it'd be designed with keybindings for a modern keyboard - probably cloning vim. Break from Emacs tradition and build something that is good at ed…

> it'd be designed with keybindings for a modern keyboard - probably cloning vim. Or not. This is something some have a hard time understanding, but some of us prefer a non-modal editor and like having simpler key chords instead of key sequences. After all, vi isn't that much younger than Emacs, and the technical underpinnings of its command language are just about as old as the oldest versions of TECO Emacs. My poin…

> This is something some have a hard time understanding, but some of us prefer a non-modal editor and like having simpler key chords instead of key sequences.

I'll second this.

I literally grew up on VI - my dad installed it with UNIX tools on the family 486 running MS-DOS. Then I dedicated a week to learning Emacs around the turn of the century, and I've never looked back.

To be sure, I still whip out vim for quick editing of remote server config files and it's my editor in mutt. But there's just so much power in emacs - I'm reminded of Vivek Halder's "Levels of Emacs Proficiency"[0], and the fact I do most everything in Emacs these days (I live in org-mode, play music in EMMS, run git through EGG, etc, etc). It's hard to think of anything with this level of consistency of keybindings, nor something that does so many things I need to do.

[0] - https://www.vivekhaldar.com/articles/the-levels-of-emacs-pro...

Re: Emacs Is Not Enough

#133

Post by worik »

Ferret7446 wrote: post #36
worik wrote: post #21

Earlier quoted context omitted.

Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.

Any system that is capable of emitting any data, can emit bytes from print debugging. Could be log file, socket, or even pulses along a GPIO pin. If the system can't emit any data, well, you're kind of stuck anyway.

Pulses on a GPIO pin are not print statements.

A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.

"print statements" are useless in this class of device.

Stretching the definition of "print statement" to recording pulses from a pin is, well, a stretch!

Poor young programmers. If the only tool you have is a hemmer, every problem is a thumb.

Re: Emacs Is Not Enough

#134

Post by worik »

the__alchemist wrote: post #72
worik wrote: post #21

Earlier quoted context omitted.

Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.

Do you have an example of one that doesn't have one?

This is in the realm of ignorant questions. It could well be that the majority of computer devices have none. E.g. the micro controller in my washing machine

Re: Emacs Is Not Enough

#137

Post by lanstin »

scruple wrote: post #123
narag wrote: post #122

Earlier quoted context omitted.

I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.

It's not Emacs fault that CSV is a garbage format. Anyone who has spent time dealing with CSV understands the hell that is lurking in it's shadows. I don't think the rants solution, though I did not finish reading it because I frankly got bored, is going to fix any of this, either.

That isnt the problem he is describing tho, it is that you have no primitives in emacs that correspond to a rectangle of text entry boxes like the semantics of csv. You only have sequence of chars.

The author wants people to rewrite emacs as a design system for arbitrary structures of data, with hooks for moving around the structure and editing the structure and i guess contents

Re: Emacs Is Not Enough

#138

Post by scruple »

lanstin wrote: post #137
scruple wrote: post #123

Earlier quoted context omitted.

It's not Emacs fault that CSV is a garbage format. Anyone who has spent time dealing with CSV understands the hell that is lurking in it's shadows. I don't think the rants solution, though I did not finish reading it because I frankly got bored, is going to fix any of this, either.

That isnt the problem he is describing tho, it is that you have no primitives in emacs that correspond to a rectangle of text entry boxes like the semantics of csv. You only have sequence of chars. The author wants people to rewrite emacs as a design system for arbitrary structures of data, with hooks for moving around the structure and editing the structure and i guess contents

I see. I thought the rant was a mess, personally, so I stopped reading it. Theres some irony to be found in an unstructed rant about... structured editing.

Anyway, if that's the point, then maybe tree-sitter can help us get there in the future? I still fail to see how this is an Emacs problem to solve. The vim/neovim model is also using what are essentially string dumps in the form of buffers. I'm sure every other editor is, too, but without going as far as actually having buffers, though I'm not invested enough into anything else to know what it's doing.

Re: Emacs Is Not Enough

#139

Post by TacticalCoder »

personomas wrote: post #10

TLDR?

Article written by someone who experienced Emacs as being slow and janky. Yet Emacs is one of the fastest software I use. Now I am definitely an Emacs power user: I started using the native-compilation branch as soon as it came out, I don't mind building from the source the latest version available when I see something that picks my interest, I've got about 3 000 lines of custom elisp code, I'll be using other really fast stuff, like burntsushi's amazing ripgrep, directly from Emacs, fzf too, etc.

I don't understand the criticism about Cider: I use it daily.

Emacs 29 with libjansson and native-compilation is plenty fast.

And most of all: apparently every single new version of Emacs not only runs but also compiles faster. And this is coupled with my computers which only gets faster too.

At the moment I'm running Emacs 29 on a AMD 3700X, soon to be replaced with a 7700 or 7700X. That's going to be yet another performance gain.

Most software only get slower and slower with each release (I was already using IntelliJ IDEA back when it was a version 4 and already bloated, since then it's been downhill perf-wise): Emacs, on the contrary, always keeps getting faster.

And the goodies added to Emacs lately are just insane: native-compilation, LSP support, tree-sitter (it's just been included in Emacs and it should bring yet another round of crazy speedups)...

Re: Emacs Is Not Enough

#140

Post by narag »

dsm9000 wrote: post #125
narag wrote: post #107

Earlier quoted context omitted.

I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big file? I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit. I have a similar problem with my current editor of choice. I used to have a "raw"…

I’ve used emacs to open and edit binaries back in the old days - basically one long line. We often needed to install proprietary software in non standard locations so changing the embedded strings within binaries worked great and better than using vi (pre vim era). Always best if the new path had a length less than that of the existing one. In any event I guess the whining about editors will never stop but meanwhile…

Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options.

A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. He goes to some sandwich shop and ask for a beef sandwich and they offer him a beef + hard boiled eggs + lettuce sandwich with mayo, cherry tomatos and oregano, or a beef + cheese + spinachs + nutmeg sandwich or whatever. But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard.

I used Notepad in Windows for simple text, that used to work OK. Then I changed to some free editor created by a guy as a programming exercise with some interesting extras. Now both have the same problem: if I need to open big text files for some reason, it takes forever.

Edit: big as in ~ 1 MB, sometimes smaller.

Post reply on HN