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

121–130 of 175 posts

Re: Emacs 26 Brings Generators and Threads

#121

Post by kqr »

oblio wrote: post #58
zeveb wrote: post #45

Earlier quoted context omitted.

> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs. Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs. Emacs…

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 button, and suddenly all new calls will call your version of the function. If your redefined function has a breakpoint in it, you'll be able to debug-step into the core of the editor as it is running.

Not sure how well TypeScript in VS Code works in that regard.

Re: Emacs 26 Brings Generators and Threads

#122

Post by kazinator »

kqr wrote: post #119
kazinator wrote: post #103

Earlier quoted context omitted.

So those GNU Emacs screenshots with embedded graphics are fakes? Like: https://www.gnu.org/software/emms/screenshots.html

Not fake. My report authoring process includes a live updating PDF preview in an Emacs sidebar. However, this graphics stuff is still bolted onto a core engine that treats everything as a text terminal.

Won't it fly away if you don't bolt it to something?

Re: Emacs 26 Brings Generators and Threads

#123

Post by kqr »

pjmlp wrote: post #28
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 OS written in Lisp, with a text editor as sample application. :)

Not only that, but also a kickass calculator! And a file manager.

Re: Emacs 26 Brings Generators and Threads

#124

Post by chriswarbo »

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.

Re: Emacs 26 Brings Generators and Threads

#125

Post by BeetleB »

gkya wrote: post #84
rudolfwinestock wrote: post #32

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…

>I have not used one program til this day that is easier and more optimised for user customisation than Emacs

The Leo editor comes close. Unfortunately, the documentation is a bit lacking. As is the UI - almost as bad as Emac's :-). The mailing list and developers are, in my experience, very helpful and in the short time I used it, they quickly created functions/commands for me when I asked "Hey, I can do it in Emacs - how can I do it in Leo?"

Re: Emacs 26 Brings Generators and Threads

#126

Post by hollerith »

hydandata wrote: post #54
rusk wrote: 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…

Not your desired behavior precisely, but Emacs does support recursive edits https://www.emacswiki.org/emacs/RecursiveEditPreservingWindo...

Although I've been using Emacs daily since 1991, I can't imagine how the code behind your link helps or how starting a recursive editing session helps with the problem you are replying to.

Re: Emacs 26 Brings Generators and Threads

#127

Post by anamoulous »

kiaulen wrote: post #71
anamoulous wrote: post #47

Earlier quoted context omitted.

vscode can only be customized by an extension. There's a bunch of one off plugins you have to install to get little bits of functionality that you can get by pasting 15 lines of elisp from the emacs wiki. If no one has built that extension yet, you have to learn to build one yourself. You could always create private "personal" extension and keep it local, but that workflow is tedious. I'm not saying vscode is less ex…

I'd argue this is a feature more than a bug. I haven't done much with VSC, but I have done a lot with both atom and emacs (via spacemacs). How do you find out even the name of what you are looking for to find it on the wiki? Is that snippet of elisp tested (or even testable?) What does it do exactly? Is it a passive effect, or something you have to execute a command to run? In atom, you can find packages on the websi…

> Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.

Sure, and Emacs has this with MELPA (And Atom with... whatever they have). It's great paradigm and all editors should have it.

But I'm not talking about thousands of lines of copied elisp. I'm thinking about molding your editor to fit your needs. Here's an example:

We use hosted Gitlab at work. I like to highlight a line in my editor, call a command in the editor and get a URL for that line in that file in that branch on our internally hosted Gitlab server (with a custom path segment prefix). This is literally maybe ~40 lines lines of very compact elisp in a global configuration file. It would probably be less in JS because I'm better at JS than elisp. It's very specific to my circumstances and doesn't really need to be generalized to anyone else.

There are ~5 different plugins in the marketplace that purport to do this, but none of them fit my use case. Which is fine, I can do this myself...

However to do this vscode I have to create an extension, edit the package.json to register the command and few other things (this is tedious, believe me), re-read/remember the plugin API, re-read/remember how to build vsix files for production, install that plugin with the command line tools, reload vscode.

If I need to make a change, do it all again. But there is no reason that the Emacs behavior couldn't be included in vscode. And maybe some day it will. But the idea that not having it and claiming that is a _feature_ or (as others have done) claim that emacs is losing to vscode in configurability misses the multitude of use cases that emacs users have benefited from for decades.

As far as testing and code quality goes, I can't really argue with that but neither can vscode users? Do you know what all your plugins are doing in the background? All of these centralized plugin repositories are significant attack vectors. Which language do you think the first big own will be written in?

Re: Emacs 26 Brings Generators and Threads

#128

Post by BeetleB »

oblio wrote: post #50
jonathanstrange wrote: post #34

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…

For some perspective: BBEdit - launched in 1992 (26 years ago), still around. Notepad++ - launched in 2003 (15 years ago), still around. Textmate - launched in 2004 (14 years ago), still around. Sublime - launched in 2008 (10 years ago), still around. Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even…

Original comment:

>One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform.

You're ignoring the first half of the sentence:

BBEdit - not on Linux

Notepad++ - not cross platform

Textmate - not cross platform

Sublime - cross platform - but can I see the source? If not, I have little faith it will be around in 20 years.

My (heavily customized) Emacs environment on Windows gives me the same experience as in Linux. No warts at all.

Re: Emacs 26 Brings Generators and Threads

#129

Post by oblio »

fredsanford wrote: post #112
oblio wrote: post #89

Earlier quoted context omitted.

I'd be interested to hear about former mainstream editors from that time that are gone. Especially cross platform and Open Source ones :)

Brief, Multiedit, Codewright, Semware, Slickedit and Epsilon used to keep the lights on at many programming/tech magazines. You don't hear much about them anymore... Clark Maurer still updates Slickedit at least annually though.

You made me curious as I'd never heard of any of these editors... (except for Slickedit, I think)

A bit of digging around:

Brief seems completely dead, was killed off by Borland.

Multiedit seems operational: http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product.

Semware is still technically "alive": http://www.semware.com/ It was last updated in 2005, so there's that :)

Slickedit: is definitely operational: https://www.slickedit.com/ I have no idea why you're counting it as dead?

Epsilon: seems operational http://www.lugaru.com/ They even had a release in 2018.

To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience.

Now, if a tool for developers reaches the mainstream, it super likely to stick.

I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...

Re: Emacs 26 Brings Generators and Threads

#130

Post by oblio »

BeetleB wrote: post #128
oblio wrote: post #50

Earlier quoted context omitted.

For some perspective: BBEdit - launched in 1992 (26 years ago), still around. Notepad++ - launched in 2003 (15 years ago), still around. Textmate - launched in 2004 (14 years ago), still around. Sublime - launched in 2008 (10 years ago), still around. Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even…

Original comment: >One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. You're ignoring the first half of the sentence: BBEdit - not on Linux Notepad++ - not cross platform Textmate - not cross platform Sublime - cross platform - but can I see the source? If not, I have…

I wasn't ignoring it, if you notice my final argument is for cross platform and FOSS stuff: Atom, Visual Studio Code.

There's even good native editors if you want that, Scite comes to mind.

Anyway, my point was just don't dismiss out of hand, don't belittle other people. Of course, if you're happy with Emacs, continue to be happy.

Oh, and the irony of this is me railing against Emacs/Vim when I'm also a Vim user and have been for at least 10 years. I say also because I've been using VS Code quite a bit lately.

Post reply on HN