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

91–100 of 115 posts

Re: Emacs 27.2

#91

Post by Smithalicious »

whobar wrote: post #52
Smithalicious wrote: post #33

Earlier quoted context omitted.

I use pre-release Emacs with the nativecomp branch ("gccemacs") and Doom. Starts in 2.1 seconds and it's blazing fast. Definitely the best thing to come to Emacs for me in a long time, very exciting. I can't wait for it to hit release so everybody can play with it!

Any warts when using it with Doom? I only recently switched from vim to Doom, and I love it, but it can be a bit laggy when using it with some of the C/C++ IDE features turned on.

It works very well with Doom, Doom has support for it and detects it's available and does everything for you. Just compile Emacs and run doom upgrade as usual.

Re: Emacs 27.2

#92

Post by vvillena »

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?

I guess so? And if the aim is to make something completely custom, that's fine. But the Spacemacs keybindings are very well thought out, the configuration is just as important as the feature itself.

Re: Emacs 27.2

#93

Post by taeric »

iib wrote: post #90
taeric wrote: post #25

Earlier quoted context omitted.

I also enable march=native for the compile. My guess is it is mostly placebo, but I feel it helps.

I only know of this discussion[1] on Daniel Lemire's blog regarding -march=native, which seems to have the "it's complicated" conclusion. But yes, _theoretically_ that is a way to compile for better performance, for your own machine. [1] https://lemire.me/blog/2018/07/25/it-is-more-complicated-tha...

Yeah, "complicated" sums it up perfectly. I know it /should/ be faster. And, it does feel so. But, I don't have hard data to prove it, such that I have to ack it could just be placebo.

Re: Emacs 27.2

#94

Post by okamiueru »

neolog wrote: post #89
ilovecaching wrote: post #32

Not to start a holy war, but what are the advantages of emacs over vim these days? I'm considering switching to emacs just to have learned both.

In some sense, they're not in the same category. The old joke "Emacs is a great operating system, it just needs a good text editor" is basically true. If you like vim, try Doom Emacs or Spacemacs. If I were going for pure text editing today I might want something like https://kakoune.org/ whose selection->action pattern seems better than Vim's action->selection pattern.

I'm a little confused. If doom emacs is good, wouldn't the emacs experience when just disabling evil (vi-bindings), and thus having regular emacs workflow not also be pretty good?

Re: Emacs 27.2

#95

Post by neolog »

okamiueru wrote: post #94
neolog wrote: post #89

Earlier quoted context omitted.

In some sense, they're not in the same category. The old joke "Emacs is a great operating system, it just needs a good text editor" is basically true. If you like vim, try Doom Emacs or Spacemacs. If I were going for pure text editing today I might want something like https://kakoune.org/ whose selection->action pattern seems better than Vim's action->selection pattern.

I'm a little confused. If doom emacs is good, wouldn't the emacs experience when just disabling evil (vi-bindings), and thus having regular emacs workflow not also be pretty good?

Spacemacs has like four different keybinding modes, one of them is regular emacs mode. I thought it was pretty good. I haven't used doom myself but I know people like it.

Re: Emacs 27.2

#96

Post by TeMPOraL »

taeric wrote: post #58
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'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible. What is the aim?

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.

Re: Emacs 27.2

#97

Post by TeMPOraL »

chriswarbo wrote: post #40
TeMPOraL wrote: post #27

Earlier quoted context omitted.

Definitely go for GccEmacs (feature/native-comp) branch if you haven't yet. Despite being experimental, it's pretty much stable. I've been running it for over half a year as a daily driver, and seen zero issues (but much performance improvements!). Similar stories abound on-line. Wish something be done about proper threading support, but I understand it's a herculean task at this point. (For those unfamiliar, GccEmac…

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

Re: Emacs 27.2

#98

Post by taeric »

TeMPOraL wrote: post #96
taeric wrote: post #58

Earlier quoted context omitted.

I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible. What is the aim?

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 benchmarks for emacs to look at and play with?

Re: Emacs 27.2

#99

Post by auganov »

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.

Super and Hyper (Right Alt and Right Pritnscreen for me).

I never use any C-c bindings. C-* & M-* already have decent defaults, so all my frequently used stuff is s-* and H-*. Some of the less frequent stuff might be H-s-*, C-s-* or M-s-* [0]. Everything else I can just call from M-x. Don't see the point of using keybindings for stuff you only need a few times a day. On the flipside the stuff where keybindings make sense should have the simplest possible one.

[0] It may seem daunting but there's usually some symmetry in the way I define them. One letter tends to do different but somewhat related things with different modifiers. For example s-x is eval defun, H-x is eval s-exp at point, s-z is eval defun and pprint, H-x is eval at point and pprint. H-s-x is eval at point and replace. C-k is kill-line so s-k is kill sexp. M-f is forward-word so s-f is forward-sexp.

Re: Emacs 27.2

#100

Post by wiswindsurf »

I started using emacs in the early 1980s. Just found out I could use it on my cell phone. Never thought I would be using it on a phone I can carry around. I just have to carry a magnifying glass to see the text with my aging eyes...
Post reply on HN