251–260 of 290 posts
Ligatures remind me of the symbols in APL. There, I can see sort of a use if your language requires it but generally in the terminal? I don't get it.
Earlier quoted context omitted.
I’ve been using emacs on and off for about 20 years and I don’t really get the fanaticism. Org mode and magit and all these things are cool. I like that you can hack it. But — to me it never stops feeling like an ongoing project when you try to live your entire life in it. I like it obviously otherwise I wouldn’t still be using it, but it will never exactly feel elegant to me. More like a good text editor and a hundr…
I like to tinker and hack on things, so I enjoy maintaining my Emacs config to an extent. However, I draw the line at "text editor" with Emacs. I have no desire to read my email, paint pictures, or compose music inside Emacs—there are better tools for that.
A few years ago I got fed up with not being able to configure Mail.app to notify me of responses to "watched" threads but nothing else and thought "...I bet the CLI tools would make this achievable."
So, I moved to mbsync for fetching email, not much for indexing the local email directory, and notmuch-mode / Emacs for reading and writing email.
It's head and shoulders above any other email setup I've ever used.
I wish I'd done it years ago.
A couple things about the content of this post, that people aren't talking about. Mastering Emacs by Mickey Petersen is a solid book on Emacs and a good companion to the official manual. Mickey usually has an update to Mastering Emacs not long after a new version is released, which is great. I'm thankful for his many contributions to the Emacs community, and I really enjoyed reading his thoughts on the new features a…
This collection page of Emacs packages: https://emacs.zeef.com contains only packages which are last updated at least 2 years ago, and it's already an impressive amount to me, which indicates that Emacs community is also very active, despite having - in IT terms- a very ancient editor.
Ancient, stable platforms enable long-termism, which encourages scratching your itches - whatever you write, it will likely keep working until after you're dead.
Earlier quoted context omitted.
What parts did you find difficult? When I first started, I found the keybindings odd, but now I love them since the core set of shortcuts—C-a, C-e, C-f, etc.—work "everywhere" from the terminal, to GNU readline-based programs, to even native macOS text boxes. If you don't like the default keybindings, you can change them or use the Evil package [0] for Vim bindings. If you want to get up and running quickly, I'd chec…
Do you use it as an IDE? That's the part I had trouble with (react/typescript and python). I could get it almost there, but essentially what I would need is a VS Code mode. A side panel with the collapsible directories, double click into them, global search, linting, syntax, etc.
Earlier quoted context omitted.
The worst part about Emacs is the bindings. :D The reason I'll never leave Emacs is that if I want to change something, I can. It doesn't really matter what it is. This might be technically true in something like VS Code (although Atom was much easier in this regard), but it takes a lot more effort and scaffolding to do something like write a single function and bind it to a keymap in VS Code.
One of the best parts is the bindings! They are present in most shells/terminals, GNU readline-based programs, and even native macOS text field. If you're in a terminal or using a terminal-based program, there's a good chance pressing any of the core Emacs keybindings does what you expect it to.
Earlier quoted context omitted.
Which keyboard, if you don't mind my asking?
Kinesis Advantage 2. In my opinion it’s still the best ergonomic keyboard on the market, I just wish it had better firmware.
There is also a successor available.
Earlier quoted context omitted.
Have you tried Doom Emacs?
I (try to) use spacemacs. I heard they're similar. Is Doom Emacs better for an IDE type experience compared to spacemacs? I'm mostly on Ubuntu if that matters
Earlier quoted context omitted.
The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into…
This is simply not my experience. For example, an IDE lets you rename a variable or type in a semantic fashion, making it easier for me to iterate on names and land on something that people understand. There's a huge mental component to coding (I doubt it's 90% though). In any case, an IDE makes that easier by getting the boring physical stuff out of the way quicker. And the speed at which you write code is quite mea…
The rename functionality is helpful, mainly for names that are referenced throughout the codebase. For locals it's not hard to replace this functionality - narrow the buffer to the scope you want (expand-region helps), then use iedit or multiple-cursors to perform the change. For public names referenced in multiple places you can use grep-find, then wgrep with iedit or multiple-cursors to do the rename. It's more work, and you risk renaming things you didn't intend to rename (ie. it's not semantic), but it works also with languages that have no IDEs or LSP implementation, so it's worth knowing.
Earlier quoted context omitted.
I can write the same code significantly faster with an IDE because of all the autocompletion and code navigation. I don't use the version control features other than the occasional blame, preferring to stick to a command line for that.
The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into…
That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone.
There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point.
[1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.