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

111–120 of 162 posts

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

#111

Post by GrumpySloth »

tshirttime wrote: post #110
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.

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…

Yeah. I can get this angle. This is why we don’t have small independent companies making C and C++ compilers today. Only BigCorps which fund this development with money made from less honourable business.

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

#112

Post by tshirttime »

BeetleB wrote: post #103
samatman wrote: post #94

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…

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

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

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

#113

Post by dleslie »

cmrdporcupine wrote: post #99
dleslie wrote: post #97

Earlier quoted context omitted.

First you have to know that lsp-mode exists. VSCode just detects what to do from the file. About projectile: Emacs ships with project.el and that does 90% of what projectile can do.

I'm sorry maybe this has improved in the two years since I tried but the last time I tried to set up VSCode to even approach the capabilities of CLion (the tool I used most at the time) it required a whole bunch of configuration, and stuff that felt more brittle and confusing than the emacs setup I have now. In particular, no, it did not do all the LSP stuff out of the box, and didn't do basic refactorings out of the…

I have never used VSCode for C/C++, only Emacs and Visual Studio, so I can't comment on how it compares to CLion. VSCode and C#, however, is something I prefer to Visual Studio or even Rider.

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

#114

Post by dleslie »

cmrdporcupine wrote: post #75
kazinator wrote: post #50

Earlier quoted context omitted.

I need an editor that starts up, cache cold, in a few hundred milliseconds at most. Thanks for playing.

To be fair, that's not emacs. I'm a huge emacs fan, but its startup is awful compared to vim & friends. Yes, you can use emacsclient, but that's a bit of a different thing and has its own disadvantages.

My Emacs is full of extra bits and pieces, and it cold starts on a Pinebook Pro in 6 seconds. That said, I still run an Emacs daemon and use Emacs clients, which start up in milliseconds.

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

#115

Post by tom_ »

cyrialize wrote: post #49
digging wrote: post #40

Earlier quoted context omitted.

Since I only use VSCode (or Codium...), what sorts of things would be in the latter list?

Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code. In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs. For example, think about doing a "Hello World"…

This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly.

If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.

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

#116

Post by riddley »

lispm wrote: post #37
widge wrote: 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.

Yea sorry for the misinformation. I'd read an earlier version of the Emacs wikipedia page that made it seem like Gosling Emacs was the original. The page is clearer now.

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

#117

Post by EdwardCoffin »

cylinder714 wrote: post #102
EdwardCoffin wrote: post #56

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?

https://news.ycombinator.com/item?id=39404903

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

#119

Post by cmrdporcupine »

dleslie wrote: post #114
cmrdporcupine wrote: post #75

Earlier quoted context omitted.

To be fair, that's not emacs. I'm a huge emacs fan, but its startup is awful compared to vim & friends. Yes, you can use emacsclient, but that's a bit of a different thing and has its own disadvantages.

My Emacs is full of extra bits and pieces, and it cold starts on a Pinebook Pro in 6 seconds. That said, I still run an Emacs daemon and use Emacs clients, which start up in milliseconds.

I mean, mine's about the same startup, but that's ... like a hundred times worse than a Vim startup.

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

#120

Post by roenxi »

globular-toast wrote: post #89
kyykky wrote: post #52

Earlier quoted context omitted.

Is there a benefit in using GPL for text editors?

Licences like MIT optimise individual freedom: they give each user the freedom to do anything including restricting the freedom of others . Licences like GPL optimise community freedom: they give each user the freedom to do anything except restricting the freedom of others . Think of it like local vs global optimisation.

Although I agree, notice that the only act the GPL compels someone to do is to hand over the source code with the program.

MIT doesn't give people a freedom to restrict because that isn't a freedom. The restriction is always done by the legal system. The GPL is just an attempt to stop the legal system from interfering in the market to restrict user freedom. So both licenses are actually communicating to a 3rd party (a judge) under what circumstances they should restrict the freedom of others. GPL says to stay out of it as long as people are sharing their source code and MIT says get involved sometimes/its complicated.

It isn't a practical difference, but it is philosophically important. The amount of personal freedom both licenses give is technically quite similar.

Post reply on HN