The benefits of everything being a buffer in Emacs

https://mbork.pl/2023-01-30_The_benefits_of_everything_being_a_buffer

by mbork_pl • 3 years ago

375 196 3 years ago

mbork_pl4• 3 years ago

This is a cool anecdote about something that happened to me last week. I'd love to hear similar anecdotes where people who use Emacs (or Vim, or other software sophisticated enough) were able to combine its features in unexpected ways.

convolvatron• 3 years ago

C-x r k C-x b *scr C-I C-x r y M-< (+ M-> ) C-j

jgrahamc• 3 years ago

"Kill" text in a "rectangle" and save its contents

    C-x r k

Switch to the scratch buffer (think there's a missing RET at the end)

    C-x b *scr C-I

"Yank" the "rectangle" saved in the first command

    C-x r y

Moves to the start of the buffer and sets a "mark"

M-<

Literals that are entered at the start of the buffer

(+

Move to the end of the buffer

M->

Another literal

Executes the buffer (or at least the LISP expression at the cursor). Note the scratch buffer allows you to type arbitrary LISP stuff and execute it with C-j.

C-j

So, suppose the initial buffer contained

Then the scratch buffer would get turned into

And when executed this would add the list of numbers and look like this:

garethrees• 3 years ago

Another way to sum a column of numbers uses calc:

  M-x calc-grab-rectangle RET V R +

wging2• 3 years ago

One lovely little thing: since everything is a buffer, autocomplete has more to work with. Specifically I'm thinking of hippie-expand's `try-expand-dabbrev-all-buffers`, which just uses all buffers as sources for 'expansions' for what's currently written. So you type "thi" -> M-/, and because another buffer has "thing-you-want", it is able to complete what you wrote out to "thing-you-want".

This is straightforward when you just think of buffers as being source files in your IDE, but it's not limited to that - you can also complete from a dired buffer, or your compiler output buffer, or your REPL. So you can get a filename to expand, even though no source code file actually contains that filename. If instead of dired and compile-mode you were using a separate file manager, and a separate terminal window to compile, you'd have text in three separate programs and no expectation that the text editor in your IDE would be able to see the other two.

mbork_pl4• 3 years ago

Oh, yes! This is something I use all the time, and it's so natural (I've been using Emacs and dabbrev for about 2 decades now) I don't even think about it.

a_e_k3• 3 years ago

Changing buffers works just fine in keyboard macros.

So sometimes I'll prepare one buffer with a list of lines that are basically meant to provide input to a macro for editing another buffer and have the macro constantly jump back and forth between them. (E.g., move to a spot in the "edit" buffer, jump over to the "input" buffer, kill the next line, jump back to the "edit", yank that line, etc.)

luispauloml• 3 years ago

Reminds me of "Episode 16: dired" of Emacs Rocks: https://emacsrocks.com/e16.html

hprotagonist3• 3 years ago

i absolutely love wdired. it’s magic.

for extra fun, it combines well with multiple-cursors or visual-regexp-steroids, at which point bulk renaming is basically a game.

marco_craveiro• 3 years ago

I also love wgrep. [1]

[1] https://melpa.org/#/wgrep

hprotagonist3• 3 years ago

and rg.el, which is that UX for ripgrep.

stevenhuang• 3 years ago

dam, where's vim's equivalent for this??

whenever I get into netrw I always have to lookup its special bindings to create/rename. I'm jealous :P

hprotagonist3• 3 years ago

i suppose you could hack something together with fzf and sed and rg. I've seen some pretty hairy stuff done that way.

avbanks• 3 years ago

Moved from Vim to Doom Emacs (w/ vim keybindings) and I'd recommend. Dired, Magit, and Org-Mode have all been great.

ossusermivami• 3 years ago

vidir from moreutils does this over an agnostic $EDITOR https://manpages.debian.org/testing/moreutils/vidir.1.en.htm...

seanw4443• 3 years ago

For me it's not the "unusual synergy" between its applications that's handy. I rarely have a situation that is significantly faster than it would be in any other editing environment. What makes it amazing to me is the uniformity of it. Everything operates the same, and the keybinds apply everywhere that they're supposed to. There are many programs that are not that way, and it's kind of jarring.

Also, every buffer is a blender of modes. Want a new feature or some handy functionality? Activate a mode.

My only argument against Emacs used to be its sluggishness, but that's no longer a thing with native compilation. So now I'm pretty sure Emacs has spoiled me, and I'll never be able to enjoy another text editor again.

agumonkey2• 3 years ago

There's probably some room for improvements. People say lispmachines were still more interesting down and up compared to emacs.

A few things I'd like to have is keymap collisions handling, but as anything in emacs, i can always code it with enough time :)

theonething2• 3 years ago

I'm pretty sure Emacs has spoiled me

Comments like this make a long time Vim lover like me very curious, but I guess not curious enough to try it. Maybe one day.

What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in. You gotta jump in head first, sink for awhile and then hopefully learn to swim. Only then will you know if you like it.

shadowofneptune4• 3 years ago

This was not my experience with Emacs, oddly enough. I started using it because it was the only editor that both supported a terminal and had a top bar. Like a windows program, pressing F10 gets you a File, Options, etc. menu that helped me get through that first session. Emacs (and other Vi's, I should note) has made a nod towards accessibility that Vim has not.

nequo3• 3 years ago

What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in.

Another thing that Emacs and Vim have in common is Vim keybindings.[1] You can pick Emacs keybindings up at your own pace. From one vimmer to another, if you want to try out Emacs, I highly recommend doing it with Evil.

[1] https://github.com/emacs-evil/evil

spamizbad• 3 years ago

FWIW vim was my first "serious" editor and I switched to Doom Emacs (which defaults vi keybindings) and couldn't be happier. Although tbh if I didn't have vim muscle memory I probably would've landed on VSCode.

kneebonian2• 3 years ago

I was a long time vim only user, that lived and breathed in the terminal. Then I found Doom Emacs, and it gave me everything I never knew I wanted or needed. I'd highly recommend giving doom emacs a try. There is also a great series of videos on how to use Doom Emacs on youtube.

outworlder• 3 years ago

What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in.

You kinda can, these days.

One of the main issues is that Emacs is, out of the box, the most complete toolbox you'll ever see, while at the same time being very incomplete. You have an email client, spreadsheet, unit converter, ASCII drawing, debugger, file explorer and so on and so forth. Meanwhile, you open a Python file and you are lacking a bunch of stuff that the likes of VSCode have out of the box.

So the solution is to customize, and that takes an inordinate amount of time.

Thankfully, some other people have solved this for us:

https://www.spacemacs.org/

Spacemacs has VI commands by default - and I don't mean just the simplest keybindings like some VI emulators do, it's using evil-mode and it's pretty good. It can also be used in 'holy' mode (Emacs keybindings).

There's also(the one I use):

https://github.com/doomemacs/doomemacs

Either of these will get you a much more modern Emacs experience out of the box. You may need to add packages (it wouldn't be feasible to add all packages that everyone could possibly want), but they make it easy. Even though Emacs now comes with a package manager, it doesn't have any opinion on how you configure things. Both Spacemacs and Doom Emacs are opinionated, and that's a good thing.

Sure, you still need to learn concepts and keybindings. Thankfully, there's no shortage of tutorials, and Emacs own built-in documentation is very good. It also has a built-in tutorial, which is how I learned.

weaksauce2• 3 years ago

you should install doom emacs. it has some vim stuff baked into it and you also get the absolutely awesome git ui that I can't stress enough is the best piece of software written in a long time. sounds like hyperbole but it's seriously so well made.

doom emacs. press spacebar to get a menu of things you can do and you also get a bunch of vim stuff for free. I don't use emacs as a daily driver but I still use it exclusively for the magit mode for git.

a caveat that you should be aware of is that you do need to learn a bit about emacs. what's a frame/buffer and how to kill them but that's not too bad.

Torwald• 3 years ago

What makes it amazing to me is the uniformity of it. Everything operates the same, and the keybinds apply everywhere that they're supposed to.

This is the best summary of what the original Macintosh was all about and why Macintsoh enthusiasts back then loved System 6 and upwards.

(They didn't call them keybindings though. Keyboard shortcuts. (Ironicly a longer word. (yes)))

ramin_hal90013• 3 years ago

Yes, and this really showed with applications like Hypercard where you could build apps making use of the operating system's widget toolkit. The old Mac OS was based on the Xerox Star, which was in turn a commercial implementation of Douglas Engelbart's original GUI computer NLS. The Xerox Star supported both Lisp and Smalltalk development environments.

Unfortunately, Steve Jobs didn't care about Lisp or Smalltalk, and he hated Hypercard, and he took the company's product lines in a consumerist direction, which is why Apple has "app stores" nowadays instead of a thriving ecosystem of tiny Lisp programs that compose well with each other.

yamtaddle• 3 years ago

Connecting the two, having emacs-like text navigation shortcuts work in any halfway-native text input or field, on Mac, now feels so right to me that any platform without that feature seems flat-out wrong.

adesanmi• 3 years ago

Did you mean to make a lisp joke here?

celrod5• 3 years ago

Regarding the uniformity...

I started using tiling window managers a few years ago. These took a little configuring. I always had one monitor with an emacs session, and then another with an internet browser, and a terminal running tmux, which again needed a bit of configuring.

It took me wayyy too long to finally try EXWM[0]. Suddenly, I have that uniformity and consistent experience everywhere, and only a single configuration language to learn and use to get things how I like them.

If you like both emacs and tiling window managers, I strongly recommend it. My only major gripe is that the single threadedness can be bothersome on occasion, when certain commands can render it unresponsive. But it is still well worth it for me.

[0] https://github.com/ch11ng/exwm

barbariangrunge• 3 years ago

What does eMacs have to offer a rider or other jetbrains ide coder? Somebody who is used to some really handy refactoring, autocomplete, and auto formatting tools for very large code bases, Eg, like an unreal engine game project (which even visual studio can’t really keep up with)

ticviking• 3 years ago

The single threadedness is the thing keeping me from trying it. Emacs with per-buffer threading would be pretty much golden, but I understand the work to get from here to there may actually be nearly impossible.

shadowofneptune4• 3 years ago

With the Emacs shell, this goes a step further. Emacs functions and /bin/ commands are put in the same namespace. '+' is now a command that can be run at the command line, while 'grep' can have its output redirected to a buffer instead of a file (Sadly no input redirection). This, all while itself being a buffer.

It doesn't work well with full-screen programs, or ones that use escape sequences. Sadly there's no away around that besides keeping a list of those programs. Unix programs have never needed to say to the OS "I am a fullscreen program" due to how little a traditional shell actually interacts with a programs.

Emacs is my login shell now. I feel however that other, more pure attempts at this like the Canon Cat and Plan 9's text editor were smothered by the Mac/Windows interface of GUI programs which rarely interact. A more evolved shell never had the chance to arise.

jrockway• 3 years ago

It doesn't work well with full-screen programs

eshell, at least in the past, is quick to involve ansi-term (M-x ansi-term) when launching a program that requires it. I recall being able to run Emacs inside of Emacs circa 2008, not sure if things have changed since then.

_emacsomancer_2• 3 years ago

There's also eshell-vterm[1], which allows eshell to use vterm for visual commands.

[1] https://github.com/iostapyshyn/eshell-vterm

shadowofneptune4• 3 years ago

That's what I meant by keeping a list, didn't expand on that much. It's something that needs to be configured per-program, which is an issue.

akira2501• 3 years ago

I've mostly ditched tmux for emacs shells. I wrote a quick script that gives me tmux like shortcuts for tagging and switching to different buffers. This allows me to start several shells and move between them with simple "Alt-Fn" shortcuts. The split screen modes and copy paste are so powerful I find myself opening emacs just to use the shells even when I don't have any need for a file editing buffer.

soamv• 3 years ago

wow, I've used emacs for a gazillion years and never thought to replace screen/tmux with it. I think I'll start now, thanks to your comment!

lelanthran2• 3 years ago

That's quite funny. I've ditched the terminal for vim with split screen, for pretty much the same reason that you are using emacs - quicker to shift between shells and copy/paste become so much more (also, searching command history is not intuitive).

Here's my shell script for vimterm.sh:

    vim -c 'call Tmux()'

And here's the relevant function from my .vimrc:

      function! Tmux()
         vsplit
         terminal
         set nonumber
         wincmd j
         q
         wincmd l
         terminal
         set nonumber
         wincmd j
         q
      endfun

abudabi123• 3 years ago

The Unicode has a Unihan_Readings.txt file that can be transformed into a readings-table for Emacs to help you accelerate your learning the character definition and key sequence for input method. To help your eyesight you can configure Emacs to enlarge the East Asia fonts. What I don't know how is to append to the "chinese-ctlaub" input method missing key sequence for input method.

For example, 雈, code point #x96c8, the chinese-ctlaub input sequence is missing. I'd like to update chinese-ctlaub with the reading "woon4".

See https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php?wo...

Here is the emacs lisp configuration.

     1 
     2 
     3 
     4 ;; --- create readings table
     5 
     6 ;; #!/bin/sh
     7 ;; M='path_to/unidata/Unihan_Readings.awk'
     8 ;; X='path_to/unidata/Unihan_Readings.txt'
     9 ;; Y='./uni-unihan-readings.el'
    10 ;; awk -f "$M" "$X" > "$Y"
    11 
    12 
    13 ;; --- readings table to load
    14 
    15 ;; (defvar readings-table
    16 ;;  (make-char-table 'readings-table nil)
    17 ;;  "Char table of definitions for East Asian characters.")
    18 ;; (aset readings-table #x340C "a tribe of savages in South China")
    19 ;; (aset readings-table #x3416 "㐖毒, an old name for India")
    20 
    21 ;; --- keybindings to locate definition or key sequence
    22 
    23 (load "~/lib/emacs/x/Unihan_Readings.el")
    24 
    25 (defun x/define-char ()                                                    
    26   (interactive)                                                            
    27     (message "%s" (aref readings-table (following-char))))  
    28 
    29 (defun xb/quail-show-key ()                                                
    30   "Always apply quail-show-key to chinese-ctlaub input method."            
    31   (interactive)                                                            
    32   (if (string= current-input-method "chinese-ctlaub")                      
    33       (quail-show-key)                                                     
    34     (progn                                                                 
    35       (set-input-method "chinese-ctlaub")                                  
    36       (quail-show-key)                                                     
    37       (toggle-input-method)))) 
    38 
    39 (defun xxb/quail-show-key ()                                               
    40   "Always apply quail-show-key to chinese-py-b5 input method."             
    41   (interactive)                                                            
    42   (if (string= current-input-method "chinese-py-b5")                       
    43       (quail-show-key)                                                     
    44     (progn                                                                 
    45       (set-input-method "chinese-py-b5")                                   
    46       (quail-show-key)                                                     
    47       (toggle-input-method)))) 
    48 
    49 (add-hook 'text-mode-hook
    50    (lambda ()
    51      (define-key text-mode-map (kbd "<f1> <up>") 'x/define-char)                          
    52      (define-key text-mode-map (kbd "<f1> <right>") 'xb/quail-show-key)                   
    53      (define-key text-mode-map (kbd "<f1> <left>") 'xxb/quail-show-key))) 
    54 
    55 ;; (setq view-mode-hook nil)
    56 (add-hook 'view-mode-hook
    57    (lambda ()
    58      (define-key view-mode-map "w" 'x/define-char)                          
    59      (define-key view-mode-map "a" 'xxb/quail-show-key)
    60      (define-key view-mode-map "d" 'xb/quail-show-key)))
    61 
    62 (dolist (charset '(kana han symbol cjk-misc bopomofo))                     
    63   (set-fontset-font                                                        
    64    "fontset-default"                                                       
    65    charset (font-spec :family "BabelStone Han" :size 28)))

shadowgovt2• 3 years ago

This was the first tricky bit to wrap my head around when using emacs: "Why do they call files 'buffers?' Every other text editor just calls them files."

Wrapping one's head around the difference is IMHO the first step into grasping why emacs sticks around after all these decades.

vidarh• 3 years ago

I use my own custom text editor, but came from emacs, and one of the best choices I made was to copy that bit.

spudlyo2• 3 years ago

Windows and frames, killing and yanking, point and mark, slurping and barfing -- there's a lot of Emacs nomenclature that confuses people initially.

jordigh• 3 years ago

This is poetry. I almost could fit it to the tune of Favourite Things, which coincidentally these thing are. My favourite things, I mean.

Conscat• 3 years ago

My instinct was to deny, but actually yeah every one of these confused me when I started.

hollerith• 3 years ago

I do not catch your meaning.

Every text editor I know of makes its edits to an in-memory copy of the file. If interactive edit commands operated directly on the file, the Save command would make no sense.

Emacs calls the in-memory copy a buffer. (VSCode calls it an editor.)

shadowgovt2• 3 years ago

Most text editors call it "file" or "document," even if it's not yet backed by disk.

It's a subtle difference, but I think emacs's decision to call them "buffers" (though it makes the editor a space-alien by modern standards, that much harder to learn) makes more clear that the user should have no expectation that any of the buffers ever get backed to long-term storage. Once one wraps one's head around that, a lot of things get much easier (including and especially writing document editing functions; where most systems would have you store blobs of text in string variables, emacs really wants you to pop up temporary buffers and manipulate them like any other buffer, with the added benefit that if a function fails mid-execution, the regular buffer editing tools make it easy to inspect the failed state).

anyfoo• 3 years ago

The distinction is that buffers are by no means necessarily in-memory copies of files. When you start up emacs, you will have more buffers active that are not backed by files than buffers that are.

cmrdporcupine• 3 years ago

The distinction becomes clearer once you start using emacs buffers for things other than text editing; like, say, an IRC client or a command shell, or elisp eval.

It is a direct manipulation interface based around interacting with text. The buffer is where it happens. "Files" or "documents" can be in those buffers. But so can textual sessions of many other kinds.

PurpleRamen• 3 years ago

There is the slight difference, that buffers are directly accessible for the user, while other editors only indirectly let you use the in-memory-data. So, what VS Code calls an editor, is in Emacs a window, not the buffer.

This subtle difference becomes relevant for example when working with multiple views on the same buffer. In VS Code, those views are only getting synced when it's a file on space. But open a new editor without an associated file, and every new view on that content, will become an independent copy.

mjw1007• 3 years ago

Yes, this sort of consistency is very valuable.

It's far too common that the interface an IDE gives you for something like adding a watchpoint is "type an expression into this small area in a dialog box, using a restricted subset of my text-editing features".

I sometimes think the main attraction of print-style debugging is that it doesn't do that to you.

textread• 3 years ago

"It is better to have 100 functions that operate on one data structure than to have 10 functions that operate on 10 data structures" - SICP <3

xyzwave• 3 years ago

I’m guessing SICP took that from Alan J. Perlis, considering he wrote the foreword.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

czx4f4bd2• 3 years ago

It's from the forward. Page xvii in this copy: https://web.mit.edu/6.001/6.037/sicp.pdf

czx4f4bd2• 3 years ago

I would posit that this is also why spreadsheets and shell scripts remain so widely used.

why-el• 3 years ago

Oh yeah, it gets even more interesting in large refactors, say an involved rename that requires you check the context before you do so (like not just global search and replace). I do a search, this opens a buffer with all results, with file name, position, all that, and Emacs can allow you to "peek" into the file without even leaving the search buffer focus (i.e use a split screen). Then, use https://github.com/mhayashi1120/Emacs-wgrep to do the magic of in-place editing.

anschwa2• 3 years ago

Yes! wdired and wgrep are really fun.

It's amazing how Emacs utilizes buffers to offer a very powerful and consistent user interface.

I think some other compelling examples are compilation-mode and magit.

a_e_k3• 3 years ago

And `e` in occur to go into the very similar occur-edit-mode (which also works in multi-occur to make changes across multiple buffers).

anschwa2• 3 years ago

Wow! Occur is the gift that keeps on giving. That's great!

TacticalCoder2• 3 years ago

Speaking of spellchecking... As devs we tend to use lots of weird words and acronyms and they're not, by default, in the spellchecker that Emacs (or other editors) do use (aspell in my case). You can add them but then I take it many of us keep "adding to the wordlist" the same words (for example, yes, "abs", "stdin" and "stdout" are correctly spelled, etc.).

Does anyone know of a good source of "programming vocabulary" made to add to spellcheckers?

teddyh• 3 years ago

Maybe https://en.wikipedia.org/wiki/Free_On-line_Dictionary_of_Com...

TacticalCoder2• 3 years ago

Thanks, I just checked Foldoc: there's definitely quite some stuff in there but then I tried terms like "Clojure" and "iptables" (which aren't recent by any means) and they're apparently not in that dictionary but it's a start, I'll dig a bit more.

fithisux• 3 years ago

I wish I could learn using Emacs. With Vi I make already baby steps.

sph• 3 years ago

It's like learning to ride a bike. It's scary at first, but you once it clicks you will forever know how to ride a bike. And bikes and Emacs both will still be around in 30 years.

Would you rather spend the next weekend learning Emacs, or a React library no one will ever use again in 6 months?

iLemming13• 3 years ago

This is what I did, years back. I created a single Org-Mode file called tasks.org. I didn't know anything about Org-Mode and in general, was a total noob in Emacs.

Whenever I had a question or felt like whatever I'm doing is taking too long or does require repetition, or simply annoyed me for any reason, I would add a new item to that list.

Slowly I learned Org-Capture, which allowed me to add items to the list much faster and without switching contexts. My list kept growing, and that forced me to learn more efficient ways of finding stuff - e.g., Org-Agenda, scheduling, deadlines, etc.

Some items, over time, have become irrelevant so I learned how to archive them. Some problems required basic knowledge of Emacs-Lisp, so I started using Org-Babel to have source blocks where I would write and play around with tiny (and sometimes bigger) elisp snippets. That lead me to the discovery of indirect buffers and I realized how amazing they are.

That single .org file had become a very important part of my life. I started using it for other things, not just to learn Emacs and Org-Mode. By the time I discovered Org-Roam and jumped into Zettelkasten, I was doing pretty much almost everything I do on the computer, in Emacs. Today I write code, check email, browse articles and blogposts, manage all my files, read books, extract subtitles from videos (to take notes), and keep my personal journal - I do all that in Emacs. And it all started with a simple .org file.

Eventually, this approach become my personal philosophy, my absolute recipe for any problem in my life - If you need to solve something, start with a simple list.

butterisgood• 3 years ago

Plan 9 makes it easy to search your terminal buffer history (it's in /dev/text) (Ok I shouldn't call it a terminal... it's a rio window with a shell in it... it's not a terminal)

Acme does similar things letting you manipulate the tag line, or body of a given window.

"Everything is a file" can be a nice interface even at the widget/application level.

"Everything is a buffer" in Emacs likely enjoys the same benefits (and predates Plan 9 and Acme)

Lapsa• 3 years ago

hoped to be impressed. better luck next time

DonHopkins3• 3 years ago

Meanwhile, in an alternate universe:

https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf

amadeuspagel• 3 years ago

Yes I know of another OS allowing this: The browser. If I rename a file in google drive it's just an input field, and spellcheck works there like in any other input field.

kleiba• 3 years ago

Does it suggest the correct spelling, or just mark a misspelled word?

iLemming13• 3 years ago

If I rename a file in google drive it's just an input field

You still have to right-click on it, then select from the list, then click again. You cannot bind any keyboard key for that specific action, you cannot replace it with a spellcheck engine you like, you can't search and replace multiple things based on regexp, no multiple cursors, no vim-like navigation, you can't change things in nested dirs without going inside, etc., etc.

What's the point of your comment here, I honestly don't understand. It's as if we were discussing femtosecond laser (or plasma blade) capsulotomies (eye surgeries), and you'd be like "one French fella invented a method for this shit sometime in 18th century using nothing but a sharp blade..."

volforix2• 3 years ago

After using Emacs for years (huge fan!) I finally realized that Emacs hinders my productivity instead of improving it. Thus I moved to other tools, sadly, and never looked back.

In this case I would use Text Extractor (part of M$ PowerToys) and Google Translate.

nonrandomstring• 3 years ago

For me the consistency of Emacs lies not only in its user interface but in stable longevity. Productivity is important, yes, but is only one dimension in complex decision space of software. What will you use next year when Microsoft throws its powertoys out of the pram and Google makes translate obsolete? Emacs is almost 50 years old, and I hope to be using it in another 50.

volforix2• 3 years ago

Good point. I'll switch back to Emacs as soon as it's best tool for my task again.

iLemming13• 3 years ago

After using Emacs for years (huge fan!) I finally realized that Emacs hinders my productivity instead of improving it.

I always take these kinds of statements with a grain of salt. Please don't get me wrong, perhaps, you had objective reasons to move from Emacs. Maybe you thought they were objective reasons, even though they weren't as such. I spoke to many "former Emacs users", and in most cases, it usually turns out that either: the person had shallow exposure or limited knowledge, or they've never attempted to learn modern Emacs packages and how they can interoperate. In most cases, they've never written a single Emacs package to solve their personal use cases, let alone publish one for the public.

I'm not saying that Emacs cannot reduce productivity. Oh, no, it very well can. And very often it drags you into the rabbit hole of "improving your workflow". It can be extremely frustrating, even for someone "after years of using Emacs" to attempt to fix a simple problem as the desired placement for a window. The complexity of choice can be exhausting. Especially, at moments when you're "in the zone" of trying to solve an unrelated problem. Emacs can get in the way. And most people just can't find the discipline to continue. Often they'd give up, without even trying. And the "novelty bias" of using different IDE creates an illusion that they have wasted time with Emacs.

The truth is - learning Emacs is a journey. You just need to keep going. And at some point, you may realize that there's simply nothing better than Emacs out there that can simplify your workflow and increase your productivity when dealing with textual information.

- Emacs has a better search. It offers way too many different ways for searching things - locally, remotely, recursively, partially, contextually, dynamically, etc. With filtering the results and sifting through and editing at the same time.

- It has some amazing window manipulation capacities. You can precisely control how, where, and what gets to show up on the screen, without having to constantly move things around, drag and resize with the mouse.

- Its extensibility simply cannot be matched. I just can't imagine anyone building let's say an InteliJ plugin, with a command that calls a function defined in a different plugin but also redefines some specific calls in that function to its internal, private methods. In Emacs, I can pick a function defined (for example) in Magit, look at the source code, and tell it to redirect its internal, private calls to my own substitute, whenever it gets called.

Emacs not only improves productivity. It brings joy to the process of writing. Writing just anything - text, math formulas, or code. But getting to that point is not quick or straightforward.

And of course, just like anything, Emacs is not a universally guaranteed tool to make you more productive or happy. Some people just "don't get it", and that's quite all right. But for many, there isn't a better alternative. You can offer a myriad of other tools claiming that the combination of them makes you insanely productive, and to that, I would say: "great, I'll delegate some calls to them from within Emacs..."

sigmonsays• 3 years ago

What is the purpose of making a statement like this and not providing any details?

xenodium2• 3 years ago

The emacs rocks episode on multiple cursors does a great job showing the power of everything in the buffer. It’s well worth watching until the end, it’s got a wonderful finale https://emacsrocks.com/e13.html

ps. I write the ocasional emacs post at https://xenodium.com

AiAi• 3 years ago

I remember this video being a great motivation for learning Emacs, the `multiple-cursors` package is awesome.

Thanks for sharing your content too!

xenodium2• 3 years ago

Nice to hear. For me also! it’s my all-time favourite from emacsrocks.

agumonkey2• 3 years ago

magnars has a real talent, most his videos are extra fun and packing dense info

he's also behind dash.el (clojure fp builtins for emacs)

billforsternz• 3 years ago

Jef Raskin, one of the people who conceived the Macintosh at Apple, spent decades advocating user interface ideas that didn't (yet?) reach a wide audience. I recall he wanted the user to be able to manipulate and interact with the filesystem in the same way as everything else, including spell check and correction. This Emacs user manages to do that with filenames within Emacs although it seems a little clunky.

meonmyphone• 3 years ago

I remember when I discovered this feature, I found it so cool! Emacs always surprises me with something like that.

gardenhedge2• 3 years ago

Sometimes I feel like I'm the only one who doesn't care for Emacs.. then I remember the real world where I've never heard of it being mentioned and never seen anyone using it.

iLemming13• 3 years ago

There are close to forty thousand McDonald's restaurants. It's the biggest fast-food chain in the history of this planet. That still doesn't make it the best, mouthwatering, finger-licking food. The "real world" is not where every programmer uses VSCode. That would be a dystopia.

gardenhedge2• 3 years ago

The "real world" is a reference to what I experience outside of the internet. With McDonald's my real world experience is that it's a popular restaurant. I don't understand why you're arguing that McDonald's isn't the best. I didn't say Emacs wasn't the best. I said I've literally never seen it used or discussed outside of the internet.

iLemming13• 3 years ago

Dired is just one of the great examples of "everything is a buffer" benefits. It lets you do some pretty gimmicky stuff like for example, converting the textual representation of a directory (the output of `ls -lR`) to a proper Dired structure you can navigate through (google 'Virtual Dired').

One of the more utilitarian examples is the use of Indirect buffers. You can, for example, create an indirect clone buffer of a file, narrow some portion of text in the original buffer, and in the cloned buffer, move the cursor to a different location. And then work with two buffers as if they're related to completely different files - narrowing, widening, selecting and deleting things. And when you save, the changes from multiple places get reflected in the same file. The total bananas about this stuff is that you can change the major mode of the indirect buffer. That for example, lets you edit comments in e.g., python code containing json snippets having highlighting, syntax checking, etc. for json, as if the underlying file is not .py, but .json.

pama• 3 years ago

Dired is indeed a neat example. As per the linked post, one fancy thing one can do is make the buffer view of the directory editable, rewrite names for the files using the full power of Emacs editing and then dump the modified file names to disk. It is also cool that a new shell in a dired buffer starts in that directory. If the dired buffer was displaying a directory in a remote machine, then the shell starts in that directory on that machine. Just like things should be.

LAC-Tech• 3 years ago

I love the idea of emacs but I find it completely unusable. I've tried several times.

Vekz2• 3 years ago

One example of synergy I have is that of TODO code comments and org-mode agenda scheduling. For context, some programmers leave //TODO comments through their projects. org-mode uses a notation syntax of *TODO to capture and schedule an agenda item for later completion. These agenda items can be scheduled on a calendar and the agenda can be queried for day, week, month TODOS.

Org mode has custom templates for capturing org agenda items. I've made a "TODO code comment" capture template that I can execute on TODO comments. Once executed the template creates org-mode entries which are added to the calendar and link to the comments file and line number.

wanderingmind2• 3 years ago

this is one thing I miss in VSCode. Can you please share the lisp code you have to customize the org-mode for this. This will be a huge favor for a lot of programmers.

Vekz2• 3 years ago

This is what I have, it def could be improved:

  (defun capture-comment-line (&optional line)
    (let ((c
          (save-excursion
            (save-window-excursion
              (switch-to-buffer (plist-get org-capture-plist :original-buffer))
            comment-start)
            )))
      (while (string-prefix-p c line)
        (setq line (string-remove-prefix c line)))
      (comment-string-strip line t t)
      ))

  (setq org-capture-templates
        '(("C" "TODO code comment" entry (file+headline "~/org/brain/code.org" "Tasks")
          "\* %(capture-comment-line \"%i\")\n  %a"
          )))

major505• 3 years ago

Man, I really like the idea behind Emacs, of integrating everything in the way it becomes an ID, but I cant just get into it, specially the weird shortcuts. After years in Vim, and Visual Studio, is hard to wrap my head around the Emacs way to do stuff.

Maybe I try again in my next vacation, when I will get some free time.

herewulf• 3 years ago

I have to wonder if this is sort of an unspoken rebuttal to the recently posted Project Mage[1] and the more amusingly written but equally intriguing "Emacs is not Enough"[2].

Well, I recently encountered a situation where "everything is a buffer" was not good. I had a Common Lisp SLY REPL buffer open and was testing out INSPECT[3]. This puts the REPL in a state where after printing some text it waits for key presses but that's not obvious and I'm using evil mode so q (for quit) just starts recording a macro and I can't enter insert mode because Emacs thinks the buffer is read only. I could only kill the buffer and start anew (while avoiding INSPECT -- turns out SLY has nice inspection functionality of its own but I shouldn't have to know to avoid running some function in the REPL!).

Surely there are some workarounds or bugfixes to be had but the whole REPL-is-a-buffer feels very rough around the edges.

[1] https://news.ycombinator.com/item?id=34380373 [2]: https://news.ycombinator.com/item?id=34375137 [3]: Specifically: (inspect *)

kyberias• 3 years ago

I'm not an Emacs user so what I'm about to say may be based on totally incorrect information.

Seems to be that Wdired is just a hack that represents file and directory metadata in a textual format (in a buffer in Emacs parlance). It's not obvious to anyone that editing a filename in this buffer actually goes to the file system and changes the name of the file. It's even less obvious that removing rows removes files or directories. It actually sounds rather dangerous to use.

This is not functionality that emerges from some elegant design of Emacs, it seems it's just a hack.

trocado• 3 years ago

It's very obvious because you have to activate the wdired mode, and then accept the changes.

a_e_k3• 3 years ago

First, Wdired is not the normal mode for Dired. You have to hit a key to activate that mode.

Second, it doesn't actually make any changes to the file system until you hit the key combo to commit them. And the files aren't deleted immediately, even when you do commit; they're just flagged for deletion in the standard Dired interface. You'll have to hit a button to actually "expunge" them from there, and that asks for confirmation again before doing so.

Think of Wdired more as a convenient way to build up a transaction of FS changes.

And since everything is a buffer, undo works just fine until you commit it. Or you can load up fresh Dired view of the original metadata in another buffer and ediff them to verify your changes before you commit. :-)

The benefits of everything being a buffer in Emacs

Related Stories