Emacs 27.2(lists.gnu.org)
lists.gnu.org
Emacs 27.2
https://lists.gnu.org/archive/html/info-gnu/2021-03/msg00008.html
114 comments
https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2... says, "This is a bug-fix release with no new features." But I don't understand what the bugs were.
Check the Changelog for that: https://raw.githubusercontent.com/emacs-mirror/emacs/master/...
Thanks!
From the OP:
> For the complete list of changes and the people who made them, see the various ChangeLog files in the source distribution.
> For the complete list of changes and the people who made them, see the various ChangeLog files in the source distribution.
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-n brings me joy.
Emacs rewards me for learning it better, and when I think about what it does, and is capable of doing, I'm just in awe. I highly recommend reading Mastering Emacs if you would like to become a more effective Emacs user.
After using it for years I can say my single biggest gripe with Emacs is its performance. Elisp is powerful but slow, and has many warts. The developments with GccEmacs excites me, and there is still GuileMacs. As a more experienced user Emacs frustrates me because at times I demand too much of it. And when that happens, I try to temper that frustration with the understanding that the program is 36 years and 5 days old to the day, and has outlived many other pieces of software. Computers looked different in 85 than they did today, and the fact that I have saved truly days of programming time due how effective it makes me cannot be overlooked.
I want Emacs to continue to improve. I want it to get even better than it already is, but I am so grateful for the people who have made it what it is today.
Emacs rewards me for learning it better, and when I think about what it does, and is capable of doing, I'm just in awe. I highly recommend reading Mastering Emacs if you would like to become a more effective Emacs user.
After using it for years I can say my single biggest gripe with Emacs is its performance. Elisp is powerful but slow, and has many warts. The developments with GccEmacs excites me, and there is still GuileMacs. As a more experienced user Emacs frustrates me because at times I demand too much of it. And when that happens, I try to temper that frustration with the understanding that the program is 36 years and 5 days old to the day, and has outlived many other pieces of software. Computers looked different in 85 than they did today, and the fact that I have saved truly days of programming time due how effective it makes me cannot be overlooked.
I want Emacs to continue to improve. I want it to get even better than it already is, but I am so grateful for the people who have made it what it is today.
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!
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.
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.
spacemacs has a very complete vim layer. By far it's the most complete implementation outside of actual vim I've seen.
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
[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.
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.
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.
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.
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.
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.
> The community has migrated over to Spacemacs
I'm guessing you meant to say Doom Emacs there?
I'm guessing you meant to say Doom Emacs there?
I did! Thank you for the correction. Editted.
I used emacs quite a lot, back in the day, and have switched to vim for now.. well, too long. Thing with vim is that I've never seen anyone using stock vim and keys, there's this whole layer of plugins and custom key bindings that make it so effective for any particular user. Would that translate to spacemacs at all? I've only glanced at it, but not sure if it supports Vim plug for example.
Stock Spacemacs is like a fully-tricked out Vim configuration, made by and for "plugin" junkies. Its leader-based keybindings are very well thought-out and discoverable since you get a small menu for the level you are at. For example <space> g gets you to the git submenu, if you forget that <space> g s gets you magit-status it will remind you there.
> Stock Spacemacs is like a fully-tricked out Vim configuration, made by and for "plugin" junkies.
That is a fantastic description of Spacemacs
That is a fantastic description of Spacemacs
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.github.io/
[4] https://github.com/emacs-helm/helm
[1] https://magit.vc
[2] https://www.emacswiki.org/emacs/TrampMode
[3] https://ergoemacs.github.io/
[4] https://github.com/emacs-helm/helm
I'm all set up with spacemacs and trying these out, thanks so much for the tips! So far so good.
It's similar to a Lisp Machine.
Based on a few old mailing list it's apparently only very slightly so, and i'm not dissing emacs, it's just that the people who made lisp os and it's graphical layer really did allow users to augment and interact with most of the system in a very fluid and capable manner. Some examples from that mailing list (thread from the 90s or maybe even 80s) were still not present on a daily basis for code edition / versionning in the 2000s. Makes you wonder
I'm curious what sort of performance you are hit by. For me, it is mainly org source buffers that I did not flag as async.
That and tramp not working too well over crappy internet. :(
That and tramp not working too well over crappy internet. :(
Tramp works a lot more reliably if you customize where Emacs puts your backups and autosaves, such that they're stored locally instead of remotely. The Emacs wiki has details on how to do that: https://www.emacswiki.org/emacs/BackupDirectory
The biggest problem I have with Tramp performance is much deeper, the need to open a new connection for every request - it makes integrating other modes with Tramp much more difficult than I would hope for (e.g. I tried to make kubernetes-mode work over tramp, and it mostly did, but each refresh had to reconnect, which would freeze the whole Emacs GUI for a second or so; thankfully kubel-mode has a more complete implementation that handles this gracefully).
I've had this in my config for a long time. Seems to make tramp work a lot better:
; use ssh instead of scpx mode for tramp
; this should work a lot better with ssh connection sharing
(setq tramp-default-method "ssh")This was problematic even with SSH multiplexing?
You still have this problem even with a control master setup with ssh?
I can't and don't blame tramp, per se. My internet has regular hiccups of being completely disconnected. Pretty sure that is not fixable. :(
Not by Emacs, but locally storing backups and autosaves means it only matters when you're actively reading or writing a file via Tramp.
Absolutely. It just sucks, as my build are so much faster on the remote machine. :)
That is, a lot of my remote editing is not just idle edits, but edit, run build, burn down compile output of tests and other items I'm working.
If I really want hell, I'll try and run lsp remotely.
None of this would matter, if I hadn't built up so much muscle memory from when I did have good internet and it did just transparently work.
That is, a lot of my remote editing is not just idle edits, but edit, run build, burn down compile output of tests and other items I'm working.
If I really want hell, I'll try and run lsp remotely.
None of this would matter, if I hadn't built up so much muscle memory from when I did have good internet and it did just transparently work.
I work in the medical field, which requires me to view large xml files and multi patient csv files with years of patient history. The CSVs contain embedded pdf strings that are long strings of bytes in the file. Emacs struggles to copy and paste, and move around in the large CSVs.
For the large XML files, I have to switch to fundamental mode, because it struggles to highlight everything, and sometimes the xmls are pure ass and are basically all on one line. I've written a python script that will prettify the xml because emacs locks up when I try to do that. My colleagues just tell me to use sublime text.
For the large XML files, I have to switch to fundamental mode, because it struggles to highlight everything, and sometimes the xmls are pure ass and are basically all on one line. I've written a python script that will prettify the xml because emacs locks up when I try to do that. My colleagues just tell me to use sublime text.
Ah, yes. Long lines are known bad. I will be excited to see anyone give a way to fix that with minimal impact on the rest of the system.
I'm curious why other editors don't trip as badly on long lines.
I'm curious why other editors don't trip as badly on long lines.
On the performance/stability of Elisp front, I just heard about remacs, which is a fork that's starting by porting all the C to Rust: https://github.com/remacs/remacs
Still in early stages, but I think that's one to keep an eye on.
Still in early stages, but I think that's one to keep an eye on.
I'd be much more interested in one of the CL rewrites, which could (1) run all of the elisp as efficient compiled Common Lisp, and (2) extend the customizability ot the deepest layers of Emacs.
Unfortunately, most seem to be relatively dead from what I've seen.
Unfortunately, most seem to be relatively dead from what I've seen.
The rust re-write is not intended to bring performance benefits. Currently the Rust version is a massive downgrade in performance relative to the C nativecomp branch.
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, GccEmacs is a parallel branch of Emacs that uses libgccjit to compile ELisp straight to native code. It does it transparently - compiling in the background and then substituting bytecode-compiled functions for native-compiled.)
Wish something be done about proper threading support, but I understand it's a herculean task at this point.
(For those unfamiliar, GccEmacs is a parallel branch of Emacs that uses libgccjit to compile ELisp straight to native code. It does it transparently - compiling in the background and then substituting bytecode-compiled functions for native-compiled.)
> 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 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?
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.
>you don't want to make a binary specifically for it
Most of the Emacs code I've seen that spawns a process spawns a short shell script: no custom binary needed.
Most of the Emacs code I've seen that spawns a process spawns a short shell script: no custom binary needed.
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?
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?
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/
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/
The inspection and modification is a strong point that I should have considered.
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).
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).
Do you know what makes it freeze? My gut would be that they did not set a buffer with a sentinel, such that even with threading, they would have still don't a blocking call there.
That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)
That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)
> Do you know what makes it freeze?
For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.
FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html
For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.
FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html
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!) ;)
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!
I can't wait for it to hit release so everybody can play with it!
I have built gccemacs a week ago. I didn't see much difference in speed and it breaks wanderlust... Are there things to know to get the speed (and yes, I've checked it was enabled during ./configure :-)) ?
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.
are binaries available somewhere, i tried compiling it about year ago but quit after struggling with few dependencies.
gccemacs works remarkably fine for such a big change, it does bite my poor x201 hard on the compiling phase (we're now as modern as lein clojure bootstrap :cough:) but it does bring speed improvements already.
Going on 25 years with Emacs. Lots of other things I've changed over the years, but still happy with Emacs and Postgres.
I wish to use Emacs, but those keyboard shortcuts do not make any sense for me.
Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest.
I do not mind keyboard shortcuts in gneeral and use them all the time, it's just those in Emacs are hard to learn/remember knowing that I wish to change them anyway .
I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it and thus it blocks me from moving forward with exploring Emacs deeper.
Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest.
I do not mind keyboard shortcuts in gneeral and use them all the time, it's just those in Emacs are hard to learn/remember knowing that I wish to change them anyway .
I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it and thus it blocks me from moving forward with exploring Emacs deeper.
> Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest.
I've got a very custom Emacs keybindings/shortcuts setup but... Sadly it requires some hackery: basically there's the whole major/minor modes shenanigan where one mode's shortcut can take precedence over the other(s). And if you want to define your own shortcuts which take precedence, all the time, over everything else, you need to dig a bit deep. And then even deeper because invariably there's this or that minor mode you'll want to use where after all you won't want your own shortcut but that one of the mode.
> I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it
Sadly this is true. I've got I'd say about 100 lines of code related only to keybindings. Now, once set up, it's pure bliss. For example I've got mod+{i,j,k,l} to move the cursor around, anywhere (text, menus, anything). It makes even more sense than vim's hjkl (ijkl mimics the cursor arrow keys layout, which is more natural and ijkl is easier to type than hjkl too).
> ... and thus it blocks me from moving forward with exploring Emacs deeper.
I can understand that. I'd say the easiest would be to define your own minor mode as explained here:
https://stackoverflow.com/questions/683425/globally-override...
This should get you started: if you do it like in the answer and make sure they always take precedence you should be good to go and can deal with the gory details later on.
I've got a very custom Emacs keybindings/shortcuts setup but... Sadly it requires some hackery: basically there's the whole major/minor modes shenanigan where one mode's shortcut can take precedence over the other(s). And if you want to define your own shortcuts which take precedence, all the time, over everything else, you need to dig a bit deep. And then even deeper because invariably there's this or that minor mode you'll want to use where after all you won't want your own shortcut but that one of the mode.
> I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it
Sadly this is true. I've got I'd say about 100 lines of code related only to keybindings. Now, once set up, it's pure bliss. For example I've got mod+{i,j,k,l} to move the cursor around, anywhere (text, menus, anything). It makes even more sense than vim's hjkl (ijkl mimics the cursor arrow keys layout, which is more natural and ijkl is easier to type than hjkl too).
> ... and thus it blocks me from moving forward with exploring Emacs deeper.
I can understand that. I'd say the easiest would be to define your own minor mode as explained here:
https://stackoverflow.com/questions/683425/globally-override...
This should get you started: if you do it like in the answer and make sure they always take precedence you should be good to go and can deal with the gory details later on.
Well, if you already know vim keystrokes, just use Spacemacs. The big win is easy discoverability: using the space bar as a menu-starter, and when you find the command you want, it tells you what key stroke you could have used instead.
It's a good question, but asking someone who has used Emacs for 25 years... I'm pretty happy with them, and indeed, do my best to have them replicated in other software I use such as shells and browsers.
Anyone running the jit Emacs? Can't wait for it. I did try compiling it from source for my linux setup. Would love to see it on windows.
I've just tried it on macOS, built by this tool: https://github.com/jimeh/build-emacs-for-macos
Unfortunately it keeps locking up my entire computer so might not be a goer just yet.
Unfortunately it keeps locking up my entire computer so might not be a goer just yet.
I am. I honestly don't notice much of a difference, but at the same time I keep seeing deferred compilation warnings for plugins I have added via straight.el
I've been using https://github.com/flatwhatson/guix-channel to manage it. I don't recommend trying the Pure GTK+ stuff yet though; some context menus don't seem to work. Specifically, treemacs rename seems broken with PGTK.
I've been using https://github.com/flatwhatson/guix-channel to manage it. I don't recommend trying the Pure GTK+ stuff yet though; some context menus don't seem to work. Specifically, treemacs rename seems broken with PGTK.
> Anyone running the jit Emacs?
I'm running the "native-comp" (libgccjit) branch daily since months and months now: not a single problem here and I've got quite a "heavy" config (thousands of lines of custom config and all the usual suspects: magit / org-mode / lsp / cider etc.).
> I did try compiling it from source for my linux setup.
And it worked? Worked on the first try for me (on the Debian distro).
I was somehow expecting lots of problems (because it's one heck of a change) but it really all just compiled and worked perfectly fine.
I'm running the "native-comp" (libgccjit) branch daily since months and months now: not a single problem here and I've got quite a "heavy" config (thousands of lines of custom config and all the usual suspects: magit / org-mode / lsp / cider etc.).
> I did try compiling it from source for my linux setup.
And it worked? Worked on the first try for me (on the Debian distro).
I was somehow expecting lots of problems (because it's one heck of a change) but it really all just compiled and worked perfectly fine.
I followed this tutorial from mastering emacs blog iirc. I built it inside docker. I think it worked on the first try for me as well. I didn't use it much since it was in docker.
I've been using it for a few months on wsl and it's been great. I'm using the Nix package and have run into only a couple of minor issues.
That's a good idea, will finally try nix package manager on windows.
I have compiled straight from source on the feature/native-comp branch, and it works noticeably much faster. I am actually scared of going back to the regular Emacs, as I may find it way too slow.
I am not sure how much it is from native Emacs, as when I did this, I also enabled all the other recommended optimizations from lsp (increasing the gc threshold early in the config, installing and compiling with native json support etc.)
As far as I know, the latest branch has all the necessary flags enabled, so you can just do
I am not sure how much it is from native Emacs, as when I did this, I also enabled all the other recommended optimizations from lsp (increasing the gc threshold early in the config, installing and compiling with native json support etc.)
As far as I know, the latest branch has all the necessary flags enabled, so you can just do
./autogen.sh && ./configure --with-nativecomp --with-xwidgets --with-json && make -j4 && make install
It looks like the configure option has been renamed to
--with-native-compilation
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...
[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.
Running the native-comp + wayland copr on fc32 for about a year, whithout any problem. About 3x faster.
https://copr.fedorainfracloud.org/coprs/deathwish/emacs-pgtk...
https://copr.fedorainfracloud.org/coprs/deathwish/emacs-pgtk...
Over half a year now, as a daily driver. Personally on Ubuntu, at work on WSL (Windows Subsystem for Linux) - which I then x-forward to an VcXsrv on Windows.
Works pretty much flawlessly, and it's much snappier on some of the workloads I put it through - like big collections of big Org Mode files, or viewing (and fontifying) large files.
Works pretty much flawlessly, and it's much snappier on some of the workloads I put it through - like big collections of big Org Mode files, or viewing (and fontifying) large files.
Yes, it's pretty solid running Doom Emacs. There's a handy macOS build script/helper:
https://github.com/jimeh/build-emacs-for-macos
The author curates a list of "known good" commits to the feature/native-comp branch so you don't waste your time with bad builds:
https://github.com/jimeh/build-emacs-for-macos/issues/6
https://github.com/jimeh/build-emacs-for-macos
The author curates a list of "known good" commits to the feature/native-comp branch so you don't waste your time with bad builds:
https://github.com/jimeh/build-emacs-for-macos/issues/6
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...
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.
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.
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.
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.
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.
I'm just getting into Emacs (~4 months) and I'd say that I have probably ~40 key-commands memorized. I M-x search for everything else and I still find it to be an excellent experience. I'm building my config and muscle memory very slowly, but enjoying every minute.
That's me, two years ago, when I made the switch from vi.
In the end, the key combinations are something to learn - but the productivity increase makes them worth learning. And for the handcramp thing: Realize that you have two control, and two meta keys on a standard keyboard.
In the end, the key combinations are something to learn - but the productivity increase makes them worth learning. And for the handcramp thing: Realize that you have two control, and two meta keys on a standard keyboard.
as a vim user, how could I learn Emacs? I know of Evil mode, but how easy is it to have some stuff just like I have in vim (such as custom text objects, vim-surround, etc..).
Look at Doom Emacs. It's pre-configured to work out of the box for modern dev.
There are also some good guides on YouTube by DistroTube, if you prefer to learn that way.
https://github.com/hlissner/doom-emacs
https://www.youtube.com/watch?v=dr_iBj91eeI
There are also some good guides on YouTube by DistroTube, if you prefer to learn that way.
https://github.com/hlissner/doom-emacs
https://www.youtube.com/watch?v=dr_iBj91eeI
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.
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.
The scripting language isn't total crap, for starters.
There's a huge amount of tools (package) that enable additional features.
It's easy to interface with other stuff.
There's a huge amount of tools (package) that enable additional features.
It's easy to interface with other stuff.
I can so recommend this.
I've switched to emacs few years ago for the same reason and spent about a year using it. Although I've switched back to vim afterwards, having spent time with emacs was fun and not a waste of time.
Have a leap of faith, find the advantages of one (or the other) for yourself. If you don't like at any time for any reason just switch back: after all, it all text files you're editing.
I've switched to emacs few years ago for the same reason and spent about a year using it. Although I've switched back to vim afterwards, having spent time with emacs was fun and not a waste of time.
Have a leap of faith, find the advantages of one (or the other) for yourself. If you don't like at any time for any reason just switch back: after all, it all text files you're editing.
You can have the best of both worlds using spacemacs in evil mode. Essentially gives you emacs with a lot of community-selected plugins, but with vim keybindings.
As a vim user, there's just certain tools emacs provides to which there's no vim equivalent (or the vim implementation is lacking). Like org mode for example: I've yet to come across something outside of the emacs ecosystem that does a good job of replicating org mode. Maybe jupyter notebooks come close in some ways, but AFAIK the org mode experience is fairly unique to emacs.
As a vim user, there's just certain tools emacs provides to which there's no vim equivalent (or the vim implementation is lacking). Like org mode for example: I've yet to come across something outside of the emacs ecosystem that does a good job of replicating org mode. Maybe jupyter notebooks come close in some ways, but AFAIK the org mode experience is fairly unique to emacs.
Take my answer with a grain of salt because I have much more experience with vim and I have used emacs only off and on for a couple years, and I only use it as an "IDE" of sorts.
So, how I experience them, they aren't exactly competitors in a direct sense.
When I use vim in the terminal, I treat my workflow in a particular way. I use tmux to have windows for multiple projects (usually I run 2 or more microservices in my day to day). I use TUIs like lazygit, and I rely heavily on command line tools to build, compile, and do most of the daily things. I am familiar with those and it's basically like the whole terminal is my IDE in some ways. For note taking and idea management, I use vimwiki within vim.
Using Emacs is different for everyone's specific use cases, but the way I have tried to use it as an IDE for golang, node, and some react. Emacs seems to prefer integrating your workflow INTO emacs rather than just having emacs be a single part of your workflow. (I'm simplifying too much, I think)
Evil mode gives me literally every single vim command I ever have used in my entire life. I am a heavy vim user, but I am not an extreme power user. I use macros, regex, and other simple vim stuff. All of it is perfectly fine in evil mode as I use it. But feature parity isn't a great reason to switch from vim IMO.
-The first thing that really is a huge improvement is org mode to capture anything in the code I am looking at that I don't have time to address. Like capturing a weird piece of code or something that might have a bug state, org capture, make a note of it and I can come right back to it later when I have free time.
- Everyone touts magit. I love magit, BUT if I'm being honest with myself, lazygit is nearly just as good...and if you've been using git commands fine for any amount of time, it's more of a nicety than a MUST have. I don't view magit as "the killer app" that other do, but I admit that I really like it and use it heavily whenever I use emacs.
- Elisp is amazing compared to vimscript. That's pretty much that whole bullet point.
There are more things, but it might depend on your personal workflow and the kind of work you do.
I recommend dipping your toes in using DOOM emacs (or spacemacs, but I didn't like that one as much) and getting a feel for emacs. You might find that you like it, you might find that you prefer your current vim & terminal based workflow better.
I'm somewhere between the worlds. I really keep coming back to emacs because of 1) Org mode 2) Csv mode (Sounds silly, but I do a LOT of csv parsing in my life) 3) elisp hacking & scratch mode.
So, how I experience them, they aren't exactly competitors in a direct sense.
When I use vim in the terminal, I treat my workflow in a particular way. I use tmux to have windows for multiple projects (usually I run 2 or more microservices in my day to day). I use TUIs like lazygit, and I rely heavily on command line tools to build, compile, and do most of the daily things. I am familiar with those and it's basically like the whole terminal is my IDE in some ways. For note taking and idea management, I use vimwiki within vim.
Using Emacs is different for everyone's specific use cases, but the way I have tried to use it as an IDE for golang, node, and some react. Emacs seems to prefer integrating your workflow INTO emacs rather than just having emacs be a single part of your workflow. (I'm simplifying too much, I think)
Evil mode gives me literally every single vim command I ever have used in my entire life. I am a heavy vim user, but I am not an extreme power user. I use macros, regex, and other simple vim stuff. All of it is perfectly fine in evil mode as I use it. But feature parity isn't a great reason to switch from vim IMO.
-The first thing that really is a huge improvement is org mode to capture anything in the code I am looking at that I don't have time to address. Like capturing a weird piece of code or something that might have a bug state, org capture, make a note of it and I can come right back to it later when I have free time.
- Everyone touts magit. I love magit, BUT if I'm being honest with myself, lazygit is nearly just as good...and if you've been using git commands fine for any amount of time, it's more of a nicety than a MUST have. I don't view magit as "the killer app" that other do, but I admit that I really like it and use it heavily whenever I use emacs.
- Elisp is amazing compared to vimscript. That's pretty much that whole bullet point.
There are more things, but it might depend on your personal workflow and the kind of work you do.
I recommend dipping your toes in using DOOM emacs (or spacemacs, but I didn't like that one as much) and getting a feel for emacs. You might find that you like it, you might find that you prefer your current vim & terminal based workflow better.
I'm somewhere between the worlds. I really keep coming back to emacs because of 1) Org mode 2) Csv mode (Sounds silly, but I do a LOT of csv parsing in my life) 3) elisp hacking & scratch mode.
NOTE: This is advice for programmers: if you're not a coder, it won't make any sense for you.
If you are a programmer, though, and you're going to learn Emacs, learn it along with Emacs Lisp and Elisp development tools.
One definite advantage of doing that is experiencing the "plugin" development environment done right. If you ever scripted Vim, or any other program other than the web browser, you're in for a fun ride. really The "plugins" in Emacs are, surprisingly, full-blown programs. When writing them, you can evaluate any part of the code and see the results immediately. You have access to a source-level debugger and two profilers out of the box. Every function you use is documented, and accessing that documentation is trivial. You can "go to definition" of any variable and function, including primitives written in C (if you compiled Emacs yourself and have the sources on disk). You can modify, extend, or override any function anywhere with advices. The language itself is also interesting: it's multi-paradigm. You can write code in procedural, functional, and OOP styles. The OOP implementation is based on generic functions and multimethods/multiple dispatch - unless you worked with Clojure or Julia, you're unlikely to have encountered that before. The quote/unquote-based macros are powerful, and even if you don't use them, you can benefit from them, for example, by using a library providing pattern-matching/destructuring (like pcase or -let).
And you get all of that just for writing plugins for an editor. Let that sink in. The tooling and language, which, though a bit clunky sometimes, rivals professional IDEs and languages like Kotlin, just for writing extensions. Seeing all of this after trying - and failing - to write a simple Vim plugin with VimL and Lua was a mind-blowing experience.
It's also an advantage - to get back to your question - which explains the massive amount of Elisp programs and plugins out there. Well worth experiencing.
If you are a programmer, though, and you're going to learn Emacs, learn it along with Emacs Lisp and Elisp development tools.
One definite advantage of doing that is experiencing the "plugin" development environment done right. If you ever scripted Vim, or any other program other than the web browser, you're in for a fun ride. really The "plugins" in Emacs are, surprisingly, full-blown programs. When writing them, you can evaluate any part of the code and see the results immediately. You have access to a source-level debugger and two profilers out of the box. Every function you use is documented, and accessing that documentation is trivial. You can "go to definition" of any variable and function, including primitives written in C (if you compiled Emacs yourself and have the sources on disk). You can modify, extend, or override any function anywhere with advices. The language itself is also interesting: it's multi-paradigm. You can write code in procedural, functional, and OOP styles. The OOP implementation is based on generic functions and multimethods/multiple dispatch - unless you worked with Clojure or Julia, you're unlikely to have encountered that before. The quote/unquote-based macros are powerful, and even if you don't use them, you can benefit from them, for example, by using a library providing pattern-matching/destructuring (like pcase or -let).
And you get all of that just for writing plugins for an editor. Let that sink in. The tooling and language, which, though a bit clunky sometimes, rivals professional IDEs and languages like Kotlin, just for writing extensions. Seeing all of this after trying - and failing - to write a simple Vim plugin with VimL and Lua was a mind-blowing experience.
It's also an advantage - to get back to your question - which explains the massive amount of Elisp programs and plugins out there. Well worth experiencing.
and... flickering is back on the NS port.
Alan Third (the NS maintainer) said on reddit that "It's too big and invasive a change for Emacs 27."[1]
[1]: https://old.reddit.com/r/emacs/comments/mc82yk/flickering_em...
[1]: https://old.reddit.com/r/emacs/comments/mc82yk/flickering_em...
Too bad. I wish they could just stop breaking things.
It's fixed on HEAD if you don't care about running from trunk. Otherwise, I suggest you to use Mitsuharu Yamamoto's Mac Port: https://bitbucket.org/mituharu/emacs-mac
what is the release cadence of emacs?
I think there isn't an official one, but since 2016 there's been a major version released approximately every two years, and a minor version every couple of months.
https://www.gnu.org/software/emacs/history.html
https://www.gnu.org/software/emacs/history.html
That's pretty solid!
While a set-in-stone release schedule doesn't exist, there is _a lot_ of development activity (emacs-devel is a very busy mailing list). 99.9% of the time it's safe to use the bleeding edge head of the repository if you want to use the latest stuff.
except in the few months following a major release (at least for me)
"Emacs 27.2 is a bug-fix release, with no new features with respect toEmacs 27.1."
[1] Excellent Steve Yegge post describing how much Emacs cares about stability and backwards-compatibility: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...