Live data from Hacker News

The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

emacsconf.org

101–110 of 162 posts

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#101

Direct Link to "Lem" the Common Lisp based "Emacs" discussed in the talk. https://lem-project.github.io/ https://github.com/lem-project/lem

Is this based on Hemlock, or was it written from scratch?

I really, really want a graphical emacs. By that I mean, I want an emacs with graphics, not an emacs in windows. I want to easily be able to draw stuff.

I ran into this the other day, I like to dabble in emacs, and I had a list of results I wanted to make a quick chart. I ended up dumping it out in a simple CSV, and copy/pasting that into a spreadsheet, and hitting "chart".

Would have been nice to go (line-chart my-list) and have a window pop up with reasonable defaults. And be able to print it to a PDF.

emacs has some SVG support, but I guess its maintainer whim whether you get it or not, I wasn't able to easily get it working on my Mac. That could be a start. But something "nicer" would be, you know, "nice".

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#102

I really wish that Deuce [1] [2] got more attention as a source for ideas for Emacs alternatives. It sounds incredibly cool. [1] https://web.archive.org/web/20221002093520/https://groups.go... [2] https://web.archive.org/web/20210407151341/https://discuss.a...

Could you do a separate HN post for this, so it'll come up in searches?

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#103
post #87

Earlier quoted context omitted.

Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?" > but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha. It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing…

> It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there? One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before…

> Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode.

I agree it is irrelevant to your use of VSCode. The comparison, though, was for VSCode with Emacs. Not "VSCode with Emacs for samatman's needs".

> For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

It's illogical to say that Emacs has to be better than all those tools to use them. We're not enforcing a dichotomy. You can use both. You can use Gmail's web interface and Emacs mailing abilities. All you need is for one to have some capability that the other doesn't, as opposed to having every capability the other has.

Next: A large part of my point in this thread is that comparing VSCode to Emacs as a whole is in itself silly - one is a fairly specialized tool and the other is fairly generic. If you want to reduce the discussion to SW development, then fine. But people (not you) blanket saying VSCode is better (or worse) than Emacs is like saying Excel is better than Linux. I don't have any desire to convince someone to leave VSCode for Emacs. What for?

Next: Implicit in your comments is the notion that stuff like reading mails is an "extra" in Emacs. It's artificially categorizing. Reading email in Emacs is not an addon - it's part of Emacs's capabilities (although you may get better experiences than the default with addons). If reading/writing emails is considered "extras", then keep in mind so are things like syntax highlighting, debugging, compiling, etc. Emacs is a text editor, and all those features are addons - at the same level as reading mails.

As a VSCode user, some of these addons mean more to you, and you don't care about the others, but understand that lots of people do care about them. So many people out there use Emacs only for org mode and magit.

> This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

Context matters. Understand that my list was in response to "What can Emacs do that VS Code can't?" If someone asked "What can Perl do that awk can't?" then mentioning CPAN and Web servers is totally appropriate. It's pointing out that if you learn Perl, it may benefit you far more than awk ever could. Whether it would or not depends on your goals, of course.

> There's such a thing as a like-for-like comparison.

Agreed, but it helps if the scope is stated clearly. More often it's "Why do you use Emacs when VSCode exists?" And then of course, I'll list all the things I do in Emacs that VSCode doesn't provide. If someone asks "Why do you shop at Walmart when you can shop at Whole Foods?" it's not a problem to respond with "Because I can buy electronics at Walmart." You wouldn't jump on him and say "Hey, you're not doing a like-for-like comparison!"

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#104

Direct Link to "Lem" the Common Lisp based "Emacs" discussed in the talk. https://lem-project.github.io/ https://github.com/lem-project/lem

Is this based on Hemlock, or was it written from scratch? I really, really want a graphical emacs. By that I mean, I want an emacs with graphics, not an emacs in windows. I want to easily be able to draw stuff. I ran into this the other day, I like to dabble in emacs, and I had a list of results I wanted to make a quick chart. I ended up dumping it out in a simple CSV, and copy/pasting that into a spreadsheet, and hi…

image-mode can render real images, so there should be a way to embed charts of some kind.

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#105
post #18

Two projects that may be of interest, related to this topic: - Rune ( https://github.com/CeleritasCelery/rune ) - A re-implementation of Emacs but in Rust (like Remacs, but actively developed) - Pimacs ( https://github.com/federicotdn/pimacs ) - Same, but using Go (created by me, but developed in a very slow pace)

Rune, the language, came before. So we have now 2 rune projects, the language and the emacs vm

And Runestone, the open source editor framework for iOS [1]. It is also a text editor on the app store that uses the framework.

[1] https://github.com/simonbs/Runestone

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#106

Earlier quoted context omitted.

I can understand wanting to restrict use of something a person created using a restrictive licence. I can’t understand being sad about someone else not restricting what they created. To me it looks like someone being sad after seeing someone else giving out free ice cream, even though the person being sad didn’t contribute to making the ice cream.

Calling the GPL a restrictive license is a bit like saying you can't cut down the trees in a public park and sell the wood is restrictive.

For those confused by the dangling modifier, he means the combined act of cutting the trees and selling the wood is restrictive. Also, a terrible analogy since trees are an exhaustible resource within a meaningful time range.

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#107

Earlier quoted context omitted.

> It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there? One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before…

The reason some people, including myself, like to do things like email or irc or whatever inside emacs is because we got hooked on the powerful text and buffer management facilities in emacs, and want them everywhere, and consistently. All these things we're talking include editors in their separate applications. They just use the default OS editor widget using CUA bindings or whatever. Pulling them into emacs turns…

Just that something is largely written in Lisp, doesn't make it a "Lisp Machine", nor a clone of it.

> but compromised and/or modified for the environments we have now.

I would think that GNU Emacs is also compromised by its own design decisions, starting in 1984, when RMS rewrote Gosling Emacs.

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#108
post #55

Earlier quoted context omitted.

And in 10 years, there will be a comment saying "XYZ is why VSCode is not as relevant as it once was." And Emacs will still be around.

And VSCode will still be around.

Atom is not around. Not 100 percent sure that VSCode will be around. (But I also don’t think that this should hold anyone back who finds VSCode to fit their needs best. There’ll be something else that will take its place.)

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#109
post #37
post #33

Earlier quoted context omitted.

The original emacs was a commercial product?

It wasn't. What he probably meant, that GNU Emacs (1984-...) was based on the code of another Emacs implementation, Gosling Emacs, which also had a commercial version. The original EMACS was developed at MIT, 1976, by Guy L. Steele Jr. and David Moon.

[deleted]

Re: The Emacsen family, the design of an Emacs and the importance of Lisp (2023)

#110

Earlier quoted context omitted.

Sadly not licensed under the GPL.

I can understand wanting to restrict use of something a person created using a restrictive licence. I can’t understand being sad about someone else not restricting what they created. To me it looks like someone being sad after seeing someone else giving out free ice cream, even though the person being sad didn’t contribute to making the ice cream.

I can't understand being sad about someone not restricting what they created

I can. The guy giving away the ice cream is destroying the market. You can't compete against free. If programmers would stop surrendering their labor, personal data resellers like Google and Facebook wouldn't be our primary means of making a comfortable living. Say what you will about Microsoft's monopoly in the 90s. At least they took your money with your eyes open.

The irony of course is free software zealots are pissed at the free ice cream guy for completely different, and I agree with you, utterly stupid reasons.

Post reply on HN