It’s been a while since Flycheck 35, but Flycheck 36 is finally here! This is a pretty big release with a lot of new features, bug fixes, and some much-needed cleanup of legacy checkers. In fact, I... Read more It’s been a while since Flycheck 35, but Flycheck 36 is finally here! This is a pretty big release with a lot of new features, bug fixes, and some much-needed cleanup of legacy checkers. 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.1 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,2 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! See https://github.com/flycheck/flycheck/pull/2160. ↩ See https://www.flycheck.org/en/latest/languages.html for the full list. ↩ Show less

Just had a really clever idea, but because I now work with 5 instances of Claude instead of actual humans—and knowing they'll all forget how smart I just was in a median 125k tokens from now—it fee... Read more Just had a really clever idea, but because I now work with 5 instances of Claude instead of actual humans—and knowing they'll all forget how smart I just was in a median 125k tokens from now—it feels kind of hollow. So FYI, I just had a great fucking idea. Feelin' cute. Show less

Almost 3 years after the rebirth of adoc-mode I’m happy to announce that adoc-mode 0.8 is finally out! This is a massive release that has been cooking for way too long, but I think it was worth the... Read more Almost 3 years after the rebirth of adoc-mode I’m happy to announce that adoc-mode 0.8 is finally out! This is a massive release that has been cooking for way too long, but I think it was worth the wait. 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! Show less

I got into a discussion thread on Bluesky where the use of Teams/ Outlook/ Sharepoint and Calendar was being discussed. One of the questions that got asked was about sharing and delegating calendar... Read more I got into a discussion thread on Bluesky where the use of Teams/ Outlook/ Sharepoint and Calendar was being discussed. One of the questions that got asked was about sharing and delegating calendars in Outlook. I was going to reply directly when I realised that it might be easier to write up a short post and share the link rather than post all the screenshots into the chat thread. Outlook lets you share any calendar to others in your organisation and set what they can do with it. I normally use the online interface for the calendar, so the screenshots below are from there rather than the Windows desktop client. Head on over to the online portal at: https://outlook.office.com/calendar/view/workweek and it will ask you to log in and take you to the working week view of your calendar. On the left, half way down, you’ll see the list of calendars. You can easily share any calendar listed under My calendars there by right clicking on the 3 dots menu (…) that shows up when you hover the mouse around the calendar you want to share, and selecting “Sharing and permissions”. This brings up the current sharing setup and allows you to see who has access, and of what kind. At a minimum, you probably want to have a basic setting to let everyone in your organisation see when you’re busy (so that they know if you’re not available at a time when they want to meet you). You can enter an email address and it will ask you what permissions you want to allow them. Most of the options are obvious enough: Can view when I’m busy: this shows them no details, just that you have something in your calendar at that time. Can view titles and locations Can view all details Can edit: this lets them make changes Delegate: this is a special setting, described below With these, you have some flexibility in how your calendar is visible to and handled by others. The special setup is Delegate which allows them to act on your behalf. The description is as below. When assigning delegates, you can allow all calendar invitations to be sent to them also in addition to you – this helps them manage your calendar better. Also, you can let them see the details of private events if they are also helping you with personal stuff, e.g., making sure that your kid’s recital is in the calendar. Hope this helps! I’d suggest that if these look like they work for you, find someone you trust in the organisation and try the settings together with them to make sure that you understand these before you start using them en masse. If you’ve seen earlier posts, you’ll know that I am quite excited by using calendars, etc. for managing time and travel better. Earlier posts are here: Part 1: Tips for travel, calendars and time zones Part 2: You’re not using your calendar enough Feel free to connect or share the post (you can tag me as @onghu on X or on Mastodon as @onghu@ruby.social or @onghu.com on Bluesky to discuss more). Show less

It's been a weird experience enabling turbocommit on my repos and watching it do a better job titling commits than I ever do. That it preserves my agent transcripts in the commit message alongside ... Read more It's been a weird experience enabling turbocommit on my repos and watching it do a better job titling commits than I ever do. That it preserves my agent transcripts in the commit message alongside code changes is really nice! https://github.com/searlsco/turbocommit Show less

Creating an AI blog editor with Claude Skills—like having a code reviewer for your writing when you don't have a human editor.

Originally appeared on Giant Robots Smashing Into Other Giant Robots.Coming from a JavaScript background, I’m used to handling permissions with simple if statements. Maybe a global “roles” object, ... Read more Originally appeared on Giant Robots Smashing Into Other Giant Robots.Coming from a JavaScript background, I’m used to handling permissions with simple if statements. Maybe a global “roles” object, or a quick check on the frontend that hides buttons if the user isn’t an admin. Working with Rails and Pundit forced me to think differently about authorization as a system. Understanding the request flow and where helper methods come from would’ve saved me a lot of time upfront. Philosophy of Pundit At its core, a Pundit Policy answers the question: Can \$USER take \$ACTION on \$RESOURCE? A Policy Scope answers: Scope down \$COLLECTION to only the ones \$USER can access. These two layers keep authorization clean and explicit: What belongs in… Show less

Originally appeared on kukicola.io - Software engineer writing about backend, infrastructure, AI, and open source..In just a few months, AI coding assistants went from autocompleting lines to shipp... Read more Originally appeared on kukicola.io - Software engineer writing about backend, infrastructure, AI, and open source..In just a few months, AI coding assistants went from autocompleting lines to shipping entire features in minutes. Everyone who knows how to utilize AI can produce several times more code than before. However, AI is not perfect and we, as humans, still need to review the code it produces. Reviewing someone else’s code is not the most exciting part of the job - it’s just boring. With thousands of lines of code, it’s easy to unconsciously skim through them and miss the important parts. Let’s figure out how we can make the process less painful and time-consuming. The review problem When writing code yourself, you have a mental model of what the code does. Unfortunately, AI-generated code… Show less

I’ve been preparing a talk about AI-assisted development and spent a lot of time reading what developers are saying online, in meetups, in conference hallways. …