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

Emacs: The Editor for the Next Forty Years [video]

media.emacsconf.org

Post reply on HN
Print view View original

241–250 of 272 posts

Re: Emacs: The Editor for the Next Forty Years [video]

#241

Post by tendencydriven »

saagarjha wrote: post #182
tendencydriven wrote: post #119

Earlier quoted context omitted.

Is this due to some notion of it being slow? VSCode is fast, native-fast. With a fantastic plugin ecosystem I've been a full-time Vim user for the past decade (now NeoVim) but I've seriously considered switching, VSCode with vim mode turned on is truly fantastic, it's just not portable enough for my needs.

> VSCode is fast, native-fast. Not when starting up…

I'd consider startup time the least important metric for measuring speed of a text editor - as long as it's not ridiculous.

Important speed metrics for me are: Switching between buffers

Scrolling up/down a page (vim used to be terrible for me before i switched terminals to Kitty)

Substitutions

Search

Re: Emacs: The Editor for the Next Forty Years [video]

#242

Post by microcolonel »

yyoncho wrote: post #233
microcolonel wrote: post #173

Earlier quoted context omitted.

My main gripe with elisp is the default to dynamic binding, which is in most systems almost never what you want. In Emacs, the dynamic bindings are used for more productive reasons than in generalized programs, but they should still be a conscious choice. When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutabl…

Use dash/s/f/ . seq is fine too but dash is pretty much clojure port.

Dash is a very cool library! Though it only really does seq. The Clojure persistent vectors, hash maps, and hash sets are all very powerful. CHAMP is often an improvement on HAMT.

I think the text buffer as a persistent vector of extended grapheme clusters is an interesting thought.

Re: Emacs: The Editor for the Next Forty Years [video]

#243

Post by kamaal »

theCodeStig wrote: post #189
omarhaneef wrote: post #32

I've noticed that (almost?) any talk about any editor in the last few years: emacs, vim, sublime, atom etc always brings up how good VS Code is. It's a huge endorsement of VS code.

I'm a diehard Emacs (+evil) user, and I tried VS Code for a few months. It really is quite good. Here are the few detractors that brought me back to Emacs as my primary editor. Lousy macro support from the Vim emulator. Evil is still leaps-and-bounds above anything else (possibly Vim itself). Flexibility of split windows. I like to view multiple files side-by-side. From my experience, Emacs and Vim have the best supp…

VS Code also doesn't support Macros in the same way Emacs and vi do.

In fact its not even remotely close.

Re: Emacs: The Editor for the Next Forty Years [video]

#244

Post by JustFinishedBSG »

dragonsh wrote: post #223
pjmlp wrote: post #214

Earlier quoted context omitted.

It doesn't do any kind of graphical tooling. IDEs also don't waste CPU cycles displaying HTML. C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

In spite of all your arguments even today most important software powering modern computing are written in C, this speaks volume about its simplicity. I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend year…

> this speaks volume about its simplicity.

No, it's just an indication of how many existing C code already exists that you have to conform to.

Re: Emacs: The Editor for the Next Forty Years [video]

#245

Post by showdeadplease »

sooheon wrote: post #227
ibrahima wrote: post #202

Earlier quoted context omitted.

https://github.com/Malabarba/paradox lets you install packages async, by the way.

That looks like an interactive ui--I can't declare use-package forms in my init.el, and have the initial install and any updates be async and concurrent.

https://github.com/jwiegley/emacs-async#enable-asynchronous-...

Re: Emacs: The Editor for the Next Forty Years [video]

#246

Post by showdeadplease »

nonbirithm wrote: post #140

If Emacs is to be "the" editor for the next forty years, I really hope it can better combat random hangs. As someone who uses Emacs as a daily driver and loves it to death for its extensibility paradigm it's painful when it maxes out the CPU, I have to restart and have no idea what it could have been. But then again scripting languages don't really have these interruption features by design. I'm developing something…

    pkill -SIGUSR2 emacs
That will cause Emacs to interrupt whatever it's doing and display a backtrace.

Re: Emacs: The Editor for the Next Forty Years [video]

#247

Post by rusk »

pjmlp wrote: post #240
rusk wrote: post #237

Earlier quoted context omitted.

Sounds like fairly specialised tools for that stuff. I typically use a document editor, to you know, write documents ...

Sorry I thought we were talking about development tools here.

Text editors

Re: Emacs: The Editor for the Next Forty Years [video]

#248

Post by olejorgenb »

jonnycomputer wrote: post #111
billfruit wrote: post #41

Earlier quoted context omitted.

OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.

Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.: PyCharm: Yes VS Code: Yes Eclipse: Yes

Vs code can't open two windows properly though..

Re: Emacs: The Editor for the Next Forty Years [video]

#249

Post by balnaphone »

simtel20 wrote: post #37
commandlinefan wrote: post #11

Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?

I don't think it's that hard to do C-a, C-k then C-y as many times as you want. If you want to bind it to a key you could record that as a macro for e.g., but I find that sequence is simple enough that I don't think hard about it

For the equivalent of vi's 'yyp', you must do C-a C-k C-k C-y C-y, or more likely 'C-akkyy'.

The first C-k only kills to end-of-line, to capture the line ending (\n) you need another C-k. The first C-y only puts back what you killed, so that needs to be doubled also to actually change the buffer in the desired way.

Subsequent C-y commands will add more copies of the line, but I find that 99% of the time it's only a single duplicate of a line that I want.

C-S-Backspace C-yy does the same thing, btw.

Re: Emacs: The Editor for the Next Forty Years [video]

#250

Post by pjmlp »

rusk wrote: post #247
pjmlp wrote: post #240

Earlier quoted context omitted.

Sorry I thought we were talking about development tools here.

Text editors

And how they lack features to match what IDEs are capable of.

Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion.

https://thenewstack.io/a-conversation-with-the-creators-behi...

Post reply on HN