7 files changed, 335 insertions, 17 deletions
diff --git a/2026/talks/anju.md b/2026/talks/anju.md
new file mode 100644
index 00000000..033837a5
--- /dev/null
+++ b/2026/talks/anju.md
@@ -0,0 +1,26 @@
+[[!meta title="Revisiting Emacs Mouse Interactions with Anju"]]
+[[!meta copyright="Copyright &copy; 2026 Charles Y. Choi"]]
+[[!inline pages="internal(2026/info/anju-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Revisiting Emacs Mouse Interactions with Anju
+Charles Y. Choi - IRC: kickingvegas, Website: <http://yummymelon.com/devnull/> Mastodon: @kickingvegas@sfba.social, <mailto:kickingvegas@gmail.com>
+
+[[!inline pages="internal(2026/info/anju-before)" raw="yes"]]
+
+Anju (안주) is a project to align mouse interactions in Emacs with contemporary expectations in 2026. Effort towards this alignment is made in the areas of context-sensitive menus, de-emphasis of middle mouse button usage, support for direct manipulation, and re-organization of the main menu bar. The features offered by Anju are opinionated, but avoids unconventional behavior. Anju aspires to bring a calmer mouse experience to Emacs.
+
+This talk will present an overview of Anju (<https://kickingvegas.github.io/anju/>), describing its design decisions and implementation.
+
+About the speaker: Charles Choi is a Computer Engineer and Emacs enthusiast.
+
+
+
+[[!inline pages="internal(2026/info/anju-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/anju-nav)" raw="yes"]]
+
+
diff --git a/2026/talks/bible.md b/2026/talks/bible.md
new file mode 100644
index 00000000..cf50fbf1
--- /dev/null
+++ b/2026/talks/bible.md
@@ -0,0 +1,64 @@
+[[!meta title="bible-gateway: A Two-Edged Sword in Emacs"]]
+[[!meta copyright="Copyright &copy; 2026 Kristjon Ciko"]]
+[[!inline pages="internal(2026/info/bible-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# bible-gateway: A Two-Edged Sword in Emacs
+Kristjon Ciko (he/him) - <mailto:kristjoc@uio.no>
+
+[[!inline pages="internal(2026/info/bible-before)" raw="yes"]]
+
+`bible-gateway` is a simple Emacs package that fetches content from
+<https://BibleGateway.com> — verses, passages, search results — directly
+into Emacs.
+
+Unlike other approaches to reading Bible text in Emacs, it doesn't
+require installing extra modules, downloading zip files of Bible text,
+maintaining a local database, or signing up for an API key or
+subscription. Everything happens over plain HTTP/HTML scraping. It
+stores nothing on disk except a small cache for the verse of the day, so
+Emacs doesn't refetch it on every startup. It supports 14 Bible versions
+in different languages that are in the public domain, all fetched live,
+with no per-language downloads.
+
+In this short talk, I'll go through the main features with quick demos:
+
+-   Verse of the day, usable as an emacs-dashboard footer or a `*scratch*` buffer message
+
+-   Insert a Bible passage at point
+
+-   Read a passage in a dedicated buffer, with n/p verse-by-verse navigation
+
+-   Listen to a Bible chapter as audio, opened in the browser
+
+-   Search the Bible by keyword, with clickable, paginated results
+
+-   Follow a daily reading plan from a CSV file, with automatic progress tracking
+
+-   Compare two Bible translations side by side in one window
+
+-   Memorise verses using a touch-typing practice mode with live feedback
+
+-   Switch between the 14 supported Bible versions/languages
+
+About the speaker:
+
+I am a postdoc at the University of Oslo, working on networking,
+transport protocols, and Wi-Fi. I have been using Emacs since 2020, and
+I now use it for nearly everything — email, Zulip, org-mode, LaTeX, and
+coding in C/C++, Python, and various scripting languages. I initially
+built the bible-gateway package to show the verse of the day in the
+emacs-dashboard footer. Over time it grew into a fuller toolkit for
+daily Bible reading, preparing devotions, and memorising Scripture — all
+without leaving Emacs.
+
+
+
+[[!inline pages="internal(2026/info/bible-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/bible-nav)" raw="yes"]]
+
+
diff --git a/2026/talks/bone.md b/2026/talks/bone.md
new file mode 100644
index 00000000..06e67545
--- /dev/null
+++ b/2026/talks/bone.md
@@ -0,0 +1,74 @@
+[[!meta title="BONE and gnaw.el: tracking what matters"]]
+[[!meta copyright="Copyright &copy; 2026 Bastien Guerry"]]
+[[!inline pages="internal(2026/info/bone-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# BONE and gnaw.el: tracking what matters
+Bastien Guerry (he) - IRC: bzg, <https://bzg.fr>, <mailto:bzg@bzg.fr>
+
+[[!inline pages="internal(2026/info/bone-before)" raw="yes"]]
+
+Most free software projects use three communication channels: one for
+general feedback, one for bug reports, and one for contributions.
+Projects that use patches instead of pull/merge requests (e.g. Emacs)
+can reduce this to two channels: a discussion list and a bug tracker.
+Some opinionated projects (e.g. Org mode) use only one channel: a
+mailing list for general discussions, bug reports and patches. This
+makes it easy for everyone to track everything. However, this requires
+a tool to help filter all the input. The Org mode tracker uses BONE
+for this filtering, and Org mode contributors can use gnaw.el as a
+BONE client.
+
+BONE (Backlog Of Notable Emails) is a bug tracker written in Clojure
+that watches a project's mailing list. An email whose subject starts
+with [BUG], [PATCH] or [FR] becomes a report. Replies update it with a
+small, fixed vocabulary: "Confirmed.", "Acked.", "Owned.", "Closed.",
+plus the usual review trailers like Reviewed-by:. Nobody creates an
+account, nobody fills a form, nobody leaves their mail client. The
+mailbox stays the single source of truth: the tracker database can be
+rebuilt from the archive at any time. BONE then exports the reports as
+static HTML, RSS, Org and, most importantly, plain reports.json files
+that anyone can fetch and reuse.
+
+gnaw.el is the Emacs client for BONE. M-x gnaw opens a report browser
+listing the bugs, patches and feature requests of the sources you
+follow, across projects. From that buffer you can search reports, read
+the underlying emails in Gnus, notmuch or mu4e, view and apply patches
+directly into a local git repository, open attachments, and organize
+your own work with local sticky and dismiss marks.
+
+The talk will:
+
+-   show BONE in action on a real mailing list, from the tagged email to
+    the exported reports;
+-   demo gnaw.el: browsing, searching, reading, applying a patch, all
+    from Emacs;
+-   discuss the pros and cons of using this tool for Org mode.
+
+The audience is anyone who maintains or contributes to a project
+through a mailing list, anyone who is tired of forge accounts, and
+anyone curious about what a tracker looks like when it is derived from
+the conversation instead of replacing it.
+
+Links:
+
+-   [BONE - Reports - Org mode ML](https://tracker.orgmode.org)
+-   BONE: <https://codeberg.org/bzg/bone>
+-   gnaw.el: <https://codeberg.org/bzg/gnaw.el>
+-   The essay behind the idea:
+    <https://bzg.fr/en/notes/the-issue-with-issue-trackers/>
+
+About the speaker:
+
+Bastien Guerry has been maintaining Org mode from 2011 until 2025.
+
+
+
+[[!inline pages="internal(2026/info/bone-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/bone-nav)" raw="yes"]]
+
+
diff --git a/2026/talks/hutch.md b/2026/talks/hutch.md
new file mode 100644
index 00000000..aa8b1e3a
--- /dev/null
+++ b/2026/talks/hutch.md
@@ -0,0 +1,61 @@
+[[!meta title="hutch: code reviews for the mildly disenfranchised"]]
+[[!meta copyright="Copyright &copy; 2026 Akshay Gupta"]]
+[[!inline pages="internal(2026/info/hutch-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# hutch: code reviews for the mildly disenfranchised
+Akshay Gupta (he/him) - Pronunciation: "UCK-shay", IRC: kitallis, Bluesky: repartee.party  Homepage: <https://kitallis.in>, <mailto:mail@kitallis.in>
+
+[[!inline pages="internal(2026/info/hutch-before)" raw="yes"]]
+
+We're here today, roughly 500 days <https://en.wikipedia.org/wiki/List_of_large_language_models#2025> in, and coding agents are genuinely more productive than, previously, instructed <https://www.youtube.com/watch?v=U_cSLPv34xk>. They are now driving much of our daily work, helping us organize, process information and be more useful overall, and, with this brainwave of an opening, I present yet another attempt at wedging large languages, agents, coding harnesses etcetera inside our beloved buffers, or something.
+
+But hopefully, an unseemly angle to consider, first.
+
+I continue to hand-write and often, hand-commit code. I prefer the pedagogical aspect of AI more than the task completing automaton aspects. The latter has driven all sorts of explosion of tooling around not just writing, but reviewing code too. Like review agents jumping in, before your colleagues do, and plopping gobs of logorrhea across twenty pull requests before you have had a chance to wake up and look at your phone. This works, sometimes, for some people. But if you're like me, you still have people looking at code before they are deployed to users, and for that, it's overall better if you respect those people and their time.
+
+This is where hutch slides in.
+
+hutch <https://github.com/adjaecent/magit-hutch> is a Magit-induced, buffer-local interface over LLM review output. Instead of the review living on code-forges as comments for everyone to see, it appears patch-shaped (usually) within Magit's transient blocks and can be triaged and applied directly within emacs, **before** you commit and push.
+
+Here's an example workflow:
+
+Imagine you've just finished implementing a function. Before committing, you ask hutch to review the diff through the Magit buffer. You get a new actionable buffer back:
+
+    src/infirmary.rb
+    @@ ...
+    - def eligible?(user) = user.age >= 18 && user.age < 18
+    + def eligible?(user) = user.age >= 18 && user.age < 65
+    
+    [hutch] This condition can literally never be true
+    [hutch] Did you mean `user.age < 65`?
+    [hutch] apply suggestion? [y]es [n]o [e]dit
+
+You can now accept, reject, or investigate each suggestion without leaving the Magit workflow. If the suggestions are useful, hutch can turn them into patches and apply; if it's nonsense, you dismiss it right there. None of it leaves your safe space.
+
+The talk walks through how it works and when it doesn't:
+
+- tour of the workflow: how to use hutch, when to use hutch, how to approve and reject things
+- patches over comments: hutch biasing outputs towards actionable items, rather than just prose
+- tools: guardrails, every agent loop earning its keep, gptel's state-machine
+- evals: how does it stack up against other external tooling on recognized benchmarks
+- dead-on-arrival: where it fails and why this is only useful if you work in a specific niche way
+
+This is a Magit and review-workflow talk that happens to involve an LLM, it doesn't purport any arguments about whether you should or shouldn't use AI with emacs.
+
+**Note:** The hutch package is available on MELPA <https://melpa.org/#/hutch>.
+
+About the speaker:
+
+Modern day aesthetically-relevant hacker. Long-time Clojure and Ruby programmer, reluctant polyglot by way of building high-throughput backends. Recently wound-down my startup Tramline, a mobile release orchestration tool, now kept alive as open source. Emacs and Magit are my daily drivers.
+
+
+
+[[!inline pages="internal(2026/info/hutch-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/hutch-nav)" raw="yes"]]
+
+
diff --git a/2026/talks/planning.md b/2026/talks/planning.md
new file mode 100644
index 00000000..896bd4d6
--- /dev/null
+++ b/2026/talks/planning.md
@@ -0,0 +1,37 @@
+[[!meta title="The Emacs Planning Habits of a Questionably Effective Person: My 40-year journey of planning with Emacs, Org Mode, paper journals, etc."]]
+[[!meta copyright="Copyright &copy; 2026 George Jones"]]
+[[!inline pages="internal(2026/info/planning-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# The Emacs Planning Habits of a Questionably Effective Person: My 40-year journey of planning with Emacs, Org Mode, paper journals, etc.
+George Jones - <mailto:gmj@pobox.com>
+
+[[!inline pages="internal(2026/info/planning-before)" raw="yes"]]
+
+This is the story of my 40+ year journey using planning tools, many of them inside Emacs since the advent of Org Mode. This is not a "now I know how to plan things perfectly" talk. I will demo Emacs planning workflows and tools I use, that I have used, and that I'm experimenting with now. You are probably a better planner than I am. You probably get more things done than I do. Sometimes getting things done is the point. Sometimes shiny objects are the point. Sometimes avoiding shiny objects is the point. I'll touch on all that.
+
+Here are some of the "Try this at home, kids" things I will touch on:
+
+-   Org and Denote capture templates
+-   My custom `org-todo-keywords`
+-   The Org Agenda: Per-project files vs. a single `diary.org`
+-   Habits, schedules, and weekly "DONE" and "Worked On" summaries
+-   Migrating to Denote
+-   "Strange new worlds" with AI/gptel creeping into my workflows
+
+Sometimes life happens outside Emacs. I admit it. I will touch on how my daily paper journaling and other inputs interact with my Emacs workflows.
+
+About the speaker:
+
+George Jones has been noodling around Emacsen since the TECO days (pre GNU) and had a bit to do with MicroEmacs finding its way onto the Amiga and USENET. Since the advent of Org mode much of his planning happens there. In this talk George will run through demos of current workflows with capture templates, custom TODO keywords, Org Agenda, habits, schedules and the use of newcomers including denote and gptel.
+
+
+
+[[!inline pages="internal(2026/info/planning-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/planning-nav)" raw="yes"]]
+
+
diff --git a/2026/talks/portable.md b/2026/talks/portable.md
index 762b17be..7f502be2 100644
--- a/2026/talks/portable.md
+++ b/2026/talks/portable.md
@@ -11,27 +11,19 @@ Mohammed Ismail Ansari - <https://myterminal.me>, <mailto:mail@myterminal.me>
 
 [[!inline pages="internal(2026/info/portable-before)" raw="yes"]]
 
-In the talk, I plan to cover my entry
-into the world of Emacs, a high-level series of events that shaped my
-experience and learning, and a few takeaways from someone coming from an
-entire different toolset and mentality, eventually having a moment of
-enlightenment to never go back again. The talk will revolve around how
-it has been my companion across multiple operating platforms and will
-remain to be one of the core elements of my computing toolset no matter
-the environment or platform. I'll talk about a few highs and lows of my
-attempts of inviting friends to Emacs, a few mentions of my
-contributions to the community and hopefully some tips for inspiration
-to newcomers and fellow Emacs-ers alike. Along with these, I'll also
-walk through how and why I created super-emacs and why I think it can be
-a reasonably easy starting point for someone getting into Emacs as their
-daily driver.
+In the talk, I'll cover my brief experience using Emacs across three
+major operating systems, how it influenced the other tools within my
+toolset, my effort to share my configuration with the rest of us, and
+eventually super-emacs: my attempt at a minimal but feature-full
+starter pack for Emacs that I've been maintaining for over a decade
+now.
 
 About the speaker: I, Mohammed Ismail Ansari (aka myTerminal), come
 from an academic background in Electronics Engineering, and have been
 working professionally as a software engineer since seventeen years.
-I love to create and experimenting with all kinds of machines, not
-just computers, enjoying the exploration and tinkering process.
-In the recent years I've also discovered my interest in personal
+I love to create and experiment with all kinds of machines, not just
+computers, enjoying the exploration and tinkering process. In the
+recent years I've also discovered my interest in personal
 productivity, and pairing them with some of the core elements within
 my toolset, including Linux, Emacs, and many other open-source
 software everything fits in place as if it was supposed to be.
diff --git a/2026/talks/writing.md b/2026/talks/writing.md
new file mode 100644
index 00000000..6b0400bd
--- /dev/null
+++ b/2026/talks/writing.md
@@ -0,0 +1,64 @@
+[[!meta title="Close the writing accountability gap with Emacs"]]
+[[!meta copyright="Copyright &copy; 2026 Blaine Mooers"]]
+[[!inline pages="internal(2026/info/writing-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Close the writing accountability gap with Emacs
+Blaine Mooers (he, him) - Pronunciation: Mooers is spoken as "Mores", <mailto:blaine-mooers@ou.edu>
+
+[[!inline pages="internal(2026/info/writing-before)" raw="yes"]]
+
+This 20-minute talk introduces writing-schedule.el and writing-habit.el available on GitHub at MooersLab.
+These tools address the challenge of managing multiple writing projects in parallel and measuring adherence to the writing schedule.
+These measurements provide valuable feedback that you can use to close the gap between your planned and actual writing activity.
+You can use this to make your writing habit antifragile, growing stronger in response to disruptions.
+
+These tools address also address the seemingly unsolvable problem of managing multiple parallel writing projects in academia.
+This issue is also widespread in other walks of life.
+Emacs can address this issue.
+
+Writing projects can span multiple days, weeks, months, and even years before they are finished.
+Long-running projects need to move forward steadily, while shorter writing projects have many deadlines.
+You can focus on only one project at a time, but you can make progress on two to four projects in a day by adhering to a schedule.
+Scheduling recurring events with time blocks is a popular approach to handling parallel projects.
+However, setting time blocks on paper or in an electronic application (e.g., iCal, gCal, or Outlook Express) quickly becomes tedious.
+We harness Emacs to cut the time spent scheduling the upcoming week in half.
+
+The package writing-schedule.el uses an org-mode table to plan the week's writing.
+Single letters are mapped to specific projects and added to cells of the table to assign time blocks to specific writing projects.
+You can quickly reassign the letters to a different project if you will use similar time slots in the upcoming week.
+
+You can use a table from the prior year as a template because the pattern of discretionary time available for writing is likely similar from year to year.
+You can create template files to reflect seasonal fluctuations in discretionary time available for writing.
+Writing schedule tables can accommodate 1-7 day work weeks.
+The information in the org-table can be exported as a list of scheduled TODOs for org-agenda, to a PDF file in the time-blocking format advocated by Calvin Newport, and to an .ics file for importing into iCal, gCal, or Outlook calendar.
+You can shift the time blocks as the day progresses to reflect what really happened.
+
+The time blocks are assigned to different writing activities: generative writing, editing, and support activities.
+You can schedule these activities to match your daily pattern of alertness and energy.
+Morning larks can assign generative writing to the early hours of the day; night owls can assign generative writing to the late hours.
+Both groups do editing best at peak alertness, usually between 9:30 and 11:30 A.M.
+They can assign support writing activities to the afternoons.
+
+This is the ideal pattern, but real-life obligations disrupt it.
+The record for the past week is compared with the planned events to measure adherence to the writing schedule using the dashboard produced by the package writing-habit.el.
+The package provides several bar plots comparing time scheduled and time spent by project and by writing activity.
+
+About the speaker:
+
+Blaine Mooers is an associate professor of biochemistry and physiology at the University of Oklahoma Health Campus, where he specializes in macromolecular crystallography.
+His research focuses on RNA structures and protein-drug complexes important in cancer.
+An avid Emacs, LaTeX, Clojure, and Python user for many years, he builds tools that optimize scientific workflows, including writing workflows.
+In this talk, he shares writing-schedule.el, which brings time blocking to org-agenda, and the template system he uses to schedule a week in minutes.
+His aim is an antifragile writing habit that grows stronger through the disruptions of academic life.
+
+
+
+[[!inline pages="internal(2026/info/writing-after)" raw="yes"]]
+
+[[!inline pages="internal(2026/info/writing-nav)" raw="yes"]]
+
+