Live data from Hacker News

Emacs 26 Brings Generators and Threads

nullprogram.com

101–110 of 175 posts

Re: Emacs 26 Brings Generators and Threads

#101

Does anyone happen to know why e-lisp iterators stop on a magic `iter-end-of-sequence` instead of on `nil`? That doesn't seem Lispy.

A likely reason is that it makes it possible to iterate through a list like `'((1 2) () (a b c))`. If you have to do in-band signaling, make it something unique and obscure.

Re: Emacs 26 Brings Generators and Threads

#102
post #84

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…

Emacs is in no race with text editors. If Emacs was a pack of a dozen of eggs, text editing would be that one egg on the corner with the fragile shell. Mr. Java can beg all he wants, but one thing people don't get is that Emacs is not a text editor. It has one, yes, but it's a program where the user can interactively manipulate data presented in buffers via Lisp, and keys bound to some Lisp. Thus, it is in a league o…

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 file.

Re: Emacs 26 Brings Generators and Threads

#103
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…

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…

So those GNU Emacs screenshots with embedded graphics are fakes?

Like: https://www.gnu.org/software/emms/screenshots.html

Re: Emacs 26 Brings Generators and Threads

#104

Earlier quoted context omitted.

To see why this isn't necessarily the case, add to your list all the text editors launched between 1992 and 2008 that are no longer around ("being around" defined as being able to install and run on whatever OS you're using on your main computer with no special effort).

Exactly. The post above yours is simply an illustration of survivorship bias.

Also, the cited survivors have certain characteristics, like being small items with no "ecosystem" baggage and few dependencies in general.

Re: Emacs 26 Brings Generators and Threads

#105
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…

There are scroll-other-window and scroll-other-window-down which are usually bound to M-PgUp and M-PgDown. You can use these to scroll the other window (perhaps another buffer) while the cursor stays in the current one at the same position.

Re: Emacs 26 Brings Generators and Threads

#106
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…

There are scroll-other-window and scroll-other-window-down which are usually bound to M-PgUp and M-PgDown. You can use these to scroll the other window (perhaps another buffer) while the cursor stays in the current one at the same position.

Yes I’ve been doing this as well

Re: Emacs 26 Brings Generators and Threads

#107
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…

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)?

Re: Emacs 26 Brings Generators and Threads

#108
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…

I use a bit of code that binds a key combo to "go back to where I was last editing", which lets me move around the file, look for something, copy it, and them go back to where I was last actually working in the file.

Re: Emacs 26 Brings Generators and Threads

#109
post #94

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…

Regarding Emacs vs. VS Code, it is kind of funny that Emacs was once the canonical big, fat, bloated editor, but it did not grow much bigger since then. So today, Emacs is kind of lightweight: On my work computer, VS Code will easily gobble up half a gigabyte of RAM with only a handful of files open, while Emacs with dozens of buffers consistently stays below 100 MB. Compared to nvi or mg, GNU Emacs is still pretty b…

A few years ago I was astonished to see Gnome's gedit having bigger memory footprint than very tricked out Emacs.

Re: Emacs 26 Brings Generators and Threads

#110
post #51

Earlier quoted context omitted.

For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom. One major reason for me to use Emacs and not newer software is that it i…

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.

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 use lsyncd to sync file trees and then the rc command just runs the command over ssh.
Post reply on HN