I'm approximately 2 weeks into using emacs as my daily editor and, well, I haven't opened JetBrains since.\nI honestly didn't expect that, but here we are.
\nHere's the list of things I noted in my last post that I said I'd come back to.\nThe list has changed a bit since the last post:
\nSolved:
\nglobal-auto-revert-mode)Haven't bothered to try resolving (infrequently used):
\nThe highlighting one is worth a bit of explanation.\nHere's what I had to do to get it working:
\n;; Highlight mutable variables (like RustRover/JetBrains).\n;; NB: Requires eglot 1.20+\n(defface eglot-semantic-mutable\n '((t :underline t))\n "Face for mutable variables via semantic tokens.")\n\n(with-eval-after-load 'eglot\n (add-to-list 'eglot-semantic-token-modifiers "mutable"))\nApparently this requires a fairly recent version of eglot to work,\nand it isn't necessarily supported by every LSP,\nbut it works for me with rust-analyzer.\nI spent way too much time on this because for some reason running M-x eglot-reconnect\nor M-x eglot and accepting a restart didn't reset the buffer settings or something.\nIf this doesn't work, try killing the buffer and then find the file again.
Here's a similarly categorized list of things that I found over the past week or so.
\nSolved:
\n(setq tab-bar-mode t)! It's great.\nIt's even better than I expected TBH since every tab can contain an arbitrary configuration of buffers.\nThis is a weird way of thinking at first, but it's really nice since stuff doesn't need to follow the traditional bounds\nthat I was used to in IDEs (e.g. a tab can be entirely terminal buffers, or cross "projects" which is useful to me).xref-matches-in-files was SLOW. Turned out to be an issue in my fish configuration (which isn't even my "preferred" shell,\nbut it's still my login shell due to being more supported than nushell, which I use for most things).\nRemoving pyenv fixed that.\nAlso you can set it to use ripgrep with (setq xref-search-program 'ripgrep)C-x p f (mnemonic: project find).consult-eglot package.\nSpecifically, it includes a consult-eglot-symbols command.Not solved yet:
\ndiff-hl package doesn't get the hint when files reload for some reason.I'll also add a quick note that it's (still) surprisingly easy to screw up your own config.\nEmacs as a system is super flexible but that also makes it somewhat fragile.\nEverything is programmable, in a single-threaded, garbage-collected language.
\nOne snag I hit was that after some period, the environment got super slow,\naffecting things like unit test runtimes in terminal buffers,\nand making input noticeably laggy.\nThe issue turned out to be my global-auto-revert-mode config.\nApparently if you do it wrong, it turns into a whole stack of polling operations for every buffer.\nThis was a consequence of Claude suggesting something dumb and me not researching it :P\nThe normal configuration will use filesystem notifications like kqueue or inotify.
I'm pretty happy with the new setup overall.\nObviously some room for tweaks, but it's pretty great overall,\nand I'm really enjoying the tab bar approach for organizing things.\nI'm also frankly shocked at how little CPU I'm using relative to previous norms on my MacBook.
\nNext up I'll probably try (in no particular order):
\nI have been a fan of JetBrains products for over a decade by now,\nand an unapologetic lover of IDEs generally.\nI've used PyCharm since shortly after it launched,\nand over the years I've used IntelliJ IDEA,\nWebStorm, DataGrip, RustRover, and more.\nI literally have the all products pack (and have for many years).
\nI truly believe that a good IDE can be a productivity multiplier.\nYou get refactoring, jump-to-definition, symbol-aware search,\nsaved build/run configurations, a nice and consistent interface\nto otherwise terrible tooling (looking at you CMake and the half dozen Python package managers\nof the last decade and change).
\nBut something has changed over the past few years.\nThe quality of the product has generally deteriorated in several ways.\nWith the advent of LSP, the massive lead JetBrains had in "code intelligence"\nhas eroded, and in many cases no longer exists.\nThe resource requirements of the IDE have also ballooned massively,\neven occasionally causing memory pressure on my amply equipped MacBook Pro with 32GB of RAM.
\n(Side note: I regularly have 3 JetBrains IDEs open at once because I need to work in many languages,\nand for some reason they refuse to ship a single product that does that.\nI would have paid for such a product.)
\nAnd as if that weren't enough, it seems like I have to restart to install some urgent nagging update\nseveral times/week, usually related to one of their confusing mess of AI plugins\n(is AI Chat what we're supposed to use? Or Junie? Or... what?).\nTo top it all off, stability has gone out the window.\nAt least once/week, I will open my laptop from sleep,\nonly to find out that one or more of my JetBrains IDEs has crashed.\nUsually RustRover.\nWhich also eats up like 30GB of extra disk space for things like macro expansions\nand other code analysis.\nThe taxes are high and increasing on every front.
\nSo, I decided the time was right to give Emacs another shot.
\nIf you know me personally, you may recall that I made some strong statements in the past\nto the effect that spending weeks writing thousands of lines of Lua to get the ultimate Neovim config was silly.\nAnd my strongly worded statements of the past were partially based on my own experiences with such editors,\nincluding Emacs.\nBasically, I appreciate that you can "build your own lightsaber",\nbut I did not consider that to be a good use of my time.\nOne of the reasons I like(d) JetBrains is that I didn't ever need to think about tweaking configs!
\nBut things have gotten so bad that I figured I'd give it a shot with a few stipulations.
\nWith these constraints, I set off to see if I needed to revise my philosophy of editors.
\nAside: why not (Helix|Neovim|Zed|something else)?\nA few reasons, in no particular order:
\nSo, how's it going so far?\nHere are a few of the highlights.
\nIt used to be the case that JetBrains had a dominant position in code analysis.\nThis isn't the case anymore, and most of the languages I use that would benefit from an LSP\nhave a great one available.\nThings have improved a lot, particularly in terms of Emacs integrations,\nover the past decade!\neglot is now bundled with Emacs,\nso you don't even need to go out of your way to get some funky packages hooked up\n(like I had to with some flycheck plugin for Haskell back in the day).
The LSP-guided tools for refactoring have also improved a lot.\nIt used to be that only a "real IDE" had much better than grep and replace.\nI was happy to find that eglot-rename "just worked".
I'm used to hovering my mouse over any bit of code, waiting a few seconds,\nand being greeted by a docs popover.\nThis is now possible in Emacs too with eldoc + your LSP.\nI added the eldoc-box plugin and configured it to my liking.
So far, every single quick-fix action that I'm used to in RustRover\nseems to be there in the eglot integration with rust-analyzer.\nIt took me a few minutes to realize that this was called eglot-code-actions),\nbut once I figured that out, I was rolling.
I frequently use the jump-to-definition feature in IDEs.\nUsually by command+clicking.\nYou can do the same in Emacs with M-., which is a bit weird, but okay.\nI picked up the muscle memory after less than an hour.\nThe weird thing though is what happens next.\nI'm used to JetBrains and most other well-designed software (glares in the general direction of Apple)\n"just working" with the forward+back buttons that many input devices have.\nEmacs did not out of the box.
One thing JetBrains did fairly well was bookmarking where you were in a file, and even letting you jump back after\nnavigating to the definition or to another file.\nThis had some annoying side effects with multiple tabs, which I won't get into but it worked overall.\nIn Emacs, you can return from a definition jump with M-,, but there is no general navigate forward/backward concept.\nThis is where the build-your-own-lightsaber philosophy comes in I guess.\nI knew I'd hit it eventually.
I tried out a package called better-jumper but it didn't immediately do what I wanted,\nso I abandoned it.\nI opted instead to simple backward and forward navigation.\nIt works alright.
(global-set-key (kbd "<mouse-3>") #'previous-buffer)\n(global-set-key (kbd "<mouse-4>") #'next-buffer)\nAside: I had to use C-h k (describe-key) to figure out what the mouse buttons were.\nAdvice I saw online apparently isn't universally applicable,\nand Xorg, macOS, etc. may number the buttons differently!
The emacs shell mode is terrible.\nIt's particularly unusable if you're running any sort of TUI application.\nA friend recommended eat as an alternative.\nThis worked pretty well out of the box with most things,\nbut when I ran cargo nextest for the first time,\nI was shocked at how slow it was.\nMy test suite which normally runs in under a second took over 30!\nYikes.\nI believe the slowness is because it's implemented in elisp,\nwhich is still pretty slow even when native compilation is enabled.
Another Emacs user recommended I try out vterm, so I did.\nHallelujah!\nIt's no iTerm 2, and it does have a few quirks,\nbut it's quite usable and MUCH faster.\nIt also works better with full-screen TUI apps like Claude Code.
I'm not going to get into the pros and cons of LLMs in this post.\nBut if you use these tools in your work,\nI think you'll be surprised by how good the experience is with vterm and the claude CLI.\nI have been evaluating JetBrains' disjoint attempts at integrations with Junie,\nand more recently Claude Code and Codex.
Junie is alright for some things.\nThe only really good thing I have to say about the product is that at least it let me select a GPT model.\nAnthropic models have been severely hampered in their ability to do anything useful in most codebases I work in,\ndue to tiny context windows.\nThat recently changed when Anthropic rolled out a 1 million token context window to certain users.
\nJetBrains confusingly refers to Claude Code as "Claude Agent" and team subscriptions automatically include some monthly credits.\nEvery single JetBrains IDE will install its own separate copy of Claude Code (yay).\nBut it is really just shelling out to Claude Code it seems\n(it asks for your permission to download the binary.\nCodex is the same.)
\nGiven this, I assumed the experience and overall quality would be similar.\nWell, I was VERY wrong there.\nClaude Code in the terminal is far superior for a number of reasons.\nNot just access to the new model though that helps.\nYou can also configure "effort" (lol), and the "plan" mode seems to be far more sophisticated than what you get in the JetBrains IDEs.
\nSo yeah, if you're going to use these tools, just use the official app.\nIt makes sense; they have an incentive to push people to buy direct.\nAnd it so happens that Claude Code fits comfortably in my Emacs environment.
\nMore directly relevant to this post,\nLLMs (any of them really) are excellent at recommending Emacs packages and config tweaks.\nSo it's never been easier to give it a try.\nI've spent something like 2-3x longer writing this post than I did configuring Emacs.\n(And yes, before you ask, this post is 100% hand-written.)\nMy basic flow was to work, get annoyed (thats pretty easy for me),\nand describe my problem to ChatGPT or Claude.\nI am nowhere near the hours I budgeted for config fiddling.\nThat surprised me!
\nWhile I'm no stranger to hacking around with nothing more than a console,\nI really don't like the git CLI.\nI've heard jj is better, but honestly I think GUIs are pretty great most of the time.\nI will probably try magit at some point,\nbut for now I'm very happy with Sublime Merge.
\nBut one thing I MUST have in my editor is a "gutter" view of lines that are new/changed,\nand a way to get a quick inline diff.\nJetBrains had a great UX for this which I used daily.\nAnd for Emacs, I found something just as great: diff-hl.
My config for this is very simple:
\n(unless (package-installed-p 'diff-hl)\n (package-install 'diff-hl))\n(use-package diff-hl\n :config\n (global-diff-hl-mode))\nTo get a quick diff of a section that's changed,\nI use diff-hl-show-chunk.\nI might even like the hunk review experience here better than in JetBrains!
I think JetBrains has the best search around with their double-shift, cmd+shift+o, and cmd-shift-f views.\nI have not yet gotten my Emacs configured to be as good.\nBut C-x p g (project-find-regexp) is pretty close.\nI'll look into other plugins later for fuzzy filename/symbol search.\nI do miss that.
The final pleasant surprise is that I don't miss JetBrains run configurations as much as I expected.\nI instead switch to putting a justfile in my repo and populating that with my run configurations\n(much of the software I work on has half a dozen switches which vary by environment).\nThis also has the side effect of cleaning up some of my CI configuration (just run the same thing!)\nand also serves as useful documentation to LLMs.
I have typos configured for most of my projects in CI,\nbut it drives me nuts when an editor doesn't flag typos for me.\nJetBrains did this well.\nEmacs has nothing out of the box (Zed also annoyingly doesn't ship with anything, which is really confusing to me).\nBut it's easy to add.
I went with Jinx.\nThere are other options, but this one seemed pretty modern and worked without any fuss, so I stuck with it.
\nThis is all a lot more positive than I was expecting to be honest!\nI am not going to cancel my JetBrains subscription tomorrow;\nthey still do make the best database tool I know of.\nBut I've moved all my daily editing to Emacs.
\nThat said, there are still some papercuts I need to address:
\neglot-x which I'll look into later.cargo fmt)!mut variables. I would love to get that back in Emacs.In my work, I've been doing a lot of ETL pipeline design recently for our geocoding system.\nThe system processes on the order of a billion records per job,\nand failures are part of the process.\nWe want to log these.
\nMost applications start by dumping logs to stderr.\nUntil they overflow their terminal scrollback buffer.\nThe next step is usually text files.\nBut getting insights from 10k+ of lines of text with grep is a chore.\nIt may even be impossible unless you've taken extra care with how your logs are formatted.
In this post we'll explore some approcahes to do application logging better.
\nMy first introduction to logs with a structural element was probably Logcat for Android.\nLogcat lets you filter the fire hose of Android logs down to a specific application,\nand can even refine the scope further if you learn how to use it.\nLogcat is a useful tool, but fundamentally all it can do is filter logs from a stream\nand it has most of the same drawbacks as grepping plain text files.
\nLarger systems often benefit from something like the tracing crate,\nwhich integrates with services like journald and Grafana Loki.\nThis is a great fit for a long-running service,\nbut is total overkill for an application that does some important stuff ™\nand exits.\nLike our ETL pipeline example.
(Aside: I have a love/hate relationship with journalctl.\nI mostly interact with it through Ctrl+R in my shell history,\nwhich is problemating when connecting to a new server.\nBut it does have the benefit of being a nearly ubiquitous local structured logging system!)
Using a database as an application log can be a brilliant level up for many applications\nbecause you can actually query your logs with ease.\nI'll give a few examples, and then show some crazy cool stuff you can do with that.
\nOne type of failure we frequently encounter is metadata that looks like a URL where it shouldn't be.\nFor example, the name of a shop being http://spam.example.com/,\nor having a URL in an address or phone number field.\nIn this case, we usually drop the record, but we also want to log it so we can clean up the source data.\nSome other common failures are missing required fields, data in the wrong format, and the like.
Rather than logging these to stderr or some plain text files, we write to a DuckDB database.\nThis has a few benefits beyond the obvious.\nFirst, using a database forces you to come up with a schema.\nAnd just like using a language with types, this forces you to clarify your thinking a bit upfront.\nIn our case, we log things like the original data source, an ID, a log level (warn, error, info, etc.),\na failure code, and additional details.
From here, we can do meaningufl analytical queries like\n"how many records were dropped due to invalid geographic coordinates"\nor "how many records were rejected due to metadata mismatches"\n(ex: claiming to be a US address but appearing in North Korea).
\nIf this query uncovers a lot of rejected records from one data source,\nwouldn't it be nice if we could look at a sample?\nWe have the IDs right there in the log, and the data source identifier, after all.\nBut since we're in DuckDB rather than a plain text file,\nwe can pretty much effortlessly join on the data files!\n(This assumes that your data is in some halfway sane format like JSON, CSV, Parquet, or even another database).
\nWe can even take this one step further and compare logs across imports!\nWhat's up with that spike in errors compared to last month's release from that data source?
\nThese are the sort of insights which are almost trivial to uncover when your log is a database.
\nNow that I've described all the awesome things you can do,\nlet's get down to the practical questions like how you'd do this in your app.\nMy goals for the code were to make it easy to use and impossible to get wrong at the use site.\nFortunately that's pretty easy in Rust!
\n#[derive(Clone)]\npub struct ImportLogger {\n pool: Pool<DuckdbConnectionManager>,\n // Implementation detail for our case: we have multiple ETL importers that share code AND logs.\n // If you have any such attributes that will remain fixed over the life of a logger instance,\n // consider storing them as struct fields so each event is easier to log.\n importer_name: String,\n}\nPretty standard struct setup using DuckDB and r2d2 for connection pooling.\nWe put this in a shared logging crate in a workspace containing multiple importers.\nThe importer_name is a field that will get emitted with every log,\nand doesn't change for a logger instance.\nIf your logging has any such attributes (ex: a component name),\nstoring them as struct fields makes each log invocation easier!
Note
\nAt the time of this writing, I couldn't find any async connection pool integrations for DuckDB.\nIf anyone knows of one (or wants to add it to bb8), let me know!
pub fn new(config: ImportLogConfig, importer_name: String) -> anyhow::Result<ImportLogger> {\n let manager = DuckdbConnectionManager::file(config.import_log_path)?;\n let pool = Pool::new(manager)?;\n\n pool.get()?.execute_batch(include_str!("schema.sql"))?;\n\n Ok(Self {\n pool,\n importer_name,\n })\n}\nThe constructor isn't anything special; it sets up a DuckDB connection to a file-backed database\nbased on our configuration.\nIt also initializes the schema from a file.\nThe schema file lives in the source tree, but the lovely include_str!\nmacro bakes it into a static string at compile time (so we can still distribute a single binary).
pub fn log(&self, level: Level, source: &str, id: Option<&str>, code: &str, reason: &str) {\n log::log!(level, "{code}\\t{source}\\t{id:?}\\t{reason}");\n let conn = match self.pool.get() {\n Ok(conn) => conn,\n Err(e) => {\n log::error!("failed to get connection: {}", e);\n return;\n }\n };\n match conn.execute(\n "INSERT INTO logs VALUES (current_timestamp, ?, ?, ?, ?, ?, ?)",\n params![level.as_str(), self.importer_name, source, id, code, reason],\n ) {\n Ok(_) => (),\n Err(e) => log::error!("Failed to insert log entry: {}", e),\n }\n}\nAnd now the meat of the logging!\nThe log method does what you'd expect.\nThe signature is a reflection of the schema:\nwhat you need to log, what you may optionally log, and what type of data you're logging.
For our use case, we decided to additionally log via the log crate.\nThis way, we can see critical errors on the console to as the job is running.
And that's pretty much it!\nIt took significantly more time to write this post than to actually write the code.\nSomeone could probably write a macro-based crate to generate these sorts of loggers if they had some spare time ;)
\nfilter_logWe have a pretty common pattern in our codebase,\nwhere most operations / pipeline stages yield results,\nand we want to chain these together.\nWhen it succeeds, we pass the result on to the next stage.\nOtherwise, we want to log what went wrong.
\nWe called this filter_log because it usually shows up in filter_map over streams\nand as such yields an Option<T>.
This was extremely easy to add to our logging struct,\nand saves loads of boilerplate!
\n/// Converts a result to an option, logging the failure if the result is an `Err` variant.\npub fn filter_log<T, E: Debug>(\n &self,\n level: Level,\n source: &str,\n id: Option<&str>,\n code: &str,\n result: Result<T, E>,\n) -> Option<T> {\n match result {\n Ok(result) => Some(result),\n Err(err) => {\n self.log(level, source, id, code, &format!("{:?}", err));\n None\n }\n }\n}\nThe concept of logging to a database is not at all original with me\nMany enterprise services log extensively to special database tables.\nBut I think the technique is rarely applied to applications.
\nHopefully this post convinced you to give it a try in the next situation where it makes sense.
\n", "summary": "", "date_published": "2025-01-13T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "software-engineering", "duckdb", "databases", "rust" ], "language": "en" } ] }