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

Toward a “modern” Emacs

lwn.net

Post reply on HN
Print view View original

501–510 of 539 posts

Re: Toward a “modern” Emacs

#501

Post by da39a3ee »

bananaface wrote: post #492
da39a3ee wrote: post #484

Earlier quoted context omitted.

Could you give some justification for that criticism and assertion please? (On its own, your comment falls short of HN standards.)

Sure, here are some samples from the source. This is Eglot's code. Try and figure out what's happening in each of these passages: https://github.com/joaotavora/eglot/blob/master/eglot.el#L41... https://github.com/joaotavora/eglot/blob/master/eglot.el#L41... https://github.com/joaotavora/eglot/blob/master/eglot.el#L17... Contrast with lsp-mode: https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.e... https://gi…

Thanks. It's true that the eglot code is hard to understand (and based on your links I suspecter hard_er_). I had been provisionally assuming that that was because the author is a much more advanced lisp programmer than me (which is true; I'm fairly sure he's one of those emacs developers that is also an experienced common lisp developer).

In any case, I would prefer that neither become part of GNU Emacs since then the development process and code review will become completely opaque (I'm not sure code review is really a thing once it's in Emacs. Just maintainers with push rights to some repo on savannah or something)

Re: Toward a “modern” Emacs

#502

Post by Siira »

hardwaregeek wrote: post #316
mapgrep wrote: post #28

I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.” Emacs is one of the most successful text editors of all time if not the most successful. It…

That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years. They care about being able to write code effectively. And emacs doesn't let users write code effectively by modern standards. Sure, after boatloads of configuration and tinkering it does, but it's unclear if it's worth it. Forking it is…

Then the solution is to just point people to some of the popular starter packs when emacs starts for the first few times. I think Doom is pretty rad by default.

Re: Toward a “modern” Emacs

#503

Post by globular-toast »

bananaface wrote: post #499
globular-toast wrote: post #494

Earlier quoted context omitted.

Upgrading to 27 made no difference for me.

In that case something dramatic is eclipsing it, it should be noticeable. It may be the GC threshold. There's about 5 settings recommended for perf issues. https://emacs-lsp.github.io/lsp-mode/page/performance/ Ordinarily I'd ignore rabbit holes like this but LSP is unusually useful. It's worth a shot.

I've done all of that. Still slow. I think the problem is other people have lower standards than I do when it comes to speed.

Re: Toward a “modern” Emacs

#504

Post by Siira »

TrisMcC wrote: post #410
trenchgun wrote: post #408

Earlier quoted context omitted.

Doom emacs is probably the state of the art emacs starter pack now. A lot faster than spacemacs, more stable etc. A rock solid default config made out of Doom emacs might work.

I don't think a starter pack that completely disables the "Customize" interface would be a good candidate for default. https://github.com/hlissner/doom-emacs/blob/a2a5038b970df20e... "Doom doesn't support `customize' and it never will. It's a clumsy interface" I find the Customize interface very useful.

It's easier this way for a beginner. Things are consistent; You put `(setq foo bar)` in your config. It's very intuitive. (I have also lost some settings to customize's bugs in Spacemacs.)

Re: Toward a “modern” Emacs

#505

Post by Siira »

coldtea wrote: post #231
jrimbault wrote: post #88

Earlier quoted context omitted.

Just to add links to the SO surveys mentionned here : - 2019: https://insights.stackoverflow.com/survey/2019#development-e... - 2018: https://insights.stackoverflow.com/survey/2018#development-e... - 2017: https://insights.stackoverflow.com/survey/2017#technology-_-... - 2016: https://insights.stackoverflow.com/survey/2016#technology-de... - 2015: https://insights.stackoverflow.com/survey/2015#tech-editor What's real…

The huge advantage of VSC: plugins can use HTML to implement whatever UI they want, from a workflow tool, to a test tool, to a Git graph view to a debugger data structure visualizer. And all that in widely-known to tons of people HTML/CSS. Never understood why other editors, like ST, didn't give more UI options (checkboxes, buttons, dropdowns, a canvas, etc) to plugin authors. Consider how clunky a lot of plugin inte…

The last two are more of disadvantages; The remote setup eats a lot of memory from the remote machine, and needs an excellent internet connection, and can't integrate with local editing (You have to use two separate windows, and it's in general nowhere as neat as tramp). The saved prefs are synced without version control, which means you can't really count on them.

Re: Toward a “modern” Emacs

#506

Post by JacksonGariety »

globular-toast wrote: post #494
bananaface wrote: post #360

Earlier quoted context omitted.

Are you on Emacs 27 yet? Below that Emacs encodes JSON in Elisp, which is extremely slow and makes LSP unusable.

Upgrading to 27 made no difference for me.

There's a command called M-x lsp-doctor that will tell you if you meet all the performance requirements for LSP mode. Among those is emacs 27 compiled with native json support (you can build emacs 27 without native json).

Re: Toward a “modern” Emacs

#507

Post by ashtonkem »

pjmlp wrote: post #464
ashtonkem wrote: post #456

Earlier quoted context omitted.

Sure, but it’s not like the choice is between Emacs and VS Code alone. I for one find IntelliJ to be far superior to VS Code for the languages I use. Especially since search and autocomplete actually work, which it doesn’t do in VS Code.

VSCode has the power of free beer, and most major plugins are done by Microsoft, Red-Hat, Google and friends, while most InteliJ goodies are available online on the commercial license.

I wonder how many devs are motivated by that. All of the ones I know are already using OSX, so standing on principle for just the IDE would be incoherent.

Re: Toward a “modern” Emacs

#508

Post by pjmlp »

ashtonkem wrote: post #507
pjmlp wrote: post #464

Earlier quoted context omitted.

VSCode has the power of free beer, and most major plugins are done by Microsoft, Red-Hat, Google and friends, while most InteliJ goodies are available online on the commercial license.

I wonder how many devs are motivated by that. All of the ones I know are already using OSX, so standing on principle for just the IDE would be incoherent.

OS X is about 10% of the world desktop market.

Hardly seen outside first world countries, and even on Europe it isn't easily spot outside the rich EU countries.

I did a couple of consulting gigs where the only iMac available for the Dev teams was used in turns for iOS deployments, for applications done in cross platform frameworks, where 90% of development time was spent in Ubuntu and Windows based computers.

Re: Toward a “modern” Emacs

#510

Post by acqq »

dragandj wrote: post #478
acqq wrote: post #474

Earlier quoted context omitted.

> No amount of crippling Emacs would help there. It can only spoil it for existing happy users. I am surely against "crippling." The initial topic of the discussion was how to make Emacs accessible to the new users. I don't suggest making fixed changes to anything, only allowing somebody to easily select different defaults which correspond with the keyboards available today. Today's keyboard has no meta key. Old keyb…

But that is certainly not only possible, but available today in Emacs. It's here. Use it and evangelize it if you like.

What I talk about is what "amadeuspagel" also describes in a post here.

And to confirm that experience, until participating in this conversation, I also didn't know that it could be possible to efficiently use Emacs with the key combinations of some "more familiar to common people" editor.

And I'm still confused: if you say "Keep in mind that all three combinations are central to Emacs 1) C-c is used in million combinations 2) C-u too 3) C-v scrolls a page down."

What then? Does it mean that I can't use the "million combinations" if I want Ctrl-C to mean copy? What is then the start of "a million combinations"? Why should't help system simply adjust to display the "start of million of combinations" as the thing I selected at the start? If I like Ctrl K instead, couldn't that be "the start of the million of combinations"?

And why should I care that "C-v scrolls a page down"? The keyboards since at least 1987 have a physical "Page Down" key, why should I not use that then?

(And they surely don't have a physical "Meta" key).

I hope that's a usable example of what confuses at least one kind of a beginner.

Post reply on HN