What’s new in Emacs 28.1?(masteringemacs.org) |
What’s new in Emacs 28.1?(masteringemacs.org) |
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.
Ancient, stable platforms enable long-termism, which encourages scratching your itches - whatever you write, it will likely keep working until after you're dead.
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 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 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'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 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'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.
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.
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.
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.
This happens to me all the time too! Anyone have a fix?
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.
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.
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.
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’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!
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.
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.
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.
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.
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 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.
`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.
https://www.gnu.org/software/emacs/download.html#nonfree https://emacsformacosx.com/
Edit: I just noticed that LWN has a news entry that explains just this – https://lwn.net/Articles/890405/ (short answer: yes).
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.logIt 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.
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.
If you're on a Mac, the railwaycat port has the equivalent already.
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.
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.
[0] https://github.com/raxod502/straight.el [1] https://github.com/hlissner/doom-emacs
Weird - Emacs by default does not auto-update packages. I do it manually as needed. Are you using Vanilla Emacs or something else?
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 :)
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...
[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...
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.
(setq mac-control-modifier 'command)
(setq mac-command-modifier 'control)
(setq mac-option-modifier 'meta)
(setq mac-control-modifier 'super)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.
-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.
I've found mbsync/isync more performant than offlineimap.
I wonder, what is "Org PDF"?
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'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 agree with you tho, I was looking for my options to develop in Java with Emacs and decided to not even try.
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.
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.
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.
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
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.
Every tool has strengths and weaknesses. Plus, some of us enjoy learning new tools and find it fun to switch things up occasionally.
Otherwise, the website linked above is a good way to get started, there's also an integrated tutorial in Emacs (C-h t).
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.
(Well, good luck writing one in Xcode, for that matter.)
(not supporting the editor/ide war troll, just trying to contribute some useful info here)
JetBrains Intellij Idea Community Edition is open source
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.
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?
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 :)
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.
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?
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.
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...
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.
<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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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
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".
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_...
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.
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.
(and I don't like modal editors :-) )
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.
Emacs has a text editor too ?!!?
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
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.
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'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.
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.
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.
Honest question because I fear my uni will start doing this out of “security “.
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.
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.
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.
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.
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.
There is also a successor available.
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...
from ancient times...
(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.)
First thought: but C is on the right.
Second thought: ah, I use Dvorak
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.
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.
brew tap d12frosted/emacs-plus
brew install emacs-plus@28 --with-native-compI 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.
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.
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.").
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).
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.
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.
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.
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).
But then why not run the daemon on that server and the GUI locally?
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.
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 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.
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.
That it does, but there's no good reason I should use my pinky to hit Ctrl to begin with.
By that rationale, there's no good reason I should use my (left) forefinger to press "g" to begin with.
(qwerty layout assumed...)
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.
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.
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).
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.
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 is nothing wrong with this. We shouldn't let old text editors hold back the productivity of programmers.
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.
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
That's ironic.