8 ms·

My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actua

My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actual thing they are doing. For example, there will be more posts about how they mimicked most of the functionality of VSCode or a Jetbrains IDE than about any actual code they wrote (other than elisp). Given that I am naturally drawn to polishing my tools rather than actually using them, I am afraid that if I try Emacs my time,attention, and productivity will be sucked into the black hole of optimizing my Emacs workflow instead of actually executing my workflow.

melissalobos 4y ago
I can sympathize with this strongly. I have tried vim/emacs a few times, and frankly I can't see any improvement from just using any reasonable editor. Also from my own experience they tend to be much inferior IDEs than even a not so great one like Geany.
- anthk 4y ago
  Geany doesn't have org-mode for notes/programming/workflow and zillions of more features.
  - melissalobos 4y ago
    I really can't say I have understood, what exactly org-mode is supposed to be. I have seen the website and had an ardent fan explain it to me, but still don't get it. How is it better than having another text file open in another tab? Or using a jupyter/pluto notebook?
    - ravi-delia 4y ago
      Org is theoretically just a markdown format. In practice it starts out as a markdown editor with a bunch of neat features, and can become this omnibus of organization. There's a whole organizational ecosystem which uses org as a sort of lingua franca, so the more you sacrifice at its alter the more it all comes together. I use it to unify my todo list and calendar, and have it display what needs to happen both on an hour to hour level and day to day. I use it to pin emails I want to reply to with one key combo, and connect notes to each other any way I want. I have no idea if it's useful enough to justify the time I put into it. For most people, probably not. But I've gotten it to the point that it's just totally frictionless for me, and not a single other system I've ever used has been easy enough to stick to.
    - User23 4y ago
      You’d have to try it for yourself and see.
    - zelphirkalt 4y ago
      It is much more capable than the things you mentioned. It can do technical documents up to thesis writing, with citations, references both document internal and external, have code blocks, which can be run, using multiple langs per file, use output of one as input for the other, spreadsheets with a whole programming lang or GNU calc behind them, per formula of course, not only per spreadsheet, it can schedule events, it can use library of babel, it can do literate programming, ... Need I say anything more?
    - rout39574 4y ago
      You start with an outline. You bolt literate programming onto it. Then you tell your code blocks they can send input and output to each other via text in the document. Now you've got an excruciatingly well documented multi-language pipeline. Then you get the source data for all your analyses in real time from [wherever they came from]. Then you render it _beautifully_ with your dependency graph documentation generated from graphviz (which graph data was newly inferred on this very run). My first org-mode killer app, years and years ago was a monthly billing collection and analysis for a backup system I was running. The first pass took me a week to figure out how to collect and analyze. A few iterations later it was literally open the org-mode document and tell it "Do the thing". All my intermediate work was shown, everything was clear and open to inspection, and beautifully typeset. And I could generate it as HTML if they wanted it in a web page. (at the time they wanted PDF). This is one of the ways org-mode is great. There are others. :)
      - anthk 4y ago
        This is what I meant. Exactly this.
    - BeetleB 4y ago
      > I really can't say I have understood, what exactly org-mode is supposed to be. It's primarily two things: 1. A markup syntax 2. a TODO manager. It's flexible enough that you can come up with your own custom TODO workflows (e.g. GTD, etc). You can do queries on a fair amount of metadata to construct your TODO list. In support of all that, it has good table features (you can do spreadsheet like functionality in them), code management (execute source code blocks similar to Jupyter, but you can have code in multiple languages communicate with one other), link to just about anything (with a bit of setup, I can even link to Outlook emails). While in the middle of your work, you can capture notes and/or TODOs and have them filed away in the appropriate file and location within that file.[1] Finally, you can export into many formats (I don't write pure LaTeX any more - I always export an org file to LaTeX). Example of a simple thing I do. I read an email. It contains actionable information. With a keystroke, I create a TODO item in org mode, which contains a link to the email. Later when browsing my TODOs, I have access to the context. Likewise, I'm reading an article in Chrome/Firefox, and I want to file it away for some reason. With a click on a bookmarklet, it sends the URL and related info to Org mode in Emacs and it is filed away. A more sophisticated example that required some elisp: I take meeting minutes at work. Any time something comes up where a TODO is assigned to a person, I hit a keystroke and type in the TODO. It finds the heading called "Action Items" for that particular meeting and files it there. At the end of the meeting, I export the minutes into HTML or Word and email it out.
- Jenk 4y ago
  Just to pile on... I've been a (neo)vim user for many years now. My init.vim (previously .vimrc) file is a constant work in progress. It has become a companion. A partner. I have more backups of this file than I do of my will. Every time I (re)turn to a language or other text-based thing, I could very easily (and often do) get sucked into a tinker-thon trying to perfect my vim experience. I've had to accept that I just have to use the IDE du jour (or de la majorite, more accurately) to get up and running. Though you bet I'll lose some evenings to getting a vim setup working.
- pmoriarty 4y ago
  I used vi/vim for 25 years before switching to Emacs and have been using Emacs now for about a decade... with both editors there was always more to learn for me, despite being a veteran user. There's no way you're going to appreciate the power of either editor after using it only a few times.
- icambron 4y ago
  I’m not trying to convince you to change editors —- it’s a highly personal choice —- but you might be interested in a couple thoughts from someone who’s used practically every editor under the sun but uses neovim by default: - the main value of vi is editing speed. It’s just much more efficient to edit text this way. Have you ever realized you needed to make a bunch of changes to a file and then sort of groaned at how much legwork that will be? Maybe you even don’t bother because it doesn’t seem worth it? vi usually makes short work of these. It’s hard for me to overstate how big of a productivity impact this has had for me: it makes sure the mechanics are never the bottleneck in my coding process. The editor can keep up with me. - the most common painpoint with vi is that you don’t get all these snazzy IDE features. That’s why sometimes people run IDEs with vi keybindings which are never quite exact; they want features like language-aware renames and other refactoring support that vi lacks, so they make a tradeoff. But this is actually improving rapidly, thanks to the proliferation of language servers and their rapidly improving support in Neovim. I hope that soon I will no longer have to think about these tradeoffs. At any rate, everyone should write code in whatever tool they like most, but that’s been my experience with it.
  - melissalobos 4y ago
    > - the main value of vi is editing speed If it is purely mechanical type changes I would just use sed or find and replace, otherwise I think scrolling with a mouse and clicking tends to be fast enough. Could you explain a bit more about how it could be faster?
    - triyambakam 4y ago
      One example is recording a macro - you can then execute it an arbitrary number of times. I've used it e.g. to add quotes and commas to a list of data so it's a proper string array, or to change a string into an object where a property is the former simple string. The workflow would be - record the abstracted process using vi editing commands, then play the macro over where needed. Probably best to see it in action to fully appreciate it.
    - icambron 4y ago
      "Fast enough" is sort of complicated. There isn't really a fast enough, per se, just an amount of effort you're willing to put in vs some amount of efficiency gain you get for it. We all hit some point at which more effort doesn't appeal to us, especially relative to all our other priorities, and perhaps that place is scrolling and clicking for you. Who is to say? I'm sure there are people who think of my editing skills as painfully inefficient, and I just can't be bothered to push them past where they are by learning my tools better, or learning new tools, because I'd rather learn something else. But it really is a lot of faster. I've watched colleagues edit code with the mouse (e.g. move this "if" block under that "else" clause or what have you) and I will say it's much, much slower than I would do in vi. They are not incompetent or clumsy; I would have been slow with the mouse too. In fact, I'm editing this comment with a keyboard and trackpad and it feels awkward and slow. Here are a few ways in which these actions just happens faster vi: 1. jumping around in the file using your keyboard. Taking your hand off the keyboard, moving the mouse to the right spot, clicking there, putting your hands on the keyboard, and then typing is a lot of movement. In vi, you have lots of tools to just move around, i.e. to do the part you do with the mouse. You have incremental search, bookmarks, jumplists, keys for jumping to the delimiter match, or the next code block, or jumping to a line number or function definition. There are EasyMotion-style plugins that let you jump quickly to whatever you're looking at on the screen. And many more. These are all optimized to be just a couple keystrokes away. They take time to learn and become fluid with but they give you a kind of total, effortless control over what part of the file you are editing. 2. Just good keyboard-centric editing basics. Putting aside all the ways you can move around a file (or files!) and all the ways you can repeat similar actions in different parts of the file, you also just get to be quicker making specific edits. You can _probably_ do all of this with readline-style keyboard shortcuts in other editors (e.g. replace this word with another word without double-cliking it with a mouse), but vi forms a sort of interactive language for doing these edits, and the way vi works just causes you to learn them and use them consistently. 3. Fine-grained control of editing actions. This is the hardest one to explain. Modal editing has the property that your actions are sort of transactions. You are in normal mode, you take some action that puts you in edit mode, you do some typing, and then you leave edit mode and the thing you did is now a block of action. It can be undone as a block and applied again elsewhere as a block. So for example, if I want to replace "}," with ");" on like four lines, I can do that by doing it once and applying it three more times to each line (using "."). Sure, you could also do that with a find-and-replace tool, but just operating that menu isn't worth the overhead for four lines. In vi, that's just how you edit; it's by-the-by, with no special effort required. 4. For more complex repeatable actions, you have macros (which is sort of like a second-level of text editing transaction), vi's strong regex support, actions that work on rectangular selections, and plugins for multiple cursors. One way to think about the sed case is: what if you didn't have to reach for another tool and it was instead sort of conceptually integrated into your everyday editing experience? It would be much lower friction to reach for, so you'd use it more and more efficiently. There's more, but I think that's the important ones, or at least the ones I think have given me the most mileage. It's all easier to show than tell, and of course YMMV.
- bachmeier 4y ago
  Here's an example from this afternoon. I wrote a function that would cut an html div and paste it to a different place in the file. Then I created a keyboard shortcut to call that function, and I added a menu item for it as well. A few minutes after deciding I wanted that functionality, I had it. I've written Geany extensions too. Believe me, that's not something you'd do in a few minutes.
- ww520 4y ago
  A sample usage just yesterday. I needed to rename a field name of a struct in Rust. I hit a key shortcut for lsp-rename and it renames the field plus all the references in all the files in the project. I know it's just basic refactoring and some IDE's support it, but it's generic across all languages.
achikin 4y ago
I agree that setting up Emacs from scratch could be a long journey, but there are prebuilt emacs configs like Spacemacs which are even more capable than VSCode out of the box.
- anamax 4y ago
  Emacs has been my primary editor since it was written in Teco and only ran on PDP-10s. I haven't had an emacs config for >25 years.
  - tra3 4y ago
    You’ve got incredible self control. I love turning knobs and dials and that’s basically what emacs is.
    - anamax 4y ago
      Nope - just lazy, or I play with other knobs. Plus, I can usually work in someone else's Emacs session and most people can work in mine. (Yes, they almost always comment on how it's odd to not have their customizations, but they're not tripped up by mine.)
mickael-kerjean 4y ago
I haven't change 1 line of my emacs config for more than 5 years, it's the exact same since I wrote the emacs tutorial series back in 2017 (https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series-episode-0/ https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series-...). Sure it was a time sink at the beginning and it tooks some time to stabilise but the initial time investment has paid off
ravi-delia 4y ago
I can say that I went through my period of customization, and haven't spent more than ten straight minutes at a time messing with my config to get something done for at least a year. I admit to occasionally setting up something really fun and complex, particularly in my ever-growing pile of machinery around Org, but for real tasks everything just works. When I hit a pain point I might spend a minute making a simple tweak (most recently adding keybindings to deploy a small project) that just uses stuff I've made before. There are definitely people who wind up messing around more than anything else, and people who don't blog about the work they actually do since their blog focuses on Emacs, but it isn't hard to avoid that. A new language isn't quite the one click plugin of VSCode, but with lsp-mode it's actually pretty close. Perhaps 4 lines of config, plus extra keybindings you can grow organically.
dpifke 4y ago
Or maybe they find Emacs hacks more interesting to blog about than the CRUD they write at $day_job. Or maybe their NDA means they can blog about their tools and not what they're using those tools for. I don't think it follows that just because you blog about something, it means you spend the majority of your time doing it.
porcoda 4y ago
I’ve been carrying around the same 20 or so line .emacs that I use with a plain stock emacs for about 15 years. I’m happily productive without a bunch of tweaking. Same with vim: tiny vimrc that I carry around along with one old package that is hard to find online anymore. In both cases I probably add to or tweak them about once a year. It’s not a tools fault if you can’t resist tweaking it. If anything, that indicates that you’re not actually optimizing a workflow if that optimization step is actively disrupting a workflow. Self discipline is a good thing to build up for workflow optimization, far more than any tweak to a dotfile.
- ziftface 4y ago
  Curious what that one old package is Personally I can't live without a few neovim packages like auto complete and switching files and searching text in a project etc. I completely agree with the set it and forget it approach though. But if that's the case I think vim/neovim might be your best bet.
- RcouF1uZ4gsC 4y ago
  > I’ve been carrying around the same 20 or so line .emacs that I use with a plain stock emacs for about 15 years. What languages do you program in, and do you use code completion/debugging? I find that code completion is a huge productivity boost for me, as well as having a good interface to a debugger (just the debugger portion of the IDE in Jetbrains justifies the price in my mind). In addition, smart annotations where the IDE will annotate a function call with the names of the parameters is a huge boost in languages that do not have names parameters (for example C, C++, Rust). In addition, when you are doing type inference (auto in C++, and let in Rust), having the IDE automatically annotate the variable with the inferred type gives the best of both worlds - allowing me to avoid boilerplate and committing to a type, while also easily allowing me to see what the type is. I am not sure I can easily get all that out of Emacs or Vim.
  - ww520 4y ago
    Use lsp-mode and company-mode for language completion. The lsp-mode connects to the language server on the language I'm developing for language specific semantic rules and syntax. Company-mode does the completion. It is a generic completion framework, which lsp-mode hooks into to provide language specific completion. The best is that I can use the standard Emacs commands I'm familiar with to use LSP. E.g. Per your example, I can use the describe-thing-at-point command, which is in Emacs for the longest time, to show the inferred type of the variable at the cursor. I can use the same command to show the signature of a function. Lsp-mode hooks into the old command to do the magic based on language context. Same with the company-mode. Since it's a generic completion framework, I'm already familiar with its commands and key bindings. It works the same for all languages and other editing mode. E.g. in writing English, the completion command would pop up a list of word choice.
copperroof 4y ago
Most of the write ups show you everything all at once. I spend maybe a minute or so a week updating or tweaking something. Over decades this is a lot of customization and If I did a write up on it it would look like a lot of work.
gumby 4y ago
> My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actual thing they are doing. Indeed, that does seem to be the community of people who blog about emacs. It's a shame because it makes emacs look complicated to the beginner. But like many users I have a short init file with very few customizations: In my case mainly removing all the chrome and other bells and whistles so emacs looks like it did back in the 1970s. And it works great!
massysett 4y ago
Emacs is not so much an editor as it is a tool well-suited for writing custom editors. This is why Orgmode is so great and why its Emacs implementation is peerless. I used Orgmode for some time. I was not really an Emacs user. I used Orgmode and my Emacs use was incidental to that. If there isn’t already a good mode for what you want to do, Emacs is good only if you want to write the mode. For instance Haskell support in Emacs is not great; the most-used mode is not part of GNU Emacs and falls well short of the quality standards of the modes GNU ships. I found myself trying to do Haskell in Emacs because I already used Emacs for Orgmode. This was a mistake. I was better off doing Haskell in Vim. So for stuff that has a good mode—Org, lisp, C, mail if that is your kind of thing—use Emacs. Otherwise don’t bother, unless you like programming your editor.
- mplanchard 4y ago
  Haskell development with the haskell language server is pretty nice in emacs I think
- na85 4y ago
  >Emacs is not so much an editor as it is a tool well-suited for writing custom editors. I hate this meme and wish it would die. Emacs is a perfectly suitable editor that happens to have really bad defaults because the developers are mostly out of touch grognards. With a modest amount of effort, emacs could be made to have appealing aesthetics and sane defaults, but because eMaCs Is An OpErAtInG sYsTeM it stays bad.
  - alimov 4y ago
    > “With a modest amount of effort, emacs could be made to have appealing aesthetics and sane defaults…” Sure, for some peoples use cases. Also “modest amount” isn’t really true for new users. The time it takes to look up potential configs, figure out how to make changes, play around and see if that’s what they want from their editor, and in general figure out what’s possible doesn’t really happen in a “modest amount” of time. > “>Emacs is not so much an editor as it is a tool well-suited for writing custom editors.” There is nothing wrong with this comment, it is a correct statement because emacs by your own admission is a flexible tool that can be modified to one’s liking. For a lot of people that means tailoring it around their workflows/uses before it’s actually useful to them.
throwanem 4y ago
> My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actual thing they are doing. I've been using Emacs for twelve years now. I don't recall having ever blogged about it, unless we count occasional longish HN comments, usually helping answer a fairly specific question. Selection bias may be vastly skewing your analysis here, is what I'm trying to say.
na85 4y ago
I've always had the sense that this is a very vocal minority of emacs users, and that there's a heavy overlap with the people who, say, spend time "ricing" their i3 configs. I spent a few tens of minutes setting up LSP for the languages I use, a few hours browsing and trying out themes, and then I maybe spend less than an hour a year on my config
deleted 4y ago
[deleted]
ww520 4y ago
People blogging about it tend to show how to configure it. People just using it don't blog since nothing interesting to talk about when things are working great.
mplanchard 4y ago
For me it’s rather spiky, like with Linux. There will be once or twice a year I go deep in trying new configurations, messing with existing ones, and so on. The rest of the time it’s just using it.
joeman1000 4y ago
How can you make that judgment in earnest? The posts you see are guides. No one is going to post ‘I’m doing this in emacs right now, for x hours’. How can you say people are configuring more than using, when you have no data on ‘using’? With that said I agree with the general sentiment. It does take a lot of configuring compared to some other editor. I’d say my configuring/working fraction is 0.1. Emacs rewards study though.
gopiandcode 4y ago
> For example, there will be more posts about how they mimicked most of the functionality of VSCode or a Jetbrains IDE than about any actual code they wrote (other than elisp). Are we reading the same articles at all? Most of the Emacs posts I see are about extending features that lesser editors could only dream of supporting (using it as a window manager, media center, GUI etc.). I always find it suprising how far anti-Emacs zealots will go to try and cast GNU+Emacs is a bad light. Somehow the fact that the GNU+Emacs community cares enough to share their configuration tips is a "bad" thing, rather than just being indicative of a supportive and friendly user community. I guess if you are stuck in proprietary, telemetry-ridden editors like M$ vs-code, or sublime text, somehow you have to convince yourself that the grass truly isn't greener on the other side, and this is just one such coping mechanism.
- throwanem 4y ago
  It's not reasonable to expect everyone to grow out of the "editor wars" phase at the same rate. Some never manage it at all.
agumonkey 4y ago
Everytime I think I had it with emacs config fatigue and try another editor. I realize I prefer emacs. I just tried vscode. Lots of good things but not clearer on how to get what you want. You spend time googling how and what preset to modify, it might or might not work. Their git interface is not clearer. The indentation logic is strange some times.

melissalobos 4y ago

I can sympathize with this strongly. I have tried vim/emacs a few times, and frankly I can't see any improvement from just using any reasonable editor. Also from my own experience they tend to be much inferior IDEs than even a not so great one like Geany.

anthk 4y ago
Geany doesn't have org-mode for notes/programming/workflow and zillions of more features.
- melissalobos 4y ago
  I really can't say I have understood, what exactly org-mode is supposed to be. I have seen the website and had an ardent fan explain it to me, but still don't get it. How is it better than having another text file open in another tab? Or using a jupyter/pluto notebook?
  - ravi-delia 4y ago
    Org is theoretically just a markdown format. In practice it starts out as a markdown editor with a bunch of neat features, and can become this omnibus of organization. There's a whole organizational ecosystem which uses org as a sort of lingua franca, so the more you sacrifice at its alter the more it all comes together. I use it to unify my todo list and calendar, and have it display what needs to happen both on an hour to hour level and day to day. I use it to pin emails I want to reply to with one key combo, and connect notes to each other any way I want. I have no idea if it's useful enough to justify the time I put into it. For most people, probably not. But I've gotten it to the point that it's just totally frictionless for me, and not a single other system I've ever used has been easy enough to stick to.
  - User23 4y ago
    You’d have to try it for yourself and see.
  - zelphirkalt 4y ago
    It is much more capable than the things you mentioned. It can do technical documents up to thesis writing, with citations, references both document internal and external, have code blocks, which can be run, using multiple langs per file, use output of one as input for the other, spreadsheets with a whole programming lang or GNU calc behind them, per formula of course, not only per spreadsheet, it can schedule events, it can use library of babel, it can do literate programming, ... Need I say anything more?
  - rout39574 4y ago
    You start with an outline. You bolt literate programming onto it. Then you tell your code blocks they can send input and output to each other via text in the document. Now you've got an excruciatingly well documented multi-language pipeline. Then you get the source data for all your analyses in real time from [wherever they came from]. Then you render it _beautifully_ with your dependency graph documentation generated from graphviz (which graph data was newly inferred on this very run). My first org-mode killer app, years and years ago was a monthly billing collection and analysis for a backup system I was running. The first pass took me a week to figure out how to collect and analyze. A few iterations later it was literally open the org-mode document and tell it "Do the thing". All my intermediate work was shown, everything was clear and open to inspection, and beautifully typeset. And I could generate it as HTML if they wanted it in a web page. (at the time they wanted PDF). This is one of the ways org-mode is great. There are others. :)
    - anthk 4y ago
      This is what I meant. Exactly this.
  - BeetleB 4y ago
    > I really can't say I have understood, what exactly org-mode is supposed to be. It's primarily two things: 1. A markup syntax 2. a TODO manager. It's flexible enough that you can come up with your own custom TODO workflows (e.g. GTD, etc). You can do queries on a fair amount of metadata to construct your TODO list. In support of all that, it has good table features (you can do spreadsheet like functionality in them), code management (execute source code blocks similar to Jupyter, but you can have code in multiple languages communicate with one other), link to just about anything (with a bit of setup, I can even link to Outlook emails). While in the middle of your work, you can capture notes and/or TODOs and have them filed away in the appropriate file and location within that file.[1] Finally, you can export into many formats (I don't write pure LaTeX any more - I always export an org file to LaTeX). Example of a simple thing I do. I read an email. It contains actionable information. With a keystroke, I create a TODO item in org mode, which contains a link to the email. Later when browsing my TODOs, I have access to the context. Likewise, I'm reading an article in Chrome/Firefox, and I want to file it away for some reason. With a click on a bookmarklet, it sends the URL and related info to Org mode in Emacs and it is filed away. A more sophisticated example that required some elisp: I take meeting minutes at work. Any time something comes up where a TODO is assigned to a person, I hit a keystroke and type in the TODO. It finds the heading called "Action Items" for that particular meeting and files it there. At the end of the meeting, I export the minutes into HTML or Word and email it out.
Jenk 4y ago
Just to pile on... I've been a (neo)vim user for many years now. My init.vim (previously .vimrc) file is a constant work in progress. It has become a companion. A partner. I have more backups of this file than I do of my will. Every time I (re)turn to a language or other text-based thing, I could very easily (and often do) get sucked into a tinker-thon trying to perfect my vim experience. I've had to accept that I just have to use the IDE du jour (or de la majorite, more accurately) to get up and running. Though you bet I'll lose some evenings to getting a vim setup working.
pmoriarty 4y ago
I used vi/vim for 25 years before switching to Emacs and have been using Emacs now for about a decade... with both editors there was always more to learn for me, despite being a veteran user. There's no way you're going to appreciate the power of either editor after using it only a few times.
icambron 4y ago
I’m not trying to convince you to change editors —- it’s a highly personal choice —- but you might be interested in a couple thoughts from someone who’s used practically every editor under the sun but uses neovim by default: - the main value of vi is editing speed. It’s just much more efficient to edit text this way. Have you ever realized you needed to make a bunch of changes to a file and then sort of groaned at how much legwork that will be? Maybe you even don’t bother because it doesn’t seem worth it? vi usually makes short work of these. It’s hard for me to overstate how big of a productivity impact this has had for me: it makes sure the mechanics are never the bottleneck in my coding process. The editor can keep up with me. - the most common painpoint with vi is that you don’t get all these snazzy IDE features. That’s why sometimes people run IDEs with vi keybindings which are never quite exact; they want features like language-aware renames and other refactoring support that vi lacks, so they make a tradeoff. But this is actually improving rapidly, thanks to the proliferation of language servers and their rapidly improving support in Neovim. I hope that soon I will no longer have to think about these tradeoffs. At any rate, everyone should write code in whatever tool they like most, but that’s been my experience with it.
- melissalobos 4y ago
  > - the main value of vi is editing speed If it is purely mechanical type changes I would just use sed or find and replace, otherwise I think scrolling with a mouse and clicking tends to be fast enough. Could you explain a bit more about how it could be faster?
  - triyambakam 4y ago
    One example is recording a macro - you can then execute it an arbitrary number of times. I've used it e.g. to add quotes and commas to a list of data so it's a proper string array, or to change a string into an object where a property is the former simple string. The workflow would be - record the abstracted process using vi editing commands, then play the macro over where needed. Probably best to see it in action to fully appreciate it.
  - icambron 4y ago
    "Fast enough" is sort of complicated. There isn't really a fast enough, per se, just an amount of effort you're willing to put in vs some amount of efficiency gain you get for it. We all hit some point at which more effort doesn't appeal to us, especially relative to all our other priorities, and perhaps that place is scrolling and clicking for you. Who is to say? I'm sure there are people who think of my editing skills as painfully inefficient, and I just can't be bothered to push them past where they are by learning my tools better, or learning new tools, because I'd rather learn something else. But it really is a lot of faster. I've watched colleagues edit code with the mouse (e.g. move this "if" block under that "else" clause or what have you) and I will say it's much, much slower than I would do in vi. They are not incompetent or clumsy; I would have been slow with the mouse too. In fact, I'm editing this comment with a keyboard and trackpad and it feels awkward and slow. Here are a few ways in which these actions just happens faster vi: 1. jumping around in the file using your keyboard. Taking your hand off the keyboard, moving the mouse to the right spot, clicking there, putting your hands on the keyboard, and then typing is a lot of movement. In vi, you have lots of tools to just move around, i.e. to do the part you do with the mouse. You have incremental search, bookmarks, jumplists, keys for jumping to the delimiter match, or the next code block, or jumping to a line number or function definition. There are EasyMotion-style plugins that let you jump quickly to whatever you're looking at on the screen. And many more. These are all optimized to be just a couple keystrokes away. They take time to learn and become fluid with but they give you a kind of total, effortless control over what part of the file you are editing. 2. Just good keyboard-centric editing basics. Putting aside all the ways you can move around a file (or files!) and all the ways you can repeat similar actions in different parts of the file, you also just get to be quicker making specific edits. You can _probably_ do all of this with readline-style keyboard shortcuts in other editors (e.g. replace this word with another word without double-cliking it with a mouse), but vi forms a sort of interactive language for doing these edits, and the way vi works just causes you to learn them and use them consistently. 3. Fine-grained control of editing actions. This is the hardest one to explain. Modal editing has the property that your actions are sort of transactions. You are in normal mode, you take some action that puts you in edit mode, you do some typing, and then you leave edit mode and the thing you did is now a block of action. It can be undone as a block and applied again elsewhere as a block. So for example, if I want to replace "}," with ");" on like four lines, I can do that by doing it once and applying it three more times to each line (using "."). Sure, you could also do that with a find-and-replace tool, but just operating that menu isn't worth the overhead for four lines. In vi, that's just how you edit; it's by-the-by, with no special effort required. 4. For more complex repeatable actions, you have macros (which is sort of like a second-level of text editing transaction), vi's strong regex support, actions that work on rectangular selections, and plugins for multiple cursors. One way to think about the sed case is: what if you didn't have to reach for another tool and it was instead sort of conceptually integrated into your everyday editing experience? It would be much lower friction to reach for, so you'd use it more and more efficiently. There's more, but I think that's the important ones, or at least the ones I think have given me the most mileage. It's all easier to show than tell, and of course YMMV.
bachmeier 4y ago
Here's an example from this afternoon. I wrote a function that would cut an html div and paste it to a different place in the file. Then I created a keyboard shortcut to call that function, and I added a menu item for it as well. A few minutes after deciding I wanted that functionality, I had it. I've written Geany extensions too. Believe me, that's not something you'd do in a few minutes.
ww520 4y ago
A sample usage just yesterday. I needed to rename a field name of a struct in Rust. I hit a key shortcut for lsp-rename and it renames the field plus all the references in all the files in the project. I know it's just basic refactoring and some IDE's support it, but it's generic across all languages.

achikin 4y ago

I agree that setting up Emacs from scratch could be a long journey, but there are prebuilt emacs configs like Spacemacs which are even more capable than VSCode out of the box.

anamax 4y ago
Emacs has been my primary editor since it was written in Teco and only ran on PDP-10s. I haven't had an emacs config for >25 years.
- tra3 4y ago
  You’ve got incredible self control. I love turning knobs and dials and that’s basically what emacs is.
  - anamax 4y ago
    Nope - just lazy, or I play with other knobs. Plus, I can usually work in someone else's Emacs session and most people can work in mine. (Yes, they almost always comment on how it's odd to not have their customizations, but they're not tripped up by mine.)

mickael-kerjean 4y ago

I haven't change 1 line of my emacs config for more than 5 years, it's the exact same since I wrote the emacs tutorial series back in 2017 (https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series-episode-0/ https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series-...). Sure it was a time sink at the beginning and it tooks some time to stabilise but the initial time investment has paid off

ravi-delia 4y ago

I can say that I went through my period of customization, and haven't spent more than ten straight minutes at a time messing with my config to get something done for at least a year. I admit to occasionally setting up something really fun and complex, particularly in my ever-growing pile of machinery around Org, but for real tasks everything just works. When I hit a pain point I might spend a minute making a simple tweak (most recently adding keybindings to deploy a small project) that just uses stuff I've made before. There are definitely people who wind up messing around more than anything else, and people who don't blog about the work they actually do since their blog focuses on Emacs, but it isn't hard to avoid that. A new language isn't quite the one click plugin of VSCode, but with lsp-mode it's actually pretty close. Perhaps 4 lines of config, plus extra keybindings you can grow organically.

dpifke 4y ago

Or maybe they find Emacs hacks more interesting to blog about than the CRUD they write at $day_job. Or maybe their NDA means they can blog about their tools and not what they're using those tools for. I don't think it follows that just because you blog about something, it means you spend the majority of your time doing it.

porcoda 4y ago

I’ve been carrying around the same 20 or so line .emacs that I use with a plain stock emacs for about 15 years. I’m happily productive without a bunch of tweaking. Same with vim: tiny vimrc that I carry around along with one old package that is hard to find online anymore. In both cases I probably add to or tweak them about once a year. It’s not a tools fault if you can’t resist tweaking it. If anything, that indicates that you’re not actually optimizing a workflow if that optimization step is actively disrupting a workflow. Self discipline is a good thing to build up for workflow optimization, far more than any tweak to a dotfile.

ziftface 4y ago
Curious what that one old package is Personally I can't live without a few neovim packages like auto complete and switching files and searching text in a project etc. I completely agree with the set it and forget it approach though. But if that's the case I think vim/neovim might be your best bet.
RcouF1uZ4gsC 4y ago
> I’ve been carrying around the same 20 or so line .emacs that I use with a plain stock emacs for about 15 years. What languages do you program in, and do you use code completion/debugging? I find that code completion is a huge productivity boost for me, as well as having a good interface to a debugger (just the debugger portion of the IDE in Jetbrains justifies the price in my mind). In addition, smart annotations where the IDE will annotate a function call with the names of the parameters is a huge boost in languages that do not have names parameters (for example C, C++, Rust). In addition, when you are doing type inference (auto in C++, and let in Rust), having the IDE automatically annotate the variable with the inferred type gives the best of both worlds - allowing me to avoid boilerplate and committing to a type, while also easily allowing me to see what the type is. I am not sure I can easily get all that out of Emacs or Vim.
- ww520 4y ago
  Use lsp-mode and company-mode for language completion. The lsp-mode connects to the language server on the language I'm developing for language specific semantic rules and syntax. Company-mode does the completion. It is a generic completion framework, which lsp-mode hooks into to provide language specific completion. The best is that I can use the standard Emacs commands I'm familiar with to use LSP. E.g. Per your example, I can use the describe-thing-at-point command, which is in Emacs for the longest time, to show the inferred type of the variable at the cursor. I can use the same command to show the signature of a function. Lsp-mode hooks into the old command to do the magic based on language context. Same with the company-mode. Since it's a generic completion framework, I'm already familiar with its commands and key bindings. It works the same for all languages and other editing mode. E.g. in writing English, the completion command would pop up a list of word choice.

copperroof 4y ago

Most of the write ups show you everything all at once. I spend maybe a minute or so a week updating or tweaking something. Over decades this is a lot of customization and If I did a write up on it it would look like a lot of work.

gumby 4y ago

> My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actual thing they are doing. Indeed, that does seem to be the community of people who blog about emacs. It's a shame because it makes emacs look complicated to the beginner. But like many users I have a short init file with very few customizations: In my case mainly removing all the chrome and other bells and whistles so emacs looks like it did back in the 1970s. And it works great!

massysett 4y ago

Emacs is not so much an editor as it is a tool well-suited for writing custom editors. This is why Orgmode is so great and why its Emacs implementation is peerless. I used Orgmode for some time. I was not really an Emacs user. I used Orgmode and my Emacs use was incidental to that. If there isn’t already a good mode for what you want to do, Emacs is good only if you want to write the mode. For instance Haskell support in Emacs is not great; the most-used mode is not part of GNU Emacs and falls well short of the quality standards of the modes GNU ships. I found myself trying to do Haskell in Emacs because I already used Emacs for Orgmode. This was a mistake. I was better off doing Haskell in Vim. So for stuff that has a good mode—Org, lisp, C, mail if that is your kind of thing—use Emacs. Otherwise don’t bother, unless you like programming your editor.

mplanchard 4y ago
Haskell development with the haskell language server is pretty nice in emacs I think
na85 4y ago
>Emacs is not so much an editor as it is a tool well-suited for writing custom editors. I hate this meme and wish it would die. Emacs is a perfectly suitable editor that happens to have really bad defaults because the developers are mostly out of touch grognards. With a modest amount of effort, emacs could be made to have appealing aesthetics and sane defaults, but because eMaCs Is An OpErAtInG sYsTeM it stays bad.
- alimov 4y ago
  > “With a modest amount of effort, emacs could be made to have appealing aesthetics and sane defaults…” Sure, for some peoples use cases. Also “modest amount” isn’t really true for new users. The time it takes to look up potential configs, figure out how to make changes, play around and see if that’s what they want from their editor, and in general figure out what’s possible doesn’t really happen in a “modest amount” of time. > “>Emacs is not so much an editor as it is a tool well-suited for writing custom editors.” There is nothing wrong with this comment, it is a correct statement because emacs by your own admission is a flexible tool that can be modified to one’s liking. For a lot of people that means tailoring it around their workflows/uses before it’s actually useful to them.

throwanem 4y ago

> My impression after reading a lot of blogs by Emacs users is that they spend more time thinking and writing about how to make Emacs do something, than the actual thing they are doing. I've been using Emacs for twelve years now. I don't recall having ever blogged about it, unless we count occasional longish HN comments, usually helping answer a fairly specific question. Selection bias may be vastly skewing your analysis here, is what I'm trying to say.

na85 4y ago

I've always had the sense that this is a very vocal minority of emacs users, and that there's a heavy overlap with the people who, say, spend time "ricing" their i3 configs. I spent a few tens of minutes setting up LSP for the languages I use, a few hours browsing and trying out themes, and then I maybe spend less than an hour a year on my config

deleted 4y ago

[deleted]

ww520 4y ago

People blogging about it tend to show how to configure it. People just using it don't blog since nothing interesting to talk about when things are working great.

mplanchard 4y ago

For me it’s rather spiky, like with Linux. There will be once or twice a year I go deep in trying new configurations, messing with existing ones, and so on. The rest of the time it’s just using it.

joeman1000 4y ago

How can you make that judgment in earnest? The posts you see are guides. No one is going to post ‘I’m doing this in emacs right now, for x hours’. How can you say people are configuring more than using, when you have no data on ‘using’? With that said I agree with the general sentiment. It does take a lot of configuring compared to some other editor. I’d say my configuring/working fraction is 0.1. Emacs rewards study though.

gopiandcode 4y ago

> For example, there will be more posts about how they mimicked most of the functionality of VSCode or a Jetbrains IDE than about any actual code they wrote (other than elisp). Are we reading the same articles at all? Most of the Emacs posts I see are about extending features that lesser editors could only dream of supporting (using it as a window manager, media center, GUI etc.). I always find it suprising how far anti-Emacs zealots will go to try and cast GNU+Emacs is a bad light. Somehow the fact that the GNU+Emacs community cares enough to share their configuration tips is a "bad" thing, rather than just being indicative of a supportive and friendly user community. I guess if you are stuck in proprietary, telemetry-ridden editors like M$ vs-code, or sublime text, somehow you have to convince yourself that the grass truly isn't greener on the other side, and this is just one such coping mechanism.

throwanem 4y ago
It's not reasonable to expect everyone to grow out of the "editor wars" phase at the same rate. Some never manage it at all.

agumonkey 4y ago

Everytime I think I had it with emacs config fatigue and try another editor. I realize I prefer emacs. I just tried vscode. Lots of good things but not clearer on how to get what you want. You spend time googling how and what preset to modify, it might or might not work. Their git interface is not clearer. The indentation logic is strange some times.