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

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

emacsconf.org

Post reply on HN
Print view View original

121–130 of 162 posts

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

#121

Post by BeetleB »

tshirttime wrote: post #112
BeetleB wrote: post #103

Earlier quoted context omitted.

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

While I, an inveterate emacs user, largely agree, you're not going to change any minds when the debate topic is "Vim and emacs both lost to vscode in the editor wars." To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing. If emails is considered extra, then so are things like syntax highlighting, debugging, compiling, etc…

> you're not going to change any minds

I am repeatedly accused of this. Consider what I have written:

> then by all means - VSCode is the superior tool.

> No one's arguing using only one tool.

> As I write this, I have both VSCode and Emacs windows open.

> We're not enforcing a dichotomy. You can use both.

> I don't have any desire to convince someone to leave VSCode for Emacs. What for?

I certainly won't change any minds, because I'm not trying to.

> To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.

While I can agree they are the majority, this is a strange take. Do HN readers come to the site to reinforce their problematic views?

And do you think Emacs submissions often hit the front page because those upvoting view Emacs as "just a programmer's editor"? Quite a lot of these top voted submissions (the majority?) are not about programming.

> Yeah no. The first is email, the latter three are directly relevant to program editing.

You are welcome to whatever hierarchy you wish. From an objective architectural standpoint, all are extras on equal footing. I suppose perhaps some of these may have extended support in the C code, but otherwise they are just elisp libraries on top of the core.

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

#122

Post by [deleted] »

stolen_biscuit wrote: post #83
GrumpySloth wrote: post #69

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.

[deleted]

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

#123

Post by roenxi »

GrumpySloth wrote: post #69
globular-toast wrote: post #43

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.

> ...even though the person being sad didn’t contribute to making the ice cream.

But the issue of non-GPL software is the person on the receiving end might want to contribute, be technically able to contribute and indeed need to contribute to be able to keep using the software ... but then be blocked for legal reasons. The GPL doesn't care if you sell software or give it away or whatever, it is all about protecting freedom over time after the initial installation has happened.

The thing that makes the ice cream analogy ok is that the ice cream is literally synthesised into your body and comes under your complete control. If the ice-cream seller retained any sort of control over the ice cream after you'd ingested it that would be a serious problem! Both technically and morally. The GPL is aligning what happens in software to the analogy.

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

#124

Post by GrumpySloth »

roenxi wrote: post #123
GrumpySloth wrote: post #69

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.

> ...even though the person being sad didn’t contribute to making the ice cream. But the issue of non-GPL software is the person on the receiving end might want to contribute, be technically able to contribute and indeed need to contribute to be able to keep using the software ... but then be blocked for legal reasons. The GPL doesn't care if you sell software or give it away or whatever, it is all about protecting f…

The poster I replied to complained about someone choosing MIT over GPL, not a proprietary licence over GPL. Noone is blocked from contributing for legal reasons. Quite the opposite.

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

#125

Post by [deleted] »

GrumpySloth wrote: post #124
roenxi wrote: post #123

Earlier quoted context omitted.

> ...even though the person being sad didn’t contribute to making the ice cream. But the issue of non-GPL software is the person on the receiving end might want to contribute, be technically able to contribute and indeed need to contribute to be able to keep using the software ... but then be blocked for legal reasons. The GPL doesn't care if you sell software or give it away or whatever, it is all about protecting f…

The poster I replied to complained about someone choosing MIT over GPL, not a proprietary licence over GPL. Noone is blocked from contributing for legal reasons. Quite the opposite.

[deleted]

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

#126

Post by roenxi »

GrumpySloth wrote: post #124
roenxi wrote: post #123

Earlier quoted context omitted.

> ...even though the person being sad didn’t contribute to making the ice cream. But the issue of non-GPL software is the person on the receiving end might want to contribute, be technically able to contribute and indeed need to contribute to be able to keep using the software ... but then be blocked for legal reasons. The GPL doesn't care if you sell software or give it away or whatever, it is all about protecting f…

The poster I replied to complained about someone choosing MIT over GPL, not a proprietary licence over GPL. Noone is blocked from contributing for legal reasons. Quite the opposite.

Riddle me this then, why use MIT over GPL?

The point of the MIT license is to make it easier to link it to proprietary software. It is setting up a situation where users will not be free. In and of itself it isn't a bad license; it just doesn't protect freedom and it can be used in ways that block people from contributing. By design.

If you expect people to treat MIT licensed software as GPL licensed software, then they should be licensing it under the GPL. That they aren't implies that the intent is different.

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

#127

Post by tshirttime »

roenxi wrote: post #126
GrumpySloth wrote: post #124

Earlier quoted context omitted.

The poster I replied to complained about someone choosing MIT over GPL, not a proprietary licence over GPL. Noone is blocked from contributing for legal reasons. Quite the opposite.

Riddle me this then, why use MIT over GPL? The point of the MIT license is to make it easier to link it to proprietary software. It is setting up a situation where users will not be free. In and of itself it isn't a bad license; it just doesn't protect freedom and it can be used in ways that block people from contributing. By design. If you expect people to treat MIT licensed software as GPL licensed software, then t…

That they aren't implies that the intent is different.

News flash buddy. OSS devs, college and graduate students mostly, are clueless about the distinction and select whatever license tickles their fancy from GitHub's dropdown menu. They see a lot of MIT licenses floating around, recognize "MIT" as a good university, and figure they can't go wrong with it. They, like most normies, don't see how "freedom" figures into software at all. All they care about is getting a little shine before they join a FAANG after graduation.

As for why someone who does understand the distinction would choose MIT over GPL, ask Linus about why he'd "never want anything to do with the FSF" after being told to switch to GPLv3. Yes, MIT versus GPL is not the same as GPLv2 versus GPLv3 but the general concepts are the same.

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

#128

Post by TacticalCoder »

whartung wrote: post #101
heinrichhartman wrote: post #3

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…

Maybe this would interest you:

https://sqrtminusone.xyz/posts/2021-05-01-org-python/

(the very first screenshot is Emacs)

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

#129

Post by roenxi »

tshirttime wrote: post #127
roenxi wrote: post #126

Earlier quoted context omitted.

Riddle me this then, why use MIT over GPL? The point of the MIT license is to make it easier to link it to proprietary software. It is setting up a situation where users will not be free. In and of itself it isn't a bad license; it just doesn't protect freedom and it can be used in ways that block people from contributing. By design. If you expect people to treat MIT licensed software as GPL licensed software, then t…

That they aren't implies that the intent is different. News flash buddy. OSS devs, college and graduate students mostly, are clueless about the distinction and select whatever license tickles their fancy from GitHub's dropdown menu. They see a lot of MIT licenses floating around, recognize "MIT" as a good university, and figure they can't go wrong with it. They, like most normies, don't see how "freedom" figures into…

If you want to argue that licenses are picked randomly then OK. But in that case, people should pick the GPL; it is a better license for preserving the freedom of software users than the MIT license.

> ... ask Linus about...

Linus uses GPLv2. I personally see merit in the argument that v2 is better than v3. Neither is MIT.

If you want to use the GPL license and not associate with the FSF then cool. If Linus wants to do that, also cool. The issue is the license, not if you want to work with the FSF. The GPL also grants users freedom from the FSF.

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

#130

Post by mark_l_watson »

After reading this article this morning I went down a very fun rabbit hole today: removed my SBCL installation, installed Roswell to install SBCL again, etc.

The good things: editing works, slime works, access to all my Quicklisp based libraries and projects. The bad things mostly involve limited Lem functionality because I rely on many eLisp libraries like treemacs, etc.

I really like the speed, and having everything in Common Lisp is fun. I was using Roswell to build Lem from source, and I really liked the project’s setup, build process.

Post reply on HN