add lots of talks

15 files changed, 830 insertions, 0 deletions

diff --git a/2024/talks/blee.md b/2024/talks/blee.md
new file mode 100644
index 00000000..7a844b66
--- /dev/null
+++ b/2024/talks/blee.md
@@ -0,0 +1,126 @@
+[[!meta title="About Blee: towards an integrated Emacs environment for enveloping our own autonomy directed digital ecosystem"]]
+[[!meta copyright="Copyright © 2024 Mohsen BANAN"]]
+[[!inline pages="internal(2024/info/blee-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. --->
+
+
+# About Blee: towards an integrated Emacs environment for enveloping our own autonomy directed digital ecosystem
+Mohsen BANAN (he/him) - Pronunciation: MO-HH-SS-EN
+
+[[!inline pages="internal(2024/info/blee-before)" raw="yes"]]
+
+Emacs has long been recognized as the ultimate integration platform, enabling
+the creation of an unparalleled user environment. In 2010, Tomohiro Matsuyama,
+captured this concept crisply:
+
+"The reason why Emacs platform is good is that it cooperates with OS,
+not because it is good by itself."
+
+Building on this idea, Blee (ByStar Libre-Halaal Emacs Environment) can be seen
+as yet another Emacs re-distribution, akin to Doom Emacs or Spacemacs. However,
+Blee is distinct. While Doom Emacs is multi-platform oriented, Blee is paired
+exclusively with Debian &#x2014; and on mobile, with Termux-Android. While Doom Emacs
+is Emacs-centric, Blee is digital ecosystem-centric.
+
+To further elucidate Blee, let’s break down the subtitle of this presentation:
+
+"Towards an Integrated Emacs Environment for Enveloping Our Own
+Autonomy Directed Digital Ecosystem."
+
+-   **"Towards":** Blee is an ever-evolving, organic, and ongoing project &#x2014; just
+    like Emacs itself.
+
+-   **"Enveloping":** Blee is designed to fully integrate and encapsulate usage of
+    an entire digital ecosystem.
+
+-   **"Our Own Autonomy-Directed Digital Ecosystem":** In contrast to the
+    proprietary American ecosystems of Google, Microsoft, Meta, Apple, and Amazon,
+    Blee is part of *the Libre-Halaal ByStar Digital Ecosystem*. ByStar is ours.
+
+By\* challenges the existing proprietary American digital ecosystem while
+operating concurrently alongside it. ByStar's primary offerings are tangible
+autonomy and genuine privacy on a very large scale. ByStar represents a moral
+inversion of the proprietary American internet services model. By\* is about
+redecentralization of internet application services.
+
+Some might dismiss ByStar as an ambitious, utopian vision. In response, I’ve
+authored a book titled:
+
+Nature of Polyexistentials:
+Basis for Abolishment of the Western Intellectual Property Rights Regime
+And Introduction of the Libre-Halaal ByStar Digital Ecosystem
+
+-   On Line US Edition: <https://github.com/bxplpc/120033>
+-   On Line International Edition: <https://github.com/bxplpc/120074>
+-   DOI:  <https://doi.org/10.5281/zenodo.8003846>
+-   US Edition Book Prints At Amazon:  >
+-   International Edition Book Prints in Iran:  <https://jangal.com/fa/product/252689/nature-of-polyexistentials>
+
+Blee and Emacs are integral parts of ByStar.
+
+Analysis of digital ecosystems is inherently interdisciplinary, and so is my
+book. But, in this presenation, I won't be delving much into the philosophical,
+ethical, moral, societal, and social dimensions of the book. This presentation,
+focuses on the technical aspects of ByStar and Blee, specifically through the
+lens of Emacs users and developers.
+
+Blee’s approach to integration differs from traditional Emacs culture in three
+key ways:
+
+1.  Avoiding the "Curse of Lisp": While Emacs culture emphasizes doing
+    everything in Lisp, Blee consciously avoids this pitfall.
+
+2.  Cultivation of Best-of-Breeds: Emacs folklore tends to follow a laissez
+    faire approach, but Blee is disciplined around cultivation of selected best
+    of breeds.
+
+3.  Digital Ecosystem Orientation: Unlike traditional Emacs, which is
+    component-focused, Blee is designed in the context of the entirety of our
+    own digital ecosystem.
+
+In ByStar, much of the integration occurs outside of Emacs, through a framework
+called BISOS (By\* Internet Services OS). BISOS builds on Debian to provide a
+unified platform for developing both internet services and software-service
+continuums. BISOS and Blee are intertwined.
+
+Now, in 2024, I am advancing Matsuyama concept with specificity:
+
+"The reason why Emacs platform is good is that it facilitates creation of
+ integrated usage environments like Blee, which cooperate with Debian, BISOS
+ and ByStar."
+
+An early version of BISOS and Blee is available for public use and
+experimentation. To get started with BISOS, Blee, and ByStar, visit
+<https://github.com/bxgenesis/start>. From a virgin Debian 12 installation
+("Fresh-Debian"), you can bootstrap BISOS and Blee in one step by running the
+raw-bisos.sh script. It produces "Raw-BISOS" which includes "Raw-Blee". You
+can then customize Raw-Blee to create different parts and aspects of your own
+ByStar DE.
+
+I welcome your thoughts and feedback, especially if you experiment with Blee,
+BISOS, ByStar, and the model and the concept of Libre-Halaal Polyexistentials.
+
+About the speaker:
+
+Mohsen Banan is a software and internet engineer.
+In this talk he describes how he has leveraged
+Emacs as an integration platform to create a
+comprehensive integrated usage environment. In his
+recent book "Nature of Polyexistentials", he
+introduces the Libre-Halaal ByStar Digital
+Ecosystem. Both in the book and this talk, he
+outlines a blueprint and presents initial
+implementations for BISOS (By\* Internet Services
+OS) and Blee (ByStar Libre Emacs Environment).
+Central to his presentation is the positioning of
+Emacs, as the core of Blee.
+
+
+
+[[!inline pages="internal(2024/info/blee-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/blee-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/color.md b/2024/talks/color.md
new file mode 100644
index 00000000..e302c691
--- /dev/null
+++ b/2024/talks/color.md
@@ -0,0 +1,50 @@
+[[!meta title="Colour your Emacs with ease"]]
+[[!meta copyright="Copyright &copy; 2024 Ryota"]]
+[[!inline pages="internal(2024/info/color-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. --->
+
+
+# Colour your Emacs with ease
+Ryota (he/him) - Pronunciation: Ree-yo-tah, https://hachyderm.io/@rytswd https://x.com/rytswd
+
+[[!inline pages="internal(2024/info/color-before)" raw="yes"]]
+
+Emacs comes with various themes to pick from, and there are myriad
+different themes out on the internet. Even when you choose a theme, from
+there, you can make your exact adjustments to add or remove certain
+colours. Emacs provides you so much control over how you work, write, code,
+and everything in between. You are certainly left equipped with all the
+controls for your theme as well.
+
+However, when it comes to colour, there is a bit of difficulty: RGB.
+Hexadecimal colour codes are ubiquitous and relatively easy to understand.
+Yet, they are difficult to work with, especially when you need to make
+different shades and variants. In recent years, CSS started to support not
+just sRGB (standard RGB), but other colour spaces such as HSL, Oklab, etc.
+With Emacs, we also have a great set of tools from color.el, as well as
+this amazing package called ct.el (<https://github.com/neeasade/ct.el>),
+
+In this talk, we will have a quick look at different colour spaces than
+sRGB, namely HSL and LCH. We will check out how ct.el can make a set of
+colour shades and variants at ease, and how they can help defining themes.
+Finally, Ryota will share his own theme called Hasliberg Theme, which is
+using the full power of LCH.
+
+About the speaker:
+
+Ryota started his Emacs journey more than a decade ago, but was forced to
+put it aside for work requirements soon after. A few years ago, he made a
+return to Emacs, and now is using Emacs almost exclusively for any sort of
+coding tasks. This talk focuses on the modern Emacs setup where he thinks
+his Emacs looks and works better than many other editors. He works for Civo
+as a Principal Engineer.
+
+
+
+[[!inline pages="internal(2024/info/color-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/color-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/graph.md b/2024/talks/graph.md
new file mode 100644
index 00000000..990372f8
--- /dev/null
+++ b/2024/talks/graph.md
@@ -0,0 +1,40 @@
+[[!meta title="Graph mode - A major mode to create, edit and display discrete element graphs."]]
+[[!meta copyright="Copyright &copy; 2024 John Darrington"]]
+[[!inline pages="internal(2024/info/graph-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. --->
+
+
+# Graph mode - A major mode to create, edit and display discrete element graphs.
+John Darrington (he/him) - IRC: jmd, <mailto:john@cellform.com>
+
+[[!inline pages="internal(2024/info/graph-before)" raw="yes"]]
+
+This project is a major mode to assist creation and editing of SVG
+images depicting discrete element graphs, optionally with presentational
+properties. The creation of such images may be of interest to
+engineers, pure mathematicians with an interest in graph theory,
+computer scientists, data administrators and others.
+
+The user specifies the topology and simple presentational attributes of the
+system and emacs takes care of the rest. Interaction is via conventional M-x
+interactive commands, or by keybindings/mouse movement.
+
+If desired, the SVG output may be edited using an external tool or by
+hand. Keeping the generated SVG readable and easy to edit is a design
+goal of the project.
+
+Example uses may include the creation of flow charts, entity-relationship
+diagrams, UML, block diagrams, and abstract graphs.
+
+This talk will demonstrate use of the mode, describe how it works, and
+discuss possible future direction.
+
+
+
+[[!inline pages="internal(2024/info/graph-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/graph-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/gypsum.md b/2024/talks/gypsum.md
new file mode 100644
index 00000000..1c3f0aa3
--- /dev/null
+++ b/2024/talks/gypsum.md
@@ -0,0 +1,88 @@
+[[!meta title="Gypsum: my clone of Emacs and ELisp written in Scheme"]]
+[[!meta copyright="Copyright &copy; 2024 Ramin Honary"]]
+[[!inline pages="internal(2024/info/gypsum-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. --->
+
+
+# Gypsum: my clone of Emacs and ELisp written in Scheme
+Ramin Honary (he/him) - <mailto:ramin.honary@gmail.com>
+
+[[!inline pages="internal(2024/info/gypsum-before)" raw="yes"]]
+
+I  would like  to demonstrate  an  Emacs clone  I have  been
+writing  in Guile  Scheme  for  the past  year,  which I  am
+tentatively  calling "Gypsum".  Unlike  other editors  which
+only clone  the Emacs keybindings (Edwin,  Jed, jEdit, Jove,
+Lem, MG,  Yi, Zile), I hope  my Emacs clone will  also fully
+clone the  Emacs Lisp programming language  well enough that
+many of the packages in ELPA, Non-GNU ELPA, and perhaps even
+MELPA, can be used in  "Gypsum" without any modification.  I
+would also  like to  talk a  little bit about  the how  I am
+implementing  it  (the  software architecture),  and  invite
+others to contribute.
+
+I  think my  project  is  of interest  to  many Emacs  users
+because, firstly, I have personally spoken with a relatively
+large number of people who have expressed interest in making
+Emacs  programmable in  Scheme.  Secondly, there  is a  good
+amount   of  prior   art  for   Scheme  implementations   of
+Emacs. There  are even  builds of Emacs  that link  to Guile
+which  provides  a   "scheme-eval"  built-in  function  that
+translates  between   Elisp  data  types  and   Scheme  data
+types. The  Guile compiler itself  ships with an  Emacs Lisp
+compiler as  well, although  it does  not provide  enough of
+Emacs's built-in functions to be of much use.
+
+So by  using Guile, we  can make use of  a lot of  the prior
+art, in fact  I am currently using the  tokenizer and reader
+used  in Guile's  built-in  Elisp  interpreter to  implement
+"Gypsum's" Elisp interpreter. That said,  I have gone out of
+my way to make my code fully R7RS compliant, so I hope I can
+port  it to  other Scheme  implementations like  MIT Scheme,
+Gambit, Stklos, and perhaps Chez Scheme with Gwen Weinholt's
+R7-to-R6RS  translator.  I  consider the  Guile  version  of
+Gypsum to  be the  reference implementation  of what  I hope
+will become a fully  cross-platform programming language and
+text editor written in portable R7RS Scheme.
+
+The   reference  implementation   of  "Gypsum"   is  a   GUI
+application   based   on   Gtk  using   a   library   called
+"Guile-GI".   Guile-GI   uses  the   GObject   Introspection
+framework to automatically generate Scheme language bindings
+to libraries  like Gtk and Glib  which are written in  the C
+programming language. There is not yet any terminal-emulator
+version of "Gypsum."
+
+The next step of the project  will be to implement enough of
+Elisp that we can run  tests written in the Emacs Regression
+Testing  (ERT)  framework.  We   can  then  incorporate  the
+original GNU  Emacs regression  test suite into  Gypsum. Any
+new API added to Gypsum  Elisp will most likely already have
+regression tests we can use to  make sure it is working in a
+way that is compatible with GNU  Emacs Lisp. I would like to
+make it as easy as possible for people to contribute to this
+project, and  having a list  of APIs to be  implemented each
+with  a set  of regression  tests the  APIs are  expected to
+pass, is a very good way to do that.
+
+About the speaker:
+
+My name is Ramin Honary, I have been a professional software
+engineer  of  16  years,   lately  mostly  doing  full-stack
+software  development. I  have always  been fascinated  with
+programming languages,  and especially  functional languages
+like   Lisp   and  Haskell.   I   have   been  using   Emacs
+since 2017.  But lately it is  with Scheme that I  have been
+spending  most  of  my  free   time.  I  am  only  a  Scheme
+programming  enthusiast,  I  am  not  involved  with  Scheme
+professionally.
+
+
+
+[[!inline pages="internal(2024/info/gypsum-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/gypsum-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/hyperbole.md b/2024/talks/hyperbole.md
new file mode 100644
index 00000000..c94e8bd1
--- /dev/null
+++ b/2024/talks/hyperbole.md
@@ -0,0 +1,34 @@
+[[!meta title="Fun things With GNU Hyperbole"]]
+[[!meta copyright="Copyright &copy; 2024 ${speakers}"]]
+[[!inline pages="internal(2024/info/hyperbole-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. --->
+
+
+# Fun Things With GNU Hyperbole
+ - matsl@mastodon.acc.sunet.se, <mailto:matsl@gnu.org>
+
+[[!inline pages="internal(2024/info/hyperbole-before)" raw="yes"]]
+
+This talk will focus on a few small fun things you can do with Hyperbole
+with less focus on going into details.
+
+GNU Hyperbole is described as the Everyday Hypertextual
+Information Manager which point in the direction of hypertext with
+some inter linkage. It has all that but it also contains other
+small and useful things. This talk will focus on the other
+supported features and demo a sample of them.
+
+About the speaker:
+
+I'm Mats Lidell. Co-maintainer of GNU Hyperbole together with the
+author Bob Weiner.
+
+
+
+[[!inline pages="internal(2024/info/hyperbole-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/hyperbole-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/hywiki.md b/2024/talks/hywiki.md
new file mode 100644
index 00000000..feee94a6
--- /dev/null
+++ b/2024/talks/hywiki.md
@@ -0,0 +1,46 @@
+[[!meta title="HyWiki: Fast, hyperlinked note-taking with no markup required"]]
+[[!meta copyright="Copyright &copy; 2024 Bob Weiner"]]
+[[!inline pages="internal(2024/info/hywiki-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. --->
+
+
+# HyWiki: Fast, Hyperlinked Note-taking with No Markup Required
+Bob Weiner - Pronunciation: wine-er, <mailto:rsw@gnu.com>
+
+[[!inline pages="internal(2024/info/hywiki-before)" raw="yes"]]
+
+This talk will demonstrate HyWiki, Hyperbole's new markup-free, personal
+Wiki system for note-taking.  HyWiki utilizes Org format and its publishing
+framework.
+
+With the press of a key, HyWiki lets you:
+
+-   create a new HyWiki page when on a WikiWord
+-   create a highlighted hyperlink to a Wiki page
+-   jump to an existing page or section therein
+-   publish an entire HyWiki to the web with numbered sections
+
+We'll demonstrate how you can efficiently take notes and have them
+automatically interlinked without having to master Org link syntax or any
+syntax at all.
+
+HyWiki is quick, simple and efficient.  It has been tested to perform well
+with 10,000 WikiWords and requires no database nor configuration.  Install
+the Hyperbole package and you are ready to go.
+
+About the speaker:
+
+Bob Weiner has been molding Emacs to his will for most of his life. His
+mega-Hyperbole package aims to simplify all kinds of information management
+across Emacs modes.  HyWiki is his take on fast hyperlinked note-taking.
+Let's see if he has something interesting to show us.
+
+
+
+[[!inline pages="internal(2024/info/hywiki-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/hywiki-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/julia.md b/2024/talks/julia.md
new file mode 100644
index 00000000..f2914ad9
--- /dev/null
+++ b/2024/talks/julia.md
@@ -0,0 +1,33 @@
+[[!meta title="Exploring shared philosophies in Julia and Emacs"]]
+[[!meta copyright="Copyright &copy; 2024 Gabriele Bozzola"]]
+[[!inline pages="internal(2024/info/julia-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. --->
+
+
+# Exploring shared philosophies in Julia and Emacs
+Gabriele Bozzola (he/him/his) - GitHub: @sbozzolo Website: <https://sbozzolo.github.io> LinkedIn: gabrielebozzola
+
+[[!inline pages="internal(2024/info/julia-before)" raw="yes"]]
+
+While seemingly disparate, the Julia programming language and Emacs share a
+surprising kinship. This talk delves into the common design principles and
+philosophies that unite these powerful tools, focusing on their shared
+emphasis
+on extensibility, customization, and interactive development. I'll explore
+how
+both Julia and Emacs empower users to tailor their experience through
+powerful
+metaprogramming and a rich ecosystem of extensions. I'll discuss the
+REPL-driven workflows that foster exploration and experimentation in both
+environments. Furthermore, I'll examine how their active and passionate
+communities drive innovation.
+
+
+
+[[!inline pages="internal(2024/info/julia-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/julia-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/language.md b/2024/talks/language.md
new file mode 100644
index 00000000..fb8cb935
--- /dev/null
+++ b/2024/talks/language.md
@@ -0,0 +1,44 @@
+[[!meta title="Immersive language learning with Emacs"]]
+[[!meta copyright="Copyright &copy; 2024 Sebastian Dümcke"]]
+[[!inline pages="internal(2024/info/language-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. --->
+
+
+# Immersive language learning with Emacs
+Sebastian Dümcke (he/him) - <https://sam-d.com>, <mailto:code@sam-d.com>
+
+[[!inline pages="internal(2024/info/language-before)" raw="yes"]]
+
+Immersive language learning helps acquiring a new language by
+surrounding oneself in environments where the target language is used
+naturally, rather than learning through traditional instruction or
+translation methods. Short of travelling to places where the language is
+native, one can also emulate this digitally: Watching movies, listening
+to music, podcasts, or radio shows, and reading books, newspapers, or
+websites in the target language.
+
+I will present a framework in Emacs to achieve the typical tasks in
+language learning: increase vocabulary and comprehension (both written
+and aural) to achieve faster fluency, better retention and ideally
+cultural competence. We will investigate how to read written documents
+and websites, watch movies and listen to music/learn lyrics all while
+collecting new vocabulary and concepts. Then we will present a spaced
+repetition framework for improving retention of these concepts.
+
+About the speaker:
+
+I am a curious person, interested to learn. I started using Emacs as a
+project management tool through org-mode 8 years ago. I has really
+helped my stay on top of things while starting my own company. Now my
+use of Emacs is slowly expanding. I was always interested in learning
+new languages: I believe they are the key to other cultures.
+
+
+
+[[!inline pages="internal(2024/info/language-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/language-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/links.md b/2024/talks/links.md
new file mode 100644
index 00000000..9a42b59e
--- /dev/null
+++ b/2024/talks/links.md
@@ -0,0 +1,51 @@
+[[!meta title="Unlocking linked data: replacing specialized apps with an Org-based semantic wiki"]]
+[[!meta copyright="Copyright &copy; 2024 Abhinav Tushar"]]
+[[!inline pages="internal(2024/info/links-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. --->
+
+
+# Unlocking linked data: replacing specialized apps with an Org-based semantic wiki
+Abhinav Tushar (he/him) - abhinav@lepisma.xyz, https://lepisma.xyz, @lepisma@mathstodon.xyz
+
+[[!inline pages="internal(2024/info/links-before)" raw="yes"]]
+
+I try to maintain a lot of personal information, annotations, etc. in Org files
+but have historically switched back to purpose built apps for different kinds of
+data. There are recipe managers for recipes, personal CRM tools for people
+related notes, bookmark managers for managing web links, etc. While these apps
+do good with the kind of data they work on, they don't operate well together in
+the sense that they don't treat *links* between entities as first class citizen. I
+believe this gap is where a lot of *personal information* live. As an example,
+consider the chain of links that tells 'person a' gave me 'this recipe' on 'my
+anniversary'.
+
+After using zettlekasten via Org-roam for some time, I came to realize the power
+of links that we (can) form between data of different kinds. For me, these links
+offset the loss that comes with leaving specialized apps. With this, I have
+again gone back to Org files, but this time deriving good value from links
+between notes. Of course there are tons of other benefits of using Org files
+like better longevity, portability, versioning, and developer accessibility.
+
+In this talk, I will cover my workflow of creating and managing different kinds
+of notes in Org mode based Semantic Wiki and the link types they tend to have. I
+will also show my workflow outside of Emacs, where I use small tools that sit on
+top of Org files to deliver missing features of niche apps (like availability on
+mobile devices, smart cross data-type queries, etc.).
+
+About the speaker:
+
+I am a Programmer and Machine Learning Engineer, and I love working with
+computers primary because of the early experiences of infinite extensibility
+that Emacs gave me. For this talk I will cover my journey of using Org files
+for notes, then leaving for specialized applications, and finally coming back to
+Org to unlock the benefits of linked data.
+
+
+
+[[!inline pages="internal(2024/info/links-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/links-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/mcclim.md b/2024/talks/mcclim.md
new file mode 100644
index 00000000..432a0180
--- /dev/null
+++ b/2024/talks/mcclim.md
@@ -0,0 +1,121 @@
+[[!meta title="Elisp and McCLIM"]]
+[[!meta copyright="Copyright &copy; 2024 screwlisp"]]
+[[!inline pages="internal(2024/info/mcclim-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. --->
+
+
+# Elisp and McCLIM
+he or e/em/eir (Spivak, male and neuter pronouns are fine) - IRC: screwlisp, Mastodon: @screwtape@mastodon.sdf.org liberachat: screwlisp MOO: lambda.moo.mud.org Name: screwtape Moo mail preferred
+
+[[!inline pages="internal(2024/info/mcclim-before)" raw="yes"]]
+
+The gist is demoing using McCLIM common lisp interface manager
+implementation to make Sandewall 1978's lisp iconic example
+scheduler app, but to drive it to and from emacs lisp via slime
+and swank.
+
+To start with, a beginner walkthrough on getting slime and
+common lisp and mcclim, and configuring and using them with
+emacs org-mode.
+
+The default clim application-frame is made and its interactor
+used.
+
+A CLIM command is then defined to refer the default describe to
+emacs lisp rather than the inferior lisp.
+
+CLIM useage with no gui via slime / org-mode is demoed.
+
+This is then used via emacs lisp.
+
+CLIM's accepting-values is used to generate an anonymous gui
+that accepts a value **into elisp**.
+
+A small final discussion on integrating the clim scheduler back
+and forth into org-agenda.
+
+Bib:
+
+```
+      @article{sandewall1978programming,
+        title={Programming in an Interactive Environment:
+    the``Lisp''Experience},
+        author={Sandewall, Erik},
+        journal={ACM Computing Surveys (CSUR)},
+        volume={10},
+        number={1},
+        pages={35--71},
+        year={1978},
+        publisher={ACM New York, NY, USA}
+        }
+    
+        @inproceedings{strandh2002free,
+        title={A free implementation of clim},
+        author={Strandh, Robert and Moore, Timothy},
+        booktitle={International Lisp Conference Proceedings},
+        year={2002}
+        }
+    
+        @article{fruhwirth2006guided,
+        title={A Guided Tour of CLIM, Common Lisp Interface Manager},
+        author={Fruhwirth, Clemens},
+        journal={Lisp Pointers},
+        year={2006}
+        }
+    
+        @article{kochmanskimcclim,
+        title={McCLIM Demonstration},
+        author={Kochmanski, Daniel}
+        }
+    
+        @inproceedings{kochmanski2020ecl,
+        title={On ECL, the Embeddable Common Lisp (ELS keynote).},
+        author={Kochmanski, Daniel},
+        booktitle={ELS},
+        year={2020}
+        }
+    
+        @misc{beane2012quicklisp,
+        title={Quicklisp},
+        author={Beane, Zach},
+        year={2012}
+        }
+    
+        @misc{marsden2003slime,
+        title={SLIME: The superior lisp interaction mode for emacs},
+        author={Marsden, Eric and Gorrie, Luke and Eller, Helmut and others},
+        year={2003},
+        publisher={URL: https://common-lisp. net/project/slime/(visited on
+    05/19/2017)}
+        }
+    
+        @article{dominik2004org,
+        title={Org mode manual},
+        author={Dominik, Carsten},
+        year={2004}
+      }
+```
+
+About the speaker:
+
+I'm screwlisp from the lispy gopher climate, a weekly Wednesday
+000UTC podcast (non-radio show) on aNONradio.net powered by sdf.org;
+(also the lesser-known Friday 1400UTC show, Zhen House Zhen Bonkwave.
+
+We are fortunate to have many great people in our live chat that
+happens in LambdaMOO during the shows. Last week, we shared Rog's
+new writing on his current personal emacs modes with his decades
+of emacs useage. (Roger Crew). That's not what this talk is about
+though, though we often deal with emacs and McCLIM, which **are** what
+this talk is about. I have many friends who picked those up in some
+small part thanks to the show.
+
+
+
+[[!inline pages="internal(2024/info/mcclim-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/mcclim-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/papers.md b/2024/talks/papers.md
new file mode 100644
index 00000000..72490a73
--- /dev/null
+++ b/2024/talks/papers.md
@@ -0,0 +1,51 @@
+[[!meta title="Writing academic papers in Org-Roam"]]
+[[!meta copyright="Copyright &copy; 2024 Vincent Conus"]]
+[[!inline pages="internal(2024/info/papers-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. --->
+
+
+# Writing academic papers in Org-Roam
+Vincent Conus (he/him) - Pronunciation: vɪnsᵊnt koʊnᵊs, IRC: sunoc, Mastodon: @sunoc@social.linux.pizza, <mailto:vincent.conus@pm.me>
+
+[[!inline pages="internal(2024/info/papers-before)" raw="yes"]]
+
+Org-mode and more so org-roam are making for a fantastic note-taking system
+inside Emacs. Combining the note-taking of org-mode, the capability to export
+a note to LaTeX and PDF directly, the spectacular org-roam-bibtex package
+and the flexibility of the elisp configuration of Emacs, it become possible
+to use a org-roam note as the main document for write academic papers, even
+when exotic templates are provided.
+
+In this presentation, I want to talk about the way I am using org-roam to write
+LaTeX documents, the benefits of it but also the various pitfalls and
+difficulties encountered in this journey.
+
+The key benefits being:
+
+-   The integration with other org-roam notes.
+-   Bibliography integration and links directly to PDF.
+-   Org-mode literate programming capabilities.
+-   Direct export to PDF.
+
+The main challenges are:
+
+-   Dealing with strangely formatted LaTeX templates.
+-   Related, having to use other LaTeX compilers.
+-   These two points can make citation of references, in particular, challenging.
+
+About the speaker:
+
+A PhD student in robotics at
+Nanzan University, Japan. I have been using Linux for around 10 years at that
+point, eventually moving many of my work and personal stuff to Emacs over the
+years, including academic writing.
+
+
+
+[[!inline pages="internal(2024/info/papers-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/papers-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/regex.md b/2024/talks/regex.md
new file mode 100644
index 00000000..32ea74f5
--- /dev/null
+++ b/2024/talks/regex.md
@@ -0,0 +1,37 @@
+[[!meta title="Emacs regex compilation and future directions for expressive pattern matching"]]
+[[!meta copyright="Copyright &copy; 2024 Danny McClanahan"]]
+[[!inline pages="internal(2024/info/regex-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. --->
+
+
+# Emacs regex compilation and future directions for expressive pattern matching
+Danny McClanahan (they/them) - Pronunciation: məˈklænəˌhæn / mk-CLAN-uh-han, han like "hand", IRC: cosmicexplorer, @hipsterelectron@circumstances.run on mastodon - @hipsterelectron on twitter -  @cosmicexplorer on github - @cosmicexplorer in #emacsconf on irc.libera.chat, <mailto:dmcC2@hypnicjerk.ai>
+
+[[!inline pages="internal(2024/info/regex-before)" raw="yes"]]
+
+Emacs is a delightful case study for the capabilities of regular expressions, because Emacs forms user interfaces via text, which retains the expressivity of a GUI with the user-level interactivity of written language. Because we use text for both input and output, regexps in Emacs form part of a user-level grammar for human thought. As a result, Emacs and Emacs users have a rich intuitive grasp of regular expressions, which provides a unique vantage point to consider how they may be improved in general.
+
+When I began my investigation, I assumed that Emacs would be able to use an existing off-the-shelf regex engine, that this would be more performant than regex-emacs.c, and that the greatest challenge would be providing a sufficiently robust build process (see emacs-devel: <https://lists.gnu.org/archive/html/emacs-devel/2024-04/msg00142.html>). However, I quickly found that Emacs (as usual) is far more configurable than alternatives (see rust regex discussion: <https://github.com/rust-lang/regex/discussions/1167#discussioncomment-8585027>). Now don't get this twisted: emacs-devel was open to deprecating functionality that hampered optimization! But the biggest challenge by far is that regex-emacs.c is categorically more powerful than alternatives: it can match against <span class="underline">non-contiguous input</span> (across both halves of the gap buffer), as well as non-UTF8 text with its fantastic multibyte encoding (see <https://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html>).
+
+So a more complex picture begins to emerge: Emacs actually uses regexps far more widely and deeply than anywhere else, and its regex engine requirements aren't "legacy", but the result of caring more deeply about language than anywhere else. While regex engines have historically been known to introduce functionality not backed by formal theory that's later found to be hard to optimize, Emacs instead charts a path for other engines to follow. Formalizing backrefs is state-of-the-art, but possible (see <https://jamiejennings.com/posts/2021-09-23-dont-look-back-2/>), and I believe the same can be achieved for the other affordances Emacs users have come to expect. Subsequently, I have focused on identifying where we can constrain the problem space to improve performance without losing those affordances, such as explicit precompilation in lisp code (see <https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00108.html>).
+
+There are many branching paths here. With the libgccjit native compiler, we can now implement regex matching in lisp itself. While \`rx' can compose patterns to an extent, we could provide a more powerful primitive than regular expressions alone for complex parsing tasks. And while many regex engines employ complex optimization heuristics, we can instead introduce specific functionality for e.g. SIMD literal search into lisp code, allowing lisp users to intelligently select for themselves how and when to employ less-powerful but more-performant search routines.
+
+We don't need to backtrack! We can try all these paths at once.
+
+About the speaker:
+
+Me: Typing free software to break the shoulders of giants from golden handcuffs.
+Work: Composeable build tools, parsing frameworks, and cryptographic messaging. All of these are misused to subjugate and oppress, but I build infrastructure for positive liberties.
+
+This talk will cover my train of thought over the course of this year on how regex engines in general may be improved, and the discussions with emacs-devel that have helped me along. I hope this talk will convince people of the boundless future directions in text search. My PhD research will be inspired by the expressivity and power of Emacs.
+
+
+
+[[!inline pages="internal(2024/info/regex-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/regex-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/repro.md b/2024/talks/repro.md
new file mode 100644
index 00000000..41712957
--- /dev/null
+++ b/2024/talks/repro.md
@@ -0,0 +1,36 @@
+[[!meta title="Reproducibly building Emacs: “Hey your checksum is the same as mine!”"]]
+[[!meta copyright="Copyright &copy; 2024 Aaron Grothe"]]
+[[!inline pages="internal(2024/info/repro-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. --->
+
+
+# Reproducibly building Emacs: “Hey your checksum is the same as mine!”
+Aaron Grothe (he/him) - Pronunciation: Err-In Growth-e, <https://www.grothe.us> LinkedIn: <https://www.linkedin.com/in/aaron-grothe/>, <mailto:ajgrothe@yahoo.com>
+
+[[!inline pages="internal(2024/info/repro-before)" raw="yes"]]
+
+The idea of a reproducible build is that you can build a package and I can build a package and we both produce the same executable.  There are security benefits to being able to create a reproducible build ensuring the integrity and reliability of the build.  There are also benefits in the world of debugging/testing as you can confirm that the end user has the same executable as the developer.
+
+The Debian project has been making huge strides with this.  With a goal to have the next Debian release “Trixie” only having 256 non-reproducible packages.  Unfortunately as of September 19, 2024 GNU Emacs is one of them.  GNU Emacs is currently in the dreaded FTBFS (Fails To Build From Source) section for reproducible builds.   Other Linux distributions including Arch and NixOS are working towards the same goal.
+
+This talk will be an overview of what is/was preventing us from producing a reproducible build for GNU Emacs and what it will take to get GNU Emacs to join this August club.   
+
+The talk will also contrast the difference between reproducible builds and the OpenBSD projects approach of randomized executables.
+
+We’ll be doing a high level overview of the Reproducible Builds - <https://reproducible-builds.org/> project and the tools, procedures, techniques they’ve put together for making the entire procedure reproducible 🙂
+
+About the speaker:
+
+Aaron Grothe has been a developer for many years. He is a two-time winner of the International Obfuscated C Code Contest <https://www.ioccc.org> and has a couple of small pieces of code in the Linux kernel. He has been published several times in 2600 magazine.  He is interested in code correctness and how we can write safer code as we head into the future. 
+
+Currently (September 19, 2024) GNU Emacs is not generating a reproducible build for GNU Debian.  This talk is a quick introduction to reproducible builds and what it will take to get GNU Emacs to generate a reproducible build.
+
+
+
+[[!inline pages="internal(2024/info/repro-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/repro-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/secrets.md b/2024/talks/secrets.md
new file mode 100644
index 00000000..1ceff9fd
--- /dev/null
+++ b/2024/talks/secrets.md
@@ -0,0 +1,26 @@
+[[!meta title="Committing secrets with git using sops-mode"]]
+[[!meta copyright="Copyright &copy; 2024 Jonathan Otsuka"]]
+[[!inline pages="internal(2024/info/secrets-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. --->
+
+
+# Committing secrets with git using sops-mode
+Jonathan Otsuka - Pronunciation: O-tsu-ka, <https://github.com/djgoku>, <mailto:pitas.axioms0c@icloud.com>
+
+[[!inline pages="internal(2024/info/secrets-before)" raw="yes"]]
+
+This is my first Emacs mode, and it was primarily driven by necessity. The process was manual prior. I wanted to encrypt and decrypt all operations within my current Emacs instance. Currently, I have some notes on how to quickly decrypt and encrypt using AWS KMS. However, it works seamlessly with GPG. I need to add some notes on the age and GCP KMS.
+
+About the speaker:
+
+My name is Jonathan Otsuka. I have a background in software development and SRE/DevOps. In my free time, I enjoy optimizing my workflow, contributing to open-source projects I use, and engaging in swimming and cycling.
+
+
+
+[[!inline pages="internal(2024/info/secrets-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/secrets-nav)" raw="yes"]]
+
+
diff --git a/2024/talks/students.md b/2024/talks/students.md
new file mode 100644
index 00000000..7a6168ba
--- /dev/null
+++ b/2024/talks/students.md
@@ -0,0 +1,47 @@
+[[!meta title="An example of a cohesive student workflow in Emacs"]]
+[[!meta copyright="Copyright &copy; 2024 Daniel Pinkston"]]
+[[!inline pages="internal(2024/info/students-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. --->
+
+
+# An example of a cohesive student workflow in Emacs
+Daniel Pinkston (he/him) - IRC: bardman, develop dot bard at-symbol gmail dot com
+
+[[!inline pages="internal(2024/info/students-before)" raw="yes"]]
+
+Most successful students have a go-to system for staying organized. It
+might be Notion, Obsidian, a bullet journal, or a simple paper planner.
+ The key is finding what fits your personal needs and style. Here's an
+interesting option some students might not have considered: Emacs.
+It's a tool that's popular with Linux people, but possibly overlooked by
+others. For the right person, it could be a game-changer in managing
+academic life.
+
+This talk is meant to showcase how different Emacs tools integrate with
+each other to create a cohesive work environment for students.
+
+Links:
+
+-   Denote <https://github.com/protesilaos/denote> - the keystone package for my preferred note taking method
+-   Logos <https://github.com/protesilaos/logos> - a focus-mode tool for writing
+-   PDF-tools <https://github.com/vedang/pdf-tools> - pdf viewer
+-   Anki-editor <https://github.com/louietan/anki-editor> - my favorite package for making flashcards in Emacs
+-   Org-fragtog <https://github.com/io12/org-fragtog> - auto toggles LaTeX fragments in my org documents
+-   Org-download <https://github.com/abo-abo/org-download> - facilitates quick image addition to org documents
+-   My Emacs configuration <https://github.com/BardofSprites/.emacs.d> - includes not only writing, but programming
+
+About the speaker:
+
+I am Daniel Pinkston, a high school student (grade 12) interested in Emacs,
+Linux, programming, and customizable/libre software. I have been using
+Emacs since 2022, starting with DOOM Emacs.
+
+
+
+[[!inline pages="internal(2024/info/students-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/students-nav)" raw="yes"]]
+
+