IRC notes from day 2

16 files changed, 255 insertions, 34 deletions

diff --git a/2021/talks/bidi.md b/2021/talks/bidi.md
index 340cbcea..96fc16c8 100644
--- a/2021/talks/bidi.md
+++ b/2021/talks/bidi.md
@@ -10,8 +10,6 @@ Mohsen BANAN -- <mailto:emacs@mohsen.1.banan.byname.net> --  محسن بنان
 pronouns: he/him, pronunciation: MO-HH-SS-EN  
 <http://mohsen.1.banan.byname.net>
 
-
-
 [[!inline pages="internal(2021/info/bidi-schedule)" raw="yes"]]
 
 ## About The Video
@@ -127,5 +125,32 @@ of bidi on existing emacs applications, including:
 <http://mohsen.1.banan.byname.net/persian> -- Farsi  
 <http://mohsen.1.banan.byname.net/french> -- French  
 
+# Discussion
+
+
+- Does OS-level stuff work when you have to change character direction on the same line, like LtR numbers in a RtL script?
+
+Feedback:
+
+- This is great. I've done a demo like this for a few friends in the past as well.
+- Whoever did the captions for this was spot on, the unicode characters would be challenging.
+- I just love the Emacs input method framework, and I don't think a lot of latin script users know about it.
+- This is really cool, it's something that I never think about from other users in other countries using Emacs.
+- The captions for this conference have has an impressive amount of work put into them.
+- omg! this is great. farsi 101 in emacs 
+- ++ to all that stuff.  Great job on the captions, and the demonstrated functionality is very impressive.
+- Yay for the captions!
+- This has been really slick. Kudos for the captions including the Farsi characters and latin text.
+- At first, I thought the captions would be unnecessary, but over time, understanding the accents for various individuals has been challenging, so the captions helped.
+- One struggle I have with this input method option is, why not use an IME that's installed on the host OS? I mean, I do that with Japanese, but that may no longer work easily with qubes, so maybe it's more of a thing that'd benefit me now.
+  - though, I'm thinking that certain input methods don't actually simulate key-presses on virtual keyboards ... ?
+  - Not a primary reason, but since I'm used to configuring Emacs, I've found it a lot easier to learn to configure the integrated IMF than to configure an external one.
+  - I used SCIM/uim for japanese input at one put, but that was before I used emacs, it was a nightmare to set up
+- I may have to try this, the IMEs I've used haven't been an issue too much in the past, but...maybe this would be better, at least I wouldn't have to worry about config on each qube.
+- Banan's work on BIDI support is an eye-opener...
+- yeah absolutely. it's a really great point that Emacs can always be expanded to be more inclusive to other languages in ways that are more than just Unicode related.
+- bidi destorying irssi, time to find a good emacs irc client ...
+- thanks for the talk...another example how Emacs is inclusive catering for all forms of text.
+
 [[!inline pages="internal(2021/captions/bidi)" raw="yes"]]
 [[!inline pages="internal(2021/info/bidi-nav)" raw="yes"]]
diff --git a/2021/talks/bindat.md b/2021/talks/bindat.md
index ab17e469..87da714b 100644
--- a/2021/talks/bindat.md
+++ b/2021/talks/bindat.md
@@ -8,8 +8,6 @@
 # Turbo Bindat
 Stefan Monnier
 
-
-
 [[!inline pages="internal(2021/info/bindat-schedule)" raw="yes"]]
 
 
@@ -25,11 +23,9 @@ Emacs-28, Bindat was rewritten so as to make it more efficient and
 flexible while respecting the kitten. In this presentation I intent to
 show how we saved those. Not recommended for birds.
 
--   ~20 minutes:
-    5 min: Intro and presentation of Bindat
-    5 min: Showcase some of its problems
-    5 min: Present the new design
-    5 min: Examples of what can be done with it
+# Discussion
+
+- I *hope* cl-loop is more efficient than building a bunch of intermediate lists when you chain map/filter/reduce operations.
 
 
 [[!inline pages="internal(2021/captions/bindat)" raw="yes"]]
diff --git a/2021/talks/build.md b/2021/talks/build.md
index dcea8624..7ec0da46 100644
--- a/2021/talks/build.md
+++ b/2021/talks/build.md
@@ -28,10 +28,25 @@ and the challenges.
 
 For more details about CEDAR: <https://gitlab.com/sasanidas/cedar>
 
--   40 minutes:
-    A dive into the Emacs/Lisp machines history, what makes GNU Emacs
-    an Emacs and how you can build an Emacs.
-
+# Discussion
+
+IRC nick: akrl
+
+- I think the performance stuff is mostly orthogonal to elisp.  ex. very large files or files with really long lines grind horribly.
+- agreed, it's typically the massive amount of code that needs to interact with eachother that causes the slowdown but Emacs Lisp itself seems fairly performant.
+- there is a WIP CL implementation written called SICL :) 
+  - akrl: yes but is bootstrapped from SBCL, so... :)
+- I know of three or four other attempts to write CL Emacsen. All long dead...
+- fundamentally there are not very many CL developers: there are probably many more elisp developers by now. C (and C++, and Java, and heck probably F# and Rust) have way more developers, so will always be more likely to gain enough momentum to not just die
+- the fashionable languages have lots of users but tend to fade away, CL is undead for ages... I would help in a CL implementation
+- I think everyone should write their own editor at some point.  It's a very good learning experience.
+  - Alan Kay says a similar thing about writing your own operating system
+  - With Emacs you get both! :-)
+- I would love to see '#_' reader macro in Elisp for comments. core.async port and maybe, immutable collection (but that one is too much to ask)
+- isn't that what Xi-editor tried to build on?
+  - it's definitely what xray tried to build on
+- akrl: I'm extremely skeptical on the feasibility of reaching 100% compatibility :) (with an approachable effort)
+  
 
 [[!inline pages="internal(2021/captions/build)" raw="yes"]]
 
diff --git a/2021/talks/day2-close.md b/2021/talks/day2-close.md
index f7bf2b84..00d459b9 100644
--- a/2021/talks/day2-close.md
+++ b/2021/talks/day2-close.md
@@ -4,8 +4,6 @@
 
 <!-- You can manually edit this file to update the abstract, add links, etc. --->
 
-
-
 # Closing remarks day 2
 
 [[!inline pages="internal(2021/info/day2-close-schedule)" raw="yes"]]
@@ -49,8 +47,14 @@
   - Organizers
   - Everyone
 
-# Feedback
+# Discussion
 
+- I really appreciate the approach of doing things prerecorded and having captions.
+- (please add a contact form for the website to make it easier for volunteers to sign up, sending an initial email can be psychologically intimidating.)
+  - i am willing to volunteer to think about /work on the form
+  - thanks! not sure if adding something like formspree would be counterproductive, but coming up with a list of ways to help out in an email takes a lot more energy than just adding your name and email to a list of potential volunteers.
+- we'll recommend opening the .webm directly as the main option
+- i managed to get a few people to watch my talk afterwards. letting them know it was only 10 minutes helped. non-emacs folks even :)
 
 [[!inline pages="internal(2021/captions/day2-close)" raw="yes"]]
 
diff --git a/2021/talks/eaf.md b/2021/talks/eaf.md
index 8ea7c786..78a52c78 100644
--- a/2021/talks/eaf.md
+++ b/2021/talks/eaf.md
@@ -15,12 +15,21 @@ application framework that extends Emacs graphical capabilities using
 PyQt5. There are many new but important updates since EmacsConf2020
 last year, this talk will briefly go over them.
 
-
-
-# Outline
-
--   5-10 minutes: (brief description/outline)
-
+# Feedback
+
+IRC nick: matthewzmd
+
+- One thing I never tried watching all this is viewing PDF files within emacs.
+- is there an eaf-app that's not a bootstrapping nightmare? I suppose having Vue as dependency makes that not so for a large number
+- This is pretty cool, from a security standpoint, I'm not sure I'd want a web browser in emacs all that much.
+  - With how Emacs deals with things like GPG/pass/etc. I feel like it's probably as secure as you make it?
+  - matthewzmd: TDT the browser application is independent from emacs itself, you're using a browser in emacs, but the browser is not actually in emacs
+  - If it can be secured under something like firejail, that may be better, as long as there's some segmenting with any communication between the two.  Then again, I generally run any browser in dedicated VMs.
+- ok now this is something i need
+- maybe i misunderstood, but is every eaf app essentially embedded QT?
+  - matthewzmd: Yes, it uses PyQt5 and it's essentially painting the Qt frame on top of emacs, simulating a buffer. EPC is used for Elisp <-> Python <-> JS communication
+  - I guess/hope this is using qtwebengine, not qtwebkit? ('cos qtwebkit is unmaintained and by now massively insecure)
+  - matthewzmd: if you wanna dig more into the internals of EAF, I suggest you to read this part of the Wiki (<https://github.com/emacs-eaf/emacs-application-framework/wiki/Hacking>) or my talk from last year (<https://emacsconf.org/2020/talks/34/>)
 
 [[!inline pages="internal(2021/captions/eaf)" raw="yes"]]
 
diff --git a/2021/talks/faster.md b/2021/talks/faster.md
index 43d30743..28b89b5d 100644
--- a/2021/talks/faster.md
+++ b/2021/talks/faster.md
@@ -7,8 +7,6 @@
 # Optimizing Emacs Lisp Code
 Dmitry Gutov
 
-
-
 [[!inline pages="internal(2021/info/faster-schedule)" raw="yes"]]
 
 [[!table header="no" class="speaker-details" data="""
@@ -28,6 +26,23 @@ Preferred contact info | <dgutov@yandex.ru>
     the bottleneck is. How to quickly load a byte-compiled version.
 -   Steps taken to speed up the Xref package recently.
 
+# Discussion
+
+IRC nick: dgutov
+
+- If somebody wants to do a remote session with me: I do have processes such as updating column view dynamic blocks that take maybe 40 minutes. So far, I avoid executing those functions when I'm around the computer myself. However, there may be room for improvement and I really can't tell wether it is in my personal setup or not because it's not always that easy to re-create a use-case with plain Emacs cnofig
+- Thanks for doing this talk.  FYI you might find the this bench-multi-lexical macro useful: https://alphapapa.github.io/emacs-package-dev-handbook/#outline-container-Optimization
+  - dgutov: I can't seem to find the exact macro you are referring to. But if it covers a use case benchmark-progn does not, consider contributing it to benchmark.el in the core.
+  - Sorry, try this link directly to that macro: https://github.com/alphapapa/emacs-package-dev-handbook#bench-multi-lexical The purpose of the macro is to compare different forms and show how they perform relative to each other
+  - dgutov: Ah yeah, that looks pretty cool. Less sure about the org format, but it must be nice for presentations.
+  - The Org format is good for documentation too.  But it just uses the output of benchmark-run, so it could easily be left in Lisp form.  :)
+  - dgutov: These things are really handy to have available in 'emacs -Q', though. When you're working on shaving some extra handful of percents.
+  - Yes, a few lines of code could be added to run the compiled code in a separate Emacs process.
+- https://github.com/alphapapa/emacs-package-dev-handbook compares some common ways to do common things in Elisp so you can see which is generally faster, e.g. https://github.com/alphapapa/emacs-package-dev-handbook#inserting-strings
+- PSA: buffer-local-value is generally much faster than with-current-buffer if all you need to do is get the value of a variable in a buffer
+- For more info about the performance of overlays vs text properties data structure, there's an Emacs TODO about it. C-h C-t and search for "Move overlays to intervals.c".
+- cl-defstruct getters/setters have compiler macros that expand into simple aref calls on vectors, they are very efficient
+
 [[!inline pages="internal(2021/captions/faster)" raw="yes"]]
 
 [[!inline pages="internal(2021/info/faster-nav)" raw="yes"]]
diff --git a/2021/talks/forever.md b/2021/talks/forever.md
index 12a49755..1f36160b 100644
--- a/2021/talks/forever.md
+++ b/2021/talks/forever.md
@@ -18,7 +18,24 @@ this talk, we'll take a look at why popular editors fade and the
 specific aspects of Emacs that will ensure it remains relevant
 regardless of mainstream popularity.
 
-
+# Discussion
+
+- My anecdotal evidence, is introducing my coworkers to org mode, and the intracacies of doing more and more in Emacs. It becomes an overwhelming advantage.
+- lots of really popular editors are primarily maintained by companies and dies when the backing companies stop maintaining it
+- Popularity also adds to people breaking features that long time users like me use everyday but they don't see as popular and so they feel the need to break for something different.
+- I think a lot of popularity could be gotten from introducing more people in academic fields to Emacs. Org-Mode is such a game changer on that front.
+- Now, Emacs is based on another mind-blowing idea. The idea of practical notation for lambda calculus, what is known as Lisp. Lisp, probably can be crowned as the most important idea in computer science. It just hard to think of something more influential than Lisp. Emacs is just a practical implementation (and frankly, not the best one) of that idea.
+- Yes.  Emacs is an editor for creating domain specific editors.
+- my only problem with the Emacs community is that the community in other language is non-existen
+- Would there be any way to have other Lisps like Guile be compatible with Emacs?
+  - Guile has an Elisp interpreter in its compiler tower, however it's afaik not up to snuff for actually running Emacs.
+  - the problem is the "big datatypes" like buffers and strings, which guile either doesn't do at all or which need expensive bidirectional transcoding across the boundary
+  - some like this? https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Using-Guile-in-Emacs.html
+- I think seeing power users do the things they do with Emacs and Org-mode and how prolific they are is a major selling point (thinking of *so* many people, but say John Kitchin comes to mind) 
+  - To piggy back on a previous comment, I think if people kept seeing the top people in their fields (be in science/academic, software engineering, devops, etc.) use Emacs and Org-mode and especially their uniquely powerful features (literate style with org-babel, etc), Emacs would start taking over beyond it's historically low single digit % adoption
+  - luckily for me, John Kitchin shows a lot of engineering applications of emacs and org-mode and I love those videos, but I can understand that a lot of people won't find someone like that for their profession
+  - The concurrent pushes for reproducible science, literate programming, literate devops, and so on, also contribute to making the case for Emacs & Org-mode
+- the performance point is spot on. That is one of the main reason why the neovim community is thriving  
 
 # Outline
 
diff --git a/2021/talks/form.md b/2021/talks/form.md
index 73fef6ee..093887ed 100644
--- a/2021/talks/form.md
+++ b/2021/talks/form.md
@@ -24,7 +24,27 @@ comes with a powerful system for object-oriented programming? Join me
 for a discussion of EIEIO, and learn how it can help you write more
 modular, flexible Emacs Lisp.
 
-
+# Discussion
+
+IRC nick: ieure
+
+- I didn't know that custom.el works with EIEIO that way, very nice
+- Dang Ian. What a talk, great demos.
+- Wow, that's a great talk.
+- Great talk. So with that Emacs is on pair with Smalltalk development environments now
+- For reference, transient.el, which we all know and love as the engine that drives the magit interface, is written via EIEIO afaik.
+- I reckon I should look more into it, I've always avoided it because I was afraid it wouldn't be /quite as nice/ as CLOS or GOOPS.
+  - ieure: It's missing a few things (most documented in the manual: https://www.gnu.org/software/emacs/manual/html_mono/eieio.html#CLOS-compatibility), but it's solid and worth using.
+    - Yeah when transient.el first came out I was impressed by how naturally it worked as part of that abstraction.
+- ieure: EIEIO all the things!  I had to cut it, but you can use dynamic dispatch based on major-mode, like: (cl-defmethod whatever ((mode (derived-mode python-mode)))) and then (whatever major-mode).
+
+- Also really nice for things like 'window-system.  I really like when callsites are clean and not cluttered with conditionals.
+- Can eieio do regexp dispatch? 
+  - ieure: Not currently, but it's possible to add.
+  - okay, so I don't need to feel too bad about coding up my own vtable for those then
+  - ieure: This is the thing that implements (thing (eql :whatever)) specialization, should be a good starting point if you want (thing (string-match-p "^foo")): <https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/cl-generic.el#n1164>
+  - thanks for the pointer, but I think I have some more pressing cl-defgeneric reimplementations to make before I touch that
+  - ieure: Extremely fair.  One thing I didn't get to touch on is that you can extend generic functions from anywhere.  So you don't have to patch up cl-generic.el, you can define a new method for a generic function defined anywhere, in any file.  Which rules.
 
 # Outline
 
diff --git a/2021/talks/imaginary.md b/2021/talks/imaginary.md
index d51918e7..a5416c28 100644
--- a/2021/talks/imaginary.md
+++ b/2021/talks/imaginary.md
@@ -29,6 +29,31 @@ iLambda. It is important to recognise IP because, for lack of a better
 term, it has far-reaching implications for intellectual property and the
 GPL. Please keep an open mind.
 
+# Discussion
+
+IRC nick: libertyprime
+
+- What Shane is saying right now reminds me a lot of the SICP opening words, about how programming, and computing ideas in general are all about dreams and magic. Creating an idealized solution from abstractions and building blocks.
+- This also reminds me of the concept of Humane Tech. Technology, and frameworks that are inherently conducive to human curiosity, intelligent, and all the best traits. <https://github.com/humanetech-community/awesome-humane-tech>
+- I think this is like semantic auto-complete on steroids, like tab completion of whatever your typing, or translation of something you've written into code for instance.
+- If you're worried about these kind of advances in AI, just remind yourself of how easily technology breaks
+- oh my god, executing code derived directly from GPT-3?! that's *lunatic*  curl | bash, eat your heart out
+- idefun definitely helped by a docstring
+  - yeah that's a use-case, gen from docstring
+- Man, I really think it would be awesome to have shane be able to explain some of these ideas more in depth as they are obviously very deep topics. I'd love to help contribute next year to possibly creating a way to have multiple talks going on at once so people have more time to speak. I believe it was sachac who mentioned it yesterday.
+- This vaguely reminds me of that one Python package that generates a CLI parser from the help string except that that python package actually made sense
+-  re slide 27, would it mean that 2 such "idefined" function would be the "same", meaning do the same thing the same way, given that they are defined without a "body"?
+- the full abstraction would look something like an interactive proof program where you could repeatedly refine the results until it matched what the user wanted
+- it started incomprehensible and then moved straight to impossible magic.
+- wow...mind blown even though that went by a bit too quick.
+- Hmm, I do think we could do test-driven imaginary programming tho i.e. you only define the ERT testcases and then do the rest with idefun
+- So `(imacro with-clifford-algebra (p q r))` would just "work"... this does feel too magical
+- I am really happy that someone is trying Deep Learning stuff *with* emacs and not just for writing Python code :D
+- well I've had pretty good success with GPT-3, I think this also supports GPT-j which is I think free/libre.
+- most users of GPT-3 do it via calls to a web api
+- is it still invite only?
+  - no, it's been opened recently
+
 
 
 # Outline
diff --git a/2021/talks/maintainers.md b/2021/talks/maintainers.md
index 2b06388b..3a06672e 100644
--- a/2021/talks/maintainers.md
+++ b/2021/talks/maintainers.md
@@ -16,12 +16,25 @@ After 11 years of helping as the Org maintainer, I would
 like to share a few lessons learned.  My goal is help everyone take
 care of Emacs maintainance by taking care of Emacs maintainers.
 
-
-
-# Outline
-
--   5-10 minutes
-
+# Discussion
+
+- I love it when people just kick it old school and write things out.
+- the spiderman syndrome is evil. it causes imposter syndrome that god knows how many contributors it has cost us
+- excellent analysis on bdfl/spidysyndrome, you can see it play out in other communities as well
+- Very interesting, I suppose I get an idea that maintainers are put on a pedestal, and you see a lot of the good, and bad from both sides of the spectrum. It can be thankless, but also incredibly rewarding. It's easy to miss the forest for the trees, and keep in mind that most every piece of FLOSS software is a very decentralized and maintanance heavy vs. centralized and focused on LOC. 
+- i don't get the project vs product
+  - project is the process of creating the product (usually)
+  - because "project" has been redefined over time to mean the product (such as the codebase), together with the project as in the endeavor to create/develop it
+  - Project is a greater scope than product, in my view.  A project is not only the code, but the relationships with others who interact with it.  The product can be the same, but doesn't usually include the support aspect since it's "free".  
+- FLOSS software is a fascinating psychological study on that ACDC concept.
+- i feel that this doesnt apply only to maintainers. So many managers should listen to it too
+- It is really good advice to keep in mind as a manager
+- GUIX has a really great community, and has folk like 'jgart' mainly, that has package maintaince workshops where they invite newbies and experienced users alike to contribute packages to GUIX. 
+- one of the things that hasn't been brought up yet is maintainer territoriality, I know for many of my projects I can be quite territorial, sometimes unintentionally
+- That kind of contribution is invaluable for being an inviting environment for congtributing to a project.
+- I think even if the maintainer doesn't intend this potential contributors can perceive it
+- Awesome talk! Not just in the context of Org-mode!
+- The hand written slides are so engaging!
 
 [[!inline pages="internal(2021/captions/maintainers)" raw="yes"]]
 
diff --git a/2021/talks/mold.md b/2021/talks/mold.md
index 24f85165..95e55e03 100644
--- a/2021/talks/mold.md
+++ b/2021/talks/mold.md
@@ -35,7 +35,15 @@ world!
 
 You can learn more about this at: <https://github.com/ag91/moldable-emacs>
 
+# Discussion
 
+IRC nick: `andrea
+
+- cool...so essentially you are developing a text based version of Glamorous Toolkit.
+  - `andrea:  yup, but only because I don't have good imaging in Emacs yet (but with tui.el...)
+- your talk helped a lot with that though. I'd been seeing posts from you for a little while, but now I "get it"
+  - `andrea: yeah sorry, I am still building my vision: it may look I have been all over the place (image recognition, editing css, parse English lately), but the common thread is the easing of creation of micro tools that help me tell the stories I need
+- I love your approach of mining other 'nuggets' from other contexts and bringing them to Emacs. I really look forward to looking in to your work and see if I can implement some of it. Thank you so much for your talk.
 
 # Outline
 
diff --git a/2021/talks/native.md b/2021/talks/native.md
index b581c222..3de0494e 100644
--- a/2021/talks/native.md
+++ b/2021/talks/native.md
@@ -31,6 +31,27 @@ During the presentation I'll touch on:
 
 Format: 40 minutes
 
+# Discussion
+
+IRC nick: akrl
+
+- What's the risk of (setq native-comp-speed 3)? will it melt my cpu?
+  - The same as the risk of using -O3 with gcc. It gives itself the latitude to aggressively optimise away code elements which it believes are unnecessary, up to and including violating the language semantics of lisp (which gcc doesn't inherently care about). -O3 is something which is fine for specific cases where you test afterwards, but you would never, for example, set -O3 globally in Gentoo.
+- so we can get type annotations in Elisp?!
+- Is there a benefit in setting native-comp-compiler-options to "-mtune=native -march=<cpu>"?
+- Would Eli agree on replacing the C parts of Emacs with Elisp? ;)
+- Why not implement Emacs Lisp in Guile and use Guile's compiler?
+  - https://www.emacswiki.org/emacs/GuileEmacs
+    - guile elisp is a very-long-term project, but so far has never been good enough: the problem seems to be, alas, time overhead involved in bidirectional conversion of strings and things like that: and unfortunately Emacs is all about strings... guile can run elisp (or something very like it) but that's not anywhere near replacing the elisp interpreter...
+
+Feedback:
+
+- what a great talk. this will rise the hype for emacs 28
+- This work is really amazing. Congratulations on the effort and the deep insights that made this possible.
+- excellent presentation and work that will be greatly appreciate by all Emacs users.
+- It is very humbling to see this depth of knowledge and how it positively impacts my day to day computing experience.
+- this is a very interesting update on his talk at last year's GNU Tools Track at LPC :)
+- The worse thing about native comp is that you get used to it after a couple of days and you don't appreciate it anymore! ;) which is not fair...
 
 [[!inline pages="internal(2021/captions/native)" raw="yes"]]
 
diff --git a/2021/talks/org-outside.md b/2021/talks/org-outside.md
index 0df228e3..f6dd2e6c 100644
--- a/2021/talks/org-outside.md
+++ b/2021/talks/org-outside.md
@@ -56,7 +56,19 @@ IRC nick: publicvoit
 - already uses the ".org.txt" file extension, so that tools that don't otherwise support the org file type will at the very least read them
 - sorry to have missed out on the discussion during your talk, but I'm extremely interested in getting org working outside elisp (re: https://github.com/tgbugs/laundry/tree/next). I started there long ago, at this point the issues that really need standardization is org-babel, but in order to do that we need the syntax settled, which has turned out to be a _lot_ of work
 - having orgdown as a way to talk about files that have org syntax seems like it is a critical piece for effective outreach
-
+- would it be worth considering a decoupling of the "orgdown" proposal into 1) just a proposal to rename "org" the markup as "orgdown" (vs "org-mode" for the piece of software running in Emacs), and 2) all the rest as in the levels/etc? Just to not put the first at risk of non-adoption because of the contents of the second? There seems to be a lot of positive sentiment towards solving #1 for sure.
+  - orgdown is not org, the markup
+  - orgdown is lightweight org, it does not have all the features
+  - In general I agree, there will be issues with how to approach the levels
+  - publicvoit: Valid approach but this train has left the station already by the decision of myself to provide OD1 to the public this weekend.
+- To be fair, I personally don't think adding tiers to org-mode makes much sense
+  - We should rather have a feature matrix for stuff like pandoc to check against
+  - developing the test suite will get us there, and then we can have the discussion about how to market the levels
+- I think we could adopt orgdown almost immediately without issue
+- I don't really see a big issue with org-mode vs. org vs. orgWHATEVER though
+  - there are major search and discovery issues with bare "org"
+  - I tend to use "org syntax" at the moment, but it isn't catchy enough
+  
 # Outline
 
 - The term Org mode stands for different things
diff --git a/2021/talks/structural.md b/2021/talks/structural.md
index d4ce9188..c301fc3b 100644
--- a/2021/talks/structural.md
+++ b/2021/talks/structural.md
@@ -44,6 +44,25 @@ syntax tree generation.
 
 Check out the GitHub repo [here](https://github.com/ethan-leba/tree-edit)!
 
+# Discussion
+
+IRC nick: ethan
+
+- any chance you tried this with Clojure as well?
+  - ethan: haven't tried it yet, i don't think tree-sitter-langs has a clojure grammar AFAIK
+    - yeah I use sogaiu's (https://github.com/sogaiu/tree-sitter-clojure) but it does not have if else and the rest, only the main data types
+- so tree-edit is orthogonal to the LSP features?
+- did not know that miniKanren had an elisp port
+- Seems like a really cool use of logic programming. All the examples I've heard of are much simpler than this.
+- Wow, voice control is a good point
+- Could tree-edit be made to work with Org (orgdown!) itself, or maybe rather what would be needed to get such a unified tree-editing framework to work also for complex Org trees?
+- Awesome talk. I'm definetly going to try out tree-edit later :)
+- Amazing talk!! Such a cool project
+- `andrea: absolutely! Also for Orgdown - which is a good start since it is much easier.
+- Andrew Blinn's talk on Fructure and Ethan Leba's talk on Tree-edit are really insightful.
+- Agreed about the lack of formal grammar (only a proliferation of parsers) being a limiting factor. Maybe we could bridge directly to the available commands without going through a grammar though. A unified tree-editing framework across languages but definitely including Org would be awesome (ala lispy/etc).
+
+
 # Outline
 
 -   Discuss motivation                          (Why should I care?)
diff --git a/2021/talks/test.md b/2021/talks/test.md
index f00f2f1d..b858bd4e 100644
--- a/2021/talks/test.md
+++ b/2021/talks/test.md
@@ -42,6 +42,20 @@ precisely: to more major modes).
 
 Eduardo Ochs <http://angg.twu.net/emacsconf2021.html>
 
+# Discussion
+
+IRC nick: edrx
+
+- I love the slide annotations!  They are really nice. :-)
+- Love the Racket's (module+ ...)  but this test blocks are interesting too...
+- looks like eev should be using eieio to me :)
+- am I the only person who never heard of eev before this talk and now has a million uses for it? I've wanted this thing for ages
+  - You're in luck! You can check EmacsConf 2019 and 2020 for more eev goodness.
+  - that happens every time edrx does a talk on eev!
+  - <https://emacsconf.org/2019/talks/27/>
+- does language support take a lot of work, or did I miss you relying on a different package that handles that?
+- Cool!  So this is kind of like a generic version of Python's doctests? (https://docs.python.org/3/library/doctest.html) 
+  - edrx: I don't think so... is it possible to run python's doctests line by line? Also, see this: https://www.youtube.com/watch?v=QUMo7vgkHJI#t=6m36s - we can change the tests on the fly...
 
 [[!inline pages="internal(2021/captions/test)" raw="yes"]]
 
diff --git a/2021/talks/ui.md b/2021/talks/ui.md
index 10a4e1e3..1bf3c854 100644
--- a/2021/talks/ui.md
+++ b/2021/talks/ui.md
@@ -30,7 +30,15 @@ updating textual content as application state changes.  This talk will
 cover use of the tui.el API and its operation in a textual environment
 by implementing some basic UI's.
 
-
+# Discussion
+
+- I'm trying the run your demos of tui... it seems that (add-to-list 'load-path "~/usrc/tui.el/") is not enough, I have to either add the subdirectories by hand or to run a standard function - whose name I don't know - to add the subdirs...
+- hey, I'm trying to run your demos of tui... I had to add the subdirectories to the load-path manually to make (require 'tui-tic-tac-toe) work. my notes are here: https://0x0.st/-7dV.txt
+- tui.el is very exciting, should open up a new era of more advanced UI in Emacs
+- seems like we can get some really cool emacs ui going in combination with svg.el
+- combine with the magit approach to menus (transient etc) and something very nice is coming!
+- I think anything you can show in a buffer should work with this, so images, text, whatever.
+- tui.el is just too cool: I am going to try it for sure :D
 
 # Outline