Emacs 26.2 Released
lists.gnu.org
lists.gnu.org
[0] Well, a WM/DE of course, either Stumpwm or Plasma. And pdfpc[1] is really pretty fantastic for showing "Beamer" (pdf) slides. And syncthing for sync'ing between machines.
ImageMagick is another one that has been around for almost 30 years, and is the Swiss army knife of batch image processing on any platform.
And in a way.. MS Office has been forever, even though it changed a lot in the recent years .. Excel is still Excel.
I suppose it could be seen as vi to Vim, though.
It's strange, but I feel extremely excited about this coincidence. :D
I'm mostly okay with code editors coming and going, but the one constant in my life has been project/task management, journalling, and personal information management in the broadest sense.
I just got tired of my tools either turning to shit, being deprecated, or not quite doing what I need them to do. Org Mode has been exactly what I've been looking for, and once I started using it seriously it became the thing I didn't know I wanted.
It's really comforting to me to know that I'll probably be able to use the same tool for the rest of my life, and that I can (and often already do) use it for many other things (Tramp, magit, coding in general).
Never too late though, and on the plus side I've now got decades of hidden Emacs goodies still to discover!
To each thier own, of course!
I still use Emacs when I ssh into my vps and, if I want primarily on Windows doing dev if Visual Studio, would likely use it for everything (as I did back when I was primarily on UNIX systems). Just writing this makes me think "maybe I'll install it on Windows on more time".
The core issue for me is context switching between Emacs and VS. Even with various keybinding tricks it is always awkward.
Best of luck on your journey with Emacs. Do it for me! :)
Emacs is often confused as being an editor, but it's not.
It certainly houses a few different editors, including Vim (as people will often point out eVil is Vim inside Emacs)
Emacs is basically a text centric computing platform, built with a flavor of Lisp.
At this point there's several thousand apps / packages.
It used to be a joke that Emacs is an Operating System that lacks a decent text editor. These days it has several.
The joke now should be that it lacks a decent logo and marketing department.
Or perhaps the joke should be that Vim users are terrified they're missing out on something they don't get so they use snark as a defense mechanism.
That’s actually the best explanation of Emacs I’ve heard. Thank you.
Every visible and invisible think is inspectable and changable at runtime, yup - pretty cool and I loved it for programming! Not sure whether I want to get on the emacs train tho. I have problems mantaining efficiency either way already... And I favor tools that work without set-up. Then again I am still young enough that learning investments pay off by a huge margin... tough.
I'm glad I took the time to investigate this discoverable interactive programmatic keyboard-oriented UI platform, that also happens to have a great editor (evil).
A uniquely empowering tool for programmers.
...so when does someone teach me the secret handshake?
Some people even replace their window manager with Emacs (see: EXWM), but I'm not ready for this just yet (I run stumpwm now, which is a tiling WM written in Common Lisp, so it's just another lispy environment with similar levels of live interop).
That seems pretty far-fetched. Very few of the things I use Jupyter notebooks for seem possible in org mode.
Org Mode can execute blocks of code in any language you can hook up to Emacs, correctly handling sessions if language supports them. Org Mode document itself can serve as a glue for exchanging data between different runtimes if you're using multiple different languages in a single document. Literate programming capabilities let you include other source blocks or even their results as code. Emacs can display images inline, and has some capability for UI widgets (though I haven't use it in org-mode context). The kind of Jupyter notebooks I've seen in the wild, I can reproduce in Org Mode with ease.
Simply not being browser-based means org mode has an incredibly steep uphill battle to even get close - the ecosystems Jupyter can tap into are vast (browser and native, language agnostic), and anything interactive is almost certain to trail behind.
I'm happy to be corrected, but I spent a while researching org mode's capabilities in this area earlier, and everything I found looked more primitive and clunky than what Python and Sage could do as long as 10 years ago.
My experience with Jupyter was limited to static plots so far (I did plenty of interactive work in ObservableHQ though), and Emacs can handle those well.
Thanks for clearing that up for me!
M-x secret-handshake (use-package flyspell
:config
(setq ispell-program-name "/usr/sbin/aspell")
(setq flyspell-consider-dash-as-word-delimiter-flag t)
(define-key flyspell-mode-map (kbd "C-:") 'flyspell-correct-wrapper)
)
(use-package flyspell-correct)
(use-package flyspell-correct-ivy)
(defun my-save-word ()
(interactive)
(let ((current-location (point))
(word (flyspell-get-word)))
(when (consp word)
(flyspell-do-correct 'save nil (car word) current-location (cadr word) (caddr word) current-location))))A nice happy medium is Prelude -- https://github.com/bbatsov/prelude
It's big, but probably not too big to understand and jump in and tweak.
I still prefer my own hand-rolled config though.
After a few months, I started to build up my configuration bit by bit with use-package, evil, and general.el. I largely use the same keybindings as Spacemacs, but it's much leaner and faster.
Changed to a clean configuration and built it slowly, everytime I hit an annoyance I fixed and learned something new, now it works better than spacemacs for my workflow and still is way snappier.
It's also a good idea to use opposing hands when using modifier keys. To press control-H, you would use the left control with your left hand, and the H with your right hand. Again, this is true regardless of using Emacs (it applies just the same to typing capital letters with the shift keys).
2. Load Emacs.
3. Press Control-H, then press T. This loads the Emacs tutorial. It should take about 10-15 minutes to run though.
If you use Bash/Zsh or Mac OS, the basic cursor movement in the very first section of the tutorial can also be used in the Bash/Zsh shell, and in many Mac OS textboxes as alternatives to the Home/End/PgUp keys etc.
4. Read the manual section on macros [1]. I don't know so many emacs-level-10-wizard level commands, but making a macro saves me a lot of time and thought at least once a week.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...
Best resources you’ve used to discover things?
`org-mode` and `org-agenda` is pretty cool and I wish I could use it, but I just gave up trying to configure and integrate it with my calendar, multiple devices and what not.
`shell-pop` is incredibly basic and useful to pop up terminal at bottom. Trying to get my popup windows to show up where I want them using `popwin` and `shackle` (still WIP, as it's far from perfect).
There is `lsp-mode` for Language Server, which makes the auto-completion and code-browsing far better. I was super surprised by how well `dumb-jump` worked in most cases (I mainly used that for C++).
I usually discover things by looking at random Emacs configuration. IIRC there is a repo on Github which keeps track of popular configuration out there.
When I 'retired' a few weeks ago I tried org-mode in a dropbox folder. Works great from my Linux and macOS laptops but iOS is a nuisance: I can read notes from the dropbox app and edit them with Textastic, but this is not 'ready at hand' tooling.
Since I 'retired' I am doing much more of my personal coding in Common Lisp and Haskell which means more Emacs use (although I also have VSCode set up for fantastic Haskell and Python dev experiences).
I need to take another look at Magit. I replaced org-mode with all-in use of G Suite (really enjoying functionality, high productivity, and security, cringing a little on privacy issues).
vscode however will probably take over that role some time during the next 12 months.
I have the same question, since someone who’s used Emacs for that long would surely have “seen the light” already. Maybe they’re yak shaving with the config instead of getting work done? That’s one of the few valid complaints I can think of.
Well, VS Code offers the equivalents of all the Emacs packages that I actually use, and they come with sane defaults. Once I've tweaked the Python module a little bit, I tend to ignore its other options and get back to editing code. And in that code editing environment, I honestly prefer VS Code. The key bindings feel like other modern apps (yay for using the same Mac shortcuts for moving around that every thing else uses). Menus (and their shortcuts) work as expected. I don't have Emacs's beautiful macros, but I do have multi-cursor editing which is beautiful in a different way. It's fast. It looks pretty, with nice easier-to-install themes and icon packages. Basically, VS Code does everything that I ask of Emacs, but in a modern package.
I still love Emacs. I had switched to Sublime Text at one point but came back to the 'Macs because ST wasn't good enough to win me over permanently. And I definitely still love the idea that I can rewrite all of Emacs to make it my own personal slice of editing heaven that is optimized for me and me alone. That's wonderful! But now that there's an excellent, MIT-licensed, well supported alternative that doesn't everything that I want in practice, I'm sold.
But if MS ever loses the plot and ruins VS Code, I'll be back on Emacs in a heartbeat.
I used VSCode for a few years, but never found a way to work with code in semantic units vs. as text. And I like that no matter what language I'm working in, the experience is the same. VSCode plugin editors may or may not (read: wouldn't have) agreed on a set of conventions for working with code independent of the programming language.
I get what you mean about Emacs's nearly universal code conventions, but that's an example of something I personally found to be more useful in theory than in practice. While I love the concept, 95% of the time I'm hacking around in Python. The rest of the time is a hodge-podge of shell scripts and the rare C snippet. Maybe a little SQL now and then, or perhaps some JavaScript. When I'm working in something that isn't my usual, I find myself spending much more time reading code than writing it, and in that context I don't get as much benefit from those conventions.
Of course this is all incredibly subjective. If you get a lot of benefit from that, awesome! I can definitely see the appeal. I just don't feel like it makes a whole lot of difference for me.
That said, I've realized that I don't do that much SCM stuff inside my editor. It's nice to have a beautiful client, but I'm comfortable with the git commandline itself and found myself using it for the tricky stuff, even when I had Magit at my fingertips.
My main editor-integrated workflow involves switching branches, committing, pulling, and other routing stuff that VSC handles just fine. It's definitely no Magit, but it covers 95% of the stuff I do.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.
Emacs does that in X11 because that is (or at least was) the standard behavior for text selection in X11. Emacs is simply conforming to the environment it is running within.
And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)
If you could fix that behavior so that Emacs behaves more like a native Cocoa application, I see no reason that the Emacs maintainers should reject a patch. Emacs has, as far as I can tell, always strived to use as much of a native system’s interface and conventions as possible. Emacs is very big, so it might seem to be a self-contained world of its own, but it’s trying not to be too idiosyncratic.
You would guess wrong.
(If you install an X server, you can run Emacs on X11 on a Mac, but if you do, the text looks radically different from the text in other Mac apps. ADDED. whereas if you run Emacs directly on Cocoa, the way most Emacs users on Mac do it excepting the ones running Emacs inside a terminal environment, the text looks exactly the same as the text in, e.g., Textmate or Terminal.app.)
I do know that Emacs did adapt a lot when coming to Unix/X11 from its initial roots on other systems, but maybe it has ossified since then.
For more info see the first answer here: https://emacs.stackexchange.com/questions/28840/os-x-emacs-d...
Even iTerm supports middle-click paste. Unix people are used to it.
Now that I read about all these younger people switching to emacs I feel even less inclined to "modernize" even though VS Code does look like a nice programmable editor.
mac pbcopy/paste into emacs does strange and horrible things. Mouse and scroll-wheel integration roughly doesn't work at all. The list is long.
I also use terminal tools a lot (data engineering), so the terminal itself (and hence tmux) is an important part of my toolset. Meaning, I can't abandon the terminal. Nor do I want to -- as others have said, I have RSI issues with touchpads and mouse-clicking. Spectacle on Mac (or any actual tiling window manager on linux desktops) helps with that, but if I never had to touch a mouse/trackball again in my life, that would be awesome.
As others have said, I mostly want to use an integrated editor and get on with my job, rather than go down a half-century old rabbit hole of reading SICP just to tweak some editor defaults. Again, don't misunderstand me: learning LISP changed my life, man. But that's not the same as "can I enable rainbow delimiters for protobuf" (As an aside, Little Schemer is a much gentler intro to LISP, and also awesome.)
And since I know we're a community of people who get distracted by the next shiny problem to solve: please don't focus on trying to fix the list of issues I'm describing. That's not the point (and I have no spare weekends).
emacs, when started with the -nw flag, has nothing to do with mouse gestures. The terminal emulator (iterm in your case) sits between you and emacs and does not pass mouse gestures to emacs.
Actually, to be painfully precise, there is a convention, which iterm and emacs might or might not use, by which iterm could conceivably pass the location of single left clicks to the emacs process, but, e.g., mouse drag events and scroll-wheel events never get passed.
So for example when the users drags the mouse, then presses Command-C, `emacs -nw` has no way of knowing the user did that, and if anything got into the system clipboard, that is iterm's doing, not emacs's.
Might I suggest `open Emacs.app` rather than `emacs -nw`? Except for a GNU or Emacs logo that can be suppressed by setting the variable inhibit-startup-screen to non-nil and except for a tool bar that can be suppressed by evalling `(tool-bar-mode -1)`, the result is indistinguishable from a terminal window to most Mac users, but has mouse and scroll-wheel integration.
To be precise, after `(server-start)` is evalled inside the Emacs.app process, whenever the command line `emacsclient <file name>` runs anywhere, inside or outside the Emacs.app process, the Emacs.app "visits" (opens) <file name>.
If I had found a way to change the size of everything on one of the Lua-based editors on the Mac, I probably would've switched years ago to one them. (I don't recall their names.)
If I stay with Emacs it will be because learning how to modify vscode, e.g., by writing my own extension, proved too difficult. (I want my editor to be a general interface to information that is easy for me to modify by writing code.)
"most of": The size of the menu-bar and pop-up menus is fixed in all of those apps when they are running on a Mac, but Apple made the text in them large and legible enough to suit me.
Setting the scaling to a fractional value in System Preferences doesn't count because the result is too blurry. I never obtained a monitor with a horizontal resolution of at least 2560, which is the minimum needed to set the scaling to 2 in System Preferences.
I use a 4k monitor and with a C-x +++ everything is bigger by 3x. I can set it permanently too.
What is vscode doing different?
I've tried it a few times but the default keybindings seem unnatural to me. Not that it's Emacs fault, considering the keyboards they used back then.
I've since switched to a proper mechanical keyboard and all is fine with the world.
[0] Technically Zmacs, but most of the key bindings were the same.
*I use a macbook pro, and my thumb is used to hitting CMD-X, CMD-C, CMD-V, s what has happened is that I hit control with my thumb instead of pinky - I curl the thumb in and below my palm.
But I still love default keybindings, and what is lovely, is that many of the navigation keys are system wide on MacOS: ctrl-a, ctrl-e, etc.
Then CMD-C and CMD-V actually also work on emacs, so I sometimes use those too (I use https://emacsformacosx.com)
I have seen a video about someone who hacked up a means to use Emacs via voice control. I may play with something like that myself. I doubt that using Emacs via a keyboard is really my bottleneck, though. So any hacks in that direction may be just for fun.
Now that Emacs is everywhere, I'm looking to going back and using evil-mode. We'll see how it goes. I find the customisation on Emacs far less hacky than vim.
[0] I used to grab tapes(!) from Uni to work and compile from source, on a fairly new / obscure architecture at the time.
It's helped (but not completely alleviated) my RSI. Absolutely worth the price for me though given that.
I use emacs all the time with all the half bad wrist positions and all and have no RSI. Not even CAPS LOCK -> CTRL trick.
For a MOOC I had to suff.. use Eclipse IDE. I don't like it but I didn't mind its keybindings. The morning after I had very nasty pain in my left hand. So I quickly got back into emacs to heal that rapid onset RSI.
I also have a Kinesis one that I used for some years. Those require some training.
The older Curve 2000 series might be a better choice if you actually want to use those keys with any frequency
(And to bring it back to emacs, I find myself using ESC-ESC-ESC quite a lot when I (or it) get confused about what state things should be in)
I would, however, love to hear a bit more on how you felt about the future of Emacs in those 30 years. I dunno much history, but is there any contrast to the present where Atom/VSCode is kinda shipping shiny (and useful) stuff way faster meanwhile being very configurable.
Then I learned several built in commands.
Years later I learned clojure, a lisp dialect. After learning it, and then looking back at emacs lisp (elisp), and a light bulb went on for me. You can write any elisp function you want, which has functions to manipulate text within buffers and much more. Using it you can create any kind of specialized editor function you can dream of, and you can call that function with "M-x function-name". If use use the function lots, then you can bind that function to a keystroke. (For example, if you wanted a completely custom function... to delete the current block of code, you could write an elisp function to go to move the point to the blocks beginning brace, set the mark, move to the matching brace, and then delete the region.)
There are several "modes" that define how buffers behave. A clojure mode will know how to highlight code and navigate around parenthesis. Magit-mode knows all kinds of commands for operating a git project, and org-mode knows commands to help facilitate note-taking.
Learn the various built-in help features, and use them. C-h C-h describes all the various help features.
Beyond that - force yourself to navigate via the keyboard only (no mouse, no arrow keys). You'll get more efficient and pick up shortcuts as you go.
I started with Emacs as my first editor when I first was learning how to code a few years ago. I played with it for about a year, then left it for VSCode when I got a job as the projects at the time were heavily JS/TypeScript based, then slowly went back to Emacs as I started to feel frustrated at how painful it was to do certain things on VSCode that I knew would be lower-friction on an editor like Emacs or Vim.
This second time around it has helped me a lot to not feel like I need to rush to master it, taking time instead to focus on committing one or two commands to muscle memory every 10 days or so, and looking at other people's configuration files for inspiration. Studying these configs in particular [0], [1] helped me quite a bit, as they're nicely commented, big enough to have some useful stuff in them and get real work done, but small enough to understand fairly quickly. I also make it a point to not add stuff to my config that I don't understand and try to follow good practices around commenting and code organization
Being OK with navigating inefficiently but making a conscious effort to learn one or two commands to handle stuff that feels painful (kill line, jump to beginning of file, jump to end of file, jump to end of line, back-to-indentation) then modifying anything that doesn't feel natural.
Learning to find help inside emacs: C-h b to list all bindings in the current buffer, or discover-my-major [2] for a friendlier interface, or [3] (highly recommended) for displaying and filtering available bindings as you type them. Cheatsheet [4] for creating your own cheatsheets to note and recall commands you're working on learning.
Finally, taking advantage of the fact that you don't need to leave Emacs for certain things. For example, at work we use Trello, and I love being able to check Trello from inside Emacs via org-trello-mode. It's very nice to not have to context switch when coding. Not to mention Magit (super powerful git gui inside emacs) and Tramp mode (for editing files over ssh from the comfort of emacs).
Also, I've generally found people to be extremely helpful on #emacs on freenode IRC. I've learned a lot thru osmosis just observing conversation there :)
[0] https://github.com/jsks/dotfiles/tree/master/emacs/.emacs.d
[1] https://github.com/flyingmachine/emacs-for-clojure/
[2] https://framagit.org/steckerhalter/discover-my-major
Here's all the actual commands (very few) I use day to day --> https://gist.github.com/franee/5d188ce36f6c24181707907614d2c...
I use mainly the emacs starter kit and build from there.
I swapped Ctrl & Caps Lock two years ago due to wrist pain when doing development in a laptop.
(1) Well, technically, that includes several years of XEmacs in the middle, when GNU Emacs didn't look as good under X11.
For what it's worth, I've actually been using on macOS the Mituharu branch [1], available in MacPorts as "emacs-mac-app". This version adds the [s]essential[/s] smooth-scrolling feature, and just in general seems to be slightly better integrated into macOS (except that it doesn't define the standard macOS keybindings, which I had to create manually. Ironic)
; Configure shortcuts if we're using Mituharu's Mac port of Emacs
(when (eq window-system 'mac)
(progn
(message "Setting emacs-mac keybindings")
(setq mac-option-modifier 'meta)
;supposedly setting this to 'nil gives them back to OS X, but that didn't work for me
(setq mac-command-modifier 'super)
(global-set-key (kbd "s-q") 'save-buffers-kill-emacs)
;I hate ⌘-w killing a window, too close to alt-w (copy). Deactivated
;(global-set-key (kbd "s-w" 'delete-frame)
(global-set-key (kbd "s-a") 'mark-whole-buffer)
(global-set-key (kbd "s-s") 'save-buffer)
(global-set-key (kbd "s-d") 'isearch-repeat-backward)
(global-set-key (kbd "s-f") 'isearch-forward)
(global-set-key (kbd "s-g") 'isearch-repeat-forward)
(global-set-key (kbd "s-z") 'undo)
(global-set-key (kbd "s-x") 'kill-region)
(global-set-key (kbd "s-c") 'kill-ring-save) ;ns has ns-copy-including-secondary, on mac- port, kill-ring-save works the same
(global-set-key (kbd "s-v") 'yank)
(global-set-key (kbd "s-y") 'yank) ;ns-paste-secondary
(global-set-key (kbd "s-u") 'revert-buffer)
;(global-set-key (kbd "s-o") 'ns-open-file-using-panel) ;no good alternative
;(global-set-key (kbd "s-p") 'ns-print-buffer) ;no good alternative
;(global-set-key (kbd "s-h") 'ns-do-hide-emacs) ;done by default
(global-set-key (kbd "s-j") 'exchange-point-and-mark)
(global-set-key (kbd "s-k") 'kill-this-buffer)
(global-set-key (kbd "s-l") 'goto-line)
(global-set-key (kbd "s-n") 'make-frame)
(global-set-key (kbd "s-m") 'iconify-frame)
(global-set-key (kbd "s-`") 'other-frame)
(global-set-key (kbd "s-,") 'customize)
(global-set-key (kbd "s-'") 'next-multiframe-window)
)
)- The server mode compatibility with the way Mac applications are set up. I'd ideally want an emacs server running in the background, and a client app open/close seamlessly whenever I'd like. What actually ends up happening is that I close the client windows but the app never "quits". So it's a zombie icon always hanging around my cmd+tab list.
- "Windows" (or Frames?) have generally not worked seamlessly for me. I've to always put in hacks in my config to ensure the emacs windows work like other apps do for mac. They're either too small and then size up when config is applied (which has some latency so it's noticeable when it happens), or they don't work at all.
- Font rendering. There is some minute rendering difference in the way the same fonts that renders on Vim/iTerm/Macvim/Sublime/VSCode/IntelliJ, but it's the worse by far on my emacs. :(
- All of these complaints are for the GUI mode tbh, which I prefer to use since I like to keep my terminal separate from my editor. Terminal-only emacs is something I tried a few years ago and I remember getting annoyed by keybinding issues etc.
Maybe all of the above are old issues that are no longer present, or maybe I was doing things the wrong way. It just never felt like it was a seamlessly integrated application on the Mac. I hope that has changed or will change. :)
It’s an annoying fix but when done right it feels exactly like emacs is a native app.
It’s a very impure emacs but I like it as it interstates in macOS well. (Drag file into icon and it opens. The cut/paste from Mac works well).
A lot of my emacs use is ssh into remote server based so I use that most of the time.
Worth double-checking, but I think that's one area Mituharu's is better than standard Emacs. I definitely recall some font rendering issues with some past version.
As for your other points, they aren't resolved. FWIW, I work around them:
> The server mode compatibility
I just have one long-running Emacs session. I have some colleagues who have experimented with using a launchd LaunchAgent to start emacs server in the background when they login. I haven't kept up with their results and I don't know if there are any side-effects.
> "Windows" (or Frames?) have generally not worked seamlessly for me
Since I have a long-running session, this isn't much of a problem for me. That said, when I do start up Emacs on first login, it indeed takes upwards of 5 seconds to startup, including a window re-themeing and resizing. It's not great, but like I said, it's only once at startup for me. Furthermore, because I came from a tiling window manager on Linux (AwesomeWM), I required similar behavior on macOS. I use SizeUp [1] with shortcuts configured to move my windows to side/corners of the screen. It's far from being as good as a true tiling window manager, but I've had to be satisfied with what I can get.
[1] https://www.irradiatedsoftware.com/sizeup/ (there are alternatives like Moom)
However, be warned, BTT’s interface is messy and the buttons it creates don’t look right unless you manually adjust the styling yourself. Also, macOS won’t show BTT’s buttons unless you either allow BTT to take over your whole Touch Bar, hiding Apple’s global buttons, or you expand the BTT toolbar beforehand, which must be closed before you next try to press the Esc key.
brew tap railwaycat/emacsmacport
brew cask install emacs-macEmacs is the most delightful software I have ever used. I could evolve a flexible todo management productivity workflow, start writing a journal and start writing new posts in a distraction free environment all using Org Mode in just two days. A complete win for someone who went back to paper (rather unsuccessfully) to organize to-dos after finding digital tools inflexible.
And for python development on remote machine, I get editing and autocomplete on remote systems out of the box (spacemacs) due to Tramp. I was like wtf, why didn't I start using this beautiful piece of software years back.
The way Emacs is a programmable platform really changes how I view what a good software should be. For instance, I was documenting a machine learning experiment in org mode file. I wanted to mention a metrics result generated as json by my machine learning code. I could just embed sh into the org file, execute it (on the remote machine without friction) and print result directly into the org file. I can trivially compare results in two files and record it back into org mode easily, even on a remote system.
It has made me think that we need more software which erases distinction of programming as something distinct from using software.
This contrasts with ncurses based CLI tools, which are little silos. And of course, most GUI applications.
In particular, I'm really fond of Org, Magit, Notmuch and PDF-Tools. I feel they are really nice additions to classic Emacs. Some old packages are really nice too. E.g. AucTeX, Gnus, Calc, Dired, Eshell... Although I feel Eshell and Gnus would really benefit from some refactorings.
And of course the myriad of programming modes.
I feel I don't need much more than Emacs, Firefox and a tiling window manager on top of some underlying OS (preferably Unix).
And, yes, pdf-tools is awesome.
Emacs is reliable, fast and elegant, and a joy to use as a truly integrated environment for all kinds of tasks, including software development.
I have yet to come across anything that compares, and I definitely prefer having Lisp built in to Python bolted on to the side.
Emacs used to be considered quite slow, but compared to the latest offerings its pretty snappy.
Never got it to work well in Windows, but that's not an issue for me anymore.
I think emacs has a few simple advantages:
1. It’s based on a high quality extensible programming language which supports writing extensible programs. This makes implementing new features, new language features, or just modifying/fixing existing ones possible and usually easy.
2. The primitives/idioms (hooks,buffers,buffer-local-variables,markers,interactive functions,advice,keymaps,text properties) tended to be good choices that allow separate modes/programs within the editor to interact well with one another. They also allow easy extension/modification/fixing of the system. I think modules (although useful and maybe necessary) do not typically fit into this category.
3. Emacs realises the idea of a programming environment built into a user interface (ie one where it is easy to interact with the user in a way that is not stdin/out). I feel like this is often touted as an advantage of html/JavaScript but in emacs one already has all the other useful programs/libraries to base one’s own creations on. On the web one always has to start from scratch. On the other hand elisp does not have any GL/canvas interface (although you can write an svg (or worse) and display it).
4. The documentation tends to be pretty good and when the documentation fails
Emacs certainly has disadvantages too. One is setting it up, another is that it often breaks and it can be hard to get used to emacs. I personally am not bothered by these because I already know enough to not mind/struggle much fixing things. Another issue is ide features but I don’t really use languages with separate ides (unless you count languages where emacs is the ide) so I don’t mind this. Indeed I mostly don’t use any of the ide attempt features like projectile or the static code parsing/analysis
“ New variable 'xft-ignore-color-fonts'.
Default t means don't try to load color fonts when using Xft, as they often cause crashes. Set it to nil if you really need those fonts.”
I see they finally caved in (although in a quite pedantly trying not to way) and allowed use of color-fonts. Whee!
The way things are going, I figure either Emacs will die or I will before I stop using it. I guess I'm a set-in-my-ways old-timer. So be it.
Recently, I reached my last nerve with MS Word and buckled down to ditch Word for emacs.
Today I do just about all my writing in emacs (markdown) and then generate word docx using pandoc at the end. Now, I use emacs all day everyday -- blessed. And I am more productive especially since I am actively pushing to keep increasing my power-user level.
What does org-mode do with writing documents that is better than Markdown?
markdown<->docx with pandoc lets me use a ref-doc.docx file that ensures all the styling I need for legal docs gets into the word doc. So you make a markdown file from the ref-doc.docx then edit the markdown file and convert to docx using the same ref-doc and everything in docx has the correct style, and stuff like line numbers and headers are preserved. Pretty sweet.
As I stand now, it seems really hard to justify to invest time into it when the benefits over using something very easy to work with (like JetBrains IDEs for Java or VS Code for Python) sound marginal.
I know experts can fly around in it and it looks amazing. Having a single point of entry for all kinds of things (ssh to VM, git, text editing, org mode, email...) sounds great, but it is so much work and it seems like I could always be spending time doing something immediately beneficial with the tools I already use. Not to mention that the end result might not even better for the given application (can I really hope to have easier time developing a Go app with Emacs and couple not-so-actively developed plugins than GoLand/VS Code?).
For nearly everything else though emacs shines.
I see VS Code touted as an emacs alternative and while your muscle memory might suit it better can it truly give you the uniform fluid experience across pretty much any development enviromnwnt you might use?
And before the VSCode fanboys downvote me, the other day my colleague's VSCode instance was using more than 200GB of virtual memory. When I typed on his editor it was noticeably laggy. He told me it was normal. He had five files open. My emacs had been running for two weeks at that point and had about 200 files, 5 shells, 2 ssh sessions and 1 IRC client going on.
Seriously, guys. The reason why you like VSCode is the same reason we like emacs. Come and use the real thing.
There do have to be real benefits to make it work. For me it was some very specific things I wanted to do for data analysis that weren’t possible in an IDE at the time, and the other benefits (org-mode, tramp etc.) just sort of compounded.
It’s certainly been a process though. And I wouldn’t have got here if I didn’t find fiddling with editors an enjoyable thing to do, while waiting for a database-query/drinking-buddy-to-leave-work/partner’s-Netflix-binge-to-conclude etc.
However, Atom has always had issues. Snippets are very limited due to design issues. Now a days I keep getting random js errors and the syntax highlighting stops working below a line I was working on.
Microsoft's acquisition of GitHub likely will hurt future community development of plugins since new programmers will assume the worst and develop for VSCode or move on.
Atom showed me how useful/important having an editor I could easily customize is. And the two above shows me how important having an editor with a strong independent community is. I am trying Emacs, but it is a struggle and Spacemacs keeps having random issues (and feels slower than Atom). So right now I am learning Vim with Vundle.
All the avante garde language extensions (Rust, D, etc.) support VS Code better than Emacs now. VS Code is where all the new ideas are tried first.
That said, VSCode has a lot of good ideas around tooling and I've been toying with the idea of looking into making a fork that replaces the editor component with an embedded NeoVim. I feel that would be the best of both worlds, but obviously a huge undertaking. There is already NyaoVim that implements a NeoVim gui as a web component.
I only learned Vim recently and I have hit no issues so far working on a large enough codebase such that navigation and autocompletion wouldn’t work effectively for any IDE.
I instead use cscope and ctags which allow me to selectively setup navigation and autocomplete from within Vim.
Regarding your last point: that already exists https://github.com/VSCodeVim/Vim
It sounds like you've found something that works. But if you find yourself with a hankering to take a long weekend, lock yourself in a hotel room like John Carmack, and devote that time to really learning Emacs, I encourage you to do so. It should prove quite rewarding.
So needless to say it was the first thing I tried when I got my shell account. I got stuck in it, couldn't figure anything out, and had to power cycle the terminal before sneaking away sheepishly.
But yeah, emacs is best, and I'm still using it now that I know how to exit.
It may be fine for a very casual vim user who wants to switch to emacs but it's too confusing for a vim power user. There are subtle differences that disrupt the flow of my muscle memory. One such example is the }{ forward and reverse paragraph motion. In vim, this is perfectly predictable and delineated by empty lines. In evil-mode, however, it's hooked into the major mode, so it's always changing behaviour as you switch between different file types.
I use Emacs very casually, mainly just for writing in org mode with Evil, and have toyed with the idea of switching to it completely. But, if you could talk about the figurative holes you fell into as a vim expert that could help inform my decision down the road.
1. Search/replace behavior - Not that it is better or worse, just that it is different. 2. Misc. ex commands. I don't remember specifics. 3. Plugin specific commands. Not really fair to bring up, but still part of my muscle memory.
Long time vim user, switched to evil emacs. Works great, have zero issues with it.
I have actually found it hard to go back to vim because emacs has been much easier to customize and many of the features I use routinely are no longer in my vim config.
But overall i prefer Spacemacs to vim for general development.
I recommend using the develop branch of spacemacs. It sometimes breaks but if there is something broken it gets fixed really fast, whereas if something is broken on master then it sometimes stays broken for a really long time.
Emacs keybindings are burned into my brain at this point, but if I had to do it again, I would probably go with spacemacs. I think modal editing is probably superior.
I'd recommend Spacemacs (even if you're not using evil) if you're new to Emacs and want to see how different and powerful a fully customized Emacs is when compared to the bare-bones experience of stock Emacs.
As many others have suggested, take a look at Evil, the best Vim emulation for any platform. Just ease your way into it by replacing Vim, then some other CLI programs, then figure out when to stop when the Emacs version is no better than what you were using before.
Also, the default theme is fantastic along with great defaults for key bindings.
I haven't tried distributions like spacemacs or doom-emacs (which is lighter-weight than spacemacs, with fewer abstractions above emacs). I think emacs is software which benefits from being well understood by the user, to the extent of "if something breaks I can fix it".
- Guile Emacs does not seem very alive: http://git.hcoop.net/?p=bpt/emacs.git
- Remacs, a Rust port, seems to be more alive: https://github.com/remacs/remacs Does not look usable as a daily driver, though.
I sometimes wish that Xi editor adopted an elisp port as one of the scripting engines. Not very likely, though; a suitable port does not exist in the first place so far.
OTOH, being an in-place rewrite, it likely cannot afford to change some of the more important architectural decisions, very likely including the ones that prevent multithreading.
> This is also only the first step in bringing threading to Emacs Lisp. Right now there’s effectively a global interpreter lock (GIL), and threads only run one at a time cooperatively. Like with generators, the Python influence is obvious. In theory, sometime in the future this interpreter lock will be removed, making way for actual concurrency.
http://blog.unicode.org/2019/03/announcing-unicode-standard-...
Dired is so handy, but it does so much. Unless I were to use this feature often enough I fear I would never remember it was there and just break out to a terminal and `tar -zcf` manually.
I feel like something already exists for this, but it would be cool if there was a "Random Mode Tip of The Day" that one could invoke for discovery and practice of things like this.
Could be modified to show, e.g. dired commands as well.
> if you can think of it, there is most probably an emacs plugin for it.
Anything Ive looked for has been out there, excepting some truly specialized things (fontification for custom file formats)
However, Windows.
By the way, I like your user name. How odd that I remember that command.
When I installed the emacs on MacOS by the step at https://www.gnu.org/software/emacs/download.html#macos (`brew install emacs --with-cocoa`). I got an `Error: invalid options: --with-cocoa`
Finally, I found the solution here: https://emacs.stackexchange.com/a/47774/13172.
Now, I want to know who can modify this command at the official site.
PS: Homebrew 2.1.0 Homebrew/homebrew-core (git revision 024e26; last commit 2019-04-13) Homebrew/homebrew-cask (git revision 20182; last commit 2019-04-13)
Mostly org-mode these days, plus whatever weird hobby language thing I'm doing (Haskell, now).
Swapping control & caps lock is essential. I got really painful RSI pain in my first pinky joint before I did that. Sounds silly until it happens.
And my config file.... :-)
For anyone curious, the Prime version of Emacs is running on a Prime emulator I set up. Telnet to em.prirun.org port 8002
Memories....
If you care about integration with other text-based tools (like email, instant messaging, source control, code review, IRC, ...) then switching to emacs will transform your workflow.
There are a couple of emacs modes that stand out, and in my opinion make emacs worth it:
* Org-mode (https://orgmode.org): A note taking system * Magit (https://magit.vc/) the best git client I've ever used.
Emacs is probably the best piece of software I’ve ever used, and will use. I bet in 100 years, emacs will still be going strong. There’s really nothing it can’t do.