What’s new in Emacs 28.1?(masteringemacs.org)
masteringemacs.org
What’s new in Emacs 28.1?
https://www.masteringemacs.org/article/whats-new-in-emacs-28-1
289 comments
This collection page of Emacs packages: https://emacs.zeef.com contains only packages which are last updated at least 2 years ago, and it's already an impressive amount to me, which indicates that Emacs community is also very active, despite having - in IT terms- a very ancient editor.
s/despite/due to/
Ancient, stable platforms enable long-termism, which encourages scratching your itches - whatever you write, it will likely keep working until after you're dead.
Ancient, stable platforms enable long-termism, which encourages scratching your itches - whatever you write, it will likely keep working until after you're dead.
Wayland support didn't make it... Oh well it is in version 29.
I've been using the wayland version with libgccjit many months now from their git repo and it is extremely snappy and stable editor.
My strategy to keep all of this together is a nix derivation that compiles the latest master branch with all the plugins. Oh and my config is an org file with clear comments...
https://github.com/pimeys/nixos/tree/main/desktop/emacs
All reproducible...
Btw. I recommend SystemCrafters video series Emacs from scratch. It teaches how to make a vanilla emacs to work like doom emacs does. It was helpful for me to understand the magic behind doom...
https://m.youtube.com/playlist?list=PLEoMzSkcN8oPH1au7H6B7bB...
I've been using the wayland version with libgccjit many months now from their git repo and it is extremely snappy and stable editor.
My strategy to keep all of this together is a nix derivation that compiles the latest master branch with all the plugins. Oh and my config is an org file with clear comments...
https://github.com/pimeys/nixos/tree/main/desktop/emacs
All reproducible...
Btw. I recommend SystemCrafters video series Emacs from scratch. It teaches how to make a vanilla emacs to work like doom emacs does. It was helpful for me to understand the magic behind doom...
https://m.youtube.com/playlist?list=PLEoMzSkcN8oPH1au7H6B7bB...
I have been testing Emacs 28 for a few weeks now, as it was reported to improve performance on LSP integration (which was sometimes sluggish for me with rust).
I have to say I wasn't disappointed. It's now comparatively blazingly fast. I hugely recommend to give it a try if you work in emacs with LSP.
Since my distro had not packaged it yet, I installed it from guix instead (package `emacs-next`). It worked like a charm.
I have to say I wasn't disappointed. It's now comparatively blazingly fast. I hugely recommend to give it a try if you work in emacs with LSP.
Since my distro had not packaged it yet, I installed it from guix instead (package `emacs-next`). It worked like a charm.
Do we have any idea when 28 will be available through the regular guix Emacs package?
emacs-next is how you installed lsp?
I tried installing a lsp package at some point, but I couldn't figure out if it was actually doing anything over and above the language major modes. Not sure if it was actually doing anything at all actually.
I tried installing a lsp package at some point, but I couldn't figure out if it was actually doing anything over and above the language major modes. Not sure if it was actually doing anything at all actually.
Sorry, to clarify: I used the package `emacs-next` from guix to install emacs 28. You still need to install and configure emacs-lsp along with the LSP backend(s) you want to use.
I'm currently using the doom-emacs "emacs distro" (https://github.com/hlissner/doom-emacs), so doom is taking charge of setting up emacs-lsp for me.
I'm currently using the doom-emacs "emacs distro" (https://github.com/hlissner/doom-emacs), so doom is taking charge of setting up emacs-lsp for me.
Thank you for that. I haven't really checked out any of these distros (doom, prelude, etc.), but maybe I should.
One of the issues I have is that I work on multiple disconnected servers, and so I usually end up installing emacs on all of them. Using tramp is an option, but often times I just want a local editor because I find myself needing one in the context I'm working in. But all the servers run slightly different OS versions, etc.
Maybe a mangaged-for-me distribution that does most everything I want without me fiddling with it is the way to go.
One of the issues I have is that I work on multiple disconnected servers, and so I usually end up installing emacs on all of them. Using tramp is an option, but often times I just want a local editor because I find myself needing one in the context I'm working in. But all the servers run slightly different OS versions, etc.
Maybe a mangaged-for-me distribution that does most everything I want without me fiddling with it is the way to go.
For me it was worked relatively well.
I track my config in a git repo, and doom-emacs is rather helpful on what external tools must be installed for various configuration "layers" (like when working with such and such language). When using LSP, it can even proposes to install an appropriate language server in some cases.
I track my config in a git repo, and doom-emacs is rather helpful on what external tools must be installed for various configuration "layers" (like when working with such and such language). When using LSP, it can even proposes to install an appropriate language server in some cases.
I was an Emacs user back in my software writing days, but I thought I had left it behind when I became a lawyer. Over the past month or two however I’ve moved more and more of my workflow over to Emacs.
I started with using Org Mode and PDF tools for note taking and reviewing PDFs and task management: https://news.ycombinator.com/item?id=30492373. More recently I switched my email over to mu4e: https://www.emacswiki.org/emacs/mu4e. Unfortunately I can’t get it to interface properly with Office 365, which has heavily locked down POP/SMTP. So I used a couple of Power Automate flows to store incoming emails into a maildir format directory in OneDrive, which I then read from mu4e: https://en.wikipedia.org/wiki/Maildir. I also use Power Automate flows to grab my calendar and store it to Org files, and watch for queued emails and send send them. Power Automate is just about the worst programming environment ever devised, but because UNIX systems like RFC 2822 (email) and maildir are so simple it didn’t take much fiddling at all!
Ironically, writing a bit of glue to get everything into Emacs offers better integration between email, calendar, todos, and notes, than just using Office 365’s own tools. After trying a ton of web/electron based tools for these purposes, going back to Emacs makes me think of this scene from Star Wars: https://m.youtube.com/watch?v=7hb8AYnRb-4
I’m using the Emacs 28.1 test release on Windows and the Emacs-Mac Port on Mac: https://bitbucket.org/mituharu/emacs-mac/src/master/. The latter has nice features like double buffering that make Emacs, while not modern feeling, quite presentable.
For such a huge change, the elisp native compilation works extremely nicely with every package I’ve thrown at it. Totally stable and ready for prime time.
I started with using Org Mode and PDF tools for note taking and reviewing PDFs and task management: https://news.ycombinator.com/item?id=30492373. More recently I switched my email over to mu4e: https://www.emacswiki.org/emacs/mu4e. Unfortunately I can’t get it to interface properly with Office 365, which has heavily locked down POP/SMTP. So I used a couple of Power Automate flows to store incoming emails into a maildir format directory in OneDrive, which I then read from mu4e: https://en.wikipedia.org/wiki/Maildir. I also use Power Automate flows to grab my calendar and store it to Org files, and watch for queued emails and send send them. Power Automate is just about the worst programming environment ever devised, but because UNIX systems like RFC 2822 (email) and maildir are so simple it didn’t take much fiddling at all!
Ironically, writing a bit of glue to get everything into Emacs offers better integration between email, calendar, todos, and notes, than just using Office 365’s own tools. After trying a ton of web/electron based tools for these purposes, going back to Emacs makes me think of this scene from Star Wars: https://m.youtube.com/watch?v=7hb8AYnRb-4
I’m using the Emacs 28.1 test release on Windows and the Emacs-Mac Port on Mac: https://bitbucket.org/mituharu/emacs-mac/src/master/. The latter has nice features like double buffering that make Emacs, while not modern feeling, quite presentable.
For such a huge change, the elisp native compilation works extremely nicely with every package I’ve thrown at it. Totally stable and ready for prime time.
Funny, just dealt with the whole O365 authentication just this week. With moving to 2 factor authentication you need to use OAuth 2 to do anything with it. I have my (work) O365 email forwarded, so I do have normal IMAP access. I use isync/mbsync [1] to receive email, goimapnotify [2] to get pushed new email, read/reply/etc with mu4e [3] and org-msg [4] and org-mode, and until recently just plain SMTP to send mail. This last part will break with 2 factor, but found oauth2ms [5] to set up the OAuth to work with O365 SMTP. The trick was to find the "tenet ID" from the Azure page of your organization and to use Thunderbird's credentials [6] (or another mail program, since I can't make new app registrations on Azure to have my own "application"). That should also allow you to use IMAP with OAuth 2 as well, but haven't done that since I still have the forwarding. (As usual, I think the Arch Wiki [7] covers most of this too.)
[1] http://isync.sourceforge.net/
[2] https://gitlab.com/shackra/goimapnotify
[3] https://www.djcbsoftware.nl/code/mu/mu4e.html
[4] https://github.com/jeremy-compostella/org-msg
[5] https://github.com/harishkrupo/oauth2ms
[6] https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s...
[7] https://wiki.archlinux.org/title/Isync#Using_XOAUTH2
[1] http://isync.sourceforge.net/
[2] https://gitlab.com/shackra/goimapnotify
[3] https://www.djcbsoftware.nl/code/mu/mu4e.html
[4] https://github.com/jeremy-compostella/org-msg
[5] https://github.com/harishkrupo/oauth2ms
[6] https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s...
[7] https://wiki.archlinux.org/title/Isync#Using_XOAUTH2
You may want to try using DavMail [1] for interfacing with Outlook. It is a reverse-proxy for email, so it talks to Outlook, and then mu4e can talk to DavMail directly.
[1] http://davmail.sourceforge.net/
[1] http://davmail.sourceforge.net/
How the hell did they break email? You need a browser with JS to log into your email server?
Isn't 2022 wonderful?
[deleted]
For instance, the Microsoft SMTP server in the cloud is picky about SSL/TLS protocols and ciphers.
Alas, in some orgs you will need permission to authenticate davmail to Outlook. My IT department has not approved davmail.
How can they tell?
Honest question because I fear my uni will start doing this out of “security “.
Honest question because I fear my uni will start doing this out of “security “.
Office 365 requires SMTP/POP/IMAP to use an "xoauth" authentication scheme which relies on getting an authentication token from a web browser. The process of getting that token involves sending a request that includes an application ID.
Are you using viper or evil-mode often (or some other thing which gives emacs vi bindings, I think there are a couple)? Because navigating text with emacs gives me the emacs pinky, I'm wondering how folks deal with that. Transposed cpslck with ctrl?
> Because navigating text with emacs gives me the emacs pinky,
I had RSI issues early in my career (not Emacs related), and learned some tricks that come handy with Emacs.
Your keyboard has two control keys. Use both of them. In particular, use the "opposite" one. If you want to press C-c, use the right Control key with your right hand. If you want to press C-l, use the left control key with your left hand. This way you're distributing the work with both hands and are not twisting your hands into weird shapes trying to get both buttons with one hand.
And also: Once you do this, no reason to insist on using your pinky to hit Control. I often use my thumb as well.
I never got the Emacs pinky.
I had RSI issues early in my career (not Emacs related), and learned some tricks that come handy with Emacs.
Your keyboard has two control keys. Use both of them. In particular, use the "opposite" one. If you want to press C-c, use the right Control key with your right hand. If you want to press C-l, use the left control key with your left hand. This way you're distributing the work with both hands and are not twisting your hands into weird shapes trying to get both buttons with one hand.
And also: Once you do this, no reason to insist on using your pinky to hit Control. I often use my thumb as well.
I never got the Emacs pinky.
I curl my little finger and press Ctrl with the first knuckle. No hand movement required in my case.
(There’s a picture of my hand doing this on Xah’s site somewhere, to which he’s added a warning about potential long term effects; but I’ve been doing this for over ten years now, with no ill effects noted.)
(There’s a picture of my hand doing this on Xah’s site somewhere, to which he’s added a warning about potential long term effects; but I’ve been doing this for over ten years now, with no ill effects noted.)
> If you want to press C-c, use the right Control key with your right hand
First thought: but C is on the right.
Second thought: ah, I use Dvorak
First thought: but C is on the right.
Second thought: ah, I use Dvorak
map capslock to be a control key.
Although it's the canonical solution, that would be a degradation for me. It's more ergonomic to use two hands to enter any modifier sequence. Mapping Capslock to Control doesn't provide extra benefits to my solution.
The other problem people have with the pinky is that they're twisting their wrist while typing, which is also against more ergonomic guidelines. The recommendation is to move the whole arm. Once you get used to that, there's no good reason to use the pinky to hit Ctrl (even when rebound to Caps lock). I would guess over half the times, I'm using some finger other than the pinky to hit Ctrl.
The other problem people have with the pinky is that they're twisting their wrist while typing, which is also against more ergonomic guidelines. The recommendation is to move the whole arm. Once you get used to that, there's no good reason to use the pinky to hit Ctrl (even when rebound to Caps lock). I would guess over half the times, I'm using some finger other than the pinky to hit Ctrl.
No it's not a degradation. It puts Ctrl in a sane place much easier to reach with your pinky. And if you really were going to use your thumb on the left control, then it's about the same distance to the Caps Lock key. I'm replying to the original asker with my advice, if you want to read more about what I think :)
> It puts Ctrl in a sane place much easier to reach with your pinky.
That it does, but there's no good reason I should use my pinky to hit Ctrl to begin with.
That it does, but there's no good reason I should use my pinky to hit Ctrl to begin with.
Your reasoning is most bizarre.
By that rationale, there's no good reason I should use my (left) forefinger to press "g" to begin with.
(qwerty layout assumed...)
By that rationale, there's no good reason I should use my (left) forefinger to press "g" to begin with.
(qwerty layout assumed...)
...or perhaps get a smaller keyboard. I have the Lenovo KU-1255 which is just the right size for me. as always, YMMV.
The emacs keybindings evolved on keyboard with two control keys on both sides, later augmented to have replicated (starting from space bar) control meta super Hyper keys. A PC104 keyboard's main sin for emacs akt where control should be - but not requiring pinky for bucky bits
I set the key left to the spacebar (usually Alt or Cmd) to act as Ctrl in Emacs, so I can press it with my left thumb. This can be done in the Emacs config like this
(setq mac-control-modifier 'command)
(setq mac-command-modifier 'control)
(setq mac-option-modifier 'meta)
(setq mac-control-modifier 'super)Note that these variables are specific to the Mac Port (https://bitbucket.org/mituharu/emacs-mac/src/master/). They use an `ns` prefix instead of `mac` in a build based on the GNU mainline. And presumably something else entirely on another OS.
It's mac-specific, but not Yamamoto port specific. You can also find them in the vanilla EmacsForMacOSX port https://www.emacswiki.org/emacs/EmacsForMacOS#toc24
Huh, I see. I stand corrected.
ns -> NeXTStep
from ancient times...
from ancient times...
The trick is to hit ctrl with the part of your hand where your pinky attaches to it. Now all you do is rotate your wrist slightly, and you hit ctrl. Doesn't work very well on flat/low-profile keyboards, doable with thinkpads, not at all possible on macbooks.
This trick gave me some pretty bad pain in my left hand after a month or so. Remapping control to CAPS LOCK worked for me for years, but what really helped was when I switched to a keyboard that had six keys on each thumb cluster, which allowed me to map control and meta to the thumbs.
Which keyboard, if you don't mind my asking?
Kinesis Advantage 2. In my opinion it’s still the best ergonomic keyboard on the market, I just wish it had better firmware.
You can update it to QMK, mods exist: https://hackaday.com/2021/08/05/kinesis-teensy-qmk-advantage...
There is also a successor available.
There is also a successor available.
Mapping control to its original keyboard placement, caps lock, is the first thing I do on any new computer/keyboard.
I mapped Control to a key under my thumb instead of Caps Lock. That's where it was originally when they chose the binding anyway. It's very comfortable now.
Yeah the caps lock switch is critical I think, since then you can press that key without curling or twisting the finger. Look at technique for musical instruments that require applying pressure with that finger, eg cello, they go through a lot of trouble sometimes to avoid that particular contortion bc of its lack of control and the long-term stress it puts on the hand.
If that doesn't work I know people who have used a usb foot pedal and it seems to work well for them.
Or, if vi bindings work for you, just use vi bindings. There's no nobility in the emacs bindings. I like them but if something else works better just use it.
If that doesn't work I know people who have used a usb foot pedal and it seems to work well for them.
Or, if vi bindings work for you, just use vi bindings. There's no nobility in the emacs bindings. I like them but if something else works better just use it.
No. In my youth I just played through the pain, but I recently just ordered this: http://xahlee.info/kbd/xbows_keyboard_review.html
Fair (though I recommend you give kinesis a try: https://kinesis-ergo.com/keyboards/advantage360/ ).
Separately, I just want to throw it out there, you guys should try sublimity: https://github.com/zk-phi/sublimity
Particularly, the minimap is awesome because it provides an intuition about where one is and that just feels nice.
Separately, I just want to throw it out there, you guys should try sublimity: https://github.com/zk-phi/sublimity
Particularly, the minimap is awesome because it provides an intuition about where one is and that just feels nice.
How did you learn that keyboard exists? It is not on their keyboard page. Kinesis needs a better organized site.
I got the Freestyle2 a few weeks ago, enjoying it, still have some issues finding the navigation keys, home, end etc. I really like having my arms pointed straight rather than angled in like with a normal keyboard. Keys are a bit mushy, went from cherry blues.
I got the Freestyle2 a few weeks ago, enjoying it, still have some issues finding the navigation keys, home, end etc. I really like having my arms pointed straight rather than angled in like with a normal keyboard. Keys are a bit mushy, went from cherry blues.
This model is not yet in full production, and while they claim it will be shipping this summer, it's possible we won't see it this year.
my .02$: get an ergonomic keyboard (I use the MS Sculpt keyboard nowadays), and learn to type like a pianist (use both hands, don't be afraid to move them to minimise strain).
Sculpt is an amazing keyboard for programmers who need to press a lot of hotkeys. It has short spacebars and huge modifiers, very comfortable for your thumb. Not to mention it is split, negative tilted, tented and has a built-in wrist rest.
Agreed, the Sculpt coupled with an vertical mouse has been a game changer for me
I remapped control to the bottom row, whichever key my thumb naturally rests on. Usually alt. Also moved \, [, ], enter, and backspace to avoid reaching for them with my right pinky. I think if your fingers start feeling even a little bit weird, you should keep remapping keys until they feel good all the time. Doesn't make sense to wait for it to get worse before taking action.
There is an extensive guide on moving Ctrl on different OSes/Window managers, which can be found in the EmacsWiki https://www.emacswiki.org/emacs/MovingTheCtrlKey
I gave up the fight to get Emacs to read Outlook emails. Instead, I figured out how to set up Org mode links to Outlook emails, as well as a VBA macro to create an Org mode TODO item based off of an email.
For mu4e and Exchange, I use:
-offlineimap
both linux and macos.
and in my home laptop, davmail because it allows me to use 2FA, which has been implemented at my Uni for external use.
-offlineimap
both linux and macos.
and in my home laptop, davmail because it allows me to use 2FA, which has been implemented at my Uni for external use.
Davmail is great.
I've found mbsync/isync more performant than offlineimap.
I've found mbsync/isync more performant than offlineimap.
yes everyone says so but I am not keen to change now, just out of laziness: there are too many tender points…
>[...] I started with using Org Mode and Org PDF for note taking and reviewing PDFs[...]
I wonder, what is "Org PDF"?
I wonder, what is "Org PDF"?
Sorry, I meant pdftools and org-pdftools: https://github.com/fuxialexander/org-pdftools
Ah, cool, thanks! I'll give that a try...
Thanks for the tips on PDF tools.
I also save org files on shared folders to sync among different machines. I use GnuPG via the epg package to encrypt all files before saving to the shared folders. GnuPG has relatively good cross platform support that I can move the encrypted files between different platforms.
I also save org files on shared folders to sync among different machines. I use GnuPG via the epg package to encrypt all files before saving to the shared folders. GnuPG has relatively good cross platform support that I can move the encrypted files between different platforms.
Did Emacs solve their freezing issues on background I/O?
I wish we could have double buffering on Windows as well...
Relevant xkcd: https://xkcd.com/297/
As usual https://xkcd.com/297 on point
The native compilation part is the highlight. Could someone who knows about these things explain the difficulty Debian has in getting emacs 28 in -unstable ? (currently on 27 according to https://packages.debian.org/unstable/emacs)
Well, it's a one-man team.
I'm not a Debian developer, but did email Rob Browning some years ago, asking if he would perhaps consider trying to make it a team effort. I don't think I ever got a reply. I appreciate the work he's done to maintain Emacs in Debian for decades (!), but it would be nice if someone could give him a hand. For instance, it looks like 27.2 wasn't packaged despite being released a year ago.
I'm not a Debian developer, but did email Rob Browning some years ago, asking if he would perhaps consider trying to make it a team effort. I don't think I ever got a reply. I appreciate the work he's done to maintain Emacs in Debian for decades (!), but it would be nice if someone could give him a hand. For instance, it looks like 27.2 wasn't packaged despite being released a year ago.
That explains it, thank you.
It has only just been released. You can compare the release dates¹ to the package dates² to see how long it tends to take to be packaged and migrate.
¹ https://www.emacswiki.org/emacs/EmacsReleaseDates
² https://tracker.debian.org/pkg/emacs
¹ https://www.emacswiki.org/emacs/EmacsReleaseDates
² https://tracker.debian.org/pkg/emacs
misses the point of my question
FWIW, emacs is extremely easy to build from source.
it is, and i do, but i got bored of doing that a few years ago, and prefer to use 100% packaged stuff.
apt install guix :)
This gives you guix "FD" and its great on top of debian for emacs especially (and you can move a lot of your emacs packages into guix as well).
The apt packages handles most of this but its good to follow along a little -
https://guix.gnu.org/en/manual/devel/en/html_node/Installati...
This gives you guix "FD" and its great on top of debian for emacs especially (and you can move a lot of your emacs packages into guix as well).
The apt packages handles most of this but its good to follow along a little -
https://guix.gnu.org/en/manual/devel/en/html_node/Installati...
thank you! I will try this now and let you know... very helpful.
It amazes me that developers pick closed source Jetbrains and Microsoft spyware for the program they rely on to make a living when Emacs and Vim/Neovim get better by leaps and bounds every year. Emacs has packages that VSCode can only dream of having and with Emacs distributions or really just lsp-mode you can have a full fledged IDE with 0 fiddling. I recently did some digging into the editor usage of noteworthy programmers by going through interviews (usesthis.com was a great resource) and found that 99% of programmers whose names are recognizable are still using Vim/Emacs. Clearly these tools are not holding anyone back from doing great things.
Edit: Just yesterday HN was overtly critical of Warp for being a proprietary, closed source, telemetry laden terminal, but they’ll suddenly lose their morals when it comes to text editing over perceived conveniences of an IDE vs. a “text editor” with LSP.
The point of Vim/Emacs isn’t just that they are good editors. It is also you voting with your installs and money for free and open source tools. You already reap the benefits of the Linux ecosystem, the least you can do is help out by picking a FOSS editor.
Edit: Just yesterday HN was overtly critical of Warp for being a proprietary, closed source, telemetry laden terminal, but they’ll suddenly lose their morals when it comes to text editing over perceived conveniences of an IDE vs. a “text editor” with LSP.
The point of Vim/Emacs isn’t just that they are good editors. It is also you voting with your installs and money for free and open source tools. You already reap the benefits of the Linux ecosystem, the least you can do is help out by picking a FOSS editor.
I'm going to assume this isn't trolling and if it is, you fooled me.
I've use Vim professionally, as well as VSCode and Jetbrains IDEs and dabbled in Emacs - the idea that one can replicate what IntelliJ does for Java for instance in any other IDE or text editor is to me, nonsensical. The amount of configuration it would require in vim/neovim/vscode to replicate the refactoring ability of IntelliJ alone would take you longer to setup than it would to code whatever project you're working on.
Saying that Vim or Emacs have "zero fiddling" compared to Jetbrains IDEs is a statement that is so vastly different to my experience (doing plenty of fiddling in both) that I would love to hear the backstory of how IDEs hurt you.
I've use Vim professionally, as well as VSCode and Jetbrains IDEs and dabbled in Emacs - the idea that one can replicate what IntelliJ does for Java for instance in any other IDE or text editor is to me, nonsensical. The amount of configuration it would require in vim/neovim/vscode to replicate the refactoring ability of IntelliJ alone would take you longer to setup than it would to code whatever project you're working on.
Saying that Vim or Emacs have "zero fiddling" compared to Jetbrains IDEs is a statement that is so vastly different to my experience (doing plenty of fiddling in both) that I would love to hear the backstory of how IDEs hurt you.
To be fair Java is an outlier here (there are few others I guess, C# comes to mind) and I would consider it a weakness of a language to require a complex IDE to do anything nontrivial comfortably.
I agree with you tho, I was looking for my options to develop in Java with Emacs and decided to not even try.
I agree with you tho, I was looking for my options to develop in Java with Emacs and decided to not even try.
I've written C# professionally for many years, though it's far from my favorite language. I write 90% of it in Emacs, reserving Visual Studio for managing .csproj and .sln files and unit testing with the Visual Studio test framework. Once my workplace switches over to .NET Core, I hope to be able to get rid of those uses. Actually writing C# in Emacs has been fine for years, with Omnisharp, and now with LSP is about on par with VSCode, except you have the rest of Emacs available at a keystroke.
I've tried Java with LSP, and I think it's on par with Eclipse rather than JetBrains these days. The language server is fine, but I've never gotten it to understand, e.g., an Android Studio project.
I've tried Java with LSP, and I think it's on par with Eclipse rather than JetBrains these days. The language server is fine, but I've never gotten it to understand, e.g., an Android Studio project.
[deleted]
Emacs distributions are built for people who want zero fiddling. Fiddling in of itself is not bad. Fiddling is how you learn, and this is a profession that requires constant learning and tinkering.
Most of features of a modern IDE are unnecessary or are actively harmful to developing good code. Thinking, taking your time, writing as little code as possible, and organizing a project so it can be easily understood and modified with nothing other than a text editor are positives that an IDE actively inhibits by trying to be helpful.
You're going back and forth. On your first post, you talk about all the things Emacs/Vim have that VSCode/Jetbrains can't possibly have. On this one, you talk about how less features is a good thing. Regardless of where you actually stand on that particular point, you're still comparing apples to oranges.
It is also worth noting that I have never had an issue jumping from vim to VSCode (or vice-versa) on the same project. Neither of the two need any extra metadata or configuration. They just work, and I'll choose whichever tool makes sense for whatever I'm doing at the moment. As, frankly, I think everyone should. This fixation over one specific type of tool over another is unnecessary: go with whatever you are most productive with.
It is also worth noting that I have never had an issue jumping from vim to VSCode (or vice-versa) on the same project. Neither of the two need any extra metadata or configuration. They just work, and I'll choose whichever tool makes sense for whatever I'm doing at the moment. As, frankly, I think everyone should. This fixation over one specific type of tool over another is unnecessary: go with whatever you are most productive with.
What I mean is that the notion that Emacs/Vim require endless fiddling is unfounded. It caters to both the people that want something easy to use, and those that want endless customization. For those that want something easy to use, Emacs distributions are built and maintained by very experienced Emacs users who curate and put together an Emacs with everything you need. All you have to do is use it, which doesn't even require much learning thanks to `which-key` integration.
Productivity is a bad word. Productivity can mean low value busy work, or it can mean high value thinking. High value thinking leads to longer term success, because it is not easily bought or replaced. It requires an individual who has invested in a breadth and depth of knowledge by not choosing the path of least resistance. We should choose tools that optimize for this type of long term success. Choosing free and open source software is a choice for long term sustainability of our industry. Choosing a tool like Vim/Emacs is a long term choice towards individual success.
This is the philosophy I follow, and I have been very successful with it both financially and in terms of making an impact on the industry. It isn't novel either, I simply emulate the many, many expert programmers who universally choose to still use Emacs/Vim despite the existence of "smarter" IDEs.
Productivity is a bad word. Productivity can mean low value busy work, or it can mean high value thinking. High value thinking leads to longer term success, because it is not easily bought or replaced. It requires an individual who has invested in a breadth and depth of knowledge by not choosing the path of least resistance. We should choose tools that optimize for this type of long term success. Choosing free and open source software is a choice for long term sustainability of our industry. Choosing a tool like Vim/Emacs is a long term choice towards individual success.
This is the philosophy I follow, and I have been very successful with it both financially and in terms of making an impact on the industry. It isn't novel either, I simply emulate the many, many expert programmers who universally choose to still use Emacs/Vim despite the existence of "smarter" IDEs.
I'm not saying that yours is necessarily the case, of course I don't know, but I feel like lots of people that hold opinions like yours greatly underestimate the amount of functionality that comes with something like a Jetbrains IDE.
It's not even about the editor itself, nor the graphical or UX stuff. It's the crazy level of introspection and of understanding your code those IDEs bring. My daily experience is just insanely better than with anything else I've tried.
In something pretty weakly typed like PHP you can happily rename methods and classes, refactor and extract code, move around namespaces, and the IDE keeps track of everything for you. You also get very smart autocomplete, snippets, integrated debugger with REPL, the whole thing.
I've played around with all sorts of vim and emacs distributions and settings and nothing ever came close.
Maybe it's just I don't have the time to set it up propert ly. But if that's the case, it's still a point in my favor here.
It's not even about the editor itself, nor the graphical or UX stuff. It's the crazy level of introspection and of understanding your code those IDEs bring. My daily experience is just insanely better than with anything else I've tried.
In something pretty weakly typed like PHP you can happily rename methods and classes, refactor and extract code, move around namespaces, and the IDE keeps track of everything for you. You also get very smart autocomplete, snippets, integrated debugger with REPL, the whole thing.
I've played around with all sorts of vim and emacs distributions and settings and nothing ever came close.
Maybe it's just I don't have the time to set it up propert ly. But if that's the case, it's still a point in my favor here.
I have used Jetbrains IDEA and Clion extensively to understand the other side. An IDEs heavy introspection isn’t necessary, and perhaps actively harmful towards writing and reading code. It’s rigid policy over tools like git is certainly actively harmful. If it takes an IDE to write your code, then it will likely take an IDE to read your code. They are tools that allow you to take shortcuts were you shouldn’t, and rob you of valuable knowledge. Programming is about thinking and continual learning and IDEs sell you the complete opposite. They help you build unsustainable projects where only a computer can understand the binary AND the source code.
The other point here is that the gap between IDE and text editor has only gotten smaller over the years and was closed considerably by LSPs. It may not be a perfect match in features, but small niceties are not an excuse for using closed source spyware for your text editor. They also do not make the difference between the success or failure of one’s work.
You can write shitty code in Emacs as well. I'm certainly guilty of that.
Steve Jobs once said that a computer is like a bicycle for your mind. It's an amplifier of sorts and an IDE fits into that metaphor. It will amplify the good and the bad. It's up to you, as a professional, to develop the skills necessary to use the tools in ways that make sense for whatever it is you are working on.
Steve Jobs once said that a computer is like a bicycle for your mind. It's an amplifier of sorts and an IDE fits into that metaphor. It will amplify the good and the bad. It's up to you, as a professional, to develop the skills necessary to use the tools in ways that make sense for whatever it is you are working on.
> If it takes an IDE to write your code, then it will likely take an IDE to read your code
I can agree with that. However, the real world is filled with random legacy projects, massive enterprise applications where a dozen developers came and went over a decade, quick-and-dirty MVPs and everything in between.
If you are paid to write well-crafted code that fits nicely within the limitations of your editor, that's great. But for the rest of us who have to deal with the realities of this industry, a helpful IDE makes it so much bearable.
I can agree with that. However, the real world is filled with random legacy projects, massive enterprise applications where a dozen developers came and went over a decade, quick-and-dirty MVPs and everything in between.
If you are paid to write well-crafted code that fits nicely within the limitations of your editor, that's great. But for the rest of us who have to deal with the realities of this industry, a helpful IDE makes it so much bearable.
As with every tool you should of course have the knowledge to do things properly without the tool, but not using a good tool is like saying we should use old style shovels instead of a modern excavator because the excavator shields us from understanding the back breaking process of the shovel. Now it is true that we programmers could need a good workout but doing things more infectively because of some immeasurable consideration of what is "harmful" is probably the reason we are still stuck in the 70s of tooling in many languages.
However what I do think is important is that every project should not actively discriminate against any of the alternative tools, in every project I manage I encourage every programmer to use the editor/IDE, shell or operating system they are most conformable with (but they need of course to manage their environment themselves and deliver the code in time).
However what I do think is important is that every project should not actively discriminate against any of the alternative tools, in every project I manage I encourage every programmer to use the editor/IDE, shell or operating system they are most conformable with (but they need of course to manage their environment themselves and deliver the code in time).
I can write the same code significantly faster with an IDE because of all the autocompletion and code navigation. I don't use the version control features other than the occasional blame, preferring to stick to a command line for that.
The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into cheap labor would have been successful, which it wasn't. Software engineering is still part art, part math, and 90% a mental activity and not a physical one.
> The speed at which you write code is meaningless.
That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone.
There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point.
[1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.
That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone.
There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point.
[1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.
This is simply not my experience. For example, an IDE lets you rename a variable or type in a semantic fashion, making it easier for me to iterate on names and land on something that people understand.
There's a huge mental component to coding (I doubt it's 90% though). In any case, an IDE makes that easier by getting the boring physical stuff out of the way quicker.
And the speed at which you write code is quite meaningful. I can easily write 1000 lines of high-quality Rust code on a good day with just the LSP (rust-analyzer) for support. More recently, I started a project that hit some bugs in rust-analyzer -- working on it was a comparatively miserable experience.
Edit: Never mind, I see above that you're comparing a full-fledged IDE to just using an LSP. I consider LSP to be in the IDE category; I agree that LSP is just about where I want to be and that a full JetBrains-like IDE is overkill. What I don't like is not having any sort of code completion or rename support.
There's a huge mental component to coding (I doubt it's 90% though). In any case, an IDE makes that easier by getting the boring physical stuff out of the way quicker.
And the speed at which you write code is quite meaningful. I can easily write 1000 lines of high-quality Rust code on a good day with just the LSP (rust-analyzer) for support. More recently, I started a project that hit some bugs in rust-analyzer -- working on it was a comparatively miserable experience.
Edit: Never mind, I see above that you're comparing a full-fledged IDE to just using an LSP. I consider LSP to be in the IDE category; I agree that LSP is just about where I want to be and that a full JetBrains-like IDE is overkill. What I don't like is not having any sort of code completion or rename support.
> For example, an IDE lets you rename a variable or type in a semantic fashion, making it easier for me to iterate on names and land on something that people understand.
The rename functionality is helpful, mainly for names that are referenced throughout the codebase. For locals it's not hard to replace this functionality - narrow the buffer to the scope you want (expand-region helps), then use iedit or multiple-cursors to perform the change. For public names referenced in multiple places you can use grep-find, then wgrep with iedit or multiple-cursors to do the rename. It's more work, and you risk renaming things you didn't intend to rename (ie. it's not semantic), but it works also with languages that have no IDEs or LSP implementation, so it's worth knowing.
The rename functionality is helpful, mainly for names that are referenced throughout the codebase. For locals it's not hard to replace this functionality - narrow the buffer to the scope you want (expand-region helps), then use iedit or multiple-cursors to perform the change. For public names referenced in multiple places you can use grep-find, then wgrep with iedit or multiple-cursors to do the rename. It's more work, and you risk renaming things you didn't intend to rename (ie. it's not semantic), but it works also with languages that have no IDEs or LSP implementation, so it's worth knowing.
>If it takes an IDE to write your code, then it will likely take an IDE to read your code
There is nothing wrong with this. We shouldn't let old text editors hold back the productivity of programmers.
There is nothing wrong with this. We shouldn't let old text editors hold back the productivity of programmers.
It's not "old text editors". There are current tools for viewing source (pull requests/diffs a prime example) that are extremely good at what they do but are language agnostic. As is so often said, code is read more than it's written. If I can't understand the source without pulling it into my IDE, that adds a lot of friction to these reading tasks.
Those other tools you work with can become more advanced to in order to keep up with the improvements your IDE offers. You want to inline a diagram to your code? That image should show up both in your editor and in the diff.
There is lots wrong with this and with this mind set. This is not about "productivity" at all but about being auditable and working in a team.
Expecting your teammates to use an IDE does not get it the way of working in a team. In my experience as a team we have a default IDE for everyone to use and a configuration file for it so everyone's is using the same settings. Usually you could use a different IDE if you could configure it to act similar, but making sure everyone uses the same tools doesn't prevent you from working as a team.
For a long time I would have agreed, but LSP has democratized the space quite a bit. If an editor has a good LSP story, it’ll be able to do all of the renaming, extracting, finding references, etc.
Eventually, maybe.
But Java, Python, and Go are just so good in the IntelliJ suite. Switching between VSCode at home and IntelliJ at work make it readily apparent that there’s still a gap.
I'm frequently very impressed with Pycharm's autocomplete suggestions. It is very context sensitive, and frequently seems to guess what I'm trying to do next.
As someone who uses Emacs for (almost) all my editing needs and has done for about 17 years I just don’t understand how you can have these beliefs. LSP-mode is great and now with things like Spacemacs and Doom Emacs getting setup and getting things reasonably configured is a lot easier. But still!
VSCode is pretty cool and is easy to use right out of the box. It does some things with ease that would be very hard with Emacs. And JetBrains looks like it does some amazing stuff.
I still end up sticking with Emacs myself, but the idea that that it’s perfect and simple and for everyone and that there’s no sensible reasons to use the other options is just insane.
VSCode is pretty cool and is easy to use right out of the box. It does some things with ease that would be very hard with Emacs. And JetBrains looks like it does some amazing stuff.
I still end up sticking with Emacs myself, but the idea that that it’s perfect and simple and for everyone and that there’s no sensible reasons to use the other options is just insane.
It amazes me there are Emacs users that don’t understand the importance of free software. You’re using the editor devised by the free software foundation, but you only want to talk about convenience. Convenience is not an excuse to switch to corporate made closed source spyware.
How many of us do you think work on "free" software? I write proprietary software and i use proprietary software to do it because it pays my mortgage. I drank the fsf Kool aid as a kid, then i grew up and had to put a roof over my head and my children's. It's great that some people get to make a living producing free as in speech software, but that's kind of like getting into the NBA. The rest of us have to contend with reality
You're presenting a false dichotomy: most software is neither proprietary or FOSS; it's in-house, custom-developed functionality, that's never released/available outside of the business that created it.
Its only "user" is the business that made it; they have full access to the source (unless they deleted it; whoops!), are not bound by its copyright (since they're the owners), etc. The FSF has no problem with that.
Although my first job was working on FOSS, all the ones since have been working on such bespoke, in-house software. To be honest, I don't think I've ever seen a job ad for proprietary software (as in, closed-source software that runs on end-user machines).
A few subtleties:
- Javascript is probably a glaring exception. Opinions differ on whether it should count as shipping proprietary software (the FSF think it is, many HNers probably consider it less clear-cut). For what it's worth, the little JS I've written professionally has always been of a progressive, site-still-works-without-it form.
- Some of that never-released software may be accessible to others, e.g. Google's search software can be accessed via google.com. The AGPL has an interesting take on that particular niche.
- Sometimes the human end-users of this software have very limited access/control over it, e.g. if Walmart maintains its own checkout software, those operating the checkouts probably can't access the source, etc. However, that's nothing to do with copyright, FOSS, etc. it's just a business decision, presumably covered by employment contracts (e.g. "in the course of your work you may be given access to computer systems; these are confidential, and you must not hack/compromise/etc.").
Its only "user" is the business that made it; they have full access to the source (unless they deleted it; whoops!), are not bound by its copyright (since they're the owners), etc. The FSF has no problem with that.
Although my first job was working on FOSS, all the ones since have been working on such bespoke, in-house software. To be honest, I don't think I've ever seen a job ad for proprietary software (as in, closed-source software that runs on end-user machines).
A few subtleties:
- Javascript is probably a glaring exception. Opinions differ on whether it should count as shipping proprietary software (the FSF think it is, many HNers probably consider it less clear-cut). For what it's worth, the little JS I've written professionally has always been of a progressive, site-still-works-without-it form.
- Some of that never-released software may be accessible to others, e.g. Google's search software can be accessed via google.com. The AGPL has an interesting take on that particular niche.
- Sometimes the human end-users of this software have very limited access/control over it, e.g. if Walmart maintains its own checkout software, those operating the checkouts probably can't access the source, etc. However, that's nothing to do with copyright, FOSS, etc. it's just a business decision, presumably covered by employment contracts (e.g. "in the course of your work you may be given access to computer systems; these are confidential, and you must not hack/compromise/etc.").
I just can't think why you might have trouble convincing people to try it :p
But you yourself bought up convenience in your original comment. If your argument is a purely moral one then no need to specify how little fiddling is required to get LSP working. But I do think if your only argument is yelling at people about it being immoral to use VSCode you ain't going to get far. Why not talk about the cool things Emacs has while acknowledging the things it still has that could be improved?
VSCode is open source by the way, MIT not GPL but you can go compile it yourself (or use VSCodium).
But you yourself bought up convenience in your original comment. If your argument is a purely moral one then no need to specify how little fiddling is required to get LSP working. But I do think if your only argument is yelling at people about it being immoral to use VSCode you ain't going to get far. Why not talk about the cool things Emacs has while acknowledging the things it still has that could be improved?
VSCode is open source by the way, MIT not GPL but you can go compile it yourself (or use VSCodium).
> VSCode is open source by the way ...
The extensions marketplace requires you to use the closed source version. Quite a few of VS Code's best extensions are also completely closed source. VS Code is already on the same path that Google took with "Open Source" Android.
The extensions marketplace requires you to use the closed source version. Quite a few of VS Code's best extensions are also completely closed source. VS Code is already on the same path that Google took with "Open Source" Android.
The largest spy organisation in the world, Google, uses mostly free software.
I'm sure your boss will be real impressed by how ethical you are as your colleagues get their work done 2x faster than you
I've been using vi since 1985, built a suite of development tools based on a custom fork of Elvis in the 90's and have been using vim professionally since the mid 90's. I've dabbled with emacs on and off for most of the 80's and 90's, including supporting a subset of the Elvis tools on emacs. I still fire up emacs now and then to see what's up.
The idea that either emacs or vim are a "0 fiddling" drop in replacement for Goland or Pycharm is ludicrous. I probably could get vim up to the point where I was as productive as I am with Goland/PyCharm but it would definitely NOT be a "0 fiddling" process.
I can't believe debugging and learning a new code base would be ANYWHERE as easy with vim as with Goland/PyCharm.
Also, both Goland and PyCharm have pretty good vim plugins so my day to day editing IS vim. Sometimes I hit stuff that I can do faster in actual vim and I switch over.
The idea that either emacs or vim are a "0 fiddling" drop in replacement for Goland or Pycharm is ludicrous. I probably could get vim up to the point where I was as productive as I am with Goland/PyCharm but it would definitely NOT be a "0 fiddling" process.
I can't believe debugging and learning a new code base would be ANYWHERE as easy with vim as with Goland/PyCharm.
Also, both Goland and PyCharm have pretty good vim plugins so my day to day editing IS vim. Sometimes I hit stuff that I can do faster in actual vim and I switch over.
Honest question from someone who never used any product from JetBrains: what those IDEs gives you in order to learn/debug a new codebase in such easy way?
Not OP but having used both PyCharm and Emacs, I really like PyCharm's visual debugging - when at a breakpoint you can see all variables in memory, their types, dictionaries and objects are nested. A lot easier than vanilla pdb.
This kind of comment gives us emacs-users bad reputation. Emacs isn't perfect, dissing people that don't use it is not helping anyone.
"you can have a full fledged IDE with 0 fiddling" - that is 100% not a thing that has ever happened to me whenever I go and look at emacs/vim!
Modal editing is not really something that is needed anymore, and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
Modal editing is not really something that is needed anymore, and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
I agree that neither vim nor emacs are "0 fiddling" [0]. However,
> Modal editing is not really something that is needed anymore
Honestly, I'm not sure it was ever "needed", but that's not really the point IMO.
It's hard for me to think about editing text in any way other than how Vim handles it. Part of that is admittedly just familiarity, but I think there's also something to the idea of treating strings as more than just arrays of characters. Once you start thinking about your text and code as nouns of various sizes and granularity [0], losing those feels cumbersome.
In order to achieve the latter, you either need modality or a huge number of control hotkeys. Vim takes the former approach while Emacs (and IDEs) takes the latter.
So yes, you can achieve the "crowning feature" of Vim (IMO) without modality, but I don't see modality itself as being a pro or a con as much as a design choice. If you don't prefer it, more power to you.
> and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
This also works the other way. I don't want to have to learn where all the buttons are in $IDE just to move my text about. Thankfully, many IDEs include a Vim mode or plugin for it, but those are never quite the same.
Every tool has some level of learning curve. If you want it to be more flexible, powerful, and to get the most out of it, that learning curve is gonna be steeper. That goes for both IDEs with their buttons and Vim with its modal commands.
For something that you might use for hours on end every single day for professional work, putting in some time to learn it pays dividends. For both Vim and IDEs.
[0]: In vim parlance, this is effectively what "movements" operate on. They sort of define these objects via implication.
> Modal editing is not really something that is needed anymore
Honestly, I'm not sure it was ever "needed", but that's not really the point IMO.
It's hard for me to think about editing text in any way other than how Vim handles it. Part of that is admittedly just familiarity, but I think there's also something to the idea of treating strings as more than just arrays of characters. Once you start thinking about your text and code as nouns of various sizes and granularity [0], losing those feels cumbersome.
In order to achieve the latter, you either need modality or a huge number of control hotkeys. Vim takes the former approach while Emacs (and IDEs) takes the latter.
So yes, you can achieve the "crowning feature" of Vim (IMO) without modality, but I don't see modality itself as being a pro or a con as much as a design choice. If you don't prefer it, more power to you.
> and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
This also works the other way. I don't want to have to learn where all the buttons are in $IDE just to move my text about. Thankfully, many IDEs include a Vim mode or plugin for it, but those are never quite the same.
Every tool has some level of learning curve. If you want it to be more flexible, powerful, and to get the most out of it, that learning curve is gonna be steeper. That goes for both IDEs with their buttons and Vim with its modal commands.
For something that you might use for hours on end every single day for professional work, putting in some time to learn it pays dividends. For both Vim and IDEs.
[0]: In vim parlance, this is effectively what "movements" operate on. They sort of define these objects via implication.
As long as your input device is optimized for inserting text (and your keyboard certainly is) modal editing is surely something desirable for programming.
You might be surprised that many of us use Vim or Emacs and also VSCode or Sublime or Visual Studio or IntelliJ or XCode or ...
Every tool has strengths and weaknesses. Plus, some of us enjoy learning new tools and find it fun to switch things up occasionally.
Every tool has strengths and weaknesses. Plus, some of us enjoy learning new tools and find it fun to switch things up occasionally.
Cheers to this. My primary is emacs, but I consider myself a pretty solid vim user, and I’ve been picking up VSCode for typescript stuff.
Even the TypeScript LSP is extremely featureful in Emacs. I thought about using VS Code for that stuff, but decided to see how the experience was in Emacs first, and now I'm no longer considering VS Code.
How do I go about learning emacs when my job requires me to work in a M$ environment, and I have limited free time? I tried learning and felt overwhelmed, and I would like to make strides to make vim or emacs my primary editors for home use, but Visual Studio / Jetbrains just make development incredibly easier to not let the tools prevent me from just writing the code.
There are "distributions" such as Doom Emacs or Lunar Vim to get started with a setup from the get-go.
Otherwise, the website linked above is a good way to get started, there's also an integrated tutorial in Emacs (C-h t).
Otherwise, the website linked above is a good way to get started, there's also an integrated tutorial in Emacs (C-h t).
With 0 fiddling? not my experience at all. has something changed?
I use Emacs for lots of things, but I've long since changed to Pycharm for Python programming. That's been close to 0 fiddling for real. Its been pretty good for JS programming too.
I use Emacs for lots of things, but I've long since changed to Pycharm for Python programming. That's been close to 0 fiddling for real. Its been pretty good for JS programming too.
I remember when one of my first professional mentors jokingly said that all those years spent in university was to write your own .emacs file so you had one when your career started. He was a bit shocked that mine was almost empty.
Good luck writing an iOS app in emacs.
(Well, good luck writing one in Xcode, for that matter.)
(Well, good luck writing one in Xcode, for that matter.)
Does Emacs ship with LSP support out of the box? They've had a habit in the past of ignoring similar features that were arbitrarily perceived as "proprietary" or not open enough.
Don't think out of the box, but https://github.com/emacs-lsp/lsp-mode works rather well with emacs 28 from my experience. Emacs "distros" such as Spacemacs and Doomemacs both make using it a nearly "out of the box" experience.
(not supporting the editor/ide war troll, just trying to contribute some useful info here)
(not supporting the editor/ide war troll, just trying to contribute some useful info here)
> It amazes me that developers pick closed source Jetbrains
JetBrains Intellij Idea Community Edition is open source
JetBrains Intellij Idea Community Edition is open source
Jetbrains products are only partially open source, which makes them non-free and still spyware due to telemetry we can’t see.
> Jetbrains products are only partially open source
You mean the repository at [0] contains code which is not licensed under an open source license? The only license mentioned at the root is Apache 2.
[0] https://github.com/JetBrains/intellij-community
You mean the repository at [0] contains code which is not licensed under an open source license? The only license mentioned at the root is Apache 2.
[0] https://github.com/JetBrains/intellij-community
Do you have a reference for "Jetbrains products are ... spyware due to telemetry we can’t see."
That's the "beauty" of phrasing it like that. It's impossible to prove or disprove.
It is packed in a small teapot orbiting the sun somewhere between Earth and Mars.
If the source code of what you are running is not fully available, assume it contains telemetry or data collection.
I assume every stranger that calls me is a scammer. That does NOT mean that everyone who calls me IS a scammer.
I use neovim within vscode. All the power of vim but with intellisense and debugging working with minimal configuration.
As for telemetry, all my work lives in Azure so I assume Microsoft are already collecting what they want about our codebase (which is publicly visible) already.
As for telemetry, all my work lives in Azure so I assume Microsoft are already collecting what they want about our codebase (which is publicly visible) already.
Cool, any thoughts on what's new in Emacs 28.1?
You miss the point. I want to click 3 buttons and have a usable IDE. Nothing will ever replace visual studio's debugging GUI.
Emacs it's not an IDE (out of the box), so it's not your use case, obviously.
If OP wants to compare Emacs to Visual Studio and Jetbraines IDE's, then we are going to compare features.
Go ahead comparing apples and oranges, what can I say.
OP literally said emacs has extensions IDE's will never have.
I've never seen an IDE with an equivalent to smart-dash-mode:
http://malsyned.net/smart-dash.html
http://malsyned.net/smart-dash.html
I used Emacs for 20 years, contributed to popular open source emacs projects, and am the maintainer of a couple of emacs packages with small numbers of users.
It's wonderful and extremely powerful having everything in lisp; don't bother with emacs if you're not interested in writing lisp.
One silly thing that I could never get to grips with is the way the minibuffer always seems to get stuck asking me a question, but the cursor isn't in the minibuffer. Or it's in some sort of recursive minibuffer mode. So many times I've just mashed C-g repeatedly in irritation!
I stopped using Emacs last year in order to access the high quality LSP experiences that are available for Typescript and Rust and other languages in VSCode. I'm firly happy with the configurability of VSCode and generally fairly happy with the move. VSCode needs Emacs' window-configuration registers though.
It's wonderful and extremely powerful having everything in lisp; don't bother with emacs if you're not interested in writing lisp.
One silly thing that I could never get to grips with is the way the minibuffer always seems to get stuck asking me a question, but the cursor isn't in the minibuffer. Or it's in some sort of recursive minibuffer mode. So many times I've just mashed C-g repeatedly in irritation!
I stopped using Emacs last year in order to access the high quality LSP experiences that are available for Typescript and Rust and other languages in VSCode. I'm firly happy with the configurability of VSCode and generally fairly happy with the move. VSCode needs Emacs' window-configuration registers though.
> don't bother with emacs if you're not interested in writing lisp.
Strong disagree. I used Emacs as a power user heavily for about a decade with virtually no elisp knowledge (beyond simple conditionals and setting variables - I couldn't write a loop for example).
Once I learned elisp ... it hasn't been a game changer. Sure, occasionally I tweak things the way I like it with custom elisp code, but there are enough config options and packages out there to do what I need without my having to write elisp code.
Strong disagree. I used Emacs as a power user heavily for about a decade with virtually no elisp knowledge (beyond simple conditionals and setting variables - I couldn't write a loop for example).
Once I learned elisp ... it hasn't been a game changer. Sure, occasionally I tweak things the way I like it with custom elisp code, but there are enough config options and packages out there to do what I need without my having to write elisp code.
FWIW lsp-mode does a great job of integrating with language servers in emacs. I and two of my coworkers use emacs with rust-analyzer, and it’s generally been a very positive experience.
> One silly thing that I could never get to grips with is the way the minibuffer always seems to get stuck asking me a question, but the cursor isn't in the minibuffer. Or it's in some sort of recursive minibuffer mode. So many times I've just mashed C-g repeatedly in irritation!
This happens to me all the time too! Anyone have a fix?
This happens to me all the time too! Anyone have a fix?
The thing you're looking for is `M-x top-level`. It exits all recursive editing levels and active minibuffers.
Thanks, that's perfect. I still have a running emacs instance for magit, and editing elisp at least, so I can still make use of your suggestion. (I made it so that C-g with prefix arg calls top-level; not sure if you'll think that UI makes sense).
The post yesterday about Pharo 10, and the Lisp Curse repost has me thinking about text editors again. I think that some fusion of the introspection abilities of Smalltalk with the good parts of Emacs might allow us to create the text editor of the future™. One that take everything good about Lisps and everything good about programming in Smalltalk. I'd need to actually explore how Smalltalk does its IDE environment to be able to comment more, but I was initially very impressed with the programmability of it during the video I watched about it.
I aspired to learn Emacs but gave up a number of times.
It's in that category of things that I believe would be Good For Me but that have such high activation energy that it never becomes a high enough priority. It's like the documentary I keep skipping over in my streaming queue, the free weights gathering dust in the basement, or the guitar I finally gave away after having only learned a few chords.
There's got to be a word to describe the realization that something is probably never going to be high enough priority to me to be worth the investment.
It's in that category of things that I believe would be Good For Me but that have such high activation energy that it never becomes a high enough priority. It's like the documentary I keep skipping over in my streaming queue, the free weights gathering dust in the basement, or the guitar I finally gave away after having only learned a few chords.
There's got to be a word to describe the realization that something is probably never going to be high enough priority to me to be worth the investment.
The best reason to use Emacs is that it’s fun. Would you learn the guitar because it’s “good for you” to learn it or because you enjoy playing music? I think the only sustainable motivation is the latter. If learning Emacs is simply a chore with an abstract promise of “productivity” as a reward you’re not missing out on anything.
By "Good For Me" I don't just mean productivity-wise, I mean a positive and rewarding experience. And frankly I do not know whether I would enjoy using Emacs. (I similarly don't know whether I would enjoy playing music.)
But I know that learning Emacs is a chore. I did not enjoy having to relearn common interaction concepts like windows, frames, yank, kill. I did not enjoy retraining muscle-memory (or modifying bindings) because editing and navigation shortcuts don't match the standards that have been codified in every other desktop text area. I did not enjoy the endless search for the right distribution/mode/extension to solve a particular problem. I did not enjoy that none of these are generalizable skills that transfer beyond the esoteric priesthood of Emacs use.
I liked the core concepts in principle and I enjoyed the new perspective it provided, like peeking into an alternate universe with a parallel evolutionary path.
Eventually life intervened and I had to retreat back to editors that take minutes to learn rather than hours or days. I suspect I'll give it another go someday when I can afford to devote the better part of a weekend to it, perhaps when the kids are older.
But I know that learning Emacs is a chore. I did not enjoy having to relearn common interaction concepts like windows, frames, yank, kill. I did not enjoy retraining muscle-memory (or modifying bindings) because editing and navigation shortcuts don't match the standards that have been codified in every other desktop text area. I did not enjoy the endless search for the right distribution/mode/extension to solve a particular problem. I did not enjoy that none of these are generalizable skills that transfer beyond the esoteric priesthood of Emacs use.
I liked the core concepts in principle and I enjoyed the new perspective it provided, like peeking into an alternate universe with a parallel evolutionary path.
Eventually life intervened and I had to retreat back to editors that take minutes to learn rather than hours or days. I suspect I'll give it another go someday when I can afford to devote the better part of a weekend to it, perhaps when the kids are older.
> Adding right-click context menus is a natural extension to Emacs’s already-extensive support for the mouse (even if a lot of people don’t use it.)
If emacs could support plan9 acme-style chords with custom commands then I'd probably use the mouse a lot more in it - acme convinced me that mousing around can be just as fast as being on the keyboard if the UX is well designed.
If emacs could support plan9 acme-style chords with custom commands then I'd probably use the mouse a lot more in it - acme convinced me that mousing around can be just as fast as being on the keyboard if the UX is well designed.
Acme was my daily driver for a couple of years (mainly writing). Went back to Emacs because of org-mode; it's just _that_ powerful.
I mostly miss chording and Acmes way of finding and opening files. It was intuitive and nothing felt hidden; like the commands and dired feels in emacs.
But I guess Acmes functionality could be added to emacs by elisp, no?
I mostly miss chording and Acmes way of finding and opening files. It was intuitive and nothing felt hidden; like the commands and dired feels in emacs.
But I guess Acmes functionality could be added to emacs by elisp, no?
Yeah, I never really looked at mouse binding, but does look quite simple.
This implements acme chording for copy/paste and the approach looks straightforward: https://github.com/akrito/acme-mouse/blob/master/acme-mouse....
And this package looks like a cool way to recreate the context sensitive text actions: https://github.com/cmpitg/wand
Combining the approach from the first and the wand package could potentially surpass the acme experience by making it easier to customize and extend.
My friend joked about how I'm religious about the keyboard, but really it's about the right tool for the job, and if I had an acme-like mouse experience with emacs I'd def be mousing around more often. Funny that compared to normal people I'm a keyboard fanatic but compared to majority of emacs users I'm on the mouse way more often :)
This implements acme chording for copy/paste and the approach looks straightforward: https://github.com/akrito/acme-mouse/blob/master/acme-mouse....
And this package looks like a cool way to recreate the context sensitive text actions: https://github.com/cmpitg/wand
Combining the approach from the first and the wand package could potentially surpass the acme experience by making it easier to customize and extend.
My friend joked about how I'm religious about the keyboard, but really it's about the right tool for the job, and if I had an acme-like mouse experience with emacs I'd def be mousing around more often. Funny that compared to normal people I'm a keyboard fanatic but compared to majority of emacs users I'm on the mouse way more often :)
Did you use https://code.google.com/archive/p/acme-sac/ or acme in p9 or inferno?
I only had limited experience with acme in p9 during some experiments with distributed audio, but once it clicked with me it made a huge impact on me - similar to when I first grokked emacs.
I only had limited experience with acme in p9 during some experiments with distributed audio, but once it clicked with me it made a huge impact on me - similar to when I first grokked emacs.
Is mouse-mouse enabled by default?
Can the insertion point be moved by clicking in a particular location?
As of recent versions of macOS, emacs isn't included by default. Last I tried, in terminal-mode emacs, the answer to the above questions seems to be no - with no reasonable explanation why this is the case.
I'm more than willing to do everything else from the keyboard, but these are basic oversights that have yet to be corrected.
EDIT: Is mouse-tracking actually the feature that enables this behavior?
Can the insertion point be moved by clicking in a particular location?
As of recent versions of macOS, emacs isn't included by default. Last I tried, in terminal-mode emacs, the answer to the above questions seems to be no - with no reasonable explanation why this is the case.
I'm more than willing to do everything else from the keyboard, but these are basic oversights that have yet to be corrected.
EDIT: Is mouse-tracking actually the feature that enables this behavior?
On Debian with the distro package, I never even thought about mouse integration. (On the Xorg interface. So much basic stuff - not emacs stuff, but really basic stuff - has been moving into DEs that I don't think the bare console is usable anymore.)
The insertion point is moved by clicking and by using the scroll wheel (now that I've thought about it, maybe I should change that second one), clicking and dragging and double click change the selection.
I normally don't use the mouse, but for moving text between windows it's nice.
The insertion point is moved by clicking and by using the scroll wheel (now that I've thought about it, maybe I should change that second one), clicking and dragging and double click change the selection.
I normally don't use the mouse, but for moving text between windows it's nice.
M-x xterm-mouse-mode gives an experience in the console that's pretty darn faithful to the full GUI when it comes to mouse interaction. Clicking, selection, and scroll wheel all work pretty much as expected. Even menus and pop-menus work; the new TTY menu in 28.1 is pretty slick!
Confession: I'm a BBEdit user most of the time, so take my questions here with a grain of salt. Although I don't need it often, I still felt the impulse to take a side w.r.t emacs and vi.
I'll see if I can dig out my old init.el from backups and try to get it up and running with 28.1. I actually hadn't heard about the scroll wheel stuff before, so that might be one way to solve this for me.
I'll see if I can dig out my old init.el from backups and try to get it up and running with 28.1. I actually hadn't heard about the scroll wheel stuff before, so that might be one way to solve this for me.
Is there a setting in Customize to control whether to use init.el or .emacs for configuration? Trying to set symlinks from $HOME to another directory and it's fighting me...
I believe the code that controls that is all in startup.el (or startup.el.gz) in the Emacs distribution. You can find the documentation here:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Fi...
I do know that ~/.emacs takes precedence over ~/.emacs.d/init.el. I've taken advantage of that in the past to keep all the public configuration that I share between machines in ~/.emacs.d/init.el, and then on my work machine I had a ~/.emacs that wraps a (load "~/.emacs.d/init") with some company-specific configuration.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Fi...
I do know that ~/.emacs takes precedence over ~/.emacs.d/init.el. I've taken advantage of that in the past to keep all the public configuration that I share between machines in ~/.emacs.d/init.el, and then on my work machine I had a ~/.emacs that wraps a (load "~/.emacs.d/init") with some company-specific configuration.
The stink of it is, I had this working: mouse-mode, correct symlinks, all of it...for like 10 mins. before I realized, 'oh crud, I forgot to disable something' and in my haste of mucking w/ settings, tossed the good init I had trying to ID what was missing.
Self: You're dumb
I think I can recreate it, but I've got other stuff to do too, so this may get paused for a while - Monterey beckons as I have yet to take that plunge, although I really should soon.
Self: You're dumb
I think I can recreate it, but I've got other stuff to do too, so this may get paused for a while - Monterey beckons as I have yet to take that plunge, although I really should soon.
emacs "gui" perfectly supports the mouse out of the box.
For use in a terminal (after using both for some time, I find the gui version better tbh), see https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
For use in a terminal (after using both for some time, I find the gui version better tbh), see https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
I personally think GUI mode is simply better. There is no real advantage to running emacs in a terminal imo.
Hard disagree. Sometimes the terminal is the most efficient way to run Emacs on a machine in a remote data center that has a mountain of CPUs, GPUs, memory, and disk. TRAMP can be slow and inefficient. A LSP server process on a huge monorepo can chew up a large amount of memory and CPU on startup. Running all of this stuff locally on the actual hardware your code needs to run on is great.
TRAMP is great, but to me it never feels the same as running locally. OTOH ssh -X (i.e. X forwarding) works for me for exactly this specific case (large and powerful remote dev box).
Incidentally my current setup is that I'm WFH and RDP'ing into my windows desktop, where I run VNC to our xvnc server where I ssh -X to the dev box where I run GUI emacs. It is surprisingly usable (I can also skip the RDP and run VNC directly if needed).
Incidentally my current setup is that I'm WFH and RDP'ing into my windows desktop, where I run VNC to our xvnc server where I ssh -X to the dev box where I run GUI emacs. It is surprisingly usable (I can also skip the RDP and run VNC directly if needed).
> to run Emacs on a machine in a remote data center that has a mountain of CPUs, GPUs, memory, and disk
But then why not run the daemon on that server and the GUI locally?
But then why not run the daemon on that server and the GUI locally?
Have you actually tried that? I know the server _can_ expose a TCP socket but it's not clear to me if it's intended to work across machines.
Thank you to everyone that contributed to Emacs for another great release :) (also thank you Mickey for explaining all the changes!)
Given all the emacs ninjas here - what’s the best way to do JSX/TSX formatting while playing nice with js2-mode, tide and web-mode? I’ve been stuck for months on finding a good config and almost wanted to move to VS Code to try it out. Then, while using it I just couldn’t do without emacs buffers and panels flexibility — so moved back :))
I gave up on getting these modes to consistently format. It seems really fragile and never quite right. So now I just have prettierjs set up and I don’t have to think about it.
prettier-emacs[0] works well, and IIRC I think the JS/TS language servers can handle formatting, if you’re using LSP or eglot!
[0]: https://github.com/prettier/prettier-emacs
[0]: https://github.com/prettier/prettier-emacs
[deleted]
Prettier the buffer every once in a while.
Tide mode can be pretty annoying with JSX. I try to be okay with temporary syntax imperfections and get in the zone with the actual changes.
Tide mode can be pretty annoying with JSX. I try to be okay with temporary syntax imperfections and get in the zone with the actual changes.
I’m interested in emacs / org-mode / org-roam. My goal is to have a local notes solution (replacing Obsidian, Apple Notes), and have the notes automatically published on the web as a crosslinked personal knowledge base. I have somewhat achieved this with Obsidian/markdown files + git + Hugo + Render. I write stuff. Check it into git. Push, and it deploys as a website. Feel pretty good about cobbling that together. But Obsidian/markdown is tough to replicate the cross-link nature & ease or use of a wiki, and it still doesn’t help out with Task, calendar, etc.
I’ve taken a couple swings at setting up Emacs… oof, but as a newbie to the ecosystem, but frankly its just been tough to plow through. Each guide/tutorial seems to have a whole different set of packages, settings, etc; then we get into Doom emacs, etc. I’ve got keyboard shortcuts printed out - but I still end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them.
Truly, it reminds me of when I jumped head first in the Java ecosystem, trying to figure out (1) java, (2) intelliJ, (3) Spring boot. Too many simultaneous brain battles…
What I’m hoping to find is a “Zero to Functioning personal information system (notes, todo, contacts, calendar, kb)” guide. I suppose, written for a willing & motivated newb?
From reddit, online tutorials, walkthru videos - it SEEMS the pieces are out there. But I’m hoping to find the guy who figured this all out a year ago, documented a functional-but-opinionated stack / workflow, and I could follow that for awhile (as training wheels).
Can anyone suggest something like this? I’d be even be willing to pair up with someone and document/publish this, if it doesn’t exist.
I mentioned it on another Emacs HN thread: I’m convinced of the power of this stack, but I’m hoping someone does the “Unix —> NeXT -> MacOS”, and puts together the Easy Button of this.
For example, my brother is writing a book - he’s not super technical but can get around. I can tell that he would benefit from this system - but I can’t fairly recommend it, because hell - I haven’t been able to coherently get it to work, and doubting he would want to be modifying init files and all that.
Hoping this plea for Emacs help reaches a previously frustrated newbie who figured it out, who can help me out (and others). Thanks!
I’ve taken a couple swings at setting up Emacs… oof, but as a newbie to the ecosystem, but frankly its just been tough to plow through. Each guide/tutorial seems to have a whole different set of packages, settings, etc; then we get into Doom emacs, etc. I’ve got keyboard shortcuts printed out - but I still end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them.
Truly, it reminds me of when I jumped head first in the Java ecosystem, trying to figure out (1) java, (2) intelliJ, (3) Spring boot. Too many simultaneous brain battles…
What I’m hoping to find is a “Zero to Functioning personal information system (notes, todo, contacts, calendar, kb)” guide. I suppose, written for a willing & motivated newb?
From reddit, online tutorials, walkthru videos - it SEEMS the pieces are out there. But I’m hoping to find the guy who figured this all out a year ago, documented a functional-but-opinionated stack / workflow, and I could follow that for awhile (as training wheels).
Can anyone suggest something like this? I’d be even be willing to pair up with someone and document/publish this, if it doesn’t exist.
I mentioned it on another Emacs HN thread: I’m convinced of the power of this stack, but I’m hoping someone does the “Unix —> NeXT -> MacOS”, and puts together the Easy Button of this.
For example, my brother is writing a book - he’s not super technical but can get around. I can tell that he would benefit from this system - but I can’t fairly recommend it, because hell - I haven’t been able to coherently get it to work, and doubting he would want to be modifying init files and all that.
Hoping this plea for Emacs help reaches a previously frustrated newbie who figured it out, who can help me out (and others). Thanks!
Have you seen this? https://github.com/nobiot/Zero-to-Emacs-and-Org-roam It's still a work-in-progress but it may be along the lines of what you're looking for.
Personally, I wouldn't recommend setting up org-roam at first. It's excellent, but it's just going to be too daunting for a beginner when combined with all the other things. I'd start by just learning emacs and org-mode. Core org-mode has enough functionality built-in to start building knowledgebases, and the org-mode manual is excellent. You can add-in org-roam later. (And you might find that org-roam is overkill and something like howm mode to get backlinks is enough.) The beauty of emacs is that you can move your notes from one system to another easily.
Personally, I wouldn't recommend setting up org-roam at first. It's excellent, but it's just going to be too daunting for a beginner when combined with all the other things. I'd start by just learning emacs and org-mode. Core org-mode has enough functionality built-in to start building knowledgebases, and the org-mode manual is excellent. You can add-in org-roam later. (And you might find that org-roam is overkill and something like howm mode to get backlinks is enough.) The beauty of emacs is that you can move your notes from one system to another easily.
>but I still end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them.
<meta>-x close-buffer will do the job.
Actually, using <meta>-x allows you to execute any emacs function, whether it has a key binding or not.
Even better, emacs will suggest completions (and once you are down to a single potential completion, tab completion works nicely) as you type the function name.
And if you don't know the name of the function you want/need, <meta>-x apropos will allow you to search for what you want -- with regexp support.
All that said, depending on your use case, it mightn't even be necessary to modify your init file at all.
I'm not a previously frustrated newbie (I started with Lugaru's epsilon[0] back in the early 1980s, moved to straight-up emacs in the late 1980s and never looked back), but I'd be happy to help.
That said, using emacs' built in help/info/apropos tools, not to mention just using <meta>-x <start typing function names> would almost certainly be a better way to figure out how things work than asking me (but don't let that stop you from doing so). And definitely better than googling/ddging/whatevering what you're looking for. '<meta>-x info' and/or <meta>-x help are good places to start.
HTHAL.
[0] https://www.lugaru.com/
<meta>-x close-buffer will do the job.
Actually, using <meta>-x allows you to execute any emacs function, whether it has a key binding or not.
Even better, emacs will suggest completions (and once you are down to a single potential completion, tab completion works nicely) as you type the function name.
And if you don't know the name of the function you want/need, <meta>-x apropos will allow you to search for what you want -- with regexp support.
All that said, depending on your use case, it mightn't even be necessary to modify your init file at all.
I'm not a previously frustrated newbie (I started with Lugaru's epsilon[0] back in the early 1980s, moved to straight-up emacs in the late 1980s and never looked back), but I'd be happy to help.
That said, using emacs' built in help/info/apropos tools, not to mention just using <meta>-x <start typing function names> would almost certainly be a better way to figure out how things work than asking me (but don't let that stop you from doing so). And definitely better than googling/ddging/whatevering what you're looking for. '<meta>-x info' and/or <meta>-x help are good places to start.
HTHAL.
[0] https://www.lugaru.com/
> local notes solution ... published on the web ... crosslinked
Definitely a lot of ways to go about this.
If you haven't already, I'd suggest checking out what the creator of org-roam does for publishing his own notes: https://github.com/jethrokuan/braindump
It works quite well, and might be exactly what you want as far as publishing goes.
> end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them
Typically 'q' will close Doom's popup windows (+popup/quit-window), otherwise you should be able use plain ol' Emacs 'C-x k' or Doom's '<leader> b k' (also 'b d') to kill a buffer.
If you actually want to keep the buffers, and you just want the windows out of the way, you can use winner-undo / winner-redo to cycle through past window configurations.
> bottom-up guide for personal information systems
AFAIK, this does not exist. But there is, I'm sure you've seen, a variety of independent users continually working out interesting new ways to process and link information using Emacs. For example, outside of bloggers in the Roam/Zettelkasten camp, you can always glean insights from John Kitchen's work [0][1], although it leans more towards research/academic use than PIM/PKM.
> my brother is writing a book - he’s not super technical but can get around
If it's technical/academic writing, you can honestly get astonishingly far just using org-mode's LaTeX export.
[0] https://kitchingroup.cheme.cmu.edu/
[1] https://github.com/jkitchin
Definitely a lot of ways to go about this.
If you haven't already, I'd suggest checking out what the creator of org-roam does for publishing his own notes: https://github.com/jethrokuan/braindump
It works quite well, and might be exactly what you want as far as publishing goes.
> end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them
Typically 'q' will close Doom's popup windows (+popup/quit-window), otherwise you should be able use plain ol' Emacs 'C-x k' or Doom's '<leader> b k' (also 'b d') to kill a buffer.
If you actually want to keep the buffers, and you just want the windows out of the way, you can use winner-undo / winner-redo to cycle through past window configurations.
> bottom-up guide for personal information systems
AFAIK, this does not exist. But there is, I'm sure you've seen, a variety of independent users continually working out interesting new ways to process and link information using Emacs. For example, outside of bloggers in the Roam/Zettelkasten camp, you can always glean insights from John Kitchen's work [0][1], although it leans more towards research/academic use than PIM/PKM.
> my brother is writing a book - he’s not super technical but can get around
If it's technical/academic writing, you can honestly get astonishingly far just using org-mode's LaTeX export.
[0] https://kitchingroup.cheme.cmu.edu/
[1] https://github.com/jkitchin
Craft.do is a good solution to your problem if you don’t mind closed source.
I personally have started using logseq.com though, it is a good fully open source file system based approach. It supports markdown and org mode, and I store the files in an iCloud Drive folder so I can access stuff on my phone (though it’s not quite as slick as craft, and setting up an auto deployed website would have to be done manually whereas craft does it for you)
I personally have started using logseq.com though, it is a good fully open source file system based approach. It supports markdown and org mode, and I store the files in an iCloud Drive folder so I can access stuff on my phone (though it’s not quite as slick as craft, and setting up an auto deployed website would have to be done manually whereas craft does it for you)
Org roam is pretty cool but with less features than actual roam. I had to force myself to use it but after that it's fine. The big disadvantage of all things Org is that unless you're doing very simple and using only defaults, there are no reasonable mobile workflows. You pretty much need a PC, or termux+keyboard for it to make any sense.
Here's an outline of a emacs/org-roam/org-publish based setup, which might be of help?
https://commonplace.doubleloop.net/my-personal-wiki-setup
https://commonplace.doubleloop.net/my-personal-wiki-setup
Finally, native compilation is part of the release. In day to day use, it provides a nice speed bust in many use cases.
Just waiting for my distro to update Emacs.
It's actually fairly easy to build yourself. No really esoteric dependencies, and you can install it to $HOME
Yeah, but there can be various hiccups.
e.g. I compiled Emacs to run on Redhat Linux. Since I wanted to compile it with --with-native-compilation flag, I had to install Redhat's developer tools to get libgccjit. These tools are installed in /opt/rh/devtoolset-10/root. An enable script is provided which modifies the LD_LIBRARY_PATH and PKG_CONFIG_PATH.
After compilation, I was able to launch Emacs from my bash terminal, but only after running the enable script (i.e. sets LD_LIBRARY_PATH to the correct directory). In a fresh terminal or after logging out and logging back in, launching Emacs gives the error:
emacs: error while loading shared libraries: libgccjit.so.0: cannot open shared object file: No such file or directory
Moreover, launching from application menu fails. I was able to get it to launch by modifying the binaries rpath, but then emacs gave lots of libgccjit.so errors afterword, when trying to lazy compile different internal applications: error invoking gcc driver.
I also tried compiling on Mac, but found myself experiencing a variety of issues that I didn't want to spend time thinking about. So I went with someone else's pre-built binaries.
e.g. I compiled Emacs to run on Redhat Linux. Since I wanted to compile it with --with-native-compilation flag, I had to install Redhat's developer tools to get libgccjit. These tools are installed in /opt/rh/devtoolset-10/root. An enable script is provided which modifies the LD_LIBRARY_PATH and PKG_CONFIG_PATH.
After compilation, I was able to launch Emacs from my bash terminal, but only after running the enable script (i.e. sets LD_LIBRARY_PATH to the correct directory). In a fresh terminal or after logging out and logging back in, launching Emacs gives the error:
emacs: error while loading shared libraries: libgccjit.so.0: cannot open shared object file: No such file or directory
Moreover, launching from application menu fails. I was able to get it to launch by modifying the binaries rpath, but then emacs gave lots of libgccjit.so errors afterword, when trying to lazy compile different internal applications: error invoking gcc driver.
I also tried compiling on Mac, but found myself experiencing a variety of issues that I didn't want to spend time thinking about. So I went with someone else's pre-built binaries.
I found mac installation pretty straightforward, and works quite well. I've been using for work for few months now.
brew tap d12frosted/emacs-plus
brew install emacs-plus@28 --with-native-compI was talking about compiling.
I use macports, and refuse to use brew (for a variety of philosophical reasons) so that option wasn't available to me. I often use the binary from https://emacsformacos.com/ but afaik it hadn't supported native compilation as yet. So I found some prebuilt binaries on github.
I use macports, and refuse to use brew (for a variety of philosophical reasons) so that option wasn't available to me. I often use the binary from https://emacsformacos.com/ but afaik it hadn't supported native compilation as yet. So I found some prebuilt binaries on github.
What are your issues with brew? Not starting an argument here but trying to understand better.
I almost wish I never tried Emacs. Ignorance is bliss, and Emacs ruined all other text editors for me.
There are absolutely areas that others do better, but the self-documenting “living program” nature is too much to give up; everything you ever need to know or do is a few keystrokes away.
There are absolutely areas that others do better, but the self-documenting “living program” nature is too much to give up; everything you ever need to know or do is a few keystrokes away.
I’ve been using emacs on and off for about 20 years and I don’t really get the fanaticism. Org mode and magit and all these things are cool. I like that you can hack it. But — to me it never stops feeling like an ongoing project when you try to live your entire life in it.
I like it obviously otherwise I wouldn’t still be using it, but it will never exactly feel elegant to me. More like a good text editor and a hundred other tools all duct taped together.
I like it obviously otherwise I wouldn’t still be using it, but it will never exactly feel elegant to me. More like a good text editor and a hundred other tools all duct taped together.
> to me it never stops feeling like an ongoing project when you try to live your entire life in it.
and that's the fascinating thing about it. What the OP called a 'living program' Smalltalk people called 'human-computer symbiosis'. Software as a fully transparent, introspective, organic thing you can directly interact with and change even as it runs.
There's actually very few software like it, and if anything philosophically more and more software tends towards the static unix "one tool one job" mantra.
and that's the fascinating thing about it. What the OP called a 'living program' Smalltalk people called 'human-computer symbiosis'. Software as a fully transparent, introspective, organic thing you can directly interact with and change even as it runs.
There's actually very few software like it, and if anything philosophically more and more software tends towards the static unix "one tool one job" mantra.
I like to tinker and hack on things, so I enjoy maintaining my Emacs config to an extent.
However, I draw the line at "text editor" with Emacs. I have no desire to read my email, paint pictures, or compose music inside Emacs—there are better tools for that.
However, I draw the line at "text editor" with Emacs. I have no desire to read my email, paint pictures, or compose music inside Emacs—there are better tools for that.
For email I disagree. notmuch and mu4e are very good and being able to apply your normal text editing tools in a text oriented context like email is very useful. If there are better tools out there I haven't found them yet.
I like having my email in Emacs, so i can reference it from org. I also like to write mails in Emacs. Triaging mails in notmuch-emacs is also quick and painless. Reading HTML mails, though — not so much.
I avoided email in emacs for a decade, using exactly this reasoning.
A few years ago I got fed up with not being able to configure Mail.app to notify me of responses to "watched" threads but nothing else and thought "...I bet the CLI tools would make this achievable."
So, I moved to mbsync for fetching email, not much for indexing the local email directory, and notmuch-mode / Emacs for reading and writing email.
It's head and shoulders above any other email setup I've ever used.
I wish I'd done it years ago.
A few years ago I got fed up with not being able to configure Mail.app to notify me of responses to "watched" threads but nothing else and thought "...I bet the CLI tools would make this achievable."
So, I moved to mbsync for fetching email, not much for indexing the local email directory, and notmuch-mode / Emacs for reading and writing email.
It's head and shoulders above any other email setup I've ever used.
I wish I'd done it years ago.
I don't have the fanaticism either but I always fall back to emacs because it can quite easily assimilate the advances made in other editors without requiring too major changes to emacs itself.
In fact, my config these days is basically vanilla emacs with some of the UI stripped away, the modus theme, and a few language-specific modes for syntax highlighting. I don't use evil or hydra or any such thing any more. The only thing I have a sticking point with is exec-path-from-shell messing with $PATH in my env because of how it works.
I guess the reason it works well for me is because I try not to write code, so I don't need a massive toolkit that helps me write code as efficiently as possible. No-code is bug-free code, maximise the work not done, etc.
In fact, my config these days is basically vanilla emacs with some of the UI stripped away, the modus theme, and a few language-specific modes for syntax highlighting. I don't use evil or hydra or any such thing any more. The only thing I have a sticking point with is exec-path-from-shell messing with $PATH in my env because of how it works.
I guess the reason it works well for me is because I try not to write code, so I don't need a massive toolkit that helps me write code as efficiently as possible. No-code is bug-free code, maximise the work not done, etc.
I used Emacs almost exclusively for half a decade and got pretty good at it. But I feel like VS Code is the natural evolution of all the great ideas of Emacs. So I use VS Code almost exclusively now.
For me it doesnt even come close to it. Maybe if you wtite your own plugins but even then there are many limitations. The one-window problem for example.
In emacs I can overwrite ANY function wherever it is from my config and change for example how shr (an html renderer) handles/styles headings. Its crazy!
One MAJOR thing that emacs does better is making things work together. I have orderless installed for matching strings in ANY completion. It works everywhere while in VSCode you cant even get close to that.
VSCode is great if you like the default and dont want to „build your text editor“ cause thats what emacs basically is. Its a toolbox with which you can build the editor to fit your exact needs with almost no limitations
In emacs I can overwrite ANY function wherever it is from my config and change for example how shr (an html renderer) handles/styles headings. Its crazy!
One MAJOR thing that emacs does better is making things work together. I have orderless installed for matching strings in ANY completion. It works everywhere while in VSCode you cant even get close to that.
VSCode is great if you like the default and dont want to „build your text editor“ cause thats what emacs basically is. Its a toolbox with which you can build the editor to fit your exact needs with almost no limitations
The cohesion and interoperability of Emacs packages is hard to find elsewhere. When I tried Neovim recently, it was blatantly obvious and I was quickly turned off by how each plugin creates psuedo-TUI elements and prompts for input slightly differently.
Exactly, it's simply the difference between having a texteditor with plugins vs. having a "vm" that is mainly a text editor.
I feel that VSCode is missing the number one critical feature of Emacs: the ability to inspect and change the program as it's running.
And don't forget the number two critical feature: the ability to call yourself an Emacs user!
Sure you can. Open up your VS Code extension in a VS Code window and live-debug it. I'd bet the process is probably very similar when editing VS Code yourself, but the point of the extension system is that you usually shouldn't have to.
That's cool. The one thing I missed in VS Code when I last used it a few years ago was a link to the implementation in the documentation of each function. Maybe I will give it a try again someday. But honestly giving up Magit, org-mode, slime, and elpy will be hard.
One pretty decent Magit alternative I found was lazygit. For a long time after quitting Magit/Emacs I just used git's CLI, but lazygit is pretty great.
Yeah the LSP ecosystem is so much nicer than the machinations hacked into text editors over the last 20 years. When you get down to it a modern editor is just a process manager for language servers, a global event bus/RPC layer across them all, and a UI layer. Instead of reinventing bespoke versions of those things, just solidify it using standard protocols like JSON RPC, HTML for UI, etc.
Absolutely. Emacs is a great UX layer, only lacking a modern UI rendering layer. Would be nice to have emacs with a DOM-based rendering engine.
I'm not sure I love that idea, but I'm guessing that's the direction Nyxt is heading in.
I mean I wholeheartedly agree but that nick
I forced myself to use emacs for about 6 months coming from IDEs and vi(m) to get past the "this is unfamiliar" stage.
At the end of the day, it was a very nice text editor with a development environment embedded in it and the ability to tweak things to my work flows was certainly interesting. However, I never enjoyed the seemingly unintuitive default key bindings and I often found myself disappearing into rabbit holes and tweaking stuff just to make everything work more smoothly. Ultimately, I decided that was time I should have been spending on more productive pursuits.
To this day though, I don't regret giving emacs a spin and I still swap caps lock and ctrl on all my systems. Remapping that key binding is helpful for so many things outside of emacs.
At the end of the day, it was a very nice text editor with a development environment embedded in it and the ability to tweak things to my work flows was certainly interesting. However, I never enjoyed the seemingly unintuitive default key bindings and I often found myself disappearing into rabbit holes and tweaking stuff just to make everything work more smoothly. Ultimately, I decided that was time I should have been spending on more productive pursuits.
To this day though, I don't regret giving emacs a spin and I still swap caps lock and ctrl on all my systems. Remapping that key binding is helpful for so many things outside of emacs.
Agree, but for me, there also are simply some features no other editors have, especially when it comes to navigation.
Some examples are all the ivy autocompletion, command autocompletion, dired, adjust-parens, windmove, smart parents, expand and contract region, agressive-indent, avy, swiper, hydra, and so on.
And it seems whatever I think about exists. Every time I go: How do I? There's a solution, and if not, I can just quickly add a function for it myself.
That's what keeps me in Emacs. Some other editors are more polished, and have better UX, might be more responsive, but there's always something they don't have and I miss from Emacs, or something that I don't like how they do it and I can't customize to my liking.
Some examples are all the ivy autocompletion, command autocompletion, dired, adjust-parens, windmove, smart parents, expand and contract region, agressive-indent, avy, swiper, hydra, and so on.
And it seems whatever I think about exists. Every time I go: How do I? There's a solution, and if not, I can just quickly add a function for it myself.
That's what keeps me in Emacs. Some other editors are more polished, and have better UX, might be more responsive, but there's always something they don't have and I miss from Emacs, or something that I don't like how they do it and I can't customize to my liking.
I've discovered aggressive-indent recently and I got immediately addicted. Now I wish it worked reliably with lsp-format-region and clangd (lack of reliability doesn't stop me from using it, even if explicitly unsupported).
How did you approach Emacs to make it such a valuable tool? I have tried to get started with Emacs a few times but the initial resistance has been too large
Ironically, part of the problem for the newbie is the enthusiasm of the heavy users, which can make getting started feel overwhelming.
Just bare emacs is a great editor. You only need a few commands, and then can incrementally learn more as you go. Often, when you learn some new command or new package you'll wonder "how did I manage to use emacs for all this time without knowing this?" But the answer is: you were able to get a lot done with what you already knew.
I've been using Emacs for over 40 years and have a very short init file with only a small amount of customization. And I still learn a new command or package every couple of weeks.
Just bare emacs is a great editor. You only need a few commands, and then can incrementally learn more as you go. Often, when you learn some new command or new package you'll wonder "how did I manage to use emacs for all this time without knowing this?" But the answer is: you were able to get a lot done with what you already knew.
I've been using Emacs for over 40 years and have a very short init file with only a small amount of customization. And I still learn a new command or package every couple of weeks.
What parts did you find difficult?
When I first started, I found the keybindings odd, but now I love them since the core set of shortcuts—C-a, C-e, C-f, etc.—work "everywhere" from the terminal, to GNU readline-based programs, to even native macOS text boxes. If you don't like the default keybindings, you can change them or use the Evil package [0] for Vim bindings.
If you want to get up and running quickly, I'd check out Doom Emacs [1] which is easier to configure and takes care of a lot of configuration for you. I personally use a reasonably-minimal config I wrote myself [2]. If you like to tinker, I'd recommend writing your own config, as it will also teach you a lot about Emacs.
If you have any questions feel free to reach out—contact info in my profile.
[0] https://github.com/emacs-evil/evil [1] https://github.com/hlissner/doom-emacs [2] https://github.com/jonpalmisc/.emacs.d/blob/master/init.el
When I first started, I found the keybindings odd, but now I love them since the core set of shortcuts—C-a, C-e, C-f, etc.—work "everywhere" from the terminal, to GNU readline-based programs, to even native macOS text boxes. If you don't like the default keybindings, you can change them or use the Evil package [0] for Vim bindings.
If you want to get up and running quickly, I'd check out Doom Emacs [1] which is easier to configure and takes care of a lot of configuration for you. I personally use a reasonably-minimal config I wrote myself [2]. If you like to tinker, I'd recommend writing your own config, as it will also teach you a lot about Emacs.
If you have any questions feel free to reach out—contact info in my profile.
[0] https://github.com/emacs-evil/evil [1] https://github.com/hlissner/doom-emacs [2] https://github.com/jonpalmisc/.emacs.d/blob/master/init.el
Do you use it as an IDE? That's the part I had trouble with (react/typescript and python). I could get it almost there, but essentially what I would need is a VS Code mode. A side panel with the collapsible directories, double click into them, global search, linting, syntax, etc.
As a heavy Emacs user for over a decade: I still use IDEs instead of Emacs for programming. Emacs has plenty of uses outside of SW development. Only recently did I manage to set up my Emacs to have IDE-like capabilities for my Python work. But if I switched to a C++ job, I'll use an IDE. And maybe, over the course of a year or two, I'll bother setting up LSP for Emacs.
It's totally fine to use IDEs if they make your life easier. In my last C++ job, I would edit code with Emacs, but keep Visual Studio open for the IDE conveniences.
It's totally fine to use IDEs if they make your life easier. In my last C++ job, I would edit code with Emacs, but keep Visual Studio open for the IDE conveniences.
You may have investigated this already (or discovered it setting Emacs up for python), but lsp-mode just about works out of the box (for most languages). Extremely minimal setup required. Maybe a few configs for lsp-ui to suit your own taste.
I use it at my current job in which I work in a large C++ codebase. I formerly used CLion.
Whether Emacs is an IDE or not depends how you define IDE. I use Eglot [0] for LSP integration; this gives me IDE-like features like "jump-to-definition", syntax error highlights, warnings, etc. and integrates with company-mode [1] for code completion. This handles most of my needs for writing code.
As for other things like a file tree, I've found that the built in `project-find-file` command combined with `vertico` [2] and `orderless` [3] makes finding files and navigating around projects easier; that pair behaves similarly to CMD+P in Sublime Text or VS Code. There are file tree packages out there, but I've found that I don't really need a file tree in practice and that I prefer navigating around projects with fuzzy file search and grep.
[0] https://github.com/joaotavora/eglot [1] https://github.com/company-mode/company-mode [2] https://github.com/minad/vertico [3] https://github.com/oantolin/orderless
Whether Emacs is an IDE or not depends how you define IDE. I use Eglot [0] for LSP integration; this gives me IDE-like features like "jump-to-definition", syntax error highlights, warnings, etc. and integrates with company-mode [1] for code completion. This handles most of my needs for writing code.
As for other things like a file tree, I've found that the built in `project-find-file` command combined with `vertico` [2] and `orderless` [3] makes finding files and navigating around projects easier; that pair behaves similarly to CMD+P in Sublime Text or VS Code. There are file tree packages out there, but I've found that I don't really need a file tree in practice and that I prefer navigating around projects with fuzzy file search and grep.
[0] https://github.com/joaotavora/eglot [1] https://github.com/company-mode/company-mode [2] https://github.com/minad/vertico [3] https://github.com/oantolin/orderless
I use emacs as an IDE with a large C++ (and python) codebase. I use emacs-lsp + clangd for completion/jump to definition/syntax error highlighting etc, but for whole tree searches, I find clangd unreliable, so sometimes I fall back to emacs-ag (I assume that emacs-ripgrep would be even better) for brute force searches.
I never found a side panel of any use (many are available), but I use projectile for quick jump to file all the time.
My python setup is less refined than C++ (I haven't bothered yet to enable LSP), but I use elpy which is works fine for lisp-style programming with a persistent REPL.
I never found a side panel of any use (many are available), but I use projectile for quick jump to file all the time.
My python setup is less refined than C++ (I haven't bothered yet to enable LSP), but I use elpy which is works fine for lisp-style programming with a persistent REPL.
This interesting to me. The sidebar in IDEs is one of the features I dislike most about them. I vastly prefer the C-x C-f helm menu with it's fuzzy search to IDE approach of aimlessly clicking around a directory tree like a philistine. For the rest (linting, syntax, autocomplete), lsp and a language mode make me pretty happy.
Give tide a try. I use it daily with typescript and it's great :-)
Have you tried Doom Emacs?
Thanks for sharing your experience! I guess my problem was to remember all the shortcuts and keybindings and how to do things, and having to look them up all the time was tiresome - but I guess the steep learning curve has some fruits in the end
At my new job a colleague mentioned he used emacs and I basically took it as inspiration and started trying emacs myself, I'm very accustomed to vim after 4-5 years of heavy usage so I started with the evil package (evil-mode) and went from there.
It boils down to using the already known vim keys for basic actions like splitting the window, save a file etc. and creating keybinds for anything else I needed. So I customized any keybind to my liking, I didn't really adopt the emacs binds since I find many of them to be quite unintuitive.
It took me like 2-3 weeks of constant configuration to get to a productive config that covers all my needs (from autocompletion, to colorscheme) and I still edit my config every 1-2 days since I discover new small "itches" and then fix those.
For example: I always want my compilation output to be on one monitor -> always open the compilation buffer ("output") in its own window. Perfect!
To me emacs is like a platform that I can use to build my "own" perfect text editor that does exactly what I want it to do without really any compromises. This is where emacs shines, the endless possibilities and nothing that holds you back and says "no the editor is not meant to do X".
It boils down to using the already known vim keys for basic actions like splitting the window, save a file etc. and creating keybinds for anything else I needed. So I customized any keybind to my liking, I didn't really adopt the emacs binds since I find many of them to be quite unintuitive.
It took me like 2-3 weeks of constant configuration to get to a productive config that covers all my needs (from autocompletion, to colorscheme) and I still edit my config every 1-2 days since I discover new small "itches" and then fix those.
For example: I always want my compilation output to be on one monitor -> always open the compilation buffer ("output") in its own window. Perfect!
To me emacs is like a platform that I can use to build my "own" perfect text editor that does exactly what I want it to do without really any compromises. This is where emacs shines, the endless possibilities and nothing that holds you back and says "no the editor is not meant to do X".
You have to find specific need that emacs will fulfil. Org-mode is the key. Don't try to use it like IDE for coding for a start.
I recommend start with video tutorials:
1. Mike Zamansky https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpF...
2. Rainer König org-mode https://www.youtube.com/watch?v=sQS06Qjnkcc&list=PLVtKhBrRV_...
I recommend start with video tutorials:
1. Mike Zamansky https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpF...
2. Rainer König org-mode https://www.youtube.com/watch?v=sQS06Qjnkcc&list=PLVtKhBrRV_...
I speak with a heavy VIM accent, so Emacs never clicked for me until I tried SpaceMacs. I mostly use Emacs only for org-mode, though.
The truth is, I think that I've outgrown SpaceMacs and ready to try vanilla Emacs with Evil sometime. But SpaceMacs was definitely the gateway to getting me into org-mode, and that really is revolution in being able to organize my life.
The truth is, I think that I've outgrown SpaceMacs and ready to try vanilla Emacs with Evil sometime. But SpaceMacs was definitely the gateway to getting me into org-mode, and that really is revolution in being able to organize my life.
It's a bit of an extreme instance but when I toyed with good old turbo pascal 7.0 ide (dos era) I was shocked by the quality of it (turbo pascal), brilliant on every aspect, mind blowing for the size and era. Yet the minute I tried to edit code I felt straightjacketed by the editor, you can only do what's built in. It was a stupid need for region aware edition.. nothing fancy but I was still stuck.
Ability to extend your system with a quick `eval` and adjust keybindings when needed is a very hard drug to me. And I'm not in the fanatic period anymore but still.
Ability to extend your system with a quick `eval` and adjust keybindings when needed is a very hard drug to me. And I'm not in the fanatic period anymore but still.
For me things started to get interesting once I set up CUA mode to have the same key shortcuts as in the usual Windows world (ctrl-C for copy, ctrl-V for paste and so on). Once I got that I was able to work on text file, programs etc. Then I slowly added packages (took months) as I was needing/discovering them. And now, what I like is that I can use the same configuration on Linxu and windows (I switch often between my work PC in my home PC). Org mode is really usefull although I just get the bare minimum. LSP makes a difference too. And the community is great: so much things happen all the time. The openness really makes a big difference. So in the end, I love it :-)
(and I don't like modal editors :-) )
(and I don't like modal editors :-) )
I think the only way is to bite the bullet and accept the somewhat steep learning curve. Unlike the other suggestions I think it's best to start off with a vanilla Emacs setup (rather than one of the fancy distributions), because it's better to start with a very simple setup and then build on that.
The initial Emacs setup is very basic and quite ugly, but good for learning. Follow the built-in tutorial.
After learning the basics, create an init.el file, learn to use the use-package package, and start off trying out interesting packages to make your life better. I would suggest finding a good theme and giving helm a go to begin with.
The initial Emacs setup is very basic and quite ugly, but good for learning. Follow the built-in tutorial.
After learning the basics, create an init.el file, learn to use the use-package package, and start off trying out interesting packages to make your life better. I would suggest finding a good theme and giving helm a go to begin with.
Spacemacs
Indeed, I started with VIM when I was in uni and things were kinda slow. After a few weeks/months I was very happy with it and it truly felt as a productivty booster. (I switched between VSCode with vim keybindings and Neovim). Then, for last year's AoC I wanted to explore Lisp, so after weeks of trying out sbcl and running it thru the terminal I finally tried Doom Emacs. And for me too, its been a journey, its a "text editor" that truly exemplifies what a good 40yo+ piece of software should be.
> ruined all other text editors for me
Emacs has a text editor too ?!!?
Emacs has a text editor too ?!!?
OT for this particular release, but I'd like to point out that one of the best features of emacs and its ecosystem is that plugins, libraries and software are almost always self-documenting.
You want to read the documentation or delve into the implementation of a feature of your programs it is literally right there in your editor instead of having to jump to some, potentially outdated, website documentation or having to figure out where to look at things from a sterile github page.
I wish that the idea of self documenation was more widespread in other ecosystems.
E.g. the ecosystem I know most, JavaScript, would have this potential, but very often dependencies are compiled and there is no such self-documenting culture so best case scenario you get types you can _almost_ trust and some jsdoc that you can _almost_ trust.
I guess the fact that the lisp and elisp community in particular has always cultivated this practice is the deciding factor rather than the languages itself.
You want to read the documentation or delve into the implementation of a feature of your programs it is literally right there in your editor instead of having to jump to some, potentially outdated, website documentation or having to figure out where to look at things from a sterile github page.
I wish that the idea of self documenation was more widespread in other ecosystems.
E.g. the ecosystem I know most, JavaScript, would have this potential, but very often dependencies are compiled and there is no such self-documenting culture so best case scenario you get types you can _almost_ trust and some jsdoc that you can _almost_ trust.
I guess the fact that the lisp and elisp community in particular has always cultivated this practice is the deciding factor rather than the languages itself.
Yeah emacs was a revelation for me on this regard, that the idea of "Free Software" could be more than just providing souce code and license.
Emacs is actually explicitly designed to give you full power to explore, discover and modify it in order to tailor it to your needs and whims.
Emacs is actually explicitly designed to give you full power to explore, discover and modify it in order to tailor it to your needs and whims.
It is actually amazing, emacs is probably the best example of a "living" program you can modify interact and debug directly while you are coding it.
Obviously lisp has been designed around its REPL and debugging experience and the concept of "living programmable programs", but emacs reaches an insanely high level of business complexity, far higher than any software any of us probably writes at work and yet modifying and learning the very program you are using with the program itself is a 30+ years old solved problem that apparently ecosystems outside lisp dialects seem not to pick up.
Obviously lisp has been designed around its REPL and debugging experience and the concept of "living programmable programs", but emacs reaches an insanely high level of business complexity, far higher than any software any of us probably writes at work and yet modifying and learning the very program you are using with the program itself is a 30+ years old solved problem that apparently ecosystems outside lisp dialects seem not to pick up.
Not only that but jumping to the source code for whatever command you are looking at is just a key press away. Edit the source, hit another key or two and you've just live patched your editor.
This is the culture in golang, too, and it's great.
I miss Emacs, but I moved to Visual Studio Code. I used Emacs for over 8 years so releases like this use to make me so happy.
On the bright side, I still use Emacs bindings in Visual Studio Code. Maybe I should spin up Emacs again and give it another shot on my new M1 (maybe it can do the auto complete stuff faster now.)
On the bright side, I still use Emacs bindings in Visual Studio Code. Maybe I should spin up Emacs again and give it another shot on my new M1 (maybe it can do the auto complete stuff faster now.)
The worst part about Emacs is the bindings. :D
The reason I'll never leave Emacs is that if I want to change something, I can. It doesn't really matter what it is. This might be technically true in something like VS Code (although Atom was much easier in this regard), but it takes a lot more effort and scaffolding to do something like write a single function and bind it to a keymap in VS Code.
The reason I'll never leave Emacs is that if I want to change something, I can. It doesn't really matter what it is. This might be technically true in something like VS Code (although Atom was much easier in this regard), but it takes a lot more effort and scaffolding to do something like write a single function and bind it to a keymap in VS Code.
One of the best parts is the bindings! They are present in most shells/terminals, GNU readline-based programs, and even native macOS text field. If you're in a terminal or using a terminal-based program, there's a good chance pressing any of the core Emacs keybindings does what you expect it to.
It's probably largely just habit at this point, but the keybindings are a big part of what keep me with emacs. I honestly have no idea how people navigate text/code with default windows keybindings. That they work by default in many other contexts is a really nice bonus. Most emacs binding emulation modes I've seen for other editors don't support even basic things like "C-<space> C-n C-w", which is basically a non-starter for me.
Yes you should!
`brew install d12frosted/emacs-plus/emacs-plus@29 --with-native-comp --with-no-frame-refocus` is easy as pie and gets you the latest build with native comp and smooth trackpad scrolling.
`brew install d12frosted/emacs-plus/emacs-plus@29 --with-native-comp --with-no-frame-refocus` is easy as pie and gets you the latest build with native comp and smooth trackpad scrolling.
Can confirm, I run this on my M1 works great!
> give it another shot on my new M1
https://www.gnu.org/software/emacs/download.html#nonfree https://emacsformacosx.com/
https://www.gnu.org/software/emacs/download.html#nonfree https://emacsformacosx.com/
the M1 is the fastest emacs-lisp machine there is. Give it a go!
I've been using Emacs for 2/3 years now, especially to take notes. It's been a bit difficult at the beginning but I really enjoy it now, it's provided many features I needed to organize my thoughts.
Knowledgeable Emacs folks in this thread: Does anyone know the status of Wayland-native Emacs? It's my last X/XWayland application, and it looks terrible on high-DPI displays.
The pure GTK branch has been merged into master and I use right now with KDE (and Wayland). I had to adjust the font size but other than that, I didn't meet any issue.
That's amazing news! Does that mean one can expect this feature in Emacs 29?
Edit: I just noticed that LWN has a news entry that explains just this – https://lwn.net/Articles/890405/ (short answer: yes).
Edit: I just noticed that LWN has a news entry that explains just this – https://lwn.net/Articles/890405/ (short answer: yes).
Just like you said indeed!
Using it on fedora and ubuntu fine with the pgtk branch for several months, and this is stable IMHO.
global line number mode wasn't stable, and resizing fails to repaint the new parts. killing openened processes (ediff-buffers) can still crash emacs.
29.0.50 is better though.
The latest pgtk cleanups just came in the last days from Po Lu.
as of today's master on ubuntu latest:
The latest pgtk cleanups just came in the last days from Po Lu.
as of today's master on ubuntu latest:
Ran 6194 tests, 6064 results as expected, 11 unexpected, 119 skipped
7 files contained unexpected results:
src/fns-tests.log
src/casefiddle-tests.log
lisp/time-stamp-tests.log
lisp/subr-tests.log
lisp/help-fns-tests.log
lisp/eshell/esh-var-tests.log
lisp/bookmark-tests.logThis was the main reason I built emacs 28 from source on Ubuntu about 3 months ago. Sadly Ubuntu 22.04 still sticks with emacs 27.1 :(
> If you’re using projectile or something else, start switching over; this is the new default target for all other integrations
It is pretty sweet something like this is getting built in, but I have not found a replacement for 'with-project-root from the (now seemingly missing) project-root package.
edit: Oh, they also add a new 'with-existing-directory' macro that should be easy to compile to do the same thing. sweet.
It is pretty sweet something like this is getting built in, but I have not found a replacement for 'with-project-root from the (now seemingly missing) project-root package.
edit: Oh, they also add a new 'with-existing-directory' macro that should be easy to compile to do the same thing. sweet.
An aside, but can someone explain to me the use or utility of ligatures? To be frank people who use them seem like those who change their i3 layout every few months, they seem/feel like a gimmick to me. I hope that isn't too harsh, perhaps I can be convinced they have use.
Ligatures remind me of the symbols in APL. There, I can see sort of a use if your language requires it but generally in the terminal? I don't get it.
Ligatures remind me of the symbols in APL. There, I can see sort of a use if your language requires it but generally in the terminal? I don't get it.
I started using Emacs as my primary editor about a year ago with doom. Emacs 28 has good changes, but it's missing pixel scrolling which at this point almost every other editor has. I believe Emacs 29 is going to finally include the feature. There's a pretty good plugin called good-scroll.el that does exactly this on older versions, but it can be buggy sometimes.
I always like to ask: Has the pixel-scrolling story gotten better on Emacs? I like how I can scroll smoothly on Visual Studio Code.
Not sure if it's included in 28.1, but its been overhauled on master. https://youtube.com/watch?v=LNK1DnPOqms
Its sadly not, I believe it will be included in version 29
pixel-scroll-precision-mode is in the mainline (Emacs 29), but didn't make it into Emacs 28.
If you're on a Mac, the railwaycat port has the equivalent already.
If you're on a Mac, the railwaycat port has the equivalent already.
In addition to the native pixel-scroll-precision-mode in Emacs 29,
there's also a MELPA package called good-scroll which implements pixel-wise scrolling for other emacs versions also.
d12frosted/emacs-plus/emacs-plus@29 on Homebrew is my fav way to install master on a Mac. Trackpad scrolling is smooth even at 120hz.
I remember seeing vim as a complex solution for text editing, and I didn't touched it for that same reason. A couple of years later I spent sometime learning it and now it's my day-to-day tool for writing code.
I feel the same with Emacs, I've been reading (very little) about it and I wonder if I dedicate the same time I did for learning vim I'd be in the Emacs bandwagon, but at the same time I don't feel that curious about it, because I feel happy with vim.
I've tried some versions with vim bindings but the problem remains the same, the energy to explore the rest just wasn't there.
I feel the same with Emacs, I've been reading (very little) about it and I wonder if I dedicate the same time I did for learning vim I'd be in the Emacs bandwagon, but at the same time I don't feel that curious about it, because I feel happy with vim.
I've tried some versions with vim bindings but the problem remains the same, the energy to explore the rest just wasn't there.
I was avoiding Emacs for years because I heard that it's a huge timesink, so I kept using Vim and later NeoVim. Last month I started learning Clojure(great language btw) and after some consideration I decided to give Emacs a try.
It's my new favorite thing, it was a pleasure to learn. It took about 4 sessions to get productive with it, a couple of days. Really not that much of an effort. After a bit of tinkering, I feel like Emacs is what I was always looking in other IDEs. (Neo)Vim is a great text editor, but I was never able to customize it to a point where I was 100% satisfied with it. With Emacs it took a couple of weeks.
If you end up giving Emacs a try, I would advise using the native keys, at least until you're comfortable with the editor. When in Rome... Also, masteringemacs.com has a great beginner article, I highly recommend it.
True, vim at the end of the day as you said -- is just a text editor. I usually use vim + tmux to handle a couple of panels with compiler + debugger. Maybe I should try Emacs since it sounds like it can do everything without ever leaving it.
One thing I remember though, startup time of emacs was a bit painful, but I could be misremembering things.
I guess tomorrow will be a fun day :^D
One thing I remember though, startup time of emacs was a bit painful, but I could be misremembering things.
I guess tomorrow will be a fun day :^D
For me, the big feature in editors is mouseless editing. With emacs my fingers never have to leave the keyboard. When I started out in the Dark Ages, vi offered the same benefit, but multiple buffers were easier in emacs, so I ended up with emacs. I use some emacs extensions (e.g. ctags recently), but that's a secondary benefit.
So from my perspective, you've already gotten most of the benefit just with vi. YMMV. If emacs were to disappear today, I'd probably switch to vi and be perfectly happy.
So from my perspective, you've already gotten most of the benefit just with vi. YMMV. If emacs were to disappear today, I'd probably switch to vi and be perfectly happy.
Vim still has some short comings when it comes to developing, since at the end of the day, is a text-editing tools. I usually use tmux + vim over SSH and it's very comfy, maybe Emacs can do all of that in Emacs itself.
I hope I can gather enough energy some day to give it a try. I'm really not into fighting for which ecosystem is better, I just want to enjoy editing code, and so far vim is making it fun, but exploration can be fun too :D
I hope I can gather enough energy some day to give it a try. I'm really not into fighting for which ecosystem is better, I just want to enjoy editing code, and so far vim is making it fun, but exploration can be fun too :D
Only thing I'm missing from Emacs is the ability to completely freeze all packages and configs.
As soon as I feel like everything is stable and great, it decides to update 180 packages while I'm trying to edit a file and destroys something in my setup.
If anyone knows a way to prevent all updates and "freeze" a version that would be excellent.
As soon as I feel like everything is stable and great, it decides to update 180 packages while I'm trying to edit a file and destroys something in my setup.
If anyone knows a way to prevent all updates and "freeze" a version that would be excellent.
You might want to check out straight.el [0] in replacement of package.el; it can pin package versions, etc. It is used by the very popular Doom Emacs [1] to lock package versions for reproducible config reasons.
[0] https://github.com/raxod502/straight.el [1] https://github.com/hlissner/doom-emacs
[0] https://github.com/raxod502/straight.el [1] https://github.com/hlissner/doom-emacs
Haven't yet needed to freeze a package, but I can confirm that setting up your packages is stupid simple in Doom (Straight), and freezing them equally so.
> Only thing I'm missing from Emacs is the ability to completely freeze all packages and configs.
Weird - Emacs by default does not auto-update packages. I do it manually as needed. Are you using Vanilla Emacs or something else?
Weird - Emacs by default does not auto-update packages. I do it manually as needed. Are you using Vanilla Emacs or something else?
I use Emacs with Nix, which parses my config for use-package declarations and installs them for me. Emacs packages are pinned the same way as anything else in Nix and, as a bonus, it can also manage non-Emacs dependencies.
I wouldn't recommend Nix just for a reproducible Emacs config, but if you end up considering Nix for broader reasons, being able to use it for Emacs could be a nice bonus :)
I wouldn't recommend Nix just for a reproducible Emacs config, but if you end up considering Nix for broader reasons, being able to use it for Emacs could be a nice bonus :)
That's weird. I use package.el and it only ever updates when I ask it to.
The solution to this is too keep your elpa/ directory under version control.
I use this hacked-up script to help me do that: https://github.com/NateEag/.emacs.d/blob/master/site-lisp/up...
The solution to this is too keep your elpa/ directory under version control.
I use this hacked-up script to help me do that: https://github.com/NateEag/.emacs.d/blob/master/site-lisp/up...
I haven't used it myself, so I cannot speak for it, but straight.el [1] has functionality to freeze the version of packages.
[1] https://github.com/raxod502/straight.el
[1] https://github.com/raxod502/straight.el
[deleted]
Secondly, the breadth of the changes in Emacs 28.1 is staggering, especially considering that Emacs 27.1 was released some 19 months ago. I think it's safe to say that despite all the hand-wringing about the antiquated email-centric way that Emacs is developed, an impressive amount of work is getting done. Emacs development is alive and well.