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

Emacs 27.2

lists.gnu.org

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Emacs 27.2

#101

Post by ashton314 »

tharne wrote: post #17
Decabytes wrote: post #14

I've used Emacs for almost 5 years now and it has served me well. In the beginning it was frustrating and confusing, but now that I understand it, it's the way I naturally interact with code on my computer. The fact that so many gnu tools have movement similar to Emacs means that I can quickly become more effective in them. The fact that my work Macbook allows me to do some rudimentary movement with C-a, C-e, C-f, C-…

I prefer vim as an editor, but in terms of being a unique and fascinating piece of software, emacs wins hands down. There's something really cool about the fact that you can't easily answer the question, "What is emacs similar to?", because it's such a total sui generis.

As mentioned under another reply, take a look at evil-mode. Near-perfect vim compatibility as far as I can tell. Best of both worlds in my opinion!

Re: Emacs 27.2

#102

Post by monsieurbanana »

prewett wrote: post #18
tharne wrote: post #17

Earlier quoted context omitted.

I prefer vim as an editor, but in terms of being a unique and fascinating piece of software, emacs wins hands down. There's something really cool about the fact that you can't easily answer the question, "What is emacs similar to?", because it's such a total sui generis.

Viper mode could give you the best of both worlds, depending on what you like about vim. If it's the key navigation, viper has you covered.

Hearing about Viper reminds me about the times where I was just starting to use Emacs, about 10 years ago! Fond memories :)

Since then, Evil-mode has effectively superseded it. I wish I had learnt vim-like editing a long time ago, as Vim-bindings seem to be mostly well-maintained in every editor.

Emacs-bindings are also in most editors, but it's not as useful since people (most people? in any case, me) usually customize the default shortcuts quite a bit. And less manpower to maintain them.

Re: Emacs 27.2

#103

Post by monsieurbanana »

iterati wrote: post #31
dfinninger wrote: post #23

Earlier quoted context omitted.

Spacemacs uses “Evil mode”[1], which is available just as a regular (MELPA) package. I started with Vim and so I’ve always used evil. “Vanilla” emacs, spacemacs, now doom. [1] https://github.com/emacs-evil/evil

I'm curious if you've already used evil with vanilla why you'd migrate to spacemacs or doom. I've never found either to add much that a custom config can't get to easily and with more control. Maybe that's changed in the past half-decade or so since I last tried Spacemacs, though.

I have a somewhat lengthy vanilla config, and I can tell you why I'm thinking about trying out Doom:

At work, I had to make some simple modifications in a go project. I've never done go before, so I had to google how to add support for it on emacs. There's always more than one choice, which one is the best maintained package? Is there an optional but ubiquitous plugin that will make it more enjoyable?

With Doom, you just add the go layer and you're good to go. I'm fine spending time setting up, i.e., a clojure config, since I use it all the time. It's well-spent effort. Not as much for a language I seldom have to use.

Re: Emacs 27.2

#104

Post by NoThisIsMe »

Klwohu wrote: post #82
vvillena wrote: post #38

Earlier quoted context omitted.

The vim bindings are only one part of Spacemacs. The other (and I'd say most important) part is the SPC menu that exposes hundreds of keybindings in a discoverable, unobtrusive, and interactive interface.

Isn't that also just an elpa / melpa package though?

The keybindings are bound with evil and displayed with which-key, but the spacemacs special sauce is the keybindings themselves. There are probably thousands of them across all the optional layers. They're crowd-sourced essentially. So you don't have to set them up manually for each language/tool you work with, you just add the layer and get sensible defaults out of the box.

Re: Emacs 27.2

#105

Post by NoThisIsMe »

acoard wrote: post #73
NyxWulf wrote: post #20

Earlier quoted context omitted.

spacemacs has a very complete vim layer. By far it's the most complete implementation outside of actual vim I've seen.

Spacemacs is indeed great, I used it myself recently. But I will say, it's no longer really actively maintained. The community has migrated over to ~~Spacemacs~ Dooom Emacs, which is very similar (still uses space as leader key and vim bindings everywhere). In my experience, Doom Emacs runs a lot faster too. https://github.com/hlissner/doom-emacs edit: Changeed Spacemacs to Doom Emacs, whoops.

Its true that many have moved on to Doom, but Spacemacs is absolutely still maintained.

Re: Emacs 27.2

#106

Post by samus »

neolog wrote: post #88
brightball wrote: post #68

I tried Emacs after reading so much about it lately...but I don’t understand how people use it. The sheer volume of key combinations always in play to do things makes my hands hurt. It made me see the appeal of some of those concave keyboards.

Many people find it helpful to swap ctrl with capslock.

I'm currently trying out a circular swap of left ctrl -> left super, left super -> left alt, left alt -> left ctrl. The goal is the same: now the thumb just curls a little bit more to reach ctrl.

Edit: my preferred keyboard layout has levels, and the Caps Lock key is a level shifter, which makes me prefer not pushing it down to Left Ctrl.

Re: Emacs 27.2

#107

Post by chriswarbo »

taeric wrote: post #98
TeMPOraL wrote: post #96

Earlier quoted context omitted.

Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.

I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good…

I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process).

I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process).

I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).

Re: Emacs 27.2

#108

Post by chriswarbo »

TeMPOraL wrote: post #97
chriswarbo wrote: post #40

Earlier quoted context omitted.

> Wish something be done about proper threading support, but I understand it's a herculean task at this point. I would agree about adding concurrency and parallelism; but threading is very much a WorseIsBetter approach, which I certainly wouldn't like to use directly. Co-routines or futures would seem a better fit for Lispy semantics. Actors seem too different and heavyweight, but I'd still prefer them to threading!

I said "threading" as a catch-all term. Whatever makes Emacs able to fully utilize multiple cores of a CPU would work.

I get that; which is why I call out such things when I see them (I really hate threading!) ;)

Re: Emacs 27.2

#109

Post by TeMPOraL »

taeric wrote: post #98
TeMPOraL wrote: post #96

Earlier quoted context omitted.

Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.

I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good…

The big things are indeed being outsourced to separate processes. LSP handles a lot, I also see some attempts at moving syntax highlighting to tree-sitter[0]. But all such work means a good chunk of code is running inside a foreign process, whose behavior cannot be easily inspected or modified at runtime.

But there are a lot of various smaller things in Emacs and elisp module ecosystem that would benefit from being able to run off the main thread. Emacs performance is fighting death by a thousand cuts, with almost everything being tied to the main thread (despite async features being used to pretend it's not).

--

[0] - https://tree-sitter.github.io/tree-sitter/

Re: Emacs 27.2

#110

Post by j4yav »

mapolone wrote: post #78
j4yav wrote: post #72

Earlier quoted context omitted.

Sincere question: if I already have a vim setup with all the plugins I like, and I switch to evil mode so everything more or less works as I had it, what does emacs open the door to that I couldn’t do before? Org mode I imagine is one piece. Is there anything else I should look at if I try it?

There are a few IMHO: magit [1] is a nice piece for Git. And there's vterm, if you wish to use a (usable) term or tmux/screen without leaving the editor, tramp mode [2] for remote files and last but not least ergoemacs [3] if you prefer the CUA style for generic commands (and reduce RSI). Oh, and forgot to mention helm [4] too... [1] https://magit.vc [2] https://www.emacswiki.org/emacs/TrampMode [3] https://ergoemacs…

I'm all set up with spacemacs and trying these out, thanks so much for the tips! So far so good.
Post reply on HN