Use GNU Emacs
www2.lib.uchicago.edu
www2.lib.uchicago.edu
I love it, it’s great, and as many others, I tried to move out of it but there was something I couldn’t do I KNEW I could get in Emacs and it frustrated me so much I kept going back.
But I don’t think it brings a lot of added value. There are many very very powerful IDEs and editors which offer out of the box great UX and feature discoverability. Hell, probably if IntelliJ toolset would allow me to customize it deeper with Lua/Lisp/JS/whatever I’d probably switch in a jiffy.
I compare Emacs to vinyls or paper books. It requires investment, in many cases it is worse than competition and requires more energy to just be on par. But it is absolutely lovable. Vinyl record comparison - they are expensive, heavy, require a lot of maintenance but for specific type of people it makes their heart skip a beat when they take it from the sleeve.
That’s why people are constantly talking about their Emacs. Same with vim or nvim. I rarely hear people talking with excitement about WebStorm or VS code.
So yeah, if you’re not into it just keep in mind that like some freak who spend their weekend on polishing rims of dream come true 1959 Fiat 500, some of us spend their time with Emacs.
Don’t get bullied into it, don’t get FOMO about it, but please don’t spoil our fun.
You’re always welcome to join in.
you use emacs to do stuff, you dont just listen to/watch it do its thing.
chopsticks might not seem like a good metaphor at first glance, as they are much more simple, but they are highly compatible with a lot of tasks and can be utilized in many ways that a fork, spoon, spork or colander just wouldnt handle as well. to my mind, the simple thing hidden in emacs' complexity is that it is a closeted lisp machine
I hear arguments around what products can offer me all the time, they make sense, but I generally go with how a product makes me feel. Probably more than I even realise.
I don’t use Emacs, I do whisk eggs and fish doughnuts out of oil with chopsticks, I couldn’t fully say why for either.
i am still a bit iffy about emacslisp, but less so than before i grokked CL (thanks for that goes to "practical common lisp" by peter seibel)
but: whatever floats your boat will keep your boat afloat :D
I will admit that for that very last teaspoon full of rice, though... I grab a spoon.
I have a strange nostalgia for the old Unix days that I was too young— perhaps not even alive yet— to experience the first time around. It's what draws me to learning and using things like vim, Perl, awk, sed, etc. Those tools feel arcane and mystical.
But going all the way back to the Big Bang at V0, a funny thing happened.
The essence was still missing. Because indeed the open-source foundations weren't really born from Unix and the PDP-11. I only had focused on the technicalities.
No. The missing half of the puzzle is ITS and the PDP-10.
This is where the hacker movement, GNU and the free software philosophy were born. The world of Stallman versus the world of Thomson. The root of emacs, LISP, TeX, and many more. Which interestingly, are both older and more timeless than the Unix part of the puzzle.
After the demise of the PDP-10 in the 80s, Unix (and ultimately Linux) just happened to be a convenient hardware abstraction layer to carry the torch, to run what really mattered. Unix had been the tool but not the essence.
This is where I reached the end of my journey: ITS, emacs, and the birthplace of the hacker and free software spirit. I was enlightened, and the words "GNU's Not Unix" finally made sense!
Not everything open and insecure, but hackable up to the last bit.
A minor joke here:
> Hell, probably if IntelliJ toolset would allow me to customize it deeper with Lua/Lisp/JS/whatever I’d probably switch in a jiffy.
It's not going to be quick and it's not going to be pretty, but I think you could technically do it with Clojure :-)))
- IDE-like features via LSP
- The best git porcelain out there: magit. Even when I'm not using emacs, I come back to magit for code-browsing (recursive blame) and staging hunks.
- Emacs/vim's fantastic buffer/window concept, where open files are not owned by their windows. I miss this whenever I use anything else.
- project support to quickly grep across all files or jump to files
- Very mature vi keybindings, with their infinite composability
I still sometimes find that it's either too rigid or too manual at certain things, but I could say the same for CLion and VSCode. I still come back to CLion for its refactoring tool, the 3-way merge window and the debugger integration.
It is a bit messy though. It's very well done for what it is, but it's cobbled together from many disparate components. It seems that it should be possible to create the same type of experience from a simpler, more coherent system. I rarely update the base system, but when I do, I've occasionally had to google for some exotic elisp error and add a fix here or there.
Why is this useful? I basically treat my nvim buffers like windows. What am I missing?
[1] Why can't we just delete the extra file after we recovered the .swp!
oh hell yes!
But, now I realize this is a very powerful configuration of Emacs if and only if you prefer using the VI keybindings.
It looks like spacemacs is that as well.
I actually enjoy Emacs keybindings, and would like to find something as polished and supported as Doom, but without using VI keybindings.
Does anyone know where I should look for that?
Or, can I revert to emacs keybindings in Doom and use the rest of the amazing features? I'm concerned I might be swimming against a tsunami if I try to do that and would be better off finding another project.
https://emacs.stackexchange.com/questions/53319/how-to-disab...
See https://github.com/doomemacs/doomemacs/blob/master/modules/e...
There's also prelude which doesn't include evil by default. Not quite as fully featured as doom/spacemacs, but it's a good place to start.
All that said, you could just set it up from scratch. Now that lsp-mode and dap-mode are things, you can setup a fully featured IDE in not very much config at all. I have everything in my init.el and setting up projectile, lsp-mode and dap-mode which is like 85% of what you need for a fully featured IDE. That bit is only about 30 lines of config. Throw in flycheck, company-mode, hydra for keybindings. maybe treemacs for a project view.. a few hundred other lines to make it not all look like trash....
On second thought, it's kind of a pain in the ass. Just use clion or vscode or something.
Can't I beg you to share your init.el? I want LSP and the other stuff but Doom even when turning off evil mode seems to far away from the emacs I'm familiar with.
https://pastebin.mozilla.org/mShC6Dm0
I'm still using evil mode. Most of my important functions are bound to some combination off space bar though.
It's certainly not perfect and has some "quirks" (or bugs if we're being honest), but it works pretty well.
Unconfigured Emacs is a bit clunky, but you'll understand it a lot better if you configure it yourself. Also, just in my opinion, there are better options than the packages supplied by Doom.
My suggestion is to set up Emacs with use-package for package configuration (this will be in Emacs 29 anyway), and then you can easily play around with different package combinations.
I'd add a nice-looking theme first of all, then try adding the following modern packages, one at a time. Play around with them a bit before adding another so you know what they do.
Vertico - visual completion UI (selecting files, buffers, commands etc.)
Orderless - user-friendly completion framework
Consult - search and navigation commands
Embark - contextual actions
Marginalia - fancy completion decorations
Magit - nuclear-powered Git framework
Eglot - lightweight LSP functionality (will be in Emacs 29)
...that gives you a powerful selection of features that play nice together and you can easily build on.
https://gitlab.com/gshulegaard/my-emacs
Disclaimer: This config is a bit perpetually dusty at this point, so I wouldn't copy it verbatim but instead use it as inspiration for some packages that might be worth looking into. JFYI anything that is from Marmelade might be worth avoiding as I suspect it is unmaintained given it's SSL cert expired in 2018. I just haven't gotten around to removing it from my config.
Emacs has a high barrier of entry though. I think it would be difficult for a novice to get a good IDE experience from emacs, even with doom.
Well, that on top of the creepy uneasiness I always feel whenever dealing with companies like Google (or M$, FANG, etc.).
It's just a text editor. For many tasks it has better usability than the competition. This is why I use it. (Not for everything, though, and that's okay.)
I'd guess most people are like me. Configuring text editors is not our hobby.
Since most people today are more than happy to code in Jyputer notebooks (yuck), I guess I'm not actually that weird.
I'll never understand comments like this. There's a full Lisp implementation available in there. Other text editors don't come with org-mode, either.
Okay? Neovim and Lite XL ship with full Lua implementations. VSCode ships with a full JS implementation.
Being scriptable is not unique to Emacs. Though I do think the combination of - big ecosystem (missing for Lite) - scripting freedom (missing for VSC, iirc its plugin APIs are kinda limiting) - GUI (neovim) is pretty much unique.
A lot of other editors are also extensible, either via scripting or dynamically linking native code.
The only reason Org is unique to Emacs is that it's "too large to clone", i.e. it'd be a lot of work. I think a lot of editors could provide the same features with a plugin, given sufficient effort.
True, some extensive modes written in Lisp by users are a work of art. That's a layer a non-programming-user may not see.
... I really just use it as an editor/IDE these days, and couldn't be happier.
Emacs is how I learned LISP which forever transformed me as a programmer and I'm grateful. But let's be clear WHY I was doing that: it was horrible as an IDE at the time and I needed it to do the thing.
Now, with elpa, great themes, solid modes for every major language, magit etc, it just works. I customize ... via customization.
I still have my .emacs (dating myself there) and a few nifty functions I wrote. I maintain a programming language, so pact-mode is still there. The ugly truth there is that it's actually easier to write integrations (for a LISP-like no less!) for VS Code than write a major mode.
I miss hacking on emacs but I'm more productive for it.
Not even to centralize the `backup.foo~` and `#auto-save.foo#` files that emacs loves to litter the file system with? I can't wrap my mind around it.
My first, very brief, foray into Emacs was at the suggestion of a friend back in, oh, '91-92. He raved about the buffers and the shell windows. Well, I couldn't run my 4GL programs in the shell windows, since they were full screen programs, and the terminal emulation wasn't working. So, I just stopped and went back to what I was doing.
This turned out to be a blessing in disguise. For this what the heart of the UNIX explosion. Everybody and their mother had some new box running some sort of UNIX, and we were installing software on all of them. While I spent my day in SCO on 486/66 (Shared by 8 other people), we were installing on Suns, IBM, NCRs, DG, Sequent, HP, and probably something else. I was always on someone else machine.
vi, of course, was everywhere. Not so much Emacs. I was also working in their environments, not mine, so box stock was the norm. And at the time, vi was more than suitable and capable. I still use vi pretty much the same way. Today I have multiple windows, unlike back then, but beyond that those formative years were so ingrained, those patterns and habits stick to this day. vi doesn't need plugins, it has bang-pipe. My file systems (notably tmp) are littered with x.x, y.y, z.z, etc. files adding as ad hoc cut and paste buffers. If I couldn't do the work with bang-pipe, shell out, bonk on some data in /tmp/x.x, pop back into vi and :r /tmp/x.x. Is it a single keystroke? No. But it's not in vi either. yyp is about as short as you can get.
Later, as I moved into Java and Python, I started adopting Emacs. I was particularly attracted to its auto formatting support for Java. Later on I chose Ant (Java build tool) because is had a -emacs switch to make the output compatible with emacs so I could jump to compiler errors. But that's stock behavior in emacs, we get that "for free", Ant conformed to emacs, vs the other way around.
I still kept my vi habits in emacs. If I wanted to refactor something, I was more apt to do something like vi `find . -name "*.java" | xargs grep methodToRename` than use emacs. I had multiple windows, so this was simple to do. Since Java is strictly typed, it coped well with yelling at my ham fisted endeavors when I went stomping through the code base.
I finally moved to an IDE, NetBeans, around NB 5 or so. Auto complete spoiled me.
Today my use of Emacs is mostly only for Lisp, and even then my Nerd Cred isn't up to par. I don't use Slime. I use emacs for lisp almost solely for auto indent, and paren matching. vi's lisp indent isn't spectacular, but emacs' is pretty good. The paren matching is about par, it doesn't bother me to use % in vi to test parens, but emacs is better. Then, I just ^S, and reload the file in my REPL.
I've tried Slime, but simply I don't do enough Lisp to make it worthwhile. It doesn't stick, so I have to relearn it when I come back. Just not worth the bother. I just want to work and get stuff done, not fight tools. Emacs on the Mac works well enough out of the box for me. Scroll wheel scrolls, Cmd-XCV cuts/copies/pastes, I can mouse around and double click things. You know, text editor. I also like messing with elisp in the scratch buffer. Even an old guy like me can remember ^J.
Basically what I've learned in my computing career, having to jump around every place, there's one commonality that's at every location I visit. Me. Rather than relying on adapted environments, I rely on an adaptable me. I like tools, I use tools, but I pick tools that work well out of the box. I want a tool, not a kit. Unix, thankfully, comes with a base set that I learned a long time ago. The important ones (important to me) have stuck with me. I can awk all day long, but I can't even spell 'perl', and it's my go to shotgun if I need it.
VSCode? It's got its fan base and it's quite vocal. Actually, Didn't VSCode collate the majority of the former Atom users, as Atom collated the majority of SublimeText before it?
I'm an editor vagabond. I went from Ed 4 to Notepad++ to JEdit to UltraEdit to TextPad to Sublime Text to Atom to VS Code.
Of all of these, Sublime Text is the one I still use every day. TextPad on Windows was the other one that was sticky, though Sublime has replaced it. I kept dabbling with Emacs, kept knocking into vi flavors for "just getting it done."
Perhaps it's time to find a home with Emacs and try to use it for everything. But there's always that next one... maybe Xi, maybe NightCode (nope), maybe Edita...
Emacs and vi will still be there, and I'll probably pay for the next three versions of Sublime Text like have the first three.
I'm also on the lookout for my next "forever home" but I set the bar to only try a modal editor that acrually differs from Vim's modes. So, modal without vim-mode.
I have been using Emacs for 40 years and still love it, but I do find myself using VSCode more often now for Python work. Emacs has very good CoPilot support, but it sometimes lags a bit behind the support in VSCode. I also have started using a proprietary MarkDown editor instead of Emacs or VSCode.
For me a big draw of Emacs is that I have it easily configured for almost all programming languages I use.
One way to think of it is any tool requires some investment. The big difference with Emacs is it has always been around and always will be around, so you are continuously building upon that investment. Contrast that more modern tools. The learning curve is nowhere near as severe to start out, yet one is far less likely to learn how to use it so the same depth in the long term since it is far less likely to exist for the long term.
It's the same thing with free software. I care, but not enough to stop me from using the easiest thing out there to use regardless of whether or not it's free.
I agree, let's not exaggerate, if the overwhelming majority in aggregate acts in the exact same way, the aggregate action overwhelms the minority action.
In this case, most people don't care and share my viewpoint on the situation.
You can care about something, but have other contributing factors to your decision that override that care.
I care about the environment, but I still drive an internal-combustion vehicle, because NOT doing so isn't really an option where I live.
I care about issues of poverty, but enough to minimize all our expenses in order to give away more funds, because we want to be able to enjoy our lives.
Emacs is likely to continue to exist for a long time, but the gap between it and modern IDEs is also likely to widen over that same timeline.
He starts with a completely empty emacs config and builds it up to a full blown IDE explaining how everything works along the way.
Some of the things he does, there are better alternatives these days but most is still relevant and it'll teach a lot about how emacs works.
That said, emacs is more of a hobby than an IDE. If you just want to get work done, using something like vscode or intellij or whatever else makes way more sense. If you find it fun to tinker around and customize your editor you can make emacs incredible, but it's something you have to want to spend time on.
My main gripe is dealing with several major modes at once, I still find that Emacs isn't the best at that.
I will say for anyone curious about Emacs, do try it out in your spare time. It's so much fun to customize and play around with.
There is an odd aggression against Emacs that typically does lead to people having to go to extra effort to justify why they use it. And I can agree many of the justifications can feel like a stretch. They aren't false, though. Nor are we working on some archaic thing that only we can appreciate.
I'm also always amazed at how we think Emacs is somehow more archaic than anything else in a computer. Getting my kids into computers. It is Scratch to start, than probably crippled Python environments. That they are almost certainly going to break and wonder what happened. We even got started on some Arduino stuff, and their IDE is not bad, necessarily, but don't pretend like it is easy and quick in ways that Emacs isn't. Want to make a small game? Good luck, as there are no other environments for that anymore. (Used to, the computer booted into a BASIC shell in ages past.)
And this is avoiding the environments for content creation. Blender is amazing. And amazingly hard to use/explain. Fusion? TinkerCAD is at least easy to explain. But again, very easy to screw up in. (And I'm growing rather tired of all of the times I come back to a computer with hundreds of tabs in a browser all convinced they need to save data.)
All of that is to say, computers are tough. Period. I hope people can find a comfort zone for creation. But I am not convinced there is a single answer there. And more than happy to share what has worked for me.
No other editor comes with such a good tutorial.
> I rarely hear people talking with excitement about WebStorm or VS code.
You seem to be living in a very remote area where no programmers can reach you, beside those using Emacs. Yeah, people using VSCode talk about it a lot, given an opportunity.
In an average programming company, programmers might talk more about Emacs because for the overwhelming majority it's a mystery. It's the same how others might be driven to discuss UFOs or weird cultural kinks found in distant lands. But, really, it's not an indication of anything.
It just works for me. It really, really does need some improvements in places but in other areas everything else just lags behind.
Emacs is the best. I do not hesitate to recommend it. Will it work for you? I don't know. Might it be exactly what you were looking for? Yep! That's how it was for me: it gave me everything I ever wanted and more. Period.
Emacs is a powerful platform for building hackable, command-and-ui driven applications. You may not like the text editor that ships with a default Emacs install, but you don't have to use it! There are others (e.g. evil.)
There are also other applications. Some of my favourites are
- calc (desktop RPN calculator with advanced functionality)
- magit (context-aware git UI that interacts seamlessly with the git command line)
- sunrise commander (orthodox file manager that thanks to TRAMP can visit remote filesystems as if they were local)
- ediff (diff reconciliation between files)
and my train is coming now so this is where the list stops but it could go on for a long time.
Never heard about sunrise commander though.
(Sorry about the bad example, I'm short on time.)
And the cool part is you can do things algebraically, too. Even solve for variables. Really crazy program.
For example, I love magit and find it much nicer than many Git GUIs, but I would still recommend something like Git Kraken (or just the GIT CLI) to someone who is not already using emacs for other things.
Emacs is extremely idiosyncratic, and the barrier to entry of using an Emacs-based app is nowhere near as small as using a JVM-based app (and even that is too much for most uses).
"Calc was originally started as a two-week project to occupy a lull in the author’s schedule.
...
Emacs Lisp would surely reach its limits long before the project got too far out of hand.
To make a long story short, Emacs Lisp turned out to be a distressingly solid implementation of Lisp, and the humble task of calculating turned out to be more open-ended than one might have expected.
Emacs Lisp didn’t have built-in floating point math (now it does), so this had to be simulated in software. In fact, Emacs integers would only comfortably fit six decimal digits or so (at the time)—not enough for a decent calculator. So I had to write my own high-precision integer code as well, and once I had this I figured that arbitrary-size integers were just as easy as large integers. Arbitrary floating-point precision was the logical next step. Also, since the large integer arithmetic was there anyway it seemed only fair to give the user direct access to it, which in turn made it practical to support fractions as well as floats. All these features inspired me to look around for other data types that might be worth having.
Around this time, my friend Rick Koshi showed me his nifty new HP-28 calculator. It allowed the user to manipulate formulas as well as numerical quantities, and it could also operate on matrices. I decided that these would be good for Calc to have, too. And once things had gone this far, I figured I might as well take a look at serious algebra systems for further ideas.
... (and on and on and on) ...
Final thanks go to Richard Stallman, without whose fine implementations of the Emacs editor, language, and environment, Calc would have been finished in two weeks."
If you look at its feature set, it is amazing how much can be done with it. It has nifty features like evaluating formulae inline in any buffer, and replacing the expression with the result. Expanding things to their LaTeX representation, etc.
I spent a lot of time trying to learn it. I use it for simple calculations, but ultimately decided it is not worth my time to go much further. That same effort would be better spent learning Sage, with a lot less cognitive load. And there is decent integration between Sage and Emacs.
I had to email the grades, together with totals, and class averages to many students in a class.
I tried fiddling with Excel and Google spreadsheets and scripted mail merges. Then I realized I could do it emacs.
Export the gradesheet into csv, and convert to an org table.
Carefully record a macro where you copy paste the name of the student the mark columns into a mail window (I used gnus), copy paste them into a calc window, do the calculation, copy the result onto the mail, and email the student. Go to the org buffer, and go to the next line. This took about 12 minutes to get right.
Keep pressing f4. Sending individual mails to 125 students took <5 minutes.
Maybe this is overkill, and I am sure excel wizards can do it in a few minutes. Nevertheless, I was surprised - if you spend time carefully recording the macro, the Emacs ecosystem (org+gnus+keyboard macros) is insanely powerful.
I assume doing the same task manually would take him at least a day or two, with the possibility of making numerous mistakes by doing it.
Your mistake was not using org first ;-)
I learned org mode while a grad TA, and one of the first times I used org tables was to keep track of student scores.
(defun compose-mail-macos (&optional to subject body)
"Compose a message using macOS's default mail program."
(interactive)
(start-process "Open Mail Message" nil "open"
(concat "mailto:"
(when to to) "?"
(when subject (concat "&subject=" (url-hexify-string subject)))
(when body (concat "&body=" (url-hexify-string body))))))
(defun compose-mail-macos-multiple (list subject body)
"ADDRESSES should be a list of email addresses in the form of:
(setq mail-list '(\"Mail 1 <mail1@example.com>\"
\"Mail 2 <mail2@example.com>\"
\"Mail 3 <mail3@example.com>\"))"
(while list
(let ((to (car list)))
(compose-mail-macos to subject body)
(setq list (cdr list)))))Reaping the benefit of everyone else's hard work at improving vscode is awesome. It just gets better over time without me having to do anything except occasionally read about new features in the release notes. Spending hours twiddling in emacs lisp to get things configured just right is just wasting my limited time.
I also don’t understand why people think spending time on the tools they use to do work is wasted. You either believe software creates value or you don’t. If your time is so limited, eliminating toil seems essential.
What I'm objecting to is the very idea of a highly customizable editor.
Some of my coworkers violently agree, but at least 20-30% get annoyed when autoupdate removes/ changes some feature (pane splitting recently I think) and they have to adapt their workflow.
The counter point to this is usually:
What exactly is your toil as a professional software developer (or associated profession) that is eliminated with a "better"[1] editor in 2023?
Refactoring is more powerful with an IDE, for mainstream languages. For non-mainstream languages 95% of what Emacs enables can be done using multi-cursors and a macro language built in to the editor, and we're in 2023. Those kinds of editors are a dime a dozen :-)
Editing data dumps or whatever is probably better with an advanced editor (I generally use Vim for that). But it's such a rare occurrence.
Writing code is super easy in an IDE.
Most of my toil is unnecessary meetings, unnecessary reporting, unnecessary social stuff. Emacs can't help with any of that.
* * *
[1] To note, "better" is strictly a claim. I'm quite sure there's no peer reviewed study that can prove conclusively that Emacs/Vim users are more productive than non-Emacs/Vim users, just due to their usage of Emacs/Vim.
For non-mainstream languages 95% of what Emacs enables can be done using
multi-cursors and a macro language built in to the editor, and we're in
2023. Those kinds of editors are a dime a dozen :-)
But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
Is it accessible? Why would I want to spend time learning the idiosyncrasies of a 40-year-old editor to write something that I might use once in a blue moon?
I have other, more interesting things in life.
https://micro-editor.github.io/index.html
And Emacs Lisp doesn't feel super accessible to most software developers under 40. Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
> But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
Devs generally write one-off or maybe reusable shell/Python/... scripts for that. But some of the examples I listed allow you to do a lot of that using Lua.
There are a ton of workflows out there, other devs don't just bang 2 rocks together because they can't automate everything <<inside>> the editor itself :-)
Also, xkcd is always very poignant:
Software devs routinely fall into this trap:
Or over 40 (I'm 42) :)
> Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
This is a great analogy. And people forget that to program any system effeciently you need to know that system. Not necessarily inside-out, but good enough. A brief look at any emacs config will show you just how many weird and inconsistent things you have to contend with: major modes, minor modes, hooks, global variables, global functions, mode-specific global functions, special lists, non-special lists, and a myriad API calls and functions in between.
Wikipedia says that emacs has 10 000 (ten thousand) built-in commands [1] That's probably on par with JVM :)
But I wanted it to have a native tab bar and I wanted to move the command bar at the top, with dropdowns instead of "expand-ups" (turns out, I read right-to-left, top-down, not right-to-left, bottom-up. You can't have either of those, in the world's most extensible editor :-(
(setq vertico-posframe-poshandler #'posframe-poshandler-frame-top-center)
Emacs isn't an editor, it's a (very) rapid development environment for textual UI applications. Text editing is a large class of such applications but there are plenty of others.
Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.
Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing. There are myriad viable ways to automate things.
> Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
Meetings, reporting and "social stuff" happen as an individual contributor because you need to sync with customers, peers, bosses, plus customers and bosses also expect you to report your progress. Social stuff isn't going out to lunch or dinner, it' just regular interaction or support.
I'm glad that you get what you want, not everyone does.
I'm just pointing out that there are many ways to happy coding and Emacs is just one of them.
I was just explaining what the "toil" is in my life and how emacs materially alleviates it. The examples you give don't, in my experience, allow a useful interactive UI to be knocked together anywhere near as quickly as it can be done by an experienced user in emacs. YMMV - use whatever tools you like and manage your career how you please.
The difference is time of development and flexibility of tge emacs result using the same universal plain text interface you use in emacs every day for me.
I mean, you could probably run Emacs as part of your CI/CD pipeline, but it would be a bit... weird?
A certain level yes, but doesn't need to be all, end all
VSCode solves most of my issues.
"oh but in Emacs you can do..." a thing that I either don't need, or I don't care about or I can do using a web service or some other offline program or maybe even a VSCode plugin or a short vim script.
or it's already available in pretty much any IDE out of the box. Most people advocating for emacs or vim usually have no idea what a modern IDE is, and pretend modern IDEs have not surpassed win3.1 notepad in terms of functionality.
And I agree, a lot of those heavy advocates live in a bubble
(And I don't see the appeal of Emacs at all.)
(And I don't see the appeal of Emacs at all.)
i think tools should be able to conform to its users' hands, i dont see that in intellij that much...
requires barely any ram
On my "small" laptop, I only use Emacs... Trying to run IntelliJ or VSCode makes the laptop burning hot and forces the fan to keep running. With Emacs, no matter what I do, it's always quiet and cool.
Though it's not horrible enough that I found the courage to set up an Emacs server, as easy as it is… Anyway, it would be nice if it could just boot instantly by default.
alias emacs='emacsclient -c -nw -a ""'
You must have accidentally closed it. Closing Emacs or your Web browser are common mistakes, and as you will surely have realized almost immediately, you needed to re-open either program within minutes.
Emacs takes 10 seconds to open. Firefox takes 15. Yes, those are wasted seconds, but it's not like they are anywhere close to the largest wastes of my day. (Hell, I'm writing a comment in HN right now!)
It's different for things like VS, Pycharm, VSCode, or Eclipse. But emacs isn't there.
Thank you for this! This cracked me up.
> Gotta go fast. Startup and run-time performance are priorities. Doom goes beyond by modifying packages to be snappier and load lazier.
Why are you using emacs, then? Emacs GC pauses are awful. The input lag is on par with vsc. There is work being done on both, but right now it's terrible.
I'm just here because I want buffers that can be scaled individually along with good vi-emulation. I'll never pretend that the performance is any good
I use IntelliJ for writing Java code. Emacs can do a lot, [1] is a good 5 minute introduction, but I think I prefer a GUI-first mouse-first UI.
I use Emacs for general text editing, so for most non-Java code. I occasionally edit individual Java classes with Emacs if I have something repetitive to do, and I know an Emacs macro (F3, do things, F4 to save, F4 to run) can do it.
I use Kate when I want its nice tabbed views with a terminal at the bottom. Often this is things like moving content between 20 different documentation files.
I often write short programs interactively to manipulate the text I am working on, and have a whole bunch of Elisp code for common things that come up at work. For example, transforming a pasted ad-hoc spreadsheet column into sql insert statements (because nobody wants to pay to add that functionality to the software, and they email me instead). I used to have a bunch of code for generating Java boilerplate, and even entire classes but the situation has improved in recent years...
Sure I could write scripts or conventional programs to do these jobs, I just prefer the interactivity and fluidity of Lisp environments. Also, being an Emacs user means I can write Lisp at work and get away with it.
Having said all that, I tend to primarily use a dedicated IDE, with a general purpose text editor in the background. I will use Emacs alone when I am writing plain text, Common Lisp, or simple stuff that doesn't require a load of configuration or a complex toolchain. I want the IDE to take care of that for me.
I continue to use Emacs not because it has the best UX--it doesn't. I use it because it's a stable foundation that I'm confident will be around as other IDE/editor fads come and go (Eclipse, Atom, Sublime, IntelliJ, VS Code, etc.). Sure occasionally I tweak my config to keep up with ecosystem developments, but that's much less dramatic than changing editors every few years. There's no particular reason I use Emacs over vim other than my own momentum, I think they both have this property. I think IntelliJ comes in second place here because the incentives of JetBrains are pretty well-aligned with developers' best interests (I definitely can't say the same for VS Code...).
I'm not that old of an engineer, but the consistency of using the same tool for 8 years continues to compound. Interacting with Emacs has become second nature, I've built up a small collection of utility Elisp functions for getting stuff done quickly, etc. It definitely compounds. This is a big deal for me. I can't find a stronger, longer-lasting foundation to build a compounding developer toolset on than Emacs.
Choosing Emacs for its low memory and CPU footprint is probably very ironic to anyone from the era of Eight Megabytes And Constantly Swapping jokes.
As for helping each other: yes, my wife is using VSCode (she's also in IT, but more of a scientific research that uses IT wing). When she has problems, I SSH into her laptop and use Emacs.
And, for users who have problems with their editor, I can only say: git gud. If you are so pathetically bad you cannot solve problems with the only tool you are supposed to know how to use well, then take a class on how to use it, spend a few weekends reading documentation. It's your responsibility to know this stuff, if you don't, you are a liability for your team.
The fuq? I feel sorry for your spouse.
I also had to work with a mostly Java shop (a branch within HP) where I was on the ops team. A significant portion of my day was spent walking between cubicles and "fixing" Maven builds. I wasn't really fixing the builds though. Every time it was because another Java dummy couldn't figure out how to do something trivial in Intellij or Eclipse and were blaming the ops for that.
No matter how much I despise Intellij products, the average Java programmer at the time seem to be incapable to internalize even the bare minimum these editors require to function. I call this "the race to the bottom", a situation where technology encourages its users to be dumber, where, in turn, the dumber users make technology worse by requesting dumb features. And this is how Intellij is. It tries to cushion the fall, to put a fence around every useful but potentially "dangerous" operation by limiting what users can do to a fixed number of choices, where free-form input would've been appropriate, by creating layers of renaming of basic stuff the users need to work with in a failed attempt to "make it easier to understand", by hiding things that it perceives as being "out of scope", giving no easy way to reveal the hidden features.
So, yeah, these programmers were a liability to the company. So much so they needed to payroll a dedicated person to do their work for them. And, of course, a dedicated person could only service single Java dummy at a time, while the rest were taking a break downstairs playing table tennis or socializing in cafeteria. Good times!
Looks like you need to :git gud with Intellij if you really believe it has a crappy text editor.
This is usually very visible when an editor tries to have something they call "Emacs keys" or "Vim editing" etc. Where once you try it, you instantly realize that the editor trying to mimic a decent editor is just so far behind, they, in principle, are incapable of implementing anything like Emacs or Vim.
Intellij products are targeted at amateurs, they aren't meant for people who are professionals at text editing. Similar to how you can buy sporting equipment, for example, designed for people who just want to stay in shape / have something comfortable to go to the gym in, and equipment meant for professional athletes. Eg. bicycles, where a typical city bicycle isn't even trying for the niche of being used in Tour de France.
Pretending that there's some kind of competition between Intellij products and Emacs is like thinking that you'd do just fine taking your average Home Depot 200 Watt drill to a concrete wall.
Comparing it with emacs is like comparing a smoothly running Tesla (Intellij) with a bullock cart of misc automobile parts (emacs). Sure you can build your Frankenstein car after a lifetime of effort, but most folks want a better quality of life. The vast majority of people don't want to build their own automobile (or washing machine).
I went through the whole phase of adding a bunch of plugins, custom macros and have a huge .vimrc file that, once in a while, would break if I was using the wrong vim variant {vi, vim, nvim}. For the sake of this argument, emacs users face some form of the same too.
It got to a point where all my hardcore configurations made my editor experience diverge even further away from the promised "out of the box" experience, and not on par with autocomplete functionalities available in modern IDEs like VSCode.
So now I'm on VSCode. A M1 MacBook can handle it, so I told myself to quit being a masochist, and that itself saves me hours especially navigating a big and complex codebase. But I remember how to use vim, and that comes in handy if I have to SSH into some remote machine and make some tweaks to scripts.
But vim moves and keybinds are just too good.
If there was a combination that actually worked well, I'd switch in a heartbeat. But so far I haven't encountered an option with all of:
* vim bindings (no compromises)
* great completion / IDE experience
* no configuration
Currently my "pick 2 out of 3" is low config nvim, with bad completion as a result...
I decided to allow myself as many extra features as I wanted with one caveat: all plugins had to be pure vimscript.
Reproducing an exact dev environment is just a git clone away, because there are no external dependencies outside of vim itself.
This is not very restrictive: you have fuzzy search with Ctrl-P, get full-featured language server support with vim-lsp etc.
This is possible because Vim8+ (released 6 years ago) has a native plugin manager which is very easy to manage via git submodules.
Personally, most vim emulations in most editors are "good enough", so I generally use Intellij (Java) or VSCode (everything else) with Vim modes.
This encapsulates my feelings completely, haha. Both require so much investment and you spend a lot of time with them, just like the pokemon you pick at the beginning.
I haven't heard that before, but I feel like that's the best way to decribe it.
~~emacs~~ water type pokemon are the best clearly.
https://www.gnu.org/software/emacs/tour/
You get not only graphics and colors, but also better keybindings which aren’t limited to 1970’s ASCII control codes.
https://blog.aaronbieber.com/2016/12/29/don-t-use-terminal-e...
I learned Emacs in 1988 or so. Only a couple years before, I had traded my Commodore 64---on which I did real work, like writing term papers---for an IBM PC XT clone. WordPerfect. Hobbyist BBSer, but networking was in the future.
When I got to college, Unix and Emacs were a revelation. This is how it's supposed to work! And the background ASSUMPTION that you could understand everything, and control everything, was something nobody at the time would have questioned. With hindsight it turns out that understanding everything was a mirage and controlling everything was the gateway drug to possibly literal addictive behaviors, but that was the ethos.
I left CS after only a couple semesters, and my career has completely diverged from it. So it's a TOTAL FLUKE that today I can comprehend---god, the whole model! of a Lisp machine! of Lisp at all! For a young person starting with modern tools? Maybe we can agree that we all see the big chasm....
But I will never give it up.
The only weakness of Emacs (according to me) was the lack of a good major mode (module) to edit web template : imagine editing a php block inside a javascript part embedded inside html.
After testing many modes, I started to develop web-mode (http://web-mode.org) that is now compatible with about thirty template engines. What a wondeful trip it was to discover the power of Lisp and what a pleasure it is everyday to know exactly what happens when I hit a key while editing an html file.
I am the only Emacs user in my company (kernix.com) but nothing would make me switch. I can not imagine using an editor that would not open in less than a second (or that would eat hundreds of Mo of RAM)
I Hope Emacs will see a usage surge with the inclusion of tree sitter… editing in emacs will be even faster and more robust. Not sure tree sitter is suitted for multi languages files … but for this you have web-mode ;)
Would be great, if anyone could comment on that. I think Emacs using Elisp has natural potential to do it recursively and therefore easily correctly, instead of cramming other modes with syntax, that does not belong there.
Seriously, it feels unproductive a bit at first. But the productivity potential is 10x higher than any other tool or editor out there.
With org-mode, Magit, Projectile and dired, I already feel more productive than in VSCode or neovim. And more importantly, I feel like I'm shaping reflexes around the editor and thus creating my own workflow.
And evil-mode is the best emulation out there. I tried neovim inside VSCode but it's not yet there. So as a vim lover, I have two options (Neovim or Emacs).
The deal breaker was org-mode, It made me switch ... My organization skills are quite poor and I tend to forget everything all the time. But org-mode is a magical tool that's probably the best piece of software written to date !! And org-babel is quite cool too!
Anyway, the key takeaway is that my relationship with emacs is two-way shaping ... Meaning I can configure it to my liking with no barriers (other than elisp, I ask ChatGPT for help) and Emacs helps me shape my workflow and improve it.
It's not for everyone. It's not for most people. But it was a match for me :)
The minimal approach to have 'one tool do one thing' ignores that all the complexity is in the interactions. People praise magit so much I think because like all other tools for Emacs, it's designed with Emacs and the common interface and language in mind. It's implicit in every extension people build.
When people today struggle how to combine all their dozens of tools from notetaking to developing, to file search to git and struggle to fit it all together I think the strength of learning Emacs comes through. My guess is that this is also one of the reasons for the popularity of VsCode as it takes a similar approach.
With UNIX, the integration platform is the shell, hooking simple specialized tools through pipes and the shell language.
With Emacs, the integration platform is a Lisp environment, hooking specialized Lisp tools and Unix tools through Emacs buffers (or buffers regions) using the Elisp language.
So it's an extra layer, but if you look at it in this way you can see similarities: an environment that makes it easy to compose elementary functions into an integrated whole.
In both cases, it's most suited for people who are ready and willing to build their own specialized environment on top of a powerful platform. Although many users don't and stick to the basics too.
I really like your point about systems approach -- it's definitely a very holistic, cohesive piece of software. This is probably one of the reasons that it can be very difficult to add new features to Emacs.
For example, when it comes to emailing, MailMate is an excellent tool that I have found to be much more effective. And for programming, VS Code is unbeatable for the overall experience. When it comes to my personal wiki, I find that Obsidian is simply too good to use Emacs + Orgmode. And for quickly capturing ideas, the Drafts app with its javascript extensibility is sweet, and a big plus: it's also available on my mobile phone.
Ultimately, I have come to realize that tinkering is a luxury that not everyone can afford. While I still use Emacs extensively as an editor with macros for transforming text, I find that those who want to focus on the task at hand cannot afford to spend more time tinkering than doing the job.
In conclusion, Emacs will always have a special place in my heart, but I have learned to recognize the value of specialized tools that offer a superior user experience with less effort. However, I should note that when it comes to regex-replace across files, BBEdit is the only thing that can beat Emacs.
1. Old folks who are used to working with them and don't bother switching.
2. Young fellas who spend a significant amount of time tinkering and playing with config files.
VScode (VScodium really :) offers everything that emacs or vim has to offer (as far as editing file is concerned) with much less time spent in the config files. With that in mind, I still use emacs bacause I belong to that second category.
What is this shilling for VSCode? It's awful. But, somehow everyone who says positive things about it either turns out to not know how those things work, or just saying something vague, never pointing at any concrete feature that makes it better than something else...
But, the reality of it is that all there is to it is a crappy CUA text editor with nothing special going on for it. There were dozens like it before.
So far, over the years of working with other people using this average-at-best editor the only remarkable thing I found about it is that it has a plugin that allows some Jenkins integration, which may be useful if you are in DevOps, but... I can live without it, not a deal-breaker, not by a long shot. The awfully lacking text editing abilities of this editor completely erase any benefit I could get from that plugin. Stuff like modal windows, mouse-only navigation, missing most useful commands of structured text navigation and proprietary nature make this tool a complete non-starter for me.
I only use a handful of packages, a smidge of Org mode, minimal customisation, & run Emacs in the terminal, so switching to something more modern should surely give me everything I need & many more features in spades. But nothing else scratches the itch despite my best efforts to move to something else.
Perhaps for me Emacs is like an old pair of slippers: comfy, familiar, does what I need it to without fuss. I can't say whether it's a good choice for anyone else, but this grey beard engineer likes it.
It's the same reason why anyone would buy Hasselblad camera over, say, Canon. Canon is fine for a person who simply wants to take pictures of things they want to remember. Maybe even for a student in photography class. But, if you are going to earn your money as a photographer... well, you want a tool that you can rely on. If you go to the Moon and want your camera to work, you'll choose Hasselblad etc.
This. Even with my fairly correctable visual impairments, the way Emacs' text-driven interfaces and amazing search capabilities spare me from having to do any visual scanning is a blessing. I can always bring everything I need to see right in front of me, the whole interface scales perfectly, and I can easily ensure high contrast on everything I need to read, even with limited color vision.
The way that buffers can just live in the background and projects can simply be inferred from version control directories similarly free me from the entire spatial metaphor for open files, windows, projects, etc. No matter what window I'm in, I have the option to just list some open buffers, fuzzy filter as I type, and bring them directly into view. I run Emacs as a daemon so I can super easily pull up old buffers, complete with their contexts and undo histories and everything even if I close the Emacs frame (the application window) entirely.
I never have to scan or squint or interpret some tiny, inscrutable hieroglyph with Emacs. Every damn thing is searchable and filterable. And when I need documentation on some function or keybinding, it's the same story. I don't have to switch to another app and mouse around or toggle a browser extension to fix some dumbass website's choice of gray-on-gray text. It's just right there in my editor, clean and searchable and resizable/reflowable in the exact same way as my own code, in the fonts that I've chosen because I find them readable and pretty.
Emacs spares me from so much navigation effort while I'm editing, even without using any truly fancy features.
It's also a comfort knowing that if I should go blind before I reach old age, as is common in my family, I will still have access to that power and convenience through Emacspeak. I'd better start practicing!
[1]: https://github.com/ch11ng/exwm/wiki
[2]: https://www.masteringemacs.org/
[4]: https://libera.chat/
[5]: https://www.gnu.org/software/emacs/manual/html_mono/erc.html
"I’m using Linux. A library that Emacs uses to communicate with Intel hardware. — Erwin, #emacs, Freenode"
The main reason is that I'm concerned that we've lost ground on some very important ideas, for which we should've done a better job onboarding new techies in the last decade or two: open standards, open source, libre software, privacy, information security, etc.
There's vague stereotypes that I've seen newbies use to dismiss those ideas, bundling concern about those ideas in with "tells you that you should use Emacs" (or Vim). Which then discredits the whole basket at once.
So I'll just say it: The typical techie will probably be happier using an editor/IDE other than Emacs.
But it's important for our field and broader society that most techies learn and care about those other ideas.
(Disclosure: https://www.neilvandyke.org/emacs/ )
emacs is my OS though :)
Why would I switch to something that does everything and has an entirely different workflow? If emacs works for people, good for them, but it isn't for everybody.
Microsoft recently cancelled PayPal for Github sponsors and Tarsius lost significant amounts of income (that was already below minimum wage)[1].
A small contribution, the price of a coffee a week, which for successful developers is very little, goes a long way in supporting open source that doesn't have extensive corporate support like chromium/linux/docker.
https://magit.vc/donate/ https://liberapay.com/hlissner/donate https://liberapay.com/bzg/ (org-mode maintainer) https://www.patreon.com/sanityinc (MELPA) https://github.com/freetonik/support-emacs-community-devs (other good list)
[1]: https://www.reddit.com/r/emacs/comments/11cezoq/magit_mainta...
2. The workflow does not mimic "modern neovim setups". It defaults to hlissner's preferred style, which predates neovim, but is extremely customisable. I mean, it's emacs, after all.
3. Hating on "neovim style" as an emacs user is something you and I better than. We are both old emacs users; we can customise emacs however we like.
4. I was an emacs user before Doom Emacs. I still found it a great as a starting point and ported over my customisations on to it. You don't have to use Doom, but you can, if you want to, and still have your emacs how you like it.
To edit large text files, I use Vim, as it is one of the fastest editors I've ever tried.
For anything else, I use Emacs: scripts, programs written in languages with no good IDE support, personal notes (Org mode is awesome!), handling of Git repositories (Magit is better than JetBrains IDEs), email (Notmuch). If only it could be made faster when editing large files…
I mean, you are in no position to judge about good editors on Earth... you haven't worked with good editors yet.
This is evidenced by your gripes about editing large files. Emacs may be configured to be used as a pager for Christ's sake! It can work with whatever file size you have. If you don't know how to do that, that's a you problem, not the editor's problem...
In macOS you can do this by going to Settings->Keyboard->Keyboard Shortcuts->Modifier Keys.
For me, a good stepping stone to Evil was God mode. It strips away the need to mash modifier keys, but retains all the Emacs keyboard bindings. It gives you a glimpse of what using a modal editor is like, roughly, with a tiny cognitive effort investment.
There is also the emacs keybind friendly modal solution meow.
- Organizer - git client - search tool - rough notes - Terminal - file management - Code editor!
Pretty much everything.
But sometime ago I realized I was adding so many customized code lines to my .emacs to reassemble the modern editors that it made me think I was using it wrong. Then I decided to take a break and start using Neovim, which imo borrows some nice stuff from EMacs like the Terminal and the lua interface.
I feel like trying to recreate vscode in emacs could be a suboptimal approach to say "add a directory sidebar and lsp-mode, but get used to emacs buffer and tab handling"
> get used to emacs buffer and tab handling
This clearly shows you've never used the program you are so confidently talking about... What tabs?
lol, quick to go for the jab mister crab.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Ta...
Specifically I use https://github.com/mclear-tools/tabspaces
There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good... Complaining about it just means you don't understand how to use the editor you are complaining about. These tabs are for people who come from another editor and think they need tabs. Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.
> What's the connection? > Complaining about it just means you don't understand how to use the editor you are complaining about.
I must admit, I'm pretty confused here.
I'm not complaining about tabs?
> There are plenty of ways of managing multiple buffers, and tabs is... just one of them, and, it's just not good
What do you use for managing multiple buffers? Do you not care about distinguishing one projects buffers from any other project?
> These tabs are for people who come from another editor and think they need tabs.
The tabs in emacs are different than the ones in vscode. In emacs terms there is only one window containing one buffer you cannot change per tab.
tab == buffer in vscode
> Similar to how you can have scrollbars or panels with buttons to do things in Emacs, but they aren't there to improve editing experience, they are there to help the inexperienced to transfer their experience from other editors onto the new one.
I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars, buttons, or the new context-menu-mode.
emacs is about freedom in a lot of ways including how you use emacs, not some "ur a noob if you use the mouse" type thing.
> they are there to help the inexperienced to transfer their experience from other editors onto the new one.
People vary. For someone disabled, it's possible that in many scenarios using the mouse is faster for them than the keyboard. So the fact they use the mouse doesn't make them inexperienced.
There is utility in these features and they don't purely exist to bridge the gap for new users coming into emacs.
Ibuffer
Some people use Helm or Projectile. There's a whole section in the Wiki about it: https://wikemacs.org/wiki/Buffer_management
> The tabs in emacs are different than the ones in vscode.
Just forget tabs exist in Emacs. Like I said, they are for people who are used to have tabs, but serve no purpose if you use Emacs. It's like if you were trying to use Photoshop to run unit tests for some JavaScript code you wrote for Web browser. Yeah, it has a built-in JavaScript interpreter, but really, it's not meant to be used as a JavaScript runtime.
> tab == buffer in vscode
Not sure what you are trying to say... Do you mean a "tab" in VSCode terminology is equivalent to "buffer" in Emacs terminology? -- If so, that's not true. VSCode has a number of fixed windows, which cannot have interchangeable contents. It has a window dedicated to showing text files, it has a window dedicated to interaction with shells, it has a window dedicated to interaction with filesystem etc. While this is really inconvenient and the lack of generic approach is really hurting due to inconsistencies between these windows, that's how they chose to do it.
> I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars
I haven't met a single Emacs user who'd use scrollbars. I probably met about 2-3 dozens. Most wouldn't even know what they look like. Scrollbars aren't well-integrated into the rest of interaction with the program. It's a handicap if you use them. I cannot think about a single reason, a single situation in which scrollbars would be preferable to other methods of navigation. They are less precise, slower and in some cases impossible to implement (eg. infinite buffers).
Freedom and being a noob are orthogonal to each other. I didn't say you should never use scrollbars. I said that if you are a noob, that's what you will likely end up using... I don't say you shouldn't be a noob, I just say that being a noob sucks.
> For someone disabled
And for some who don't have hands, it's even worse... what's your point? There's the reality of text editors: if you have two functioning hands, you are in a very advantageous situation compared to someone who doesn't. Comparing the two doesn't make sense in the same way how it doesn't make sense to let super-heavy-weight boxers compete with light-weight boxers.That's why those categories were created in the first place.
(please read the emacs manual the other post of this thread as posted)
That's a great succinct way to put my longer elaborate example that's a sibling to this response.
> Ibuffer
> Some people use Helm or Projectile. There's a whole section in the Wiki about it: https://wikemacs.org/wiki/Buffer_management
I'm familiar with and have used Helm, Projectile, and project.el. I've also read that Wiki quite a few times :)
>> The tabs in emacs are different than the ones in vscode.
> Just forget tabs exist in Emacs. Like I said, they are for people who are used to have tabs, but serve no purpose if you use Emacs.
That's not true.
I use both Ibuffer and tabs. I effectively use tabs to hold window configurations and project buffers. That means instead of having to pick related buffers out of ibuffer I just switch to tab `proj1` and things are probably how I need them already. I suppose I could use registers, but that seems like more steps.
I'll use this ibuffer state with two projects open as reference for my next example:
MRL Name Size Mode Filename/Process
--- ---- ---- ---- ----------------
[ Default ]
% *Help* 506 Help
* *proj1-eshell* 41 Eshell /tmp/proj1/
% proj1 212 Dired by name /tmp/proj1/
*% *Completions* 134 Completion List
* *proj2-eshell* 41 Eshell /tmp/proj2/
% proj2 212 Dired by name /tmp/proj2/
foo 0 Fundamental /tmp/proj1/foo
bar 0 Fundamental /tmp/proj2/bar
*scratch* 145 Lisp Interaction
*% *Messages* 1697 Messages
*% *Async-native-c... 228 Fundamental
- `C-s foo RET` to open the foo buffer - `C-x p e` to open the eshell buffer
I don't have to do that if I use tabs because the window configuration was already in that form.
If I had many source files open or some other more elaborate window configuration it's even more unwieldy to not use tabs. Imagine this example scaled up to with `proj1` and `proj2` having `foo2` through `foo6` and `bar2` through `bar6` each visible in a window split 3x3.
Each time I switch projects I wouldn't want to manually recreate that split. I may not even remember it. Even if I created a register I may not remember that I created a register.
However if there is a tab that already contains that window configuration it is unavoidable because that tab holds the context for me.
I don't see any other way to get this functionality without tabs or without me "just remembering".
In case you have some counter-example in mind, it'd be good to work from a common example. Here's the bash snippet I used for the example above:
cd /tmp && mkdir proj1 && cd proj1 && git init && touch foo && cd .. && mkdir proj2 && cd proj2 && git init && touch bar
> Not sure what you are trying to say... Do you mean a "tab" in VSCode terminology is equivalent to "buffer" in Emacs terminology? -- If so, that's not true. VSCode has a number of fixed windows, which cannot have interchangeable contents. It has a window dedicated to showing text files, it has a window dedicated to interaction with shells, it has a window dedicated to interaction with filesystem etc. While this is really inconvenient and the lack of generic approach is really hurting due to inconsistencies between these windows, that's how they chose to do it.
I meant to express that vscode tabs are more limited than emacs tabs.
>> I used to think this, but my mind was changed after seeing many experienced emacs users that do prefer using scrollbars
> I haven't met a single Emacs user who'd use scrollbars. I probably met about 2-3 dozens. Most wouldn't even know what they look like. Scrollbars aren't well-integrated into the rest of interaction with the program. It's a handicap if you use them. I cannot think about a single reason, a single situation in which scrollbars would be preferable to other methods of navigation. They are less precise, slower and in some cases impossible to implement (eg. infinite buffers).
Scrollbars are the least convincing example of my point. The menu-bar and context menu are much more compelling I'd say. FWIW I don't actually use visual elements at all and just use the keyboard.
But in the past few years I've noticed more and more nodejs and python programs insist on providing "enhanced" output which do not work well in shell-mode. Things like little multi-line progress bars with colors, checkboxes, weird unicode spinners, etc. Most of those depend on cursor motion and ANSI sequences not supported in shell-mode so when I run those I often end up with junk. Setting various recommended environment variables to prevent this rarely works. For example here's what I get if I run a node app that uses a vorpal.js-based REPL in a shell-mode buffer:
myapp$ ^[[7D^[[7Chelp
^[[1000Dmyapp$ h^[[8D^[[8C^[[1000Dmyapp$ he^[[9D^[[9C^[[1000Dmyapp$ hel^[[10D^[[10C^[[1000D
myapp$ help^[[11D^[[11C^[[1000Dmyapp$ help^[[11D^[[11C
I suspect few enhanced output terminal CLI developers care about emacs shell-mode users, but I'm hopeful some of them might read this and take a little time to read https://no-color.org and ensure their programs honor things like NO_COLOR, npm config set color false, TERM=dumb, INSIDE_EMACS etc.
I've used vim since about the year 2000. Before having access to a computer running a Unix, I'd read books about the Unix environment and fell a little in love with ed commands. Their power, yes, but also the immediacy of the user experience. It's just there, all the time, in vi.
Having coded a decent amount of vimscript... Eh. vim is not great (I'll likely never switch to neovim either.) Perhaps the best part about vim is the manual. There are so many features, some of which depend on/affect other features in various ways. I use vim for taking freeform notes, transcribing long form texts mostly - the auto formatting that can hard wrap at textwidth, without any extra command or keypress to trigger the formatting) is a feature I use a lot. The ability to quickly pipe text through Unix filters (mostly `par' in my case) is also great.
All this is easily done in emacs too, but I feel there's more immediacy in vi (and vimscript).
I salivate at the better unicode support in emacs, and the ability to have frames - separate GUI windows of the same emacs process. I would use these all the time. (g)vim likely won't get better in these areas within my lifetime.
Availability on mobile devices: I use an iPhone - it's from work, I have it with me all the time. I do not want to carry along any other device. A recent-enough version of vim is available in the AppStore as iVim. This has become the only note-taking app I can bear to use. It can write to text files on iCloud and access them later from other devices.
On vi clones - I wish Thomas Dickey's editor (vile) had become popular, instead of vim. Proper lexing and parsing for syntax highlighting (instead of regexp soup) - Imagine! I started out on computing with Red Hat Linux, where vim was installed by default - and most documentation, online resources, might have mentioned vim instead of any other clone, leading to vim gaining mindshare.
But I can say git, RCS, etc integration in Emacs is easy and a pleasure to use.
I tried some IDEs a while ago, and they are way to busy for me and required heavy use of the mouse. All I really need for development is tag files, and I was able to find some lisp code that makes Emacs tag handling quite similar to vi/vim.
The only real complaint I have on Emacs is handling of tabs when editing flat text data files. But I get around that by having this:
(fset 'my-expand [?\C-u ?\M-| ?e ?x ?p ?a ?n ?d return])
I'm having better luck using my web browser for email, sublime merge for Git, debuggers in external programs, etc. If I need to do some edits with multiple selections I open up Kakoune, and if I have a burning need for LSP I switch to VS code.
I personally have a set of ⌘N and ⌘W chords [0] for various creations and deletions. ⌘W S to close all saved files is a particular favourite; I don't really pay particular attention to my tabs anymore (just open on the filespace), which is one less thing to think about when coding.
[0] https://github.com/yunruse/.config/blob/zsh/vscode/keybindin...
nnoremap @@ :update<cr>
vnoremap @@ <c-c>:update<cr>gv
inoremap @@ <c-o>:update<cr>
The title in those cases could benefit of including a "[book]" tag at the end like in: "Use GNU Emacs [book]".
I use vscode as my primary editor
thats actually my reason for switching away from vscode as im mostly working on machines without a discrete gpu AND utilize the gpu in my projects.. i cant have my code editor use 30% of gpu just to scroll text up and down (without any plugins installed) it's just silly XD
look, you go and support apple, and thats fine, but i really dont see the point in choosing hardware that is looking at locking its users in somehow.
oh and one more thing:
i assure you, this computer is more than good enough for browsing websites and do whatever you would do as a regular user... idk how you came to the conclusion it was otherwise.
it's not even the case that vscode makes anything slow here, there is no ditch in performance, everything is smooth as butter, i simply report the GPU spiking up to 30% whenever i make vscode scroll text.
are you telling me this is acceptable when i can just as well use a mightier software tool that doesnt utilize the gpu at all?
on another note: how is it be acceptable to anybody to poop a browser into every other new app? element, discord, vscode, you name it, it has electron or whatever in it. i prefer versatile tools over simple ones just like the next person, but i know for a fact: we can have that without all the blingblong.
ok, NOW im done with this
If a tool runs poorly on commodity hardware the solution isn't "get better hardware," but "improve the tool."
...okay, unless the tool absolutely requires specialized capabilities, like a neural network which needs a dedicated GPU for number crunching.
if apple ever becomes a beacon of openness, transparency and sustainability: sign me up for the newsletter. i'll even consider their ridiculous pricetags if apple became comparable to, let's say MNT.
in the meantime im considering to switch my personal laptop over from a T220 to a mnt reform
why do you imagine just saying the windows version of emacs sucks should bring emacs brand ambassadors to you to make their argument for emacs?
it's very odd.
So, if people who want to use Windows don't become Emacs users -- I couldn't care less. I don't want these people to swamp the developers with requests to add mouse-based navigation or modal windows. Being few years a dad, I discovered that in situations that don't endanger my son's help, it's more expedient to let him make his own mistakes, if he really wants to, but it doesn't work if I try to pretend that his bad ideas are equally valid as good ideas. In other words, if people want to use Windows, they should be told they are doing something stupid, but they shouldn't be strong-handed out of it.
the new job was using a language where the source code was in a database of sorts. really fussy about how to handle the code. using external tools was a huge nono.
two jobs later i find myself working with msvs and vscode and eventually realize those are THE WORST tools in existence. well, if you disregard that stuff from earlier...
i returned to emacs, had a hard look at my choices and settled for cygwin. it has its own flaws, but emacs is not one of them <3
now i just need to learn how to use gdb to get rid of msvs for gud xD
"binary releases of VS Code without MS branding/telemetry/licensing"
https://github.com/VSCodium/vscodium
or alternatively:
"VSCodium is a community-driven, freely-licensed binary distribution of Microsoft’s editor VS Code."
> Microsoft will still track usage by default.
It failed to innovate and address UX issues so its market share devoured.
They should care about it. Losing market share means people are finding more value in other editors. Do the developers not want Emacs to give the most value as possible to users?
some people just dont get it. emacs is not an editor :)
They clearly do not.
Having said that, "market share" doesn't seem like a relevant metric since the community seems perfectly content being niche.
This is just admitting defeat. There is no reason Emacs couldn't be the number one editor right now. GNU projects in general all tend to fail to innovate and seem to ignore the last couple of decades of learnings.
There is a simple reason for it not to be number one: The developers and users do not care for it to be.
I certainly don't. As long as Emacs has hit critical mass (which it trivially has), it is good enough for me.
The number one selling car is Toyota. You wouldn't go and say Porsche is an inferior product because they are not the number one selling car.
I suspect you're right that under different stewardship Emacs could have taken over the wold. And who knows, if they cared to run usability studies on the initial user experience it might still be possible.
> This is just admitting defeat
If you assume that everyone values popularity or ease-of-use then this is a reasonable conclusion.
But if you'd forgive some unsolicited advice: assuming everyone shares your values will make it hard to understand or predict other people's actions which will hinder your attempts to communicate, negotiate, or manage anyone not like you. It may be simpler to imagine they're crazy, foolish, or deluded but personally I've found it useful to operate under the assumption that their values are real and just as valid as mine.
Failing to implement UX fad of the moment means that you can rely on the GUI being consistent across years instead of having to relearn it every few months.
But it does show what software is generally better.
>A thriving ecosystem and active development is.
Despite being thriving it still is very lacking in code navigation abilities and has poor performance in general. Not to mention the editor grinds to a halt when working on big files due to extensions being poorly optimized.
>Failing to implement UX fad of the moment means that you can rely on the GUI being consistent across years instead of having to relearn it every few months.
The user experience of a product is much more than just the user interface. Emacs requires you to learn elisp and write a whole configuration file by hand or use really clunky menus.
Have you not been giving the pep talk, "if everyone jumped off a building...", as kid ?
Usually that talk is nonsense, but not here.
Use an IDE, you filthy barbarians. There is no substitute for a real IDE when it comes to seamless transition between writing code with full autocomplete support and using the debugger to step through and examine the behavior of that code. And yes, God damn it, you need a debugger. You need edit and continue. You really need structured editing and it's a crime that this isn't available for every programming language, everywhere, in 2023. Modern IDEs give you all these things except for maybe the last in a smooth integrated fashion, and this has been the case for decades now. Using anything else when this is available is like breaking your legs in preparation for the 50m dash. For God's sake, Visual Studio got you 90% of the way to a Lisp machine type dev experience. In the early 2000s, for C++ and other languages people actually use. And Unix weenies still insisted on their stone-knives-and-bearskins tooling, to all our collective detriment.
For languages without robust IDE support, Visual Studio Code will get you most of the way there with the click of a button. Releasing VSCode support including LSP for your language is now table stakes if you want to introduce a new language people will actually use.