Live data from Hacker News

Emacs 26 Brings Generators and Threads

nullprogram.com

131–140 of 175 posts

Re: Emacs 26 Brings Generators and Threads

#131
post #121
post #58

Earlier quoted context omitted.

VS Code can be extended in Typescript: https://code.visualstudio.com/docs/extensions/overview#_writ... Philosophically Lisp may be superior, but I'm not sure it's so clear cut in real life. Regarding most of the features you present, a good chunk of them aren't editing features and another chunk are related to running in a limited environment (the terminal). So a big part of them aren't as strong selling points as yo…

One of the frequently overlooked benefits of Lisp is that the culture around Lisp actively promotes software that is /supposed/ to be extended by its user and sort of grow into the user, rather than the user growing into it. There is also a huge difference between "building an extension" and "extending the actual code that is the running process." In Emacs, one can redefine one of its core functions at the push of a…

I've found that I prefer a very nice, coherent design by someone who spent a lot of time thinking about the problem in a holistic manner, than tinkering with stuff. And I do/did tinker a lot.

IMO that's the best design: a solid, coherent design with clear extension points.

Of course, I'm the Anti-Emacs by saying this :)

Re: Emacs 26 Brings Generators and Threads

#132
post #110

Earlier quoted context omitted.

Once I had to work remotely over 2g cell phone. Using remote terminal was too painful due to huge latencies approaching 1s. What worked surprisingly well was to work on a local copy of files in a local editor and then to run command remotely I would prefix them with a script that I aliased like rc. The script rsyncs first the tree to the remote host and then run the command there. These days for much simpler setup I…

For that use case, if you have Emacs locally, you could use TRAMP - which basically works the way your script does. It allows you to transparently access files, directory structures, or even run shells on remote machines. It supports many protocols; the typical way it works, is it starts an ssh connection in the background, and uses the shell to ferry the file you want to edit to your local machine, and then transpar…

TRAMP does not work like that. First it does not have a whole directory tree, rather it just caches the opened buffers so things like grep etc. must run remotely which sucks on a high latency link or could be much slower if the server is not very powerful VM. Second at least like 5 years ago when the last time I played with TAMP it worked really badly on an unreliable connections or when the laptop switches to different wifi network. If ssh connection hangs, the whole GUI often hangs and sometimes after reconnecting I had to throw away resent edits and reopen the buffer. It could be that nowadays things are better, but for me nothing beats my lsyncd + explicit remote command script. Even file completion works with trivial efforts. As paths in my local tree copy matches the remote paths, completing by files just works, and it is trivial to call completion scripts for remote command from the completion script for rc.

Re: Emacs 26 Brings Generators and Threads

#133
post #95
post #51

Earlier quoted context omitted.

Emacs is compared to vim because both can be run in a terminal on a remote machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent chance I’d switch away from vim if I ever had a job where I could edit code locally.

Emacs has TRAMP, which allows transparent access to files on remote systems using a variety of protocols (but mostly ssh/sftp).

But the coolest thing by far is that you can now go the reverse direction. If you have a ssh tunnel you can run emacsclient --tramp $file on the remote system and it will pop up on your local Emacs window.

Re: Emacs 26 Brings Generators and Threads

#134
post #115
post #102

Earlier quoted context omitted.

Emacs is not optimized for customizations. It allows to customize everything, but the efforts required often becomes a programming project on its own. 20 years ago I spent eventually months to make the buffers switch the way I liked. Yes, i made it work precisely the way I wanted, but I suspect it would be easier to implement that feature in a native code as a patch for an editor where a configuration is just an ini…

Why would writing a patch for any other editor be easier (or less hard) than writing a patch for Emacs?

Emacs API is just insane with too many special cases or with other packages unexpectedly affecting semantics. Even after stepping in debugger I often could not be sure if the things worked like I thought they should work with too much unstructured global state that is randomly poked.

Re: Emacs 26 Brings Generators and Threads

#135
post #21

Here's what grinds my gears: That the cursor follows the visible buffer. It would be nice to be able to scroll to another part of a file and then just start typing and be back where I was ... I mean I could understand if this was an efficiency thing to do with scaling to large files due to a kind of a tiling memory model or something, but emacs doesn't even do that! It's not a huge deal I've learned to get used to us…

Now I kind of want to try my hand at implementing this. I imagine an implementation would add a buffer-local variable holding the position of the point as of the last non-scrolling operation. This would be updated in post-command-hook, but only if the last command was not a scrolling command (which would probably have to be defined as a list of "blacklisted" commands that shouldn't change the point). This hook would…

I've seen an implementation, but don't remember its name or how to find it again.

If I remember, I'll send an email to the address on your resumue.

Re: Emacs 26 Brings Generators and Threads

#136

In all honesty, the main selling point of Emacs for me isn't just how configurable it is but also how performant it is in different environments. Since VSCode uses Electron editing feels sluggish, high ram and cpu usage is expected, and there's a noticable latency between keypresses. While these may seem like trivial issues, they actually negatively impact my typing experience to a high degree. I'm currently using th…

> While these may seem like trivial issues, they actually negatively impact my typing experience to a high degree.

I don't think these are trivial issues at all. I do the majority of my computing work in a text editor so it's important to me that it's as performant as possible. Imagine if, in real life, there was a slight lag every time you sent a "command" (e.g. pick up coffee). It would drive you crazy. And yet a lot of developers think that lag is acceptable in software. (I say "developers" because a lot of non-developers I meet complain about software being frustrating to use, even if they may not consciously notice it is laggy.)

People think I'm joking when I say this, but I'm so attuned to Emacs, especially when I'm in a flow state, that I can actually feel when the garbage collector kicks in. It totally throws me off. I have a bunch of optimizations set up, like running GC whenever I tab out of Emacs or am idle for 5 seconds, but sometimes I can still feel it. I hope Emacs makes some progress in this area -- I hear there's a Rust rewrite in the works :)

> If VSCode or any other text editor managed to provide a fast yet highly configurable editing experience without draining my laptop battery instantly

This is huge for me. I basically work by grabbing my laptop and sitting, standing, or laying wherever I feel like. I can't stand the idea of having an "office". So I'm acutely aware of when an application is running down my battery. Emacs is awesome in this regard because it has no noticeable energy usage, which boggles the mind when I think about how powerful it is as software. I honestly see no reason whatsoever to use anything else.

Re: Emacs 26 Brings Generators and Threads

#137
post #88
post #25

Seeing generators and threads being mentioned in the release announcement of a text editor feels a bit... strange. Then again, Emacs is closer to a LISP toolkit for building text editors than it is a text editor, so I guess it's not so strange after all.

Emacs is an application platform, just like how the browsers are today. It has a nice way for making UIs: it's all text, parts interactive, and you can bind keys, make hooks and thus create decent, customisable applications in it. Add to that the possibility to update code on the go and advices, and you have a very nice place to make yours completely. I wish we had a popular OS where the main UI toolkit was similar,…

The thing is such an OS would never be popular, because the vast majority of users never will be programers (again).

Re: Emacs 26 Brings Generators and Threads

#138
post #133
post #95

Earlier quoted context omitted.

Emacs has TRAMP, which allows transparent access to files on remote systems using a variety of protocols (but mostly ssh/sftp).

But the coolest thing by far is that you can now go the reverse direction. If you have a ssh tunnel you can run emacsclient --tramp $file on the remote system and it will pop up on your local Emacs window.

Consider my mind blown! :)

Re: Emacs 26 Brings Generators and Threads

#139
post #118
post #95

Earlier quoted context omitted.

Emacs has TRAMP, which allows transparent access to files on remote systems using a variety of protocols (but mostly ssh/sftp).

...and if you haven't given TRAMP an honest shot, you definitely should. I took the leap not too long ago, and it is absolutely amazing. Whenever I can't access a host using TRAMP (does happen, but very rarely), I put off whatever task I have to do on that host for a very long time. The fact that TRAMP lets you open files on remote systems in and of itself is fairly mundane. What makes it really cool is that it works…

It's this sort of thing that when I first saw it on Apollo's Aegis and again later on Plan 9 it was so obviously useful I figured it would just be everywhere in no time. At then Sun touted "The Network Is The Computer (TM)" and I was like here it comes! But it hasn't quite panned out that way. Considering the number of viruses and ransomware perhaps that's a good thing but it would be cool as hell if I had shared name spaces with my wife, mother, sister, etc rather than the artificial constraint of mapping into Facebook or Google Photos (for example) to share a photo album.

Re: Emacs 26 Brings Generators and Threads

#140
post #107

Earlier quoted context omitted.

The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs th…

You have a source on Gosling trying to get people not to use Emacs (not calling you out; just genuinely curious)?

From ten years ago: https://www.computerworld.com.au/article/207799/don_t_use_em...
Post reply on HN