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

Emacs Bedrock: A minimal Emacs starter kit

sr.ht

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Emacs Bedrock: A minimal Emacs starter kit

#111

Post by cmrdporcupine »

michaelsbradley wrote: post #110
cmrdporcupine wrote: post #108

Earlier quoted context omitted.

So I tried again and disabled guru mode (had to hunt for how and had to read the author's opinionated nonsense about the "one true way to use Emacs is by using it the way it was intended to be used " (phbtbt... nonsense... have you looked at the Space Cadet keyboard?). So far I like the bundling of lsp and so on, it worked nicely out of the box to bring in my Rust projects ... it's nice to have it all set up. But the…

Maybe there's been a recent change, but I use C-g all the time every day to get out of prompts, etc. For me, C-x u opens a buffer for undo-tree, not sure if that's what you meant or not. It's possible I customized for C-g and or C-x u; I haven't changed much in .emacs.d/personal recently, except for adding a few scripts. In any case, glad you gave it another shot, but perhaps it isn't your cup of tea. It's great that…

Yeah I don't want an undo-tree bound like that, because when I'm hitting undo, I just want a quick response. Default emacs behaviour is what I want.

And C-g, yeah, I don't know what it was doing. It got really weird.

In general this thing seems to want to open buffers all over the place. It's... visually confusing and I kept losing cursor focus in the task I was trying to focus on.

Re: Emacs Bedrock: A minimal Emacs starter kit

#112

Post by billfruit »

ljm wrote: post #109
billfruit wrote: post #88

Earlier quoted context omitted.

Is there code-completion/intellisense baked-in as of Emacs 29? I think not. Why can't something that is built into IDEs like Intellij be built into Emacs even after 30+ years of development?

It is built in, and it’s better with eglot. It’s just not enabled by default because emacs isn’t used exclusively for programming.

It's not built in, eglot is only an LSP client, it requires a LSP server to function which is not included with Emacs.

Re: Emacs Bedrock: A minimal Emacs starter kit

#113

Post by billfruit »

G3rn0ti wrote: post #93
billfruit wrote: post #88

Earlier quoted context omitted.

Is there code-completion/intellisense baked-in as of Emacs 29? I think not. Why can't something that is built into IDEs like Intellij be built into Emacs even after 30+ years of development?

You don’t understand how Emacs works. It is not supposed to be an IDE from the get-go. But there are extensions that together can turn it into one. For whatever language you program with.

I understand that, my point was that the LSP server which is required for code completion to work is not built in/packaged together with Emacs.

Re: Emacs Bedrock: A minimal Emacs starter kit

#114

Post by G3rn0ti »

billfruit wrote: post #113
G3rn0ti wrote: post #93

Earlier quoted context omitted.

You don’t understand how Emacs works. It is not supposed to be an IDE from the get-go. But there are extensions that together can turn it into one. For whatever language you program with.

I understand that, my point was that the LSP server which is required for code completion to work is not built in/packaged together with Emacs.

There are hundreds of language servers out there. Even VScode does not ship all of those. Emacs‘ LSP client „lsp-mode“ tries to download them for you if possible. For example, in case of JavaScript and TypeScript you don’t have to provide it yourself.

Re: Emacs Bedrock: A minimal Emacs starter kit

#116

Post by zelphirkalt »

not_kurt_godel wrote: post #105
G3rn0ti wrote: post #104

Earlier quoted context omitted.

> for the ... Raku devs it does not appear that finding references So the Raku server has a deficiency, currently. Too bad. But in Emacs you can work around that by writing into your config file: (remove-hook 'xref-backend-functions #'lsp--xref-backend t) if you use "lsp-mode.el" or equivalently (remove-hook 'xref-backend-functions 'eglot-xref-backend t) if you happen to use "eglot.el". (There are two major language…

It's not happy hacking to have to think about the internal configuration of how broken my IDE's language support is. Emacs is cool for what it is but it's objectively deficient for modern professional development

You seem to have a peculiar definition of "professional development", that does some lifting there and that you are not sharing with us. There are many people here, who do use Emacs when developing in their profession.

Re: Emacs Bedrock: A minimal Emacs starter kit

#117

Post by G3rn0ti »

billfruit wrote: post #112
ljm wrote: post #109

Earlier quoted context omitted.

It is built in, and it’s better with eglot. It’s just not enabled by default because emacs isn’t used exclusively for programming.

It's not built in, eglot is only an LSP client, it requires a LSP server to function which is not included with Emacs.

See my comment above. LSP servers are complicated beasts coming with a lot of specific dependencies. It is simply impossible to ship all available language servers together with Emacs. Even VSCode does not do it. For popular languages it downloads them automatically for you. But this is exactly what "lsp-mode" (the alternative to "eglot.el") does, too [1]. If you are an expert in a specific language it also should not be too difficult for you to install and setup one yourself.

My personal prediction, however, is this: Thanks to the advent of the static parser framework "treesitter" we will see language servers becoming obsolete in the long run. Treesitter enables an editor to load a parser backend as a plugin and on top of that provides a powerful query API to semantically analyse your code. This should be sufficient to implement all of what an external language server does already but inside the editor's process.

[1] https://emacs-lsp.github.io/lsp-mode/page/languages/

Re: Emacs Bedrock: A minimal Emacs starter kit

#118

Post by globular-toast »

kramerger wrote: post #67

I have two comments, that I think also apply to any other HN post on emacs: 1. We are on version 30. By this time emacs should have come with some better defaults. It's 2023, not 1960 people. 2. Why are 90% of emacs frameworks trying to make it into vi?? I choose emacs, if I wanted vi-ish I would have used vi from the beginning

Have you ever done any software development? One does not simply change defaults... Who cares about defaults anyway? Just change them.

Re: Emacs Bedrock: A minimal Emacs starter kit

#119

Post by lproven »

lycopodiopsida wrote: post #83
lproven wrote: post #78

Earlier quoted context omitted.

:-) That's sort of the point. I learned all those editors (VMS EDT and RPED and LocoScript and Edlin and WordStar and WordPerfect and DisplayWrite and MultiMate and loads of BASIC editors, including the very strange RISC OS one, with two independent cursors) before I ever saw Vi for the first time, which was on SCO Xenix in about 1989 or so. Vi was just another weird editor to me, a supercharged Edlin and you'd have…

The millions of unknowing CUA users don't know or use any keybindings - they just click, scroll and select with a mouse. Arguably, it is also what made CUA the worst option - there is just no selection pressure from users, no complains is something is not working properly. Vim keybindings are so well supported compared to the share of users because vim users care . I would also agree, that vim keybindings shine for p…

Something which is the default for basically every keyboard-driven GUI in the world isn't dead by any reckoning.

Re: Emacs Bedrock: A minimal Emacs starter kit

#120

Post by lproven »

Otek wrote: post #80
lproven wrote: post #57

Earlier quoted context omitted.

> Emacs is a relic It's true. The thing is, so is Unix. And yet we use it. So is macOS because it's a Unix™. So is Windows, it's just a newer relic (from 1993 instead of ~1973). We don't have anything left that are not relics any more. The relics got good enough that we stopped trying.

I agree but also feel like there is so much to improve in editor spaces but current “defaults” are just good enough. I like the keyboard example - current staggered keyboard layout is only used because we had physical typewriters that needed staggered keys because of physical constraints. But our fingers aren’t really good at going left and right, even slight movement means that you need to move your whole wrist left…

> And I’m honestly hungry for some revolution here

Nicely put.

Yes, I think there is room for a lot of innovation yet in many areas: OS design, programming language design, input devices, GUIs, and much more besides.

Saying that, when implemented well, there's a lot of stuff that's pretty good.

I think one aspect that's neglected is that yes, some tech we all use is very old and legacy-inspired. But often, it's not that we use some ancient thing because it's ancient and it hasn't changed. It's because it had lots of competitors but it beat them all.

For instance, QWERTY. Yes it is very old and yes it came from typewriters.

But I own 2 computers with

ABCDEF

GHIJKL

MNOPQR

STUVWX

YZ

... layouts. There are also QWERTZ and AZERTY used by millions. Dvorak failed to its inventors' deep misery. (No, not Dvořák, although Dvorak was a descendant of Dvořák.)

There have been tonnes of others tried.

The survivors are the ones that beat out the competition.

And in some instances, the competition survives and does OK in its little niche, and that is fine, too...

Post reply on HN