While TreeSitter is the future of Emacs major modes, the present remains a bit more murky – not everyone is running a modern Emacs or an Emacs built with TreeSitter support, and many people have asked that “classic” major modes continue to be improved and supported alongside the newer TS-powered modes (in our case – clojure-ts-mode). Your voices have been heard! On Bulgaria’s biggest national holiday (Liberation Day), you can feel liberated from any worries about the future of clojure-mode, as it keeps getting the love and attention that it deserves! Looking at the changelog – 5.22 is one of the biggest releases in the last few years and I hope you’ll enjoy it!¹

Now let me walk you through some of the highlights.

edn-mode Gets Some Love

edn-mode has always been the quiet sibling of clojure-mode – a mode for editing EDN files that was more of an afterthought than a first-class citizen. That changed with 5.21 and the trend continues in 5.22. The mode now has its own dedicated keymap with data-appropriate bindings, meaning it no longer inherits code refactoring commands that make no sense outside of Clojure source files. Indentation has also been corrected – paren lists in EDN are now treated as data (which they are), not as function calls.

Small things, sure, but they add up to a noticeably better experience when you’re editing config files, test fixtures, or any other EDN data.

Font-locking Updated for Clojure 1.12

Font-locking has been updated to reflect Clojure 1.12’s additions – new built-in dynamic variables and core functions are now properly highlighted. The optional clojure-mode-extra-font-locking package covers everything from 1.10 through 1.12, including bundled namespaces and clojure.repl forms.² Some obsolete entries (like specify and specify!) have been cleaned up as well.

On a related note, protocol method docstrings now correctly receive font-lock-doc-face styling, and letfn binding function names get proper font-lock-function-name-face treatment. These are the kind of small inconsistencies that you barely notice until they’re fixed, and then you wonder how you ever lived without them.

Discard Form Styling

A new clojure-discard-face has been added for #_ reader discard forms. By default it inherits from the comment face, so discarded forms visually fade into the background – exactly what you’d expect from code that won’t be read. Of course, you can customize the face to your liking.

Notable Bug Fixes

A few fixes that deserve a special mention:

• clojure-sort-ns no longer corrupts non-sortable forms – previously, sorting a namespace that contained :gen-class could mangle it. That’s fixed now.
• clojure-thread-last-all and line comments – the threading refactoring command was absorbing closing parentheses into line comments. Not anymore.
• clojure-update-ns works again – this one had been quietly broken and is now restored to full functionality.
• clojure-add-arity preserves arglist metadata – when converting from single-arity to multi-arity, metadata on the argument vector is no longer lost.

The Road Ahead

So, what’s actually next for clojure-mode? The short answer is: more of the same. clojure-mode will continue to receive updates, bug fixes, and improvements for the foreseeable future. There is no rush for anyone to switch to clojure-ts-mode, and no plans to deprecate the classic mode anytime soon.

That said, if you’re curious about clojure-ts-mode, its main advantage right now is performance. TreeSitter-based font-locking and indentation are significantly faster than the regex-based approach in clojure-mode. If you’re working with very large Clojure files and noticing sluggishness, it’s worth giving clojure-ts-mode a try. My guess is that most people won’t notice a meaningful difference in everyday editing, but your mileage may vary.

The two modes will coexist for as long as it makes sense. Use whichever one works best for you – they’re both maintained by the same team (yours truly and co) and they both have a bright future ahead of them. At least I hope so!

As usual - big thanks to everyone supporting my Clojure OSS work, especially the members of Clojurists Together! You rock!

That’s all I have for you today. Keep hacking!

But that’s just the start of it. This is the most important release for me since I assumed the project’s leadership and I hope this article will manage to make you agree with my reasoning.

Enough empty words – let me now walk you through the highlights.

A Proper Copilot Client

The single biggest change in this release is the migration from the legacy getCompletions API (reverse-engineered from copilot.vim) to the standard textDocument/inlineCompletion LSP method provided by the official @github/copilot-language-server.

This might sound like a dry and boring internal change, but it’s actually a big deal. copilot.el started its life as a port of copilot.vim – we were essentially reverse-engineering how that plugin talked to the Copilot server and replicating it in Elisp. That worked, but it was fragile and meant we were always playing catch-up with undocumented protocol changes.

Now we speak the official LSP protocol. We send proper textDocument/didOpen, textDocument/didChange, and textDocument/didFocus notifications. We manage workspace folders. We handle server-to-client requests like window/showMessageRequest and window/showDocument. We perform a clean shutdown/exit sequence instead of just killing the process. In short, copilot.el is now a proper Copilot LSP client, not a reverse-engineered hack.

This release, in a way, completes the cycle – from a package born out of reverse engineering copilot.vim to a legitimate Copilot client built on the official API.¹

But wait, there’s (a lot) more!

AI Model Selection

You can now choose which AI model powers your completions via M-x copilot-select-completion-model. The command queries the server for available models on your subscription and lets you pick one interactively. The selection is persisted in copilot-completion-model.

Parentheses Balancer 2.0

The parentheses balancer – the component that post-processes completions in Lisp modes to fix unbalanced delimiters – got a complete rewrite. The old implementation counted parentheses as raw characters, which meant it would “balance” parens inside comments and strings where they shouldn’t be touched. The new implementation uses parse-partial-sexp to understand the actual syntactic structure, so it only fixes genuinely unbalanced delimiters.

Whether the balancer will remain necessary in the long run is an open question – as Copilot’s models get smarter, they produce fewer unbalanced completions. But for now it still catches enough edge cases to earn its keep. You can disable it with (setopt copilot-enable-parentheses-balancer nil) if you want to see how well the raw completions work for you.

Improved Server Communication

Beyond the core API migration, we’ve improved the server communication in several ways:

• Status reporting: didChangeStatus notifications show Copilot’s state (Normal, Warning, Error, Inactive) in the mode-line.
• Progress tracking: $/progress notifications display progress for long-running operations like indexing.
• Request cancellation: stale completion requests are cancelled with $/cancelRequest so the server doesn’t waste cycles on abandoned work.
• User-defined handlers: copilot-on-request and copilot-on-notification let you hook into any server message.
• UTF-16 positions: position offsets now correctly use UTF-16 code units, so emoji and other supplementary-plane characters no longer confuse the server.

Tests and Documentation

This release adds a proper test suite using buttercup. We went from zero tests to over 120, covering everything from URI generation and position calculation to the balancer, overlay management, and server lifecycle. CI now runs across multiple Emacs versions (27.2 through snapshot) and on macOS and Windows in addition to Linux.

The README got a (almost) complete rewrite – it now covers installation for every popular package manager, documents all commands and customization options, includes a protocol coverage table, and has a new FAQ section addressing the most common issues people run into. Plenty of good stuff in it!

This might sound like a lot of effort for not much user-visible payoff, but when I started hacking on the project:

• I really struggled to understand how to make the best use of the package
• The lack of tests made it hard to make significant changes, as every change felt quite risky

Anyways, I hope you’ll enjoy the improved documentation and you’ll have easier time setting up copilot.el.

Bug Fixes

Too many to list individually, but here are some highlights:

• copilot-complete now works without copilot-mode enabled (#450)
• Partial accept-by-word no longer loses trailing text when the server uses a replacement range (#448)
• JSON-RPC requests send an empty object instead of omitting params, fixing authentication on newer server versions (#445)
• The company-mode dependency is gone – no more void-function company--active-p errors (#243)
• The completion overlay plays nice with Emacs 30’s completion-preview-mode (#377)

See the full changelog for the complete list.

What’s Next

There’s still plenty of work ahead. We have three big feature branches in the pipeline, all open as PRs and ready for adventurous testers:

• Next Edit Suggestions (NES) – proactive edit suggestions that appear at your cursor based on your recent editing patterns, similar to the NES feature in VS Code.
• Copilot Chat – interactive chat with Copilot, right inside Emacs.
• Native installation without Node.js – use the pre-built Copilot language server binary instead of requiring a Node.js installation.

If any of these sound interesting to you, please give them a spin and report back. Your feedback is what shapes the next release.

Thanks

A big thanks to Paul Nelson for contributing several partial acceptance commands and the overlay clearing improvements – those are some of the most user-visible quality-of-life changes in this release. Thanks also to everyone who filed detailed bug reports and tested fixes – you know who you are, and this release wouldn’t be the same without you.

That’s all I have for you today. Keep hacking!

In fact, I’d say it’s the biggest and most important Flycheck release since I became the project’s primary maintainer a couple of years ago. For a while I had mostly gone with the flow (adding/improving linters and fixing bugs), but by now I feel more confident to make bigger and bolder changes.

Anyways, you’re probably interested to learn more about Flycheck 36, so let me walk you through the highlights.

New Checkers

We’ve added a couple of new checkers:

• javascript-oxlint – a checker using oxlint, the blazing-fast JavaScript/TypeScript linter written in Rust. If you haven’t tried oxlint yet, you really should – it’s impressively fast.
• org-lint – an Org mode checker using Emacs’ built-in org-lint. It detects issues like invalid links, dead links, and duplicate IDs. This one went through a rewrite mid-cycle to run in the current Emacs process instead of a --batch subprocess, which eliminates false warnings for source block languages provided by external packages.

Security

We’ve mitigated CVE-2024-53920 in the emacs-lisp checker by disabling local eval directives and restricting local variables to safe values during byte-compilation. This was an important fix – byte-compilation involves macro expansion, which means untrusted Elisp files could potentially execute arbitrary code during syntax checking. A follow-up fix for Emacs 30+ using trusted-content is in the works.¹

ShellCheck Improvements

The sh-shellcheck checker got some love in this release:

• New flycheck-shellcheck-infer-shell option to let ShellCheck auto-detect the shell dialect
• flycheck-shellcheck-args for passing extra command-line arguments
• flycheck-shellcheck-enabled-checks to enable optional checks via --enable

Quality-of-Life Improvements

A bunch of small but welcome improvements:

• flycheck-command-map now works as a prefix command with keymap-set and friends – no more need for the define-key workaround
• Buffers are automatically re-checked after revert-buffer, so global-auto-revert-mode users get up-to-date diagnostics without manual intervention
• The mode-line indicator now includes info-level errors (format: errors|warnings|infos)
• The python-ruff checker got an error explainer, so you can quickly look up what a rule means
• Pyright rule names (like reportGeneralTypeIssues) now show up as error IDs

Bug Fixes

This release includes a massive number of bug fixes – over 25 of them. Some highlights:

• Fixed error pattern matching in non-English locales by forcing LC_ALL=C for checker processes
• Fixed the rust checker on Windows (no more /dev/null errors)
• Fixed flycheck-navigation-minimum-level being ignored in some cases
• Fixed compilation warnings on Emacs 30
• Fixed several issues with the python-ruff, tex-chktex, emacs-lisp, and awk-gawk checkers

Check the release notes for the full list.

Spring Cleaning

We’ve removed a number of checkers for tools that have been dead or deprecated for years:

• typescript-tslint (deprecated since 2019, use ESLint with typescript-eslint)
• sass, scss, sass/scss-sass-lint, scss-lint (Ruby Sass is dead, use Stylelint)
• eruby-erubis, eruby-ruumba (Erubis abandoned since 2011)
• css-csslint (abandoned since ~2017, use Stylelint)
• coffee-coffeelint, protobuf-prototool, nix-linter

If you’re still using any of these tools… well, it’s probably time to upgrade!

Documentation Site

flycheck.org got a visual refresh – we’ve switched from the old Alabaster Sphinx theme to Furo, which gives the site a clean, modern look with proper dark mode support and better mobile responsiveness. We’ve also added prominent GitHub links at the top of every page, making it easier to jump to the source or file issues.

I hate the old theme, so this one is a major win in my book! I’ve also took some effort to make sure the documentation accurately reflects the current state of project, as here and there things were out-of-sync.

Flycheck is Alive and Well

I know that many people wrote Flycheck off when Flymake got tight integration with Eglot (they share a maintainer, after all), and I understand why – it’s hard to compete with something that’s built into Emacs and “just works” out of the box. But Flycheck continues to advance and evolve. We have excellent Eglot support via flycheck-eglot, a massive library of built-in checkers,² and a feature set that Flymake still can’t match in many areas.

More importantly, Flycheck’s biggest strength has always been that it’s community-driven and easy to contribute to. Adding a new checker is straightforward, PRs get reviewed quickly, and you don’t have to go through the FSF copyright assignment process. That matters, and it’s why the project keeps growing.

Epilogue

I’m pretty happy with this release. The combination of new features, security hardening, and cleanup of dead checkers puts Flycheck in a much healthier state. Looking ahead to Flycheck 37, I’m thinking about tree-sitter integration, more new checkers (OCaml and Swift are already in the pipeline), and potentially dropping support for Emacs 27 so we can take advantage of newer APIs. The plan is still hazy, but it’s starting to take some shape…

As always, contributions are very welcome! If there’s a lint tool you use that Flycheck doesn’t support yet, PRs are the fastest way to make it happen. As mentioned above, Flycheck’s biggest strength remains its community, and are the community.

That’s all I have for you today. Keep hacking!

Let me walk you through the highlights.

Native Code Block Highlighting

This was the flagship feature I teased at the end of my 0.7 announcement, and it’s easily the most impactful change in this release. Source code blocks now get fontified using the appropriate language major mode – Ruby code looks like it does in ruby-mode, Python code looks like python-mode, and so on.

The feature is enabled out-of-the-box with a sensible default – only code blocks of 5000 characters or fewer are fontified natively, to avoid performance issues with very large blocks. You can set adoc-fontify-code-blocks-natively to t if you want unlimited fontification, or to nil to disable it entirely.

Inline Image Preview

You can now see images directly in your buffer instead of just staring at image::path/to/screenshot.png[]. Image previews are displayed automatically when you open a file (controlled by adoc-display-images), and you can toggle them on and off with adoc-toggle-images.

Right-clicking on an image link gives you a context menu to generate or remove the preview for that specific image. Remote images are supported too – set adoc-display-remote-images to t if you want to fetch and display images from URLs.

Navigation

A couple of welcome additions here:

• adoc-follow-thing-at-point (bound to C-c C-o and M-.) lets you follow URLs (opens in browser), include:: macros (opens the referenced file), and cross-references (jumps to the anchor). It’s one of those features that once you have it, you can’t imagine living without.
• adoc-goto-ref-label (C-c C-a) jumps to an anchor by ID, with a smart default pulled from the xref at point.
• The imenu index is now hierarchical – headings are nested under their parent sections, which makes navigating large documents much more pleasant.

Asciidoctor Inline Macros

adoc-mode now highlights Asciidoctor-specific inline macros like kbd:[], btn:[], menu:[], pass:[], stem:[], latexmath:[], and asciimath:[]. These were previously ignored by font-lock and would just blend in with regular text.

I’m a heavy user of Antora, and I really appreciate this one.

Bug Fixes Galore

This release squashes a lot of long-standing bugs:

• Fixed a noticeable lag when typing in code blocks (this one was particularly annoying).
• Fixed an Emacs hang caused by escaped curly braces in attribute references.
• Fixed multiline font-lock for inline formatting (bold, italic, etc. spanning multiple lines).
• Prevented auto-fill-mode from breaking section title lines.
• Prevented Flyspell from generating overlays for links and other non-prose regions.
• Fixed table delimiter highlighting (was limited to 4 columns).
• Fixed unconstrained monospace delimiters.
• And quite a few more – check the release notes for the full list.

Internal Improvements

I’ve also spent some time cleaning up the internals:

• The minimum Emacs version is now 28.1 (up from 26).
• Deprecated AsciiDoc backtick-apostrophe quote styles (not supported by Asciidoctor) have been removed.
• Two-line (Setext) titles are now disabled by default, since Asciidoctor has deprecated them.
• Image display and tempo templates have been extracted into separate files (adoc-mode-image.el and adoc-mode-tempo.el), making the main file more manageable.

The codebase is in much better shape than it was 3 years ago, but there’s still some room for improvement.

One More Thing: asciidoc-mode

I did eventually act on that idea I mentioned in my 0.7 post – I created asciidoc-mode, a tree-sitter-based AsciiDoc major mode for Emacs 30.1+. It’s a very different beast from adoc-mode – focused on the essentials (highlighting, navigation, folding) and leveraging tree-sitter for accurate and performant parsing.

If you’re on Emacs 30+ and prefer a lighter-weight editing experience, asciidoc-mode might be a good fit. If you want the full kitchen sink – image previews, tempo templates, native code block highlighting – adoc-mode is still the way to go. Both packages are maintained by me and they complement each other nicely.

Epilogue

adoc-mode 0.8 is available on NonGNU ELPA, MELPA Stable, and MELPA. Upgrading is just a M-x package-install away.

I’d like to thank everyone who contributed bug reports, pull requests, and feedback over the past 3 years. Open-source is a team sport and this release wouldn’t have happened without you. You rock!

That’s all I have for you today. Keep hacking! And keep writing… in AsciiDoc, of course!

So, what’s new?

Probably the highlight is the ability to pre-configure default values for dynamic variables in all nREPL servers that are launched locally (either per project or system-wide). The most useful application for this would be to enable *warn-on-reflection* in all REPLs. To achieve this, create ~/.nrepl/nrepl.edn with this content:

{:dynamic-vars {clojure.core/*warn-on-reflection* true}}

Now, any nREPL server started from any IDE will have *warn-on-reflection* enabled.

$ clojure -Sdeps "{:deps {nrepl/nrepl {:mvn/version \"1.4.0\"}}}" -m nrepl.cmdline -i
user=> #(.a %)
Reflection warning, NO_SOURCE_PATH:1:2 - reference to field a can't be resolved.

Note: nREPL doesn’t support directly XDG_CONFIG_HOME yet, but you can easily override the default global config directory (~/.nrepl) with NREPL_CONFIG_DIR.

Another new feature is the ability to specify :client-name and :client-version when creating a new nREPL session with the clone operator. This allows collecting information about the clients used, which some organizations might find useful. (I know Nubank are making use of this already)

One notable change in nREPL 1.4 is the removal of support for Clojure 1.7. Clojure 1.7 was released way back in 2015 and I doubt anyone is using it these days, but we try to be extra conservative with the supported Clojure versions and this is only the second time nREPL’s runtime requirements were bumped in the 7 and a half years I’ve been the maintainer of the project. (early on I bumped the required Clojure from 1.2 to 1.7)

As usual the release features also small bug-fixes and internal improvements. One such improvement was the introduction of matcher-combinators in our test suite. (which was the main motivation to bid farewell to Clojure 1.7) You can check out the release note for a complete list of changes.

That’s all I have for you today. I hope we’ll have more exciting nREPL news to share by nREPL’s “official” birthday, October 8th.¹ Big thanks to everyone who has contributed to this release and to all the people supporting my Clojure OSS work! In the REPL we trust! Keep hacking!

# regular Ruby code
Markdown.render <<~MARKDOWN
  # Hello there

  This is a Markdown file. See?

  1. This is a list
  2. With items
  3. And more items
MARKDOWN

# proposed syntax
Markdown.render <<~
  # Hello there

  This is a Markdown file. See?

  1. This is a list
  2. With items
  3. And more items
~>>

Even though this proposal didn’t make it, you can get pretty close by just using _ as your heredoc delimiter:

Markdown.render <<~_
  # Hello there

  This is a Markdown file. See?

  1. This is a list
  2. With items
  3. And more items
_

Looks a bit weird, but it gets the job done.

That’s all I have for you today. Keep Ruby weird!

This is a huge release that has an equal amount of new features, improvements to the existing ones, and also trimming down some capabilities in the name of improved efficiency and maintainability.

I’m too lazy to write a long release announcement today, so I’ll just highlight the most important aspects of CIDER 1.18 and how they fit our broader vision for the future of CIDER.

Let’s go!

Reduced surface area

• CIDER 1.18 dropped support for Boot and Emacs 26. Boot development has been frozen for many years, and it’s now a long past due to migrate to other build tools.
• CIDER no longer bundles Puget dependency. Puget is still supported as a pretty-printer for all CIDER output, but you need to add it to dependencies explicitly.
• Haystack is no longer included. With it, we removed some largely unknown facilities for parsing printed stacktraces and presenting them inside *cider-error* buffer.
• Replaced the outdated thunknyc/profile dependency with a homegrown implementation in Orchard.

I’m happy that we continue on the path of reducing the 3rd-party dependencies in cider-nrepl and rely more and more on functionality optimized for our use-cases, living in Orchard. Looking back, at some of the decisions I’ve taken in the past - I sometimes regret going overboard with the feature set (we have so many features today, that even I occasionally forget about some of them) and the dependencies needed to provide certain features. Going forward I hope to gradually reduce the feature set and the dependencies by:

• removing features that are rarely used
• making certain dependencies optional (instead of bundling everything with cider-nrepl)

Inspector

Our beloved inspector got a lot better!

• New analytics module (orchard#329) (shows you some useful info about the data you’re inspecting)
• Table view mode (orchard#331) (I think you’ll totally love this!)
• Pretty-printing mode (#3813) and a command to separately pretty-print the currently inspected value (#3810)

That’s how the analytics and the table view look:

Cool stuff!

Error handling

• In exchange for removing Haystack, CIDER now allows jumping to munged Clojure functions and Java methods anywhere from the source buffers or the REPL. This means that you can press M-. on printed frames like clojure.core$with_bindings_STAR_.doInvoke or clojure.lang.Compiler$InvokeExpr.eval within the exception, and CIDER will take you there.
• Stacktrace processing has been greatly simplified and optimized. You may notice that the delay between an exception occuring and *cider-error* buffer popping up disappeared, especially in big projects.
• Ex-data is now always displayed for each exception cause which has it, albeit in an abbreviated form. You can click or press RET (a.k.a. Enter) on to open it in the inspector (#3807).

I’m guessing some of those changes might be considered slightly controversial (especially the last item), but I think they are a bit step towards simplicity and more internal consistency.

Misc features

• Completions got better with priority-based sorting and fuzzy-matching enabled by default (so you can complete unimported short classnames, and things like cji, rkv, etc.)
• The middleware that powers dynamic font-locking was made tremendously faster and more memory efficient on both Clojure and Emacs sides of CIDER. Again, this effect would be more pronounced in large codebases. This optimization is well overdue, and perhaps it will encourage more editors to embrace the track-state middleware, as I think it’s one of the coolest aspects of CIDER.
• Added support for dynamic indentation in clojure-ts-mode (#3803)

Side note - I’ve been spending a lot of time on clojure-ts-mode lately and it’s shaping up pretty nicely. If you’re happy with clojure-mode there’s no real reason to switch yet, but if you’ve experienced performance issues with font-locking on indentation you may want to check out clojure-ts-mode.

I’m happy to report that I’ve also finally started to clean up the numerous compilation warnings introduced in Emacs 29. Most of the meaningful problems are now addressed and the bulk of the remaining work is related to a new rule for quoting ' in docstrings, which is annoying but not particularly important.

Epilogue

This release is named “Athens” for a reason - Athens is one of the greatest cities in the world¹ and I think that’s one of the greatest CIDER releases!

For me that’s one of the most important CIDER releases in the past couple of years, if not the most important. We’ve tackled a lot of long-standing problems and we’ve started to simplify the internals of CIDER. The feedback we got from the “State of CIDER” survey really helped us with some of the decisions - stay tuned for a detailed analysis of all the feedback we’ve collected there.

As usual - a huge shoutout to all the contributors and “Clojurists Together” for their support! A special thanks to Sashko Yakushev, who has been firing on all cylinders lately, and was once again the driving force behind most of the work in this release. You’re a legend, buddy!

Sadly, the amount of financial support CIDER is receiving has dropped a lot in the past 3 years (by about 50%). I hope the situation will change, as solid and predictable financial backing is the only way to ensure the long-term future of CIDER and friends.

This is all I have for you today. I hope you’ll have as much fun using it, as we had developing it! Keep hacking!

• The cache for all projects is stored in the same file, which means that often you need to load information that you don’t really need. Also - storing all the cache data in the same file means that there’s a higher chance that the cache would get corrupted for one reason or another.
• When caching is enabled, Projectile loads the data from the cache file when projectile-mode is enabled. That causes two problems:
  • The mode’s init is slower than it could be
  • The cache is not loaded unless you enable projectile-mode

I’m happy to report that I finally got to doing something about the problems listed above!¹ In a nutshell:

• Now each project gets its own cache file in the root of the project’s directory. (named .projectile-cache.eld by default)² I’ve opted for this approach over something like .emacs.d/cache, as it avoids the need to hash the project paths. (so cache files could be mapped to project root paths) I might change this behavior in the future, depending on the user feedback I receive.
• The cache is read from disk only when you trigger projectile-find-file for the first time.
• Both reading and writing the cache file is much faster, as you’re only reading/writing the cache file for the currently visited project.

This means that Projectile’s loading time is much snappier if you’re a heavy cache user.

I’ve also addressed a common problem for people using Projectile over TRAMP - that writing to the cache file can be quite slow there if you’re working on huge project. The writing of the cache when individual files are added to it is now deferred using run-with-idle-timer³, which means that you’ll never experience a lock-up right after creating a new file within a project. Perhaps even more importantly - I’ve introduced the concept of “transient” cache. Basically it lives only in memory and is not persisted to a file.⁴ Going forward this is going to be the default caching behavior in Projectile, as I think it offers a better blend of performance and convenience. To enable the traditional “persistent” cache you’ll have to add this to your config:

(setq projectile-enable-caching 'persistent)

To make things better I’ve also reorganized how known projects are initialized, so now no IO operations happen during Projectile’s initialization and it’s lightning fast! To illustrate this with a bit of code:

;; projectile-mode init before
;;
;; initialize the projects cache if needed
(unless projectile-projects-cache
  (setq projectile-projects-cache
        (or (projectile-unserialize projectile-cache-file)
            (make-hash-table :test 'equal))))
(unless projectile-projects-cache-time
  (setq projectile-projects-cache-time
        (make-hash-table :test 'equal)))
;; load the known projects
(projectile-load-known-projects)
;; update the list of known projects
(projectile--cleanup-known-projects)
(when projectile-auto-discover
  (projectile-discover-projects-in-search-path))

;; projectile-mode init now
;;
;; nothing IO-related to show here

Last week I’ve started to prepare for the release of Projectile 2.9, which will bring a lot of bug fixes and improvements. I know that a lot of people have probably written off Projectile by now, but I still believe that it has a place in the broader Emacs ecosystem (as a community-driven and more feature-rich alternative of project.el) and the best is yet to come!

That’s all I have for you today. Keep hacking!

P.S. I’d appreciate it if more Projectile users experimented with the current snapshot package, before Projectile 2.9 gets officially released.

There’s an exciting new feature waiting for you in the latest CIDER MELPA build. After updating, try turning on the new variable cider-download-java-sources (M-x customize-variable cider-download-java-sources and then toggle to enable it). Now CIDER will download the Java sources of third-party libraries for Java classes when:

• you request documentation for a class or a method (C-c C-d C-d)
• you jump to some definition (M-.) within a Java class

Note that eldoc won’t trigger the auto-download of Java sources, as we felt this might be harmful to the user experience.

This feature works without enrich-classpath.² The auto-downloading works for both tools.deps and Leiningen-based projects. In both cases, it starts a subprocess of either clojure or lein binary (this is the same approach that Clojure’s 1.12 add-lib utilizes).

And that’s it! The new approach is so seamless that it feels a bit like magic.

This approach should work well for most cases, but it’s not perfect. You might have problems downloading the sources of dependencies that are not public (i.e. they live in a private repo), and the credentials are non-global but under some specific alias/profile that you start REPL with. If this happens to you, please report it; but we suspect such cases would be rare. The download usually takes up to a few seconds, and then the downloaded artifact will be reused by all projects. If a download failed (most often, because the library didn’t publish the -sources.jar artifact to Maven), CIDER will not attempt to download it again until the REPL restarts. Try it out in any project by jumping to clojure.lang.RT/toArray or bringing up the docs for clojure.lang.PersistentArrayMap.

Our plan right now is to have this new feature be disabled by default in CIDER 1.17 (the next stable release), so we can gather some user feedback before enabling it by default in CIDER 1.18. We’d really appreciate your help in testing and polishing the new functionality and we’re looking forward to hear if it’s working well for you!

We also hope that other Clojure editors that use cider-nrepl internally (think Calva, iced-vim, etc) will enable the new functionality soon as well.

That’s all I have for you today! Keep hacking!

P.S. The State of CIDER 2024 survey is still open and it’d be great if you took a moment to fill it in!

It’s been a while since the first and only “State of CIDER” survey.¹ Right after it happened in the end of 2019, the world went to shit and I kind of forgot about my intent to do the survey annually. 5 years later, it’s high time we get back on track!

CIDER has changed a lot in the past 5 years. nREPL has changed a lot. The development tooling Clojure ecosystem has changed a lot. Even Emacs has changed a lot. I’m guessing your usage of CIDER has changed a lot as well. If you’re still using Clojure and CIDER today, that is…

You can find the new survey here. We’ve made several updates to the questions - most notably there’s now a question about how frequently are you using certain CIDER features.

I’ve been thinking a lot lately that perhaps we went overboard with the feature-set in CIDER and that it might be prudent to trim the fat in CIDER 2.0, but we need data, so we can accurately know what’s being used and what’s not. I’ve also been thinking that mentioning many of the less known features in the survey might provoke some people to try them out. We’ll see.

There are other important questions that I like to get answers for, e.g.:

• Can we drop support for Emacs 26 (and maybe even Emacs 27)?
• Can we drop support for Java 8?²
• Do people think that CIDER improved in the last year?
• How often are people upgrading their CIDER installation?
• What problems are users encountering? What would they like to see added/changed/improved?
• Are people willing to support the project in one way or another?³
• Is Figwheel still a thing in ClojureScript?

Your responses will also be instrumental in shaping up the roadmap for CIDER 2.0.

Last time around we got 545 responses and I hope this time around we’ll do a bit better, as more responses mean that the data we got is more accurate. The new survey is off to a pretty slow start - less than 200 responses in the first week. It will likely stay open till the end of January, so I hope we are going to get 500+ responses in total this around time as well.

Thanks for taking the time to fill in the survey! This means a lot to me and our team! I’d really appreciate it if you shared the survey on your social media profiles, so more people see it and take part in it. Let’s make CIDER better together!

That’s all I have for you today. Keep hacking!