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

Emacs 26 Brings Generators and Threads

nullprogram.com

Post reply on HN
Print view View original

141–150 of 175 posts

Re: Emacs 26 Brings Generators and Threads

#141

Post by floren »

gkya wrote: post #80
floren wrote: post #72

Earlier quoted context omitted.

Acme does this, and I love it, but most people's response to seeing Acme is "what the hell? No syntax highlighting? No autocomplete?" You can also easily create a second "view" into a file with the Zerox command, which is a nice way to look at two parts of a file at once. It's the best thing I've found for managing large numbers of buffers at once, though, and with things like acmego (go fmt + add missing imports on…

> You can also easily create a second "view" into a file with the Zerox command, which is a nice way to look at two parts of a file at once. Emacs has this too. You can look at a buffer from different windows, or clone-indirect-buffer in order to edit multiple parts of it simultaneously.

You're right, it's been so long since I used emacs I forgot it's a thing. Vim does it too, I think, but I only use vim to quickly edit a file.

Re: Emacs 26 Brings Generators and Threads

#142

Post by jackewiehose »

Pimpus wrote: post #136
Diobo1000 wrote: post #117

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 l…

>> 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'm stunned that anyone would actually be OK with "a noticable latency between keypresses" in text-editors. This might be still a thing if the whole desktop is streamed on a slow network but it shuld be completely unacceptable for normal text-editing.

(Unfortunatly I do have that problem sometimes with emacs (on cygwin) with c++-files that are too large. But I won't dismiss cygwin.)

Re: Emacs 26 Brings Generators and Threads

#143

Post by [deleted] »

technofiend wrote: post #139
kqr wrote: post #118

Earlier quoted context omitted.

...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 nam…

[deleted]

Re: Emacs 26 Brings Generators and Threads

#144

Post by KirinDave »

chriswarbo wrote: post #124
KirinDave wrote: post #63

This is cool, but it's too bad folks here don't seem to have kept up with the evolution of iteratees/enumerators and free monadic computations (conduit/pipes/streaming) that other languages have pushed forwards as evolutions of the generator ideal. The net result for common iteration ops is quite nice, and has options for reasonable optimizations in the world of lisp where macros are real.

I thought the natural "successor" to generators was delimited continuations, rather than iteratees or free monads/algebraic effects. Do such streaming concepts map well to eager, imperative code? I've only encountered them in Haskell, where laziness makes stuff like co-induction/recursion trivial.

Certainly for conduit the laziness sort of goes away since you must sink a source and unless you do that to some observable effect the entire result disappears and no work is done at all.

But certainly iteratees as an independent went out of fashion when conduit and pipes came on scene.

Re: Emacs 26 Brings Generators and Threads

#145

Post by cup-of-tea »

gkya wrote: post #88
pilif wrote: 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,…

There is a window manager called stumpwm like that.

Re: Emacs 26 Brings Generators and Threads

#146

Post by samatman »

technofiend wrote: post #139
kqr wrote: post #118

Earlier quoted context omitted.

...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 nam…

Not that it's the /correct/ solution, but Keybase does a good job of providing that shared-directory experience, and the free tier is pretty roomy.

Not affiliated, just getting good use out of it.

Re: Emacs 26 Brings Generators and Threads

#147

Post by gkya »

_0w8t wrote: post #134
kqr wrote: post #115

Earlier quoted context omitted.

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.

I use Emacs since about five years straight, every day, and have used it on and off before, and have quite some Elisp in my .emacs.d, and can say that you're totally wrong on this. Yes the language has problems, the API, having been there since many decades ago, has quirks, but not more than most of the common languages out there, JS, C/C++, Python, Ruby, Perl, what not. What modifies the global state (mark, match, etc.) is well defined, and you can avoid learning it unless you're sending patches or maintaining your own packages. And dealing with programming languages' idiosyncacies is our raison d'etre anyways.

Re: Emacs 26 Brings Generators and Threads

#148

Post by gkya »

jackewiehose wrote: post #97
gkya wrote: post #85

Earlier quoted context omitted.

It's C-u in Emacs lingo; it pops the mark ring. Some actions like C- , M- push the position of the point to the mark ring before moving it, and when you pop the mark ring, you jump to the position that was pushed most recently.

> Some actions [...] push the position of the point to the mark ring before moving it Notably C-s and C-r (incremental search forward/backward). That in combination with C-space is the way to navigate in emacs like a pro :-) (btw: its C-u C-space. C-u space inserts 4 whitespace)

TIL! I didn't know search pushed marks, thanks!

Re: Emacs 26 Brings Generators and Threads

#149

Post by gkya »

cup-of-tea wrote: post #145
gkya wrote: post #88

Earlier quoted context omitted.

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,…

There is a window manager called stumpwm like that.

Well that's just a fraction of what I was talking about. StumpWM is nice, but it's the window manager. But imagine an environment where, say in the web browser you could hit C-h k, find what function is bound to the key that bookmarks the current tab, and advice that function to make a backup of the bookmarks database. And that such mechanism being built in to the OS' application programming libraries, so that writing a GUI app becomes essentially reminiscent of writing an Emacs major mode. Imagine all apps on your desktop had hooks where you could attach code to be run on certain events.

Re: Emacs 26 Brings Generators and Threads

#150

Post by kqr »

varjag wrote: post #111
kamaal wrote: post #75

Earlier quoted context omitted.

Java by many definitions is a bit like assembly language of our current times. You will end up stitching highly verbose pieces of code. Which is why Java IDEs have specific features to emit get/set functions etc. Plus you will have to access a method hiding 5 class layers below. You will need IDEs designed to do this sort of work really well. Emacs and Vi have been designed to largely play with Text, plus I think wit…

Wouldn't call assembly programming "highly verbose". If anything it's opposite - very little boilerplate, if at all.

Do we have different ideas of what boilerplate is? Almost everything in assembly is boilerplate because there are no advanced, built in features. (Sure, modern x86 assembly is a complex language with many advanced builtins but they are generally meant to express solutions in the x86 domain, not the business domain.)
Post reply on HN