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

31–40 of 162 posts

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

#31

Post by ericvsmith »

tom_ wrote: post #28
tom_ wrote: post #25

Earlier quoted context omitted.

I suppose TextMate was a bit more niche, being OS X only, but at one point it seemed to be everywhere .

Hmm, while we're counting, what about BRIEF? At one point, widely enough used that Visual Studio even had BRIEF emulation! (When I was starting out in software development, almost all of my colleagues used this. Now just a footnote.)

BRIEF by UnderWare! I loved that editor. I particularly liked the “go to this line number, but use the line number before unsaved edits”. This let you compile a file, get the error log, then start making edits; but the line numbers in the error log were still useful.

https://en.wikipedia.org/wiki/Brief_(text_editor)

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

#32

Post by BeetleB »

dleslie wrote: post #19

It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche. If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete wit…

> It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top.

Many (most?) Emacs enthusiasts don't use it primarily for SW development. VSCode simply isn't an alternative for their needs.

Make two lists:

- List of things you can do in VSCode that you can't in Emacs

- List of things you can do in Emacs that you can't in VSCode

The latter list will be 10-100x longer.

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

#34

Post by dleslie »

Pr0ject217 wrote: post #30
dleslie wrote: post #19

It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche. If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete wit…

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 allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality. If you're savvy enough you can install lsp-mode and it will add that functionality, but at that point you may as well just install the language server yourself.

And about magit: it's a beautiful piece of software, it truly is. It's also hot garbage with large repositories hosted on Windows. I simply cannot use it for work because every operation takes around a minute to resolve, which locks up Emacs entirely. Again, here VSCode shines because the default git integration is pretty good, and there are extensions that make it excellent.

For these reasons, and more, I always recommend VSCode to new developers and don't recommend Emacs. Emacs is for people who want to make editor customization a _hobby_.

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

#35

Post by dleslie »

LukeShu wrote: post #20
dleslie wrote: post #19

It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche. If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete wit…

I'm pretty sure I read this exact comment 10 years ago, but "Sublime Text" instead of "VSCode".

VSCode is why Sublime Text, Atom, and others are not as relevant as they once were.

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

#37

Post by lispm »

widge wrote: post #33
riddley wrote: post #27

It's so crazy to think the original emacs was a commercial product.

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.

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

#38

Post by DonaldFisk »

moi2388 wrote: post #5
account-5 wrote: post #4

Completely off topic but this website is how it should be done. No JavaScript enabled and I can play the videos and see the text and images. Well done.

Well I can’t play any of the media, perhaps JavaScript isn’t that bad?

I don't know the reason in your case, but for a few weeks ending today, I wouldn't have been able to either, due to a long-standing issue with Opera and libffmpeg.so. Today Opera updated itself and everything now works fine, at least until the problem recurs. Maybe you have a similar problem?

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

#39

Post by digging »

lupusreal wrote: post #16
moi2388 wrote: post #5

Earlier quoted context omitted.

Well I can’t play any of the media, perhaps JavaScript isn’t that bad?

Sounds like a Safari/Apple issue, not a lack-of-javascript issue.

For sure, I'm on Orion browser (Safari clone) and it's not playing even with JS enabled.

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

#40

Post by digging »

BeetleB wrote: post #32
dleslie wrote: post #19

It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche. If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete wit…

> It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. Many (most?) Emacs enthusiasts don't use it primarily for SW development. VSCode simply isn't an alternative for their needs. Make two lists: - List of things you can do in VSCode that you can't in Emacs - List of things you can do in Emacs that you can't in VSCode The latter list will be 10-100x longer.

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