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

141–150 of 162 posts

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

#141

Post by vindarel »

phforms wrote: post #81
logicprog wrote: post #60

I like the idea of a more modern Emacs that uses the full power of Common Lisp a lot, but I worry I'd miss a lot of features. Does Lem have org mode, a good LSP system, something like projectile, and the ability to display images and GUI buttons and such? And most importantly, does it have an evil mode with doom/spacemacs style leader key support?

Take a look at the GitHub readme[1]: “Lem supports other programming languages thanks to its built-in LSP client. You can choose between an Emacs and a Vim mode.”. Although I wish they’d explore the Kakoune/Helix style of editing too, which I think will become a major competitor to Vim (and I personally prefer it myself). However, I am also worried that Lem won’t gain any traction because the Emacs ecosystem is just…

> magit

Lem has a wip Git mode: see status, stage files/hunks, commit, interactive rebase, basic hg and fossil support. (I added it)

It's WIP and undocumented yet (don't worry I'll document when ready, I love documentation ;) ) Use

   M-x lisp-eval-string RET (ql:quickload :lem/legit)
then

   M-x legit-status or C-x g
> Dired

Lem has a directory mode with some actions: sort (name, mtime, size), mark by regexp, rename, delete, find files…)

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

#142

Post by vindarel »

cmrdporcupine wrote: post #64

I tried out Lem a couple times, and I was impressed, but couldn't see myself moving to it. What was impressive is how starting it up just.. worked... with LSP type stuff... I was editing Rust and that all functioned. Not as featureful as my Emacs setup, but further along than I expected. And the keybindings were mostly familiar. But so many of the things I now rely on -- company mode, treemacs, vertico, etc. are not…

> treemacs

try C-x d aka M-x filer?

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

#143

Post by mark_l_watson »

vindarel wrote: post #138
mark_l_watson wrote: post #130

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

> treemacs Try C-x d in Lem (Alt-x filer) https://lem-project.github.io/usage/usage/#filer---project-e...

Thanks!

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

#144

Post by tshirttime »

GrumpySloth wrote: post #139
globular-toast wrote: post #134

Earlier quoted context omitted.

That's ridiculous. The GPL explicitly allows people to make copies. What many free software advocates actually want is a world without copyright on software. It's copyright that frames copying as stealing. In a world with copyright, the only way to counter that is copyleft. The fact GPL can also enforce inclusion of source code is a nice side effect of copyleft. But ultimately what we want is a world where software i…

> What many free software advocates actually want is a world without copyright on software. Some of them sure. The subset of them who are GPL advocates are simply confused though. GPL is not possible in a world without copyright. In a world without copyright I can release software, which can be written from the ground up or be based on something open source, doesn’t matter, and not share the code with anyone. Just th…

I recommend this piece

You and the author appear to be the same guy. To be sure, the piece itself is an academic exercise hypothesizing a world in which the MIT license were law. And in such a world, the GPL gestapo would continue railing against opaque binaries even if those binaries were shameless but legal ripoffs of someone's hard work.

If I took emacs, modified it to be thread-safe, and distributed it as an opaque binary, John Q. Emacs User retains his thread-unsafe version but now knows there's something better out there which he can't iterate on. You can say this knowledge isn't a real "loss," but that would be dismissing the concept of opportunity cost.

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

#145

Post by roenxi »

GrumpySloth wrote: post #137
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…

> It is setting up a situation where users will not be free. No. It is setting up a situation where users can choose between a free option A and a proprietary option B based on A. Being sad about A being too liberal is suggesting it’s more important for you that B doesn’t exist than that A exists. > If you expect people to treat MIT licensed software as GPL licensed software, I don’t. Contrary to GNU and FSF websites…

But it sounds like we have found agreement on the point that the MIT license is setting up an option B, where a person is blocked from contributing for legal reasons?

That is the big difference between MIT and GPL. With MIT licensed software, sometimes you have software that you can't legally adjust (or help others adjust). With GPL ... I mean it might be technically possible with some wildly creative approach but I haven't heard of such a thing.

> Most people, outside of GNU-centric places like this post about Emacs, prefer more liberal licences.

Controlling someone else's computer through legal means isn't liberal. I'm sure a liberal could call for that and accept a little ideological impurity.

If software is property, it has a new owner after it is sold and they can do what they like with it. That isn't what copyright does, it creates some sort of Frankenstein permanent-rent concept where the owner often doesn't maintain anything that is at odds with technical and market realities, relying heavily on the prosecution of victimless crimes. Which although arguably a desirable thing (I don't think so myself though) is illiberal.

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

#146

Post by GrumpySloth »

tshirttime wrote: post #144
GrumpySloth wrote: post #139

Earlier quoted context omitted.

> What many free software advocates actually want is a world without copyright on software. Some of them sure. The subset of them who are GPL advocates are simply confused though. GPL is not possible in a world without copyright. In a world without copyright I can release software, which can be written from the ground up or be based on something open source, doesn’t matter, and not share the code with anyone. Just th…

I recommend this piece You and the author appear to be the same guy. To be sure, the piece itself is an academic exercise hypothesizing a world in which the MIT license were law. And in such a world, the GPL gestapo would continue railing against opaque binaries even if those binaries were shameless but legal ripoffs of someone's hard work. If I took emacs, modified it to be thread-safe, and distributed it as an opaq…

> You and the author appear to be the same guy.

We are not. We’re not even on the same continent.

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

#147

Post by cmrdporcupine »

vindarel wrote: post #142
cmrdporcupine wrote: post #64

I tried out Lem a couple times, and I was impressed, but couldn't see myself moving to it. What was impressive is how starting it up just.. worked... with LSP type stuff... I was editing Rust and that all functioned. Not as featureful as my Emacs setup, but further along than I expected. And the keybindings were mostly familiar. But so many of the things I now rely on -- company mode, treemacs, vertico, etc. are not…

> treemacs try C-x d aka M-x filer?

That's.. sort-of similar. Treemacs is more project based, not CWD based. That seems more like "dired in a left-panel."

Useful though.

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

#148

Post by hollerith »

dleslie wrote: post #34
Pr0ject217 wrote: post #30

Earlier quoted context omitted.

Speaking from personal experience, I moved from VSCode to Doom Emacs a year ago, and the on-ramp wasn't nearly long or as tough as I thought. The defaults are good, and anything else that I customized I actually just used ChatGPT/GPT-4 to generate it. It took about a month to get used to the new setup. With LSP/Magit, it feels like I'm not missing out on much from what VSCode offered, and then whenever I want to pers…

I've been using Emacs for roughly three decades; it's my favourite editor. And for sure, LSP has been an absolute game changer. Worth noting is that LSP came from Microsoft as part of their efforts to build a better editor experience; and its integration with VSCode is largely unparalleled. For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allo…

I've also been using Emacs for 3 decades. Although I could probably be happy with vscode for coding, neither vscode nor any other app I am aware of is a satisfactory substitute for Emacs as a personal information manager (PIM) because neither vscode nor any other app can be modified easily enough. (Apparently, I care whether my PIM supports my personal way of working more than I care whether my code editor or IDE does.)

Maybe if I were a professional web developer, I would be able to modify vscode in the ways I feel it needs to be modified to support my personal style after a reasonable investment in learning vscode internals, but that is manifestly not actually the case.

BTW, I don't use and don't like org mode.

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

#149

Post by tmtvl »

globular-toast wrote: post #134
GrumpySloth wrote: post #93

Earlier quoted context omitted.

This and similar arguments in this thread work on the same logic that frames software piracy as theft. It’s the fallacy of treating software as a tangible thing that, when copied, is taken away from someone and altered irreversibly.

That's ridiculous. The GPL explicitly allows people to make copies. What many free software advocates actually want is a world without copyright on software. It's copyright that frames copying as stealing. In a world with copyright, the only way to counter that is copyleft. The fact GPL can also enforce inclusion of source code is a nice side effect of copyleft. But ultimately what we want is a world where software i…

I care a great deal for the GPL, but I'd be fine with copyright if it wasn't so stupidly long. The reason I care about the GPL is my belief in an informed public. As far as I'm concerned, withholding vital information (like a list of ingredients or source code) from the public should be a criminal offence.

Whilst yes, you could technically say 'well, if the user wants to know what this software is doing, they can just disassemble it', I'd consider that malicious compliance. It's like listing ingredients by their scientific names (like 'Arachis Hypogaea' instead of 'peanut').

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

#150

Post by tmtvl »

kleiba wrote: post #70
taeric wrote: post #14

Earlier quoted context omitted.

Same. The live demo at the end was very effective at spiking more interest, as well.

Really? I find that the one really good design decision that survived in GNU emacs over all these years is that it does not have dialog windows. But it seems that that's pretty much what Lem does, at least when you find a file?!

Technically GNU Emacs does have dialog windows (at least the GTK version): if you click File in the menu bar, followed by 'Visit New File...' it opens the GTK file picker.

I only know that because when using Emacs on the Steam Deck using the menu bar is a little easier than doing input using Hacker Keyboard on my phone passed to the Deck using KDE Connect.

Post reply on HN