diff options
Diffstat (limited to '2021/talks')
54 files changed, 5108 insertions, 0 deletions
diff --git a/2021/talks/babel.md b/2021/talks/babel.md new file mode 100644 index 00000000..cd28d54b --- /dev/null +++ b/2021/talks/babel.md @@ -0,0 +1,114 @@ +[[!meta title="Babel for academics"]] +[[!meta copyright="Copyright © 2021 Asilata Bapat"]] +[[!inline pages="internal(2021/info/babel-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + +# Babel for academics +Asilata Bapat + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/babel-schedule)" raw="yes"]] + +Plain org-mode is already an extremely powerful and +customisable tool for task and time management, note-taking, calendar +and agenda management, and much more. Babel takes org a step further +by letting you write, evaluate, and export code in different languages +from within a single file. In this talk, I will highlight some +features of babel that I find exciting and extremely useful, +particularly for an academic workflow. + +Getting started with babel can be intimidating, but it's hard to stop +using it once you start. As an academic, I typically don't manage +large coding projects. My primary purpose is writing lecture notes, +assignments, and papers, and managing related admin. Typically, I want +to try and automate the boring portions of my workflow without extra +overhead. I also tend to find various tasks easier in some programming +languages and harder in others, and prefer to mix and match languages +as the task dictates. Babel makes this process seamless. + +A basic use case is writing a document in org-mode and exporting it to +LaTeX or HTML. Org-mode even lets you write multiple documents in a +single org file, which can be convenient. Babel lets you add all sorts +of enhancements to the same file. For example, suppose we have a +single org document with all the problem sets for a course. Within +this single file, we could now: + +- draw pictures in ditaa, graphviz, or python instead of LaTeX, +- use python to do complex calculations and then output the result as LaTeX, +- define skeletons to quickly draw up assignment templates, +- toggle exporting of assignments with or without solutions based on tags, +- locally change export settings or run a post-export hook, +- automatically export to LaTeX after saving, +- tangle code blocks from some or all of the languages to external files. + +I will try to showcase features of babel that academics could find +helpful, by presenting some ways in which I have tried to use babel. I +would also like to be inspired by other people's babel workflows! + +# Links +- Course webpage: <https://asilata.github.io/ggm/2021/> +- Code: <https://github.com/asilata/emacsconf2021> +- Code (gitlab mirror): <https://gitlab.com/asilata/emacsconf2021> + +# Discussion + +IRC nick: asilata + +Pad: + +- Q1: The talk was amazing thanks! I show the img inline in the Org + file with org-toggle-inline-images, maybe useful to others too. + - A: Thanks! I do that if I want to look at previews, too, but + sometimes it slows down my document. Any tips for that? +- Q2: I always tried to use Tikz for showing diagrams in Org Mode + documents, but dot code blocks definitively make drawing graphics + easier! Thanks for sharing! + - Remark by Karl: In my personal workflows, I love the abstraction + layer of <https://plantuml.com/> + +From BBB: + +- Don't have a question, just to say inspiring to see how you use org-mode + babel. Thx! +- Ha, a question, is your setup online somewhere? +- Asilata Bapat: <https://github.com/asilata/emacsconf2021> +- thanks so much for the presentation and sharing the details of your workflow +- I particularly appreciated your "causal use" of skel :D + +IRC: + +- the export-setup block is a great use case for orgstrap :) + - asilata: I was just thinking that after the orgstrap presentation :) +- Man I was just wondering how to write LateX in Emacs this is incredible. +- I really liked the resulting LaTeX output file -- looked gorgeous :) +- Yeah seriously. I am pleasantly surprised. I think I'll have to switch over to using Emacs and LateX +- Theme: zenburn +- wait ... does elisp support unicode lambda like racket? + - I mean... you can make it, but not out of the box. + - asilata: I think it's just an org prettification + - prettify-symbols-mode +- do you use latex preview in the org buffer too? + - asilata: no, I usually don't, I find it slows down my system a bit. +- some very nice examples of wicked-cool org stuff there :) +- I also use python to generate latex from babel so that I don't mess things up + +From [YouTube](https://www.youtube.com/watch?v=1Ooi4KAd2FM&feature=em-comments): + +- Cool talk! I suggest to export your diagrams to some vector format (PDF, SVG, etc.) if you (as you say) embed it in LaTeX/PDF later. Otherwise, you can see blur on a large enough scale. + + +Links: + +- <https://asilata.github.io/ggm/2021/> +- <https://github.com/asilata/emacsconf2021/> + +# Speaker information +- Name pronunciation: /ˈəsɪʟət̪ɑ ˈbɑpəʈ/ UH-si-luh-tah BAH-putt +- Pronouns: she/her +- Homepage: <https://asilata.github.io> +- Email: <mailto:asilata.bapat@anu.edu.au> + +[[!inline pages="internal(2021/captions/babel)" raw="yes"]] + +[[!inline pages="internal(2021/info/babel-nav)" raw="yes"]] diff --git a/2021/talks/bidi.md b/2021/talks/bidi.md new file mode 100644 index 00000000..5669a817 --- /dev/null +++ b/2021/talks/bidi.md @@ -0,0 +1,195 @@ +[[!meta title="Perso-Arabic Input Methods And BIDI Aware Apps"]] +[[!meta copyright="Copyright © 2021 Mohsen BANAN"]] +[[!inline pages="internal(2021/info/bidi-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Perso-Arabic Input Methods And BIDI Aware Apps +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 + +The video is a screen capture of a [reveal](https://revealjs.com) presentation +prepared with Beamer XeLaTeX and [HaVeA](http://hevea.inria.fr). So, the +[original reveal +presentation](http://web.by-star.net/lcnt/PLPC/180063/current/pres/PLPC-180063-pres.html) +allows you to click on links that you see in the video and also navigate through +the slide. In html, it is also availble as a [Presenation-As-Article +format](http://web.by-star.net/lcnt/PLPC/180063/current/presArt/PLPC-180063-presArt.html) +which includes complete text of the audio. [The traditional beamer slides]( +http://web.by-star.net/lcnt/PLPC/180063/current/pres/PLPC-180063-pres.pdf) are +also available. The Access Page for +[PLPC-180063](http://www.by-star.net/PLPC/180063) points to all available forms +and formats. + +## About This Presentation + +Emacs is a multilingual user environment. A true multilingual editor must +support bidirectionality and shaping of characters. Perso-Arabic scripts require +both of these features. + +Starting with Emacs 24, full native bidi +(bidirectional) support became available. For +many years prior to that Unicode support was +available and by around year 2000, reasonable +open-source shaping libraries were also available. + +With these in place at around 2012, I developed +two Persian input methods for emacs. These input +methods or variations of them can also be used for +Arabic and other Perso-Arabic scripts. + +With all of these in place, Emacs has now become +the ne plus ultra Libre-Halaal and Convivial usage +environment for Perso-Arabic users. + +Since emacs comes loaded with everything (Gnus +for email, Bbdb for address books, XeLaTeX modes +for typesetting, org-mode for organization, spell +checkers, completion systems, calendar, etc.), all basic +computing and communication needs of Perso-Arabic +users can be addressed in one place and +cohesively. + +In this talk I will demonstrate what a wonderful +environment that can be. + +My talk will be in two parts. + +In Part 1, I cover Persian input methods. With an emphasis on "Banan +Multi-Character (Reverse) Transliteration Persian Input Method". The +software is part of base emacs distribution. Full documentation is available +at: + + + Persian Input Methods + For Emacs And More Broadly Speaking + شیوههایِ درج به فارسی +<http://mohsen.1.banan.byname.net/PLPC/120036> + +In Part 2, I'll demonstrate that Emacs is far more than an editor. Emacs can be +a complete Perso-Arabic usage environment. I will also cover the ramifications +of bidi on existing emacs applications, including: + +- Spell Checking, Dictionaries And Completion Frameworks: + - Existing emacs facilities can be extended to cover Perso-Arabic. + +- Gnus: + - Perso-Arabic rich email sending in HTML. + - Ramifications of bidi on from:, to: and subject: lines. + +- Bbdb: Ramifications of bidi on display and completion. + +- Calendar: + - Ramifications of bidi on display. + - Use of Persian text for Persian (solar) calendar. + - Use of Arabic text for Muslim (lunar) calendar. + +- AUCTeX: Persian typesetting with XeLaTeX + - Option of having right-to-left Perso-Arabic aliases for all latex commands. + +# References: + +## Persian Input Methods: +<http://mohsen.1.banan.byname.net/PLPC/120036> +<http://www.persoarabic.org/PLPC/120036> -- Persian Input Methods Access Page +<http://www.persoarabic.org> -- Various Perso-Arabic resources +<http://www.freeprotocols.org/Repub/fpf-isiri-6219> -- Re-Publication Of + Persian Information Interchange and Display Mechanism, using Unicode +<https://github.com/bx-blee/persian-input-method> -- Git repo for + persian.el -- Quail package for inputting Persian/Farsi keyboards + +## BIDI: +<http://www.unicode.org/reports/tr9/> -- Annex #9 of the Unicode standard +<https://www.gnu.org/software/emacs/manual/html_node/elisp/Bidirectional-Display.html> + Emacs Bidirectional Display +<http://www.persoarabic.org/answers> + Paragraph Directionality Results Into Serious Communication Problems + +## Blee and Persian-Blee: +<https://github.com/bx-blee/env2> -- Very messy work-in-progress git repo for: + Blee: By* Libre-Halaal Emacs Environment +<http://www.by-star.net> -- A Moral Alternative To The Proprietary American Digital Ecosystem +<http://mohsen.1.banan.byname.net/PLPC/120033> -- + Nature of Polyexistentials: + Basis for Abolishment of The Western Intellectual Property Rights Regime +<http://mohsen.1.banan.byname.net/PLPC/120039> -- Defining The Libre-Halaal Label + +## Mohsen BANAN -- محسن بنان: +<http://mohsen.1.banan.byname.net/> -- Globish +<http://mohsen.1.banan.byname.net/persian> -- Farsi +<http://mohsen.1.banan.byname.net/french> -- French + +# Discussion + +Pad: + +- Q1: is there any additions that you have to add to emacs for using + non-English/latin characters or does it work mostly out of the box? + - A: [Prot] : I only set the default-input-method to "greek". + Then switch to it with C- (toggle-input-method) +- Q2: One stuggle I have with this input method option is, why not use + an IME that's installed on the host OS? + - A:I live inside Emacs, and that the host OS typically provides + an unintelligent keyboard, and Farsi and transliterate BANAN + provides multi-character input, which is a lot more powerful. +- Q3: Do you write any lisp or other code/markup with these scripts? + (Sorry if I missed you mentioning this.) + - A:No, everything is in pure Elisp. +- Q4: What alternatives have you looked into for solving the problem + related to your markup language idea? What isn't achieved by them? + - A:The way that Emacs has evovled about properties about string + and text. And I suggest we adopt the "web" model for Emacs + application development. If you step back and look at where we + are, there's no such thing as no 'emacs native markup language + mode' similar to HTML for web. Emacs's display engine is + capable of doing everything, but we're not exposing .... + (sorry, missed this part) + - Makes sense to me, thanks! +- Q5: bandali: genenrally curious about the state of writing/reading + Persian in the TTY +- Q6: Does your input method also solves problems with exporting + doctuments ? usually when you exporting a Persian-Enlight doc it + redirects the Persian scripts to LTR + +Questions/comments: + +- Thanks for giving such a nice presentation of the Emacs input method framework! I'm just curious about if you've made any plans for setting up your markup language? I know you said you hadn't written any code for it yet. +- That makes sense. Do you think you could use org more exclusively, and just add portions to implement your idea? As-in, there's nothing within org mode that would need to be fundamentally changed, correct? +- I wonder about that. Org doesn't quite support all the expressivness that you see in some buffers/modes. +- I agree. Finding a way to reach a happy medium without having to go "full elisp" would be quite powerful. +- Potentially the tui.el system mentioned earlier in the conference could mix will with your idea as well. +- I have one last, quick question. If you've used a version of Emacs 28, how have you found the new feature of doing a quick switch into a different IME? I know John Wiegly mentioned it in his talk earlier. +- 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. +- Lots to think about. Thanks for the talk and inspiration! +- Awesome. Thanks again for such a great talk and a great q&a! + +[[!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 new file mode 100644 index 00000000..e9cfffaa --- /dev/null +++ b/2021/talks/bindat.md @@ -0,0 +1,83 @@ +[[!meta title="Turbo Bindat"]] +[[!meta copyright="Copyright © 2021 Stefan Monnier"]] +[[!inline pages="internal(2021/info/bindat-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Turbo Bindat +Stefan Monnier + +[[!inline pages="internal(2021/info/bindat-schedule)" raw="yes"]] + + +# Table of Contents + + + +Bindat is an ELisp library to help manipulate binary data. This is a +niche library that is used by packages such as Websocket, EMMS, and +cpio-mode. Its implementation was repeatedly caught harassing hapless +kitten while at the same time providing poor service slowly. For +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. + +# Discussion + +- Q1: bindat seems very similar to GNU Poke (except that GNU Poke is a + superset, and then some, with a different syntax). I'm wondering if + it might be good to add a bindat variant that translates to/from + Poke if need be (using libpoke), for sheer insane blazing + native-code JITted speed. (And, later, maybe letting bindat gain + some of the insanely expressive capabilities GNU Poke has got). Its + use of eval blocked this in times past. but now... + - A:GNU Poke is indeed the natural evolution, and is much more + powerful. Given the fairly little use of BinDat so far, I'm + not sure there will be enough motivation to give access to GNU + Poke from Emacs, tho. One of the main benefits of using GNU + Poke would probably be that lots of formats are already + available for GNU Poke, so you could directly re-use them. +- Q2: Is your dog's name something Lisp or PL related...? :) + - A:Winnie? I don't think so, no (we didn't choose the name, in + any case) +- Q3: This looks amazing! Is it merged into mainline Emacs, a patch, + an external library? + - A: It's in Emacs-28 +- Q4: Are there benchmarks of this vs. the older bindat? + - A:There is a benchmark for it in the `elisp-benchmarks` +- Q5: Do you know of any CL or Scheme libs similar to bindat.el? + - A: No, but I'd be interested to hear about it if someone else + does. +- Q7: You are a hero of kittens everywhere. Do you have any feline + pets as well? :) + - A: Not yet. If you're near Montreal and you have a kitten for + me, I'm interested +- I *hope* cl-loop is more efficient than building a bunch of intermediate lists when you chain map/filter/reduce operations. +- Curious: how is gnu poke more flexible? +- What hobbies/interests do you have besides Emacs (and PL)? :) +- do you have any thoughts about how to make EmacsConf even better next year? +- I was surprised to see that a whole new DSL was developed for poke from scratch. Do you think would have been better to develop/improve a library like bindat on top of an existing language instead? +- What are some of your favorite talks from this conf so far? +- what kind of dog is Winnie? + - comment: I hadn't heard of that breed before +- How do you see more control over types (type hints/decl through type specifiers etc) (SBCL like programming model) coming into Elisp? +- Do you plan to add bit-level support? + +Other comments: + +- I can imagine using bindat to improve Emacs's music player packages +- yes last year the Q&A periods were much longer + - last year some of the presentations were live though +- I've asked this question to them during LPC 2020 but infact haven't got a very satisfactory answer :) +- If you ever write a library for window management in Emacs, you could call it winnie.el :) +- hints in unoptimized code should be assertions +- we probably need both ways of compiling: safe and less safe :) +- I think this is classic problem that is almost impossible to accomplish. many libraries try to do that but in the end the only working ones are relaying on C compilers. +- also you have the problem of size of objects. like how big is a long? this is not specified and is arch dependent +- parsing a generic .h file is way more difficult but is another subject. +- yep, the automatic translation is more for libraries trying to write automatically C bindings + +[[!inline pages="internal(2021/captions/bindat)" raw="yes"]] + +[[!inline pages="internal(2021/info/bindat-nav)" raw="yes"]] diff --git a/2021/talks/borg.md b/2021/talks/borg.md new file mode 100644 index 00000000..159e93a0 --- /dev/null +++ b/2021/talks/borg.md @@ -0,0 +1,34 @@ +[[!meta title="Manual Package Management in The Era of Repositories - Why and How"]] +[[!meta copyright="Copyright © 2021 Dhavan (codingquark)"]] +[[!inline pages="internal(2021/info/borg-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Manual Package Management in The Era of Repositories - Why and How +Dhavan (codingquark) + +[[!inline pages="internal(2021/info/borg-schedule)" raw="yes"]] + +Emacs now has many package repositories - enought to have conflicts +and arguments about. The packages are becoming big, they depend on many +other packages and it is not easy to keep track of what all is being +installed in our Emacsen. An aggressive way out of this is to use Yet +Another Package and install all elisp code manually - with borg[1]. + +[1]: <https://github.com/emacscollective/borg> + + + +# Outline + +- 5-10 minutes: (brief description/outline) + 1. What are we trying to solve? + 2. What is borg? + 3. How to use it? + 4. Assimilate a package for demo + + +[[!inline pages="internal(2021/captions/borg)" raw="yes"]] + +[[!inline pages="internal(2021/info/borg-nav)" raw="yes"]] diff --git a/2021/talks/bug.md b/2021/talks/bug.md new file mode 100644 index 00000000..7a2279dc --- /dev/null +++ b/2021/talks/bug.md @@ -0,0 +1,23 @@ +[[!meta title="Let's talk about bug trackers"]] +[[!meta copyright="Copyright © 2021 Bastien Guerry"]] +[[!inline pages="internal(2021/info/bug-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Let's talk about bug trackers +Bastien Guerry + +[[!inline pages="internal(2021/info/bug-schedule)" raw="yes"]] + +For 17 years, the Org developers didn't use a bug tracker, +shamelessly failing the Joel Spolsky test. Why was it "good enough"? +Why was it wrong? Why did we move to Woof!? Why Woof! is not a bug +tracker? + +- 20 minutes + + +[[!inline pages="internal(2021/captions/bug)" raw="yes"]] + +[[!inline pages="internal(2021/info/bug-nav)" raw="yes"]] diff --git a/2021/talks/build.md b/2021/talks/build.md new file mode 100644 index 00000000..c8edc0d8 --- /dev/null +++ b/2021/talks/build.md @@ -0,0 +1,72 @@ +[[!meta title="How to build an Emacs"]] +[[!meta copyright="Copyright © 2021 Fermin MF"]] +[[!inline pages="internal(2021/info/build-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# How to build an Emacs +Fermin MF + +[[!inline pages="internal(2021/info/build-schedule)" raw="yes"]] + +[[!template id="help" +summary="main talk does not have captions" +volunteer="João Pedro" +tags="help_with_main_captions" +message="""This talk does not have captions yet. Would you like to help [caption this talk](/2021/contribute/#edit-captions)? You may be able to start with these +[autogenerated captions](https://media.emacsconf.org/2021/emacsconf-2021-build--how-to-build-an-emacs--fermin-mf--main.vtt) +and [timing information](https://media.emacsconf.org/2021/emacsconf-2021-build--how-to-build-an-emacs--fermin-mf.en.srv2)."""]] + +This is a deep dive in the Emacs philosophical and technical +aspect on what makes our beloved GNU Emacs +what it it. It's also a talk about the early LISP machines and +fascinating were those days of experimentation and engineering. + +It will continue with the Emacs benefits/trade-offs from an +user/developer stand points, what things can be improved and +what can be an hypothetical path on how to build a software that +can also be called Emacs. + +As a last part, I'll talk about CEDAR, an Emacs that I've been +developing in Common Lisp, the project goals +and the challenges. + +For more details about CEDAR: <https://gitlab.com/sasanidas/cedar> + +# Discussion + +Pad: + +- Q1: Which level of compatibility with GNU Emacs do you want to achieve? + - A: I want to achieve 100% compatibility (when possible) +- Q2: Are you then planning to reimplment all Emacs C primitives? + - A:No, the underlayer would be different +- Q3: Do you plan on doing something to ease interaction between redundant "components" in both Elisp and Common Lisp (like CLOS and EIEIO)? How about semantic differences between both? + - A: (Probably answered by voice.) +- Q4: Have you used Nyxt, which is Emacs-like and written in Common Lisp? If so, what did you think about it? + - A: I think it's a great project and I would like to use it as a my main Browse (with the firefox extension layer) +- Q5: "Emacs is a great operating system, just lacking a good editor." How do you feel about the push to use Emacs as a full computing interface, and do you think Cedar could thrive in some of the fully common lisp system ideas that might catch on (like Robert Strandh's proposed CLOSOS)? + - A: I think CEDAR can achieve more integration with the OS (the same as the CL implementations) but I think the goal of been a good Emacs is good enought + +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"]] + +[[!inline pages="internal(2021/info/build-nav)" raw="yes"]] diff --git a/2021/talks/clede.md b/2021/talks/clede.md new file mode 100644 index 00000000..59bb10f6 --- /dev/null +++ b/2021/talks/clede.md @@ -0,0 +1,43 @@ +[[!meta title="CLEDE the Common Lisp Emacs Development Environment."]] +[[!meta copyright="Copyright © 2021 Fermin MF"]] +[[!inline pages="internal(2021/info/clede-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# CLEDE the Common Lisp Emacs Development Environment +Fermin MF + +[[!inline pages="internal(2021/info/clede-schedule)" raw="yes"]] + +I've been developing a package that helps with the development of +Common Lisp's software, +it's uses the internal semantic framework, it has a custom reader +and integration for +common Emacs packages (like Sly and the internal inferior-lisp-mode). + +The idea is to supply features that other language with and static +analyzer have, +like refactoring and code generation. + +For more details: <https://gitlab.com/sasanidas/clede> + +- 20 minutes: + It seems like not too much people knows about semantic, so I can + summarize some of it in 10 minutes + and then An explanation on how to use the package, how to extend it + and the future of it. + +# Discussion + +Pad: + +- Q1: You mentioned clede-start - is there also some kind of clede-stop? (I often get frustrated with functionality that I cannot disable / revert) + - A: There is no stop, you should never stop doing common lisp :) +- Q2: Is writing common lisp a big context switch between elisp? + - A: In some regards, it is, Ithink even more when you work Common Lisp professionally. + + +[[!inline pages="internal(2021/captions/clede)" raw="yes"]] + +[[!inline pages="internal(2021/info/clede-nav)" raw="yes"]] diff --git a/2021/talks/cs.md b/2021/talks/cs.md new file mode 100644 index 00000000..0b1fb3ad --- /dev/null +++ b/2021/talks/cs.md @@ -0,0 +1,84 @@ +[[!meta title="One effective CS grad student workflow"]] +[[!meta copyright="Copyright © 2021 Greg Coladonato"]] +[[!inline pages="internal(2021/info/cs-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# One effective CS grad student workflow +Greg Coladonato + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/cs-schedule)" raw="yes"]] + +When I was an undergrad, I learned many things, most of +which I forgot. In the time since then, I've discovered Org Mode, Org +Roam, Org Noter, Org Ref. PDF Tools, and Anki. I would like to share +my approach for capturing all the information that comes my way as a +MS CS student at Georgia Tech, in the hopes that I can both get +feedback on ways to improve the system I use, as well as hopefully +inspire others to build workflows that make them more productive. + +# Discussion + +IRC nick: gcoladon + +Pad: + +- Q1: Can org-roam also be used with EPUB files? It would be nice to + make notes for books as well. + - A: Interesting question -- I've never considered doing it that + way. When there is a textbook I want to take notes on, I find + the PDF for the textbook and split it into one PDF file per + section or chapter, and then use those PDFs just like any other + PDFs. What do you like about EPUB files? +- Q2: How does pdf-tools not being maintained as it used to affect + you. Since emacs have replaced image magic library and pdf-tools is + dependent on it how are you going to transition your work flow? + - A: Hmm I have not considered this at all. Is there some time in + the near future at which pdf-tools will stop working on the + current version of Emacs? I was not aware of that if that's the + case. Thanks for bringing that to my attention! +- Q3: Your workflow is very impressive. Would it be possible that you + share your emacs configuration files? (via email) + - A: Yes, I will work on collecting up the bits of elisp that make + up that configuration and share it , probably via Github gist. + +BBB: + +- I'm trying to develop one, but haven't spent enough time on it. (My interests are mostly related to programming language standards and history, and the PDFs are generally enormous and inscrutable.) +- have you ever considered org-ref for references? I think you used org-capture on the talk. Sorry If I am mistaken. + - gcoladon: I honestly don't know how one should use org-ref for references -- my references go into a bib file. And I use the org-ref convenience functions, but don't really know if I'm doing it right + - It sounds like others do love it +- I don't use org-roam; I'm using zetteldeft. Haven't made the leap to roam, as it seemed more of a real leap of faith that it would work and not change too much. +- Yes IIRC the heading property points to the PDF +- Thank you for you talk. So far, I've only used org-roam as a simple knowledge-base. I would love to replicate what you showcased. Organized notes associated with pdf docs that you then generate Anki cards with. Awesome stuff. +- If you have further links or tips on how you arrived at your current setup. A link to your emacs config?? +- Semi-related: M-l can downcase the next word quickly. + +IRC: + +- gcoladon: Yes it was software called ThoughtManager which ran on my Palm Treo 680 +- a similar workflow for videos using timestamps would be quite interesting +- this is a sweet script, surely it should be possible to write in elisp though... +- i know there exists the anki-editor package that works pretty well + - gcoladon: Yeah I am going to explore anki-editor sometime. It would be much better than my sed script :) +- how to get started? this is a great workflow + - gcoladon: not sure how to help people get started with this workflow, but I am happy to work on such a thing +- This is a workflow I really do like. Well done! +- interesting on the custom id approach, I stick a timestamp on nearly every heading that I create, but I never thought to make it a custom id +- gcoladon: I haven't tried to make my config sharable yet + +# Outline + +- 5-10 minutes: Go through some typical workflows associated with being a grad student, using the packages mentioned in the abstract. + +# Personal information + +- Name pronunciation: the syllables of my last name should be easy enough to pronounce for English speakers; the accentuation is colado-NA-to +- Preferred contact info: gmail account gcoladon + +[[!inline pages="internal(2021/captions/cs)" raw="yes"]] + +[[!inline pages="internal(2021/info/cs-nav)" raw="yes"]] diff --git a/2021/talks/dashboard.md b/2021/talks/dashboard.md new file mode 100644 index 00000000..53572fff --- /dev/null +++ b/2021/talks/dashboard.md @@ -0,0 +1,213 @@ +[[!meta title="Productivity Dashboards with Emacs and Kindle"]] +[[!meta copyright="Copyright © 2021 Mehmet Tekman"]] +[[!inline pages="internal(2021/info/dashboard-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Productivity Dashboards with Emacs and Kindle +Mehmet Tekman + + + +[[!inline pages="internal(2021/info/dashboard-schedule)" raw="yes"]] + +[[!table header="no" class="speaker-details" data=""" +Name pronunciation: | Meh-met Teck-man +Pronouns: | He/him +Preferred contact info: | @mtekman:matrix.org +Support: | <https://liberapay.com/mtekman/donate> +"""]] + +<https://gitlab.com/mtekman/kindle-sync> + +Since 2008, Amazon have released a new Kindle device every year, +supplanting each generation with a newer model that boasts highly +promoted incremental features which greatly devalues the price of +their older models. These forgotten models are sold on Ebay and +other secondhand websites at highly discount prices by owners who +do not see the true potential of these devices: Kindles are +excellent high contrast low-refresh display rate E-Ink devices, +with Wifi capability, that run embedded Linux in the +background. Depending on the model, an idle Kindle can last weeks +before needing a recharge. This makes them ideal as passive image +devices that can be configured easily using a few shell +scripts. Indeed, efforts have been made in dedicated hacker forums +to expose the Linux filesystem and to enable features such as +custom screensavers, SSH networking, and more. By exploiting these +features, and by carefully disabling the software/bloatware that +comes with the device, these Kindles have found new life as online +dashboard devices which can fetch and display information from the +internet at timely intervals. + +Here we describe a tool to control multiple Kindle devices with a +single org-mode/shell-based tool, built initially to periodically +serve updated Emacs Org-Agenda views, but later expanded to produce +online local weather reports and work calendar, Emacs calendars +(calfw, org-gcal), daily dietary information (org-calories), +Org-Mode sparse TODO trees, miscellaneous image and text content +(via imagemagick), small messages, and much more. + +In this talk, we show how to configure multiple Kindles with any +desired custom content, following any daily/weekly schedule, all +easily managed from Emacs within a single Org-Mode file. + +# Discussion + +- Q1: I know almost nothing about this stuff so please forgive my + ignorance (Actually, I did I dip a toe into some basic jail + breakage a few years ago and was delighted/intimidated to find a + capable community on mobilereads, as you mentioned; I was living + cheaply at the time, and having KUAL and KO and kterm around + improved my QOL considerably.) As for your talk, I enjoyed it very + much. I was wondering if you'd given any thought to possible + real-world applications for your dashboards. Just spitballing a + bit, a few possibilities came to mind, like perhaps disseminating + information on a work floor or lab setting where cable runs or + temperature increases from LCD monitors might be unwelcome; or + perhaps doing so in more a public setting like a refugee or + detention camp where power might be limited and where mounting TVs + behind protective glass or restraining them with cables might be + bad for morale. Also, have you thought about putting together + and/or selling "kits" so folks with limited time could acquire a + basic setup as a turnkey solution (perhaps with some assembly + required)? Thanks. +- Hi. Lovely idea to use an ebook reader as dashboard. Are all kindle devices supported or only older ones? +- Mehmet Tekman: I recorded this in two parts: with caffeine, and without +- As soon as i can get my hands on a kindle i will give this a try. Lovely Idea. +- Are the images only pushed or can i request for an update from the kindel itself? + - Mehmet Tekman: images are usually only pushed, but it's done over ssh so pulling is also possible. the main idea is that the interaction is only Server → Client +- Thanks for you talk I have just finished watching it on youtube. +- I have some old kobo's rather than kindle's but thinking of nipping onto ebay to get some + - Mehmet Tekman: I think it would work well Kobo's, since that's likely also a linux system right? + - yes they are linux + - Mehmet Tekman: There are only a few kindle-specific commands, but you can comment them out and adapt them for the Kobo + - there was some work getting kde onto them + - Mehmet Tekman: Woah you have access to an X11 session? + - i think the developers helped, but we are talking 7 years ago for the one they helped with + - Mehmet Tekman: it's not mainline then? + - I don't think so I still use them both for reading books so not messed with them just in case they break + - Mehmet Tekman: That's the beauty of the kindle, it's from such a horrible company and it's so cheap that you have no qualms if you break it :P + - Mehmet Tekman: The kindle basically locks you out of X, which is frustrating since the Kindle Touch runs AwesomeWM. If I had money, I would definitely buy one :O +- The use concept is really useful, so thanks for pointing me in the right direction. +- as someone who easily gets distracted it will be usefull to check on what I am supposed to be doing lol + - Mehmet Tekman: Welcome! For a more stripped down version I can really heavily recommend the kindle-dashboard from Pascal Widdershoven + - Mehmet Tekman: And yep -- I can definitely relate! + +Links: + +- Main Repo : <https://gitlab.com/mtekman/kindle-sync> +- Mobile Read Forum (Kindle) : + <https://www.mobileread.com/forums/showthread.php?t=180113> +- Mentioned Repos : + - <https://gitlab.com/mtekman/org-calories.el> + - <https://github.com/takaxp/org-tree-slide> + - <https://github.com/pascalw/kindle-dash> + +# Outline + +- 5-10 minutes: + + 1-3 mins + Talk about repurposing Kindles: + + - Cheap second-hand wifi device, hackable + - Low-powered, long battery life, low refresh rate – perfect + for a dashboard + - Timely updated Org-Mode Agendas anyone? + - Reference to inspired projects (kindle-dashboard) + + 2-3 mins + Generate content + + - A static text+picture image easily generated with imagemagick + wrapper + - An image of a sparse tree of org-mode TODO file + - An image of another emacs view (e.g. Calfw, or org-calories) + - Show post-processing for optimizing image for Kindles + + 1-2 mins + Configuration in a single org-mode file + + - Defining Machines + - Defining Commands to generate content + - Defining Schedules to run Commands on multiple Machines at + specific points in the day + + 1-2 mins + Export and Run: + + - Show exported shell configs and generated cronjobs + - Witness multiple Kindles producing desired content with wakeup + timers + +<!-- +- 20 minutes: + + 4 mins + Repurposing Kindles + + - Cheap second-hand wifi device, hackable + - Low-powered, long battery life, low refresh rate – perfect + for a dashboard! + - Reference to inspired projects (kindle-dashboard) + - Discuss Use Cases: + - Dynamic content: Org-Mode Agendas, Weather Reports, Web + Calendars + - Static content: Gallery, Motivational Messages + - Untapped potential + + 3 mins + Generate content + + - A static text+picture image easily generated with imagemagick + wrapper + - An image of a sparse tree of org-mode TODO file + - An image of another emacs view (e.g. Calfw, or org-calories) + - Show post-processing for optimizing image for Kindles + + 4 mins + Configuration in a single org-mode file + + - Defining Machines + - Defining Commands to generate content + - Types of commands + - Extending the commands with custom + - Defining Schedules to run Commands on multiple Machines at + specific points in the day + + 6 mins + Export and Run: + + - Show exported shell configs and generated cronjobs + - Scripts and Design Considerations: + - Killing services (to keep amazon out) + - Iptables blocking (to keep amazon out) + - What SSH keys are shared and where (to keep amazon out) + - How the Sleep and Wakeup timers work + - Optimizing for longer battery life + - Eips and X + - Minimizing service checks + - Graph of number of screen updates per drop in battery life + - View many Kindles simultaneously in action + + 3 mins + Final Thoughts + + - Limitations: + - Cannot interrupt a device's sleep, it wakes up only when you + last told it to + - Hard to see at night, invest in some LEDs maybe? + - Take back your devices! + - Name suggestions? "kindle-sync", "kindle-cluster", + - Something that won't be forced to change at a later date if + it becomes too notorious. + - Planned features + - Acknowledgments and Resources + +- 40 minutes: N/A +--> + +[[!inline pages="internal(2021/captions/dashboard)" raw="yes"]] + +[[!inline pages="internal(2021/info/dashboard-nav)" raw="yes"]] diff --git a/2021/talks/day1-close.md b/2021/talks/day1-close.md new file mode 100644 index 00000000..0425d237 --- /dev/null +++ b/2021/talks/day1-close.md @@ -0,0 +1,50 @@ +[[!meta title="Closing remarks day 1"]] +[[!meta copyright="Copyright © 2021 "]] +[[!inline pages="internal(2021/info/day1-close-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Closing remarks day 1 + +- Thanks for your patience with the technical issues! +- Hey look, we got captions! And prerecs! =) +- Prerecorded videos, transcripts, and other resources provided by the + speakers are already available on the talk pages. +- Tomorrow we'll have a bit more time for Q&A, so we might have more + of those on the main stream. +- Remember, there's a general-audience talk at the end of tomorrow's + program, so come and join us for M-x Forever by David Wilson of + SystemCrafters. + +[[!inline pages="internal(2021/info/day1-close-schedule)" raw="yes"]] + +# Discussion + +- Q1: To anyone who can answer this, what is a good method to request + speakers for next EmacsConf? + - A: Encourage the speaker directly when you see the next call for proposals. +- Q3: Is there a way to donate to the volunteers of EmacsConf? + - A: sachac: That's very thoughtful of you! We cover EmacsConf costs out of pocket. I think the speakers have some support links on their pages. So if you particularly liked a talk, please feel free to e-mail a speaker or see if they have a tip jar! + - sachac: also, if you want to contribute time by volunteering to help with EmacsConf this year or next year, that would be even better =) For example, it was super-helpful to have a couple of volunteers help me caption all the day 1 talks and most of the day 2 talks this year, _and_ they got early access to all the talks and could caption the talks they wanted. We did the captioning using subed.el in Emacs, using the speakers' Org files or autogenerated captions from Youtube as starting points. + - sachac: for example, if some people could help with streaming alternate tracks, we could have longer talks and longer Q&As, because I think we're just going to have more and more awesome Emacs talks, and I think we're reaching the limit of how much we can physically squeeze into two days ;) so our current strategy is lots of short talks/demos, and then people can learn more about the stuff that they find interesting. but it would be so nice to have more deep dives too. + - I think having alternate tracks is a great idea sachac, I think I noticed that speakers were very rushed because time was tight, and it'd be cool to that have that alleviated. And it would likely reduce stress for you guys so that technical issues aren't as dire. + - maybe if we can figure out some topics that would be good to dive deeper into (attendee feedback) that could be looked in to +- Q4: How can we sign up to volunteer for next year if there is need? + - A: <https://emacsconf.org/2021/contribute/> has some ideas and + an e-mail address you can reach us at. + +- Is there any documentation anywhere how to give financial support to EmacsConf? +- maybe each presentation should allocated five or ten minutes for a Q&A session afterwards before the next presentation starts. +- the subtitles are really good! you can tell it was human-written :) even nasty names are right +- Love the citations in subtitles. + +(from devel talk) + +- do you have any thoughts about how to make EmacsConf even better next year? + - yes last year the Q&A periods were much longer + - last year some of the presentations were live though + +[[!inline pages="internal(2021/captions/day1-close)" raw="yes"]] + +[[!inline pages="internal(2021/info/day1-close-nav)" raw="yes"]] diff --git a/2021/talks/day1-open.md b/2021/talks/day1-open.md new file mode 100644 index 00000000..47bc4a0b --- /dev/null +++ b/2021/talks/day1-open.md @@ -0,0 +1,60 @@ +[[!meta title="Opening remarks"]] +[[!meta copyright="Copyright © 2021 "]] +[[!inline pages="internal(2021/info/day1-open-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Opening remarks + +[[!inline pages="internal(2021/info/day1-open-schedule)" raw="yes"]] + +- Welcome to EmacsConf 2021 +- How to participate: + - Collecting questions, answers, and shared notes on Etherpad (https://etherpad.wikimedia.org/p/emacsconf-2021) + - You can also post questions and discuss things on #emacsconf on chat.emacsconf.org (frontend for libera.chat if you want to use your favorite IRC client) +- Conduct guidelines: + - One of the neat things about Emacs is that there are so many ways to do things. Please remember to be nice! =) +- What's new in this EmacsConf 2021 + - Lots of talks! Shorter time, Q&A might be live/pad/IRC, might have alternate stream if needed + - Streaming with open captions thanks to volunteers - all the day 1 talks have been captioned, and we might get day 2 sorted out too + - Prerecorded videos will be published as soon as we can (aiming for publishing them as the talks stream, so you can easily catch up with any talks you've missed) + - APAC-time-friendly alternate stream by LibreAustralia folks <https://libreau.org/past.html#emacsconf21> +- Thanks + - Speakers, volunteers + - Karl Voit for managing the pad + - Bhavin Gandhi and Hannah Miller for help with the captions + - Free Software Foundation, especially the FSF tech team, for their continued help and support + - LibrePlanet 2022 Call for Sessions open for a few more days; consider giving a talk! See <https://libreplanet.org/2022/> and <https://my.fsf.org/lp-call-for-sessions/> + - FSF's Fall 2021 fundraiser happening now! See <https://fsf.org/appeal> if you'd like to give :) + - Fosshost, for BigBlueButton server and for ftp-upload server + - Computer Science Club of the University of Waterloo, for continuing hosting the videos/files on the CSC mirror server + - Jan Prunk (yang), for EU mirror of EmacsConf videos/files: <https://de1.mirror.si/emacsconf/> + - Grant Shangreaux, for beautiful music :) (under CC BY-SA 4.0) <https://churls.world/basement-days/basement-days.html> + - Qiantan Hong (qhong), author/maintainer of crdt.el which we used for sharing Emacs buffers between organizers + - Wojciech Siewierski (vifon), for assisting zaeph with his scripts last minute + - Organizers + - Everyone +- 09:12 Schedule overview + - Day 1 (general talks), Day 2 (development) - but come back for some general-audience talks at the end of day 2, including the closing talk on M-x Forever by David Wilson (System Crafters) + - Day 1 + - Morning + - User stories + - Philosophy (including a talk by Prot) + - Configuration + - Demos of Emacs's flexibility + - Afternoon + - A peek behind the curtain at Emacs Development (janitor talk) + - Org Mode + - Workflows + - Tech + - Research + - External things + - Dev update + - On the design of text editors - Nicolas P. Rougier + - Even if you're not a developer, consider coming back for tomorrow's closing +- APAC stream + +[[!inline pages="internal(2021/captions/day1-open)" raw="yes"]] + +[[!inline pages="internal(2021/info/day1-open-nav)" raw="yes"]] diff --git a/2021/talks/day2-close.md b/2021/talks/day2-close.md new file mode 100644 index 00000000..00d459b9 --- /dev/null +++ b/2021/talks/day2-close.md @@ -0,0 +1,61 @@ +[[!meta title="Closing remarks day 2"]] +[[!meta copyright="Copyright © 2021 "]] +[[!inline pages="internal(2021/info/day2-close-nav)" raw="yes"]] + +<!-- 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"]] + +- Prerecs have already been posted, yay! You can find them on the talk pages and at <https://media.emacsconf.org/2021/> (We'll figure out how to get the Q&As.) +- Thanks to everyone who submitted talks to EmacsConf, including those + whose talks didn't make it into this year. We'll be + sharing more resources as they come in, so subscribe to <emacsconf-submit@gnu.org> +- Next steps + - We'd love to hear what you liked and what we can improve. + Please share your conference feedback and ideas at the end of the + Etherpad under the heading "General discussion about EmacsConf 2021" <https://etherpad.wikimedia.org/p/emacsconf-2021> or + e-mail them to us at <emacsconf-submit@gnu.org>. If you would like + to keep your feedback semi-anonymous, you can e-mail it to either + <bandali@gnu.org> or <sacha@sachachua.com> and we'll keep your + name private when sharing the feedback with the other organizers. + - Post your questions/thoughts to the + <https://etherpad.wikimedia.org/p/emacsconf-2021> Etherpad or + email it to us at <emacsconf-submit@gnu.org> by Dec 10, and we'll + e-mail your question to the speakers for following up + - Subscribe to emacsconf-discuss for announcements <https://lists.gnu.org/mailman/listinfo/emacsconf-discuss>, like when additional captions or videos become available + - There were lots of talks! Feel free to rewatch, follow links, and learn more. + - If you want to help caption talks (4 left! also, the archive) or Q&A, or help with other tasks, see [[/2021/contribute.md]] + - Keep in touch with Emacs News <https://sachachua.com/emacs-news> - weekly updates + - Check out <https://www.emacswiki.org/emacs/Usergroups> to find a user group near you or online +- Thanks again + - Speakers, volunteers + - Karl Voit for managing the pad + - Bhavin Gandhi and Hannah Miller for help with the captions + - Free Software Foundation, especially the FSF tech team, for their continued help and support + - LibrePlanet 2022 Call for Sessions open for a few more days; consider giving a talk! See <https://libreplanet.org/2022/> and <https://my.fsf.org/lp-call-for-sessions/> + - FSF's Fall 2021 fundraiser happening now! See <https://fsf.org/appeal> if you'd like to give :) + - Fosshost, for BigBlueButton server and for ftp-upload server + - Computer Science Club of the University of Waterloo, for continuing hosting the videos/files on the CSC mirror server + - Jan Prunk (yang), for EU mirror of EmacsConf videos/files: <https://de1.mirror.si/emacsconf/> + - Wojciech Siewierski (vifon), for assisting zaeph with his scripts last minute + - Grant Shangreaux, for beautiful music :) (under CC BY-SA 4.0) <https://churls.world/basement-days/basement-days.html> + - the developers and maintainers of all the things that made this possible, with a special shout-out to: + - Random User (rndusr), whose subed.el made it easy to caption these talks inside Emacs + - And Qiantan Hong (qhong), author/maintainer of crdt.el which we used for sharing Emacs buffers between organizers + - Organizers + - Everyone + +# 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"]] + +[[!inline pages="internal(2021/info/day2-close-nav)" raw="yes"]] diff --git a/2021/talks/day2-open.md b/2021/talks/day2-open.md new file mode 100644 index 00000000..ff737f95 --- /dev/null +++ b/2021/talks/day2-open.md @@ -0,0 +1,20 @@ +[[!meta title="Opening remarks day 2"]] +[[!meta copyright="Copyright © 2021 "]] +[[!inline pages="internal(2021/info/day2-open-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Opening remarks day 2 + +[[!inline pages="internal(2021/info/day2-open-schedule)" raw="yes"]] + +- Welcome back! +- Prerecs available for day 1 on the talk pages +- Some of the talks for today have not yet been captioned, but we may follow up on them; if you want to help out, please volunteer +- Dev day has a bit more space for questions, so we'll have that on the main stream and use the alternate stream to keep going +- BBB room links will be posted to the talk pages and IRC so that you can join + +[[!inline pages="internal(2021/captions/day2-open)" raw="yes"]] + +[[!inline pages="internal(2021/info/day2-open-nav)" raw="yes"]] diff --git a/2021/talks/design.md b/2021/talks/design.md new file mode 100644 index 00000000..84a89de9 --- /dev/null +++ b/2021/talks/design.md @@ -0,0 +1,115 @@ +[[!meta title="On the design of text editors"]] +[[!meta copyright="Copyright © 2021 Nicolas P. Rougier"]] +[[!inline pages="internal(2021/info/design-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# On the design of text editors +Nicolas P. Rougier + + + +[[!inline pages="internal(2021/info/design-schedule)" raw="yes"]] + +Text editors are written by and for developers. They come +with a large set of default and implicit choices in terms of layout, +typography, colorization and interaction that hardly change from one +editor to the other. It is not clear if these implicit choices derive +from the ignorance of alternatives or if they derive from developers' +habits, reproducing what they are used to. Durint this talk, I will +characterize these implicit choices and illustrate what are some +alternatives using GNU Emacs. + +# Outline + +1. Review of a "modern" code editor (5mn) +2. Introduction of an alternative using Emacs (5mn) + +# Links from the slides: + +* [Elegant Emacs](https://github.com/rougier/elegant-emacs) (https://github.com/rougier/elegant-emacs) +* [On the Design of Text Editors](https://arxiv.org/abs/2008.06030) (https://arxiv.org/abs/2008.06030) +* [N Λ N O Emacs](https://github.com/rougier/nano-emacs) (https://github.com/rougier/nano-emacs) +* [svg-lib (ELPA)](https://elpa.gnu.org/packages/svg-lib.html) (https://elpa.gnu.org/packages/svg-lib.html) +* [nano-theme (ELPA)](https://elpa.gnu.org/packages/nano-theme.html) (https://elpa.gnu.org/packages/nano-theme.html) +* [nano-modeline (ELPA)](https://elpa.gnu.org/packages/nano-modeline.html) (https://elpa.gnu.org/packages/nano-modeline.html) +* [nano-agenda (ELPA)](https://elpa.gnu.org/packages/nano-agenda.html) (https://elpa.gnu.org/packages/nano-agenda.html) + +# Discussion + +- Q1: Do you have any plans for somewhat scientific testing of colors, + layout, etc? + - A: There are already some studies on the usefulness of + colorization but they're not consistent. I would love to make a + study with some students but it's a bit beyond my expertise. +- Q2: I have really enjoyed looking at the development of NANO emacs. + The only thing I slightly disagree with are the colours: on my + system some of them are extremely low-contrast and faded. Otherwise + the design is fantastic! Do you have any comments on the colour + scheme? + - A: I think you're right and I might need to revise the color + scheme, taking inspiration (or copying) some of the colors from + modus themes since Prot designed proper colors backed by + scientific theory. +- Q3: Are your examples hand-selected from design-perspective or does + "everything" look good automatically with your setup? + - A: Screenshots I've shown are available on GitHub and you + should obtain the same if you install them. Some parts come from + my personal configuration (org-agenda and mu4e mostly) but I can + post the code if you're interested. +- Q4: Should we use monocromatic colour schemes over full-coloured + ones? + - A: I'm not sure I can answer this question, I would need to + search if there are any recommendation on that matter. +- Q5: Are there ways that emacs could be improved to make these kinds + of usability experiments easier and more accessible to users? For + example making it easier to switch between such experiments? + - A: <https://github.com/plexus/chemacs> is a perfect answer. It + allows you to switch from one configuration to another without + messing up your own. +- Q6: Would it be possible to integrate nano emacs design to default + emacs design? What would the pushback be for integrating "better" + UI changes? + - A: I think Emacs would benefit from better defaults and I would + vote for modus themes to be the new default theme. Next would be + to package Emacs with a decent font (e.g. Julia Mono, Iosevka, + Inconsolata, Victor Mono) that would really help changing the + first impression of new users. Last would be to tweak a the + mode-line a bit. +- Q7:Spellchecking now highlights the whole word, to me this is a bit + too emphasized. Are there plans to make these less intrusive; i.e. + underline or similar? (And no, no bright red crinkles ;) + - A: Good point, can you open an issuer on GitHub? + +- What's this theme? +- i'll be sharing this with my friends that praise on vscode +- Wow, incredible analysis of that editor. +- looks beautiful +- how much of that is just bigger margins and roboto though? +- I love nano Emacs. I use it too +- i wonder if I can steal the splash screen and header line +- I really think that the default emacs theme could use this kind of effort and scrutiny in order to improve it +- A4: good idea, but few people have A4 *screens*... +- holy crap it looks so good +- yet again, though, the contrast is awful! black and white, please, not light grey and not-quite-so-light grey. it's almost unreadable, IMHO +- How hard would it be to integrate nano emacs changes with the default emacs? Like, would there be a lot of pushback? + - of course! there was massive pushbac over using curly quotes, for goodness' sake +- Are you aware of the modus-themes and what are your thoughts after contrast and accessibility? + - yeah, i just love modus themes by Prot because i'm colorblind and the fact that it has a strict contrast ratio is really really helpful, but even on modus themes i have to set success, error and warning to some really strong colors like pure red, green and blue + - I'm *not* colourblind and having high contrast is still good! there's a reason books are black on white, not grey on grey. or at least the background and body-text foreground must be highly distinct + - protesilaos: there are also options for deuteranopia, in case you need them (will need to refactor them for simplicity's sake) +- What Nicolas Rougier does is most welcome. Emacs can benefit a lot from such work. +- hmmm maybe Emacs needs to be able to handle WOFF! sounds like a job for fontconfig, I might look at it some day +- Nano Emacs + modus-themes would be a perfect combination, as it were. + +- From [YouTube](www.youtube.com/watch?v=7OTe26RZH9A&feature=em-comments): Great efforts & I'm rooting for you! but you might consider rebranding, because of the GNU nano text editor (22 years of recognition) + +# Contact information +* Contact [nicolas.rougier@inria.fr](mailto:nicolas.rougier@inria.fr) +* Follow my work at [github.com/rougier](https://github.com/rougier) +* Support my work at [github.com/sponsors/rougier](https://github.com/sponsors/rougier) or [en.liberapay.com/rougier/](https://en.liberapay.com/rougier/) + +[[!inline pages="internal(2021/captions/design)" raw="yes"]] + +[[!inline pages="internal(2021/info/design-nav)" raw="yes"]] diff --git a/2021/talks/dev-update.md b/2021/talks/dev-update.md new file mode 100644 index 00000000..a3467171 --- /dev/null +++ b/2021/talks/dev-update.md @@ -0,0 +1,29 @@ +[[!meta title="Emacs development updates"]] +[[!meta copyright="Copyright © 2021 John Wiegley"]] +[[!inline pages="internal(2021/info/dev-update-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs development updates +John Wiegley + +[[!inline pages="internal(2021/info/dev-update-schedule)" raw="yes"]] + +# Discussion + +- the real question: do we still have time to get our patches in to the 28 branch ^_^ +- So I assume a lot of distros will make those native-comp related packages some sort of dependency, right? + - the conversations I have seen among the distro maintainers seems to suggest that at least some of them will bundle the .eln files + - What about ELPAs? + - if a distro packages elisp files they would, but for ELPA even the .elc files aren't stored (iirc?), so those would be compiled asynchrously +- That's great so that I'm not using weird commands on incompatible modes +- Yes yes yes, the input mode update sounds incredible. I already hack that in my init.el, but I guess it'll be native. +- thank you so much for the great work on Emacs! +- why would emoji support be important in any way.. for anybody? Especially.. in the larger scheme of things or more important problems? Am i missing something? + - Unicode compatibility's always a good thing +- so you have to have a toolchain present even if you are only using precompiled .eln files + +[[!inline pages="internal(2021/captions/dev-update)" raw="yes"]] + +[[!inline pages="internal(2021/info/dev-update-nav)" raw="yes"]] diff --git a/2021/talks/devel.md b/2021/talks/devel.md new file mode 100644 index 00000000..3cb9412a --- /dev/null +++ b/2021/talks/devel.md @@ -0,0 +1,60 @@ +[[!meta title="Don't write that package! or: How I learned to stop worrying and love emacs-devel"]] +[[!meta copyright="Copyright © 2021 Stefan Kangas"]] +[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Don't write that package! or: How I learned to stop worrying and love emacs-devel +Stefan Kangas + +[[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]] + +We need a successful Emacs on this planet. This means that we need an +excellent out-of-the-box experience -- one that just works, but that you +can still hack and customize. There is so much great experimentation +and work going on out there in the wider Emacs community, but we would +be even better off if more of that could go into Emacs itself. + +Emacs' greatest strength is unfortunately sometimes also its greatest +weakness: it is *too* hackable. + +On occasion, people out there add stuff to their Init file to fix this +or that annoyance, or even bug. The more ambitious might go on to +package up such fixes: "Hey, 'foo-mode' doesn't have support for +'bookmark-set', let's write a package!" I am here to suggest that you +should not do that. + +You should submit a patch to Emacs! Maybe more people have that same +problem or annoyance, and would benefit from your solution? + +It is sometimes perceived as hard to contribute to Emacs core. I want +to encourage more people to get involved, and show that the barrier to +entry is really not that high. If I can do it, you can do it too! + +So should you really write that package, or should you stop worrying and +learn to love emacs-devel? Listen to my talk to find out more! + +# Discussion + +- I can imagine using bindat to improve Emacs's music player packages e.g. reading/writing metadata tags +- I hadn't heard of Poke until today +- Curious: how is gnu poke more flexible? +- I was surprised to see that a whole new DSL was developed for poke from scratch. +- I'll ask what I also asked Andrea earlier: What hobbies/interests do you have besides Emacs (and PL)? :) +- Do you think would have been better to develop/improve a library like bindat on top of an existing language instead? +- What are some of your favorite talks from this conf so far? +- If you ever write a library for window management in Emacs, you could call it winnie.el :) +- How do you see more control over types (type hints/decl through type specifiers etc) (SBCL like programming model) coming into Elisp? +- Do you plan to add bit-level support? +- I think this is classic problem that is almost impossible to accomplish + - many libraries try to do that but in the end the only working ones are relaying on C compilers +- also you have the problem of size of objects +- like how big is a long? +- this is not specified and is arch dependent +- parsing a generic .h file is way more difficult +- yep, the automatic translation is more for libraries trying to write automatically C bindings + +[[!inline pages="internal(2021/captions/devel)" raw="yes"]] + +[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]] diff --git a/2021/talks/dsl.md b/2021/talks/dsl.md new file mode 100644 index 00000000..a2a952dd --- /dev/null +++ b/2021/talks/dsl.md @@ -0,0 +1,49 @@ +[[!meta title="Self-Describing Smart DSL's: The Next Magits"]] +[[!meta copyright="Copyright © 2021 Psionic"]] +[[!inline pages="internal(2021/info/dsl-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Self-Describing Smart DSL's: The Next Magits +Psionic + +[[!inline pages="internal(2021/info/dsl-schedule)" raw="yes"]] + +When we begin programming, the promise is to automate away repetitive +tasks in life. As those program's capability grows, we begin to need +configuration UI's. We can start with a CLI, but as any CLI grows, we +run into the following issues: + +- As options pile up, the intuition of simplicity is lost in helps and +manpages + +- Stateless operation has no idea what to do next and loses terseness +- Frequent dispatch of commands to interrogate state required for the +operator to decide what action to perform + +- Composition compounds with all of these issues + +Magit has the UI trifecta of being terse, intuitive, and intelligent. +Magit's UI input library, Transient, is a standalone package for +developing more killer UI's, and not just for CLI applications, but +also for server applications, Emacs applications, and Emacs itself. + +While Transient's potential is to create the most highly productive +UI's short of thought control, going beyond simple command dispatchers +requires a deeper dive. When we think like constructing a DSL for the +task and using transient to input that DSL, we get an intelligent, +self-describing modal programming system. + + +# Outline + +- Updates to Transient documentation and demos of API examples +- Wrapping a custom CLI tool in Transient + +<!--- 40 minutes: Wrapping a server in Transient to make a new Emacs application --> + + +[[!inline pages="internal(2021/captions/dsl)" raw="yes"]] + +[[!inline pages="internal(2021/info/dsl-nav)" raw="yes"]] diff --git a/2021/talks/eaf.md b/2021/talks/eaf.md new file mode 100644 index 00000000..3c8f9bf3 --- /dev/null +++ b/2021/talks/eaf.md @@ -0,0 +1,112 @@ +[[!meta title="Emacs Application Framework: A 2021 Update"]] +[[!meta copyright="Copyright © 2021 Matthew Zeng"]] +[[!inline pages="internal(2021/info/eaf-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs Application Framework: A 2021 Update +Matthew Zeng + +[[!inline pages="internal(2021/info/eaf-schedule)" raw="yes"]] + +Emacs Application Framework (EAF) is a customizable and extensible GUI +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. + +# Feedback + +Pad: + +- Q1: is there any additions that you have to add to emacs for using + non-English/latin characters or does it work mostly out of the box? + - A: [Prot] : I only set the default-input-method to "greek". + Then switch to it with C- (toggle-input-method) +- Q1: Any plans for supporting other languages? It'd be great to use EAF to offload processing to Common Lisp, for example. + - A: You're able to use Python & JavaScrpt/Vue to extend on top of Elisp, it is so far enough (Python for Qt apps and JS for web apps). Currently I don't see a clear advantage of using Common Lisp as well, but there could definitely be a support in theory. +- Q2: is there an eaf-app that's not a bootstrapping nightmare? (having Vue as a dependency, eg) + - A: I don't fully understand what you mean by "bootstrapping nightmare", all these dependencies are system dependencies that you install like any other system dependency, it doesn't slow the Emacs startup nor the system startup. But if you're asking for an app suggestion with lightweight dependencies without JS or Vue dependencies, the popular EAF Browser and EAF PDF Viewer are cool app options. +- Q3: Are there security implications to having a browser in emacs? + - A [opalvaults]: With how Emacs deals with things like GPG/pass/etc. I feel like it's probably as secure as you make it? + - A: [matthewzmd] the browser application is independent from emacs itself, you're using a browser in emacs, but the browser is not actually *in* emacs. The browser is QtWebEngine, a modified Chromium without Google stuff, it is as safe as a Chromium can be. +- Q4: maybe i misunderstood, but is every eaf app essentially embedded QT? + - A: yes, it's built upon qt-webengine + - A: 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 so that you can extend Emacs in various langauges + - Q: I guess/hope this is using qtwebengine, not qtwebkit? + - A: right, qtwebengine. 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/) +- Q5: Can the EAF dependencies be made into dynamically loadable modules for Emacs, so there will be no need to rebuilt Emacs? + - A: There is no need to rebuilt Emacs, they're simply dependencies that you can install using the system package managers (pacman, apt, etc), npm install and pip install + +IRC nick: matthewzmd + +- Q1: Any plans for supporting other languages? It'd be great to use + EAF to offload processing to Common Lisp, for example. + - A: You're able to use Python & JavaScrpt/Vue to extend on top + of Elisp, it is so far enough (Python for Qt apps and JS for web + apps). Currently I don't see a clear advantage of using Common + Lisp as well, but there could definitely be a support in theory. +- Q2: is there an eaf-app that's not a bootstrapping nightmare? + (having Vue as a dependency, eg) + - A: I don't fully understand what you mean by "bootstrapping + nightmare", all these dependencies are system dependencies that + you install like any other system dependency, it doesn't slow + the Emacs startup nor the system startup. But if you're asking + for an app suggestion with lightweight dependencies without JS + or Vue dependencies, the popular EAF Browser and EAF PDF Viewer + are cool app options. +- Q3: Are there security implications to having a browser in emacs? + - A [opalvaults]: With how Emacs deals with things like + GPG/pass/etc. I feel like it's probably as secure as you make + it? + - A: [matthewzmd] the browser application is independent from + emacs itself, you're using a browser in emacs, but the browser + is not actually *in* emacs. The browser is QtWebEngine, a + modified Chromium without Google stuff, it is as safe as a + Chromium can be. +- Q4: maybe i misunderstood, but is every eaf app essentially embedded + QT? + - A: yes, it's built upon qt-webengine + - A: 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 so that you can extend + Emacs in various langauges + - Q: I guess/hope this is using qtwebengine, not qtwebkit? + - A: right, qtwebengine. 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/)> +- Q5: Can the EAF dependencies be made into dynamically loadable + modules for Emacs, so there will be no need to rebuilt Emacs? + - A: There is no need to rebuilt Emacs, they're simply + dependencies that you can install using the system package + managers (pacman, apt, etc), npm install and pip install + +- 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/>) + +Links and other notes: + +- <https://github.com/emacs-eaf/emacs-application-framework> +- <https://github.com/emacs-eaf/eaf-file-manager> +- <https://github.com/emacs-eaf/eaf-rss-reader> +- <https://github.com/manateelazycat/popweb> +- 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"]] + +[[!inline pages="internal(2021/info/eaf-nav)" raw="yes"]] diff --git a/2021/talks/erg.md b/2021/talks/erg.md new file mode 100644 index 00000000..4d1ca6dd --- /dev/null +++ b/2021/talks/erg.md @@ -0,0 +1,50 @@ +[[!meta title="Emacs Research Group, Season Zero: What we did together with Emacs in 2 hours a week for a year"]] +[[!meta copyright="Copyright © 2021 Noorah Alhasan, Joe Corneli, Raymond Puzio, Leo Vivier"]] +[[!inline pages="internal(2021/info/erg-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs Research Group, Season Zero: What we did together with Emacs in 2 hours a week for a year +Noorah Alhasan, Joe Corneli, Raymond Puzio, Leo Vivier + + + +[[!inline pages="internal(2021/info/erg-schedule)" raw="yes"]] + +The four of us met at EmacsConf 2020, and joined together around a +common interest in Emacs and research. Since then, we have convened as +the Emacs Research Group for weekly meetings. During these meetings, we +took notes collaboratively, using a ‘conflict-free replicated data type’ +package (crdt.el); at the end of each session, we debriefed using a +template that we call a Project Action Review (PAR). As as a +meta-review of our sessions, every six weeks we prepared a Causal +Layered Analysis (CLA), which gave us a different perspective on what we +had done. We reflected further on our experiences and methods, linking +our CLA to plans and design patterns. As a formal research output, we +contributed a write-up of these matters to a joint paper which we +presented at the Pattern Languages of Programs Conference (PLoP 2021). +The paper included an interactive workshop, in which we explored roles +in real-time problem solving and collaboration. + +In our short talk we share information about these methods, making a +case for other people getting together and creating their own small +research communities similar to ours. + +# Discussion + +- So this group really spawned out of last year's conf? You four were just met up and kept in touch? +- Excellent -- I actually meant to post Citizen Science, but I got confused with another thing +- I am definitely interested in incorporating your workflow. What resource would you recommend as a started - and is it one I could share with colleagues who do not yet use Emacs? +- Btw, I loved the rapid problem solving approach you take. I am also using "rapid response collecting" with my students to promote a similar 'prescience of the present'! +- would be willing to share the paper with me as well? i would also love to start an Emacs Research Group, i think Emacs has more to offer to science and people's day to day life than we realize currently +- Do you have sample workflows on your website? +- <http://metameso.org/~joe/docs/submission_candidate-25-Nov-2021.pdf> +- <https://github.com/exp2exp/exp2exp.github.io/blob/master/src/erg-2021-11-20.org> +- <https://github.com/exp2exp/exp2exp.github.io/blob/master/src/cla-16-october-2021.org> +- <https://exp2exp.github.io/cla-16-october-2021> +- also, a bit of a technical question: how do you get a public IP to share a session on crdt? + +[[!inline pages="internal(2021/captions/erg)" raw="yes"]] + +[[!inline pages="internal(2021/info/erg-nav)" raw="yes"]] diff --git a/2021/talks/exec.md b/2021/talks/exec.md new file mode 100644 index 00000000..b25defb0 --- /dev/null +++ b/2021/talks/exec.md @@ -0,0 +1,103 @@ +[[!meta title="Org as an executable format"]] +[[!meta copyright="Copyright © 2021 Tom Gillespie"]] +[[!inline pages="internal(2021/info/exec-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Org as an executable format +Tom Gillespie + + + +[[!inline pages="internal(2021/info/exec-schedule)" raw="yes"]] + +Org mode is known for its flexibility, power, and staggeringly diverse +number of workflows, users, and use cases. + +This talk explores just how far we can push the boundaries of the sane +and sensible with regard to Org workflows. + +In particular it will discuss shebang blocks, and elvs: two parts of a +complete system for creating executable Org files. + +Org syntax does not support shebang lines. However, it turns out that +Org syntax enables something even better — shebang blocks. + +Org is also (supposedly) not an executable file format. However, by +combining a shebang block with a Org babel source block, and eval +local variables (elvs) Org becomes a multi-language executable format. + +In this talk we introduce shebang blocks and elvs as a two part system +that transforms Org files into executable documents that can run on any +recent version of Emacs. + +These ideas are implemented in +<https://github.com/tgbugs/orgstrap/blob/master/README.org> and +<https://github.com/tgbugs/orgstrap/blob/master/shebang.org>, and +orgstrap.el is available as a package on MELPA and can be installed +via M-x install-package orgstrap. + +The talk will open with a demo of how to create an executable Org file +using the orgstrap machinery. + +We then discuss security considerations, and show example use cases. + +Finally the talk will cover the details and development of the +portable shebang block for Org mode that works on a wide variety of +systems and shells, and on the development of a formal specification +and a reference implementation for using Org source blocks to +transform Org files from plain text documents with a bit of markup +into self describing computational documents, or interactive +applications. + +# Discussion + +IRC nick: tgbugs + +- what prompted you to create orgstrap? +- Tom Gillespie: <https://github.com/tgbugs/orgstrap/blob/master/README.org#background-file-local-variables-and-checksums> +- yeah, usually this kind of stuff starts out as a minor annoyance +- is there a way to choose which blocks are going to be executed? +- What are some practical specific use cases that you had in mind? +- Tom Gillespie: <https://github.com/SciCrunch/sparc-curation/blob/master/docs/sckan/welcome.org> +- Tom Gillespie: <https://github.com/tgbugs/orgstrap/blob/master/README.org#use-cases> +- i'll for sure incorporate it in my company and research, so both corporate and academic environments will benefit from your work. i already use Org for documenting a lot of stuff so its just a natural next step +- I have experimented with dblocks in an org-mode buffer to do the equivalent of javascript in a browser. Does that make sense? + +From IRC: + +- This is supercool !! +- That is absolutely wild +- is the hash not just security theater? + - tgbugs: you need it to enable non-theater workflows + - anyone who could write the org-file could update the hash as well, no? +- I don't understand why he needs to talk about powershell, more than the other shell. :( + - tgbugs: very late response, but the reason I talked about powershell more than the others is because it is the most different and required some explainiation, I also was :/ about that + - that sounds that is a good reason to not include it xD . you can add fish in the talk and it will be bettter. + +# Outline + +- 5-10 minutes: + +A demo of adding the orgstrap block and elvs, +adding a shebang block, and then running an org file. + +<!-- +- 20 minutes: + +Same as above, followed by a walkthrough of the approach orgstrap +takes for preventing arbitrary code execution, followed by some +examples uses of orgstrap. + +- 40 minutes: + +Depending on flow/interest, security overview and the examples +bits could be swapped and overflow beyond 20 mins, followed by +a deeper dive into the internals, and a discussion about interest +in incorporating such functionality into org-mode directly. + +--> +[[!inline pages="internal(2021/captions/exec)" raw="yes"]] + +[[!inline pages="internal(2021/info/exec-nav)" raw="yes"]] diff --git a/2021/talks/faster.md b/2021/talks/faster.md new file mode 100644 index 00000000..0434db61 --- /dev/null +++ b/2021/talks/faster.md @@ -0,0 +1,133 @@ +[[!meta title="Optimizing Emacs Lisp Code"]] +[[!meta copyright="Copyright © 2021 Dmitry Gutov"]] +[[!inline pages="internal(2021/info/faster-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + +# Optimizing Emacs Lisp Code +Dmitry Gutov + +[[!inline pages="internal(2021/info/faster-schedule)" raw="yes"]] + +[[!table header="no" class="speaker-details" data=""" +Name pronunciation: | d-MEET-ri GOO-tov +Pronouns: | he/his +Homepage: | <https://github.com/dgutov/> +Preferred contact info | <dgutov@yandex.ru> +"""]] + +- Before optimizing, benchmark first. +- Different benchmarking approaches. +- Live evaluation, step-debugging, measuring from a debugger breakpoint. +- How to determine if a function is expensive. How to pick one from + competing alternatives (cl-lib, seq, dash, lean core). +- Print-benchmarking. +- Byte-compiled code can give a very different picture, changing where + the bottleneck is. How to quickly load a byte-compiled version. +- Steps taken to speed up the Xref package recently. + +# Discussion + +IRC nick: dgutov + +Pad: + +- Q1: Why are overlays slow compared to text-properties? I (believe + to) understand that it is (in part only?) due to "get element n in + vector vs list". If so, then why don't we change that? There could + be a text-property called "overlays", so that lookup would also be + like in a vector. What benefits does the datastructure currently + used for overlays have that make that undesirable? Would a mixed + approach make sense; i.e. allow non-modifiyng lookups to use the + "cached" overlays that are stored in the "overlay" text-property + and make text-inserting and overlay-moving actions store in the + currently used datastructure as well as in the indirect + text-property=>overlay cache? + - A: "There is a pending patch to represent the set of a + buffer's overlays as an AAtree or somesuch.." + - Sounds promising :) + - For more details, check out these threads: + - <https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html> + - <https://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00475.html> + - <https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00565.html> + - <https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00115.html> +- Q2: As a non-programmer, would these sorts of optimizations be + helpful to do on a personal init.el file? + - A: Probably not + - Though too much mode-line customisation may slow things down. +- Q3: What's a good approach for benchmarking destructive + operations? If you delete elements from a list in-place, all + subsequent runs will be artificially fast. + - A: There is an example of a comparison between operations from + different libraries in the example file provided by the talk. + Particularly check the benchmarks for delete and remove + operations (destructive and non-destructive, respectively). +- Q4:Cl-lib constructors, getters, and setters usually expand into + multiple levels of let-bindings. AFAIU, every let-binding is an + extra memory allocation. Do you recommend avoiding cl-defstruct in + favour of "pure" lists/vectors? + - A: basically no. if defstruct allows you to organise better, go + ahead. +- Q5: Is it possible to optimize some emacs packages by making use of + code compiled from other languages (like C or Common Lisp) ((i.e. in + the same way python is able to import C code))? + - A: yes emacs modules allow you to run C or Rust, transitioning + between emacs proper and module (passing the data) might slow + things down? Because of copying that's necessary to avoid + issues with gc. +- Q6:You mentioned that overlays are much slower compared to text + properties. What about text properties vs. buffer-local variables to + store position cache? + - A: I haven't measured it but offhand I'm going to guess that + buffer-local variables will be faster. + - Also depends on the structure you're going to use for the + cache - is it a single cons, or a list, or a tree, etc. + +BBB: + +- AVL tree +- defstruct accessors should expand with compiler macros to aref calls, which are very fast +- They have extra if though +- oh you mean for testing whether the value is such a struct? +- yes there is that test, but I wouldn't expect that to make it 3x slower, AFAIK + +IRC: + +- 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 + +Links: + +- you might find the this bench-multi-lexical macro useful: + <https://alphapapa.github.io/emacs-package-dev-handbook/#outline-container-Optimization> + or + <https://github.com/alphapapa/emacs-package-dev-handbook#bench-multi-lexical> +- <https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/elp.el> +- <https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/benchmark.el> +- "Use hash tables kids!" +- 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 +- EIEIO's object construction is slow because it goes through + `make-instance` which is a generic function and it itself calls + various other generic functions, so there's a lot of cl-generic + dispatch overhead; and then there's the fact that the (keyword) + arguments are laboriously parsed at run-time so it itself is slow as + well. +- There is a pending patch to represent the set of a buffer's + overlays as an AAtree or somesuch. +- <https://media.emacsconf.org/2021/emacsconf-2021-faster--optimizing-emacs-lisp-code--dmitry-gutov.el> + +[[!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 new file mode 100644 index 00000000..f8c29489 --- /dev/null +++ b/2021/talks/forever.md @@ -0,0 +1,118 @@ +[[!meta title="M-x Forever: Why Emacs will outlast text editor trends"]] +[[!meta copyright="Copyright © 2021 David Wilson"]] +[[!inline pages="internal(2021/info/forever-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# M-x Forever: Why Emacs will outlast text editor trends +David Wilson + + + +[[!inline pages="internal(2021/info/forever-schedule)" raw="yes"]] + +The computer software industry has seen many "popular" text editors come +and go, often due to the mercurial fashions of software development. In +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 + + +Pad: + +- Q1: In your opinion, what is Emacs achilles heel? It's obviously a powerful tool, but no tool is perfect. What would make your life easier in day to day use with Emacs (either a package you wish existed, or a core Emacs infrastructure change). + - A: (Probably answered by voice.) +- Q2:Comparing Emacs just to *code* editors is not a good measure as Emacs is so much more; GTD, word processor, (reference) organizer, or recently expressed on reddit as being a text productivity platform. + - A: (Probably answered by voice.) +- Q3: What is your opinion about the documentation of Emacs in another language in addition of english. There aren't too much non-english community. The people from another non-english countries should write documentation in own language or in english? + - A: (Probably answered by voice.) +- Q4: Do you think more effort should be made to popularize hacking on the C-parts of Emacs? It seems that this is the achilles-heal for the the long-term maintainance of Emacs, if less and less people understand what is going on underneeth eval and apply. + - A: (Probably answered by voice.) +- Q5: Can you name a couple or a few features from other programming languages that you miss in Emacs Lisp? + - A: (Probably answered by voice.) +- Q6: A lot of people take issue with Emacs commitment to to Free Software. They claim it holds it back, and that it should be more "pragmatic". What are your oppinions on this? + - A: (Probably answered by voice.) +- Q7: Do you think that packages like Magit or Org-Mode make people see Emacs as an obstacle to these applications they want to use? Is this an issue, or should it be seen as an opportunity to teach them about Emacs/Free Software? + - A: (Probably answered by voice.) +- Q8: Should Emacs continue to present itself as a esotetic program and culture? Or should we try to dispell the myth, and make clear that anyone can use it, not just extreem entusiasts? Or is this needed to motiviate people to invest time into properly learning Emacs? + - A: (Probably answered by voice.) +- Q9: Do you think there could be changes made to the core of Emacs that would betray the ethos you (and most people here) appriciate? I am thinking of points that some of Emacs' critics demand, to allegedly make Emacs more popular. Do you think this is a realistic threat, or could we save ourselves by forking? + - A: (Probably answered by voice.) +- Q10: The kids want to know : when an ongoing joint video collaboration between @daviwil and @protesilaos? + - A: (Probably answered by voice.) +- Q11: If you had to choose between graphics layer (2D & 3D), or "real" browser support inside Emacs, which would you choose? + - A: (Probably answered by voice.) +- Q12: How'd you feel on being an Emacs focused Youtuber? Do you think Youtube generates a lot of new users? + - A: (Probably answered by voice.) +- Q13: There might once have been a debate whether to add more typesetting capablities to emacs to make it more of a word processor or work on the core performance issues. The current work on native compilation and the community's response to that work show users are actually very interested in perfomance enhancements. What is your opinion on it? + - A: (Probably answered by voice.) +- Q14: Can you give us a sneak peek of what's coming in the YouTube Channel soon? + - A: (Probably answered by voice.) +- Q15: what about guix ? videos about emacs and guix + - A: (Probably answered by voice.) +- Q16: Are you interested in making Youtube videos on the new cool things happening in Emacs, like EAF or Nyxt? + - A: (Probably answered by voice.) + +BBB: + +- Hey Daviwil, I'm curious if you'll do a video showing your personal workflow? +- What do you think about Guix or Nixos + emacs videos ? +- It's nice to watch your videos and grab ideas from your workflows, or your code. +- That happens whenever I've used magit at work :D. +- Any thoughts on the idea that the best tool to use is the one which is easiest to leave? Possibly this is now even more relevant now that there is a heavy push to cloud services. + - I guess it also depends on who owns said tool (given that most cloud services aren't owned by the user). +- Do you think that there should an updated initial configuration for fresh Emacs installations with more "modern" (UI) features, or even CUA-like shortcuts? +- I really appreciate the live-video format: non-edited, live, thinking aloud videos - compared to all the polished super-edited "artificial" videos are more a show-of (see me!) as opposed to actually want to share knowledge... +- Hm. Will you do live pair-programming in the future? I believe you did that with JT some weeks ago. +- I would be very interested in summaries! +- Transcript remark: name mentioned by iLemming is written "John Lindquist". +- I think (possibly) emacs content might have been statistically relevant enough for bots to generate videos and upload them. For the last few months there seemed to be a constant stream of videos with the same intro and outro, plus some text to video in the middle. + - Sound like Tony's videos, which are user generated, but seem very automatic generated. +- 2 min videos will be *too* short - event for a short video. I think 5-10 min will allow for a good short intro to a specific functionality.. + +IRC: + +- 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 + +- From [YouTube](https://www.youtube.com/watch?v=9ahR5K_wkNQ&feature=em-comments): + - Emacs has changed the way I use my computer. It is absolutely + amazing. I use Emacs to: write latex files, write code, organize my life + (with the help of org mode), check my email, use git , use terminal etc. + Actually I have recently switched my desktop environment to exwm and it is + perfect for my workflow. I guess nothing can beat this tool. + - What I noticed from one graph you showed was that most people using stack overflow also use visual studio code, is there a correlation there I wonder. + - As for Google analytics ranking, some other factors to consider: - What percentage of emacs users search via Google? I may be wrong, but I think emacs users are more likely to use alternative search engines like Duck Duck Go. - There is so much help info built into emacs compared to other editors that is easy to look up right from inside our editor, I wonder what percentage of the searches on Google for the other editors are basic usage questions of the kind emacs users wouldn't need to search online for? I don't know how much weight these factors have in skewing results, but as you said, it doesn't really matter! + - This goes too show in 2004 less people where on the internet and most of then where hard core programmers, and now with more an more people coming into tech , new peeps just want to code and don't care about tools as much . So yeah , I am grateful to you david for introducing me to emacs even though I am too in this new wave + +# Outline + +- Discuss the core thesis, the features that make Emacs + desirable for long-term use (extensibility, day-to-day 'life' features) + +- Include more background on the text editor landscape and + how the scope of various editors is more narrow and doesn't compare to Emacs. + +- Talk about specific instances where editors were popular, fell out + of popularity, and why (due to changing fashions, not usually + better features). +[[!inline pages="internal(2021/captions/forever)" raw="yes"]] + +[[!inline pages="internal(2021/info/forever-nav)" raw="yes"]] diff --git a/2021/talks/form.md b/2021/talks/form.md new file mode 100644 index 00000000..41ef151c --- /dev/null +++ b/2021/talks/form.md @@ -0,0 +1,113 @@ +[[!meta title="Old McCarthy Had a Form"]] +[[!meta copyright="Copyright © 2021 Ian Eure"]] +[[!inline pages="internal(2021/info/form-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Old McCarthy Had a Form +Ian Eure + + + +Name Pronunciation: (EE-un YOU-r) + +Pronouns: he/him/his + +Preferred contact info: ian@retrospec.tv / ieure on Libera + +[[!inline pages="internal(2021/info/form-schedule)" raw="yes"]] + +<http://atomized.org/blog/2021/11/28/old-mccarthy-had-a-form/> + +Most practical languages are multi-paradigm, offering several +abstractions for the programmer. But did you know that Emacs Lisp +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 + +- Q2: AFAIK, EIEIO is generally slower than, e.g. cl-defstructs. When + do you think EIEIO is not suitable for performance reasons? + - A: I agree with Dmitry: first make it work, then make it fast. + I don't think there's a blanket reason not to use EIEIO, but + definitely profile if you're using it in a performance-critical + context. EXWM is one project that uses EIEIO extensively and + seems to perform well, so I don't think it's off-limits for + performance-critical code. +- Q3: Do you have any tips about introspection? e.g. IIRC there's an + EIEIO introspection facility, though it may be somewhat primitive. + - A: It is somewhat primitive, but seems to work okay + (<https://www.gnu.org/software/emacs/manual/html_node/eieio/Introspection.html)>. + I haven't found a need for anything fancier (yet). +- Q4: Have you used any of the EIEIO-related serialization tools? + IIRC there are some limitations with regard to printable/readable + values. + - A: I haven't had call for this, but + <https://www.gnu.org/software/emacs/manual/html_mono/eieio.html#eieio_002dpersistent> + is the mechanism (for anyone wondering) +- Q5: I did not get how generic functions can work with non class + objects + - A: Dynamic dispatch is very powerful! +- Q6:So with that Emacs is on pair with Smalltalk development + environments now (?) + - A: Not very familiar +- Q7: Most of what you presented can be done without `defclass`. + AFAICT, the only exception is *multiple* inheritance (since + `cl-defstruct` also supports single inheritance via `:include`). + - A: Yes, you can mix and match structs/objects or any other + type. You need classes if you want the EIEIO customization + editing facility or MI. I think also `initialize-instance` is + class-only, so you need classes if you have to do some kinds of + complex (cross-slot) initializtaion. + +- 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. +- This is not a question: Brilliant title for the presentation. :) + +Links: + +- <https://www.gnu.org/software/emacs/manual/html_mono/eieio.html> +# Outline + +- What is EIEIO? +- Why OOP? +- The CLOS Model + - Classes + - Generic Functions + - Methods + - Specialization + - Method Qualifiers + - Multiple Inheritance + - Nice Properties +- Practical Examples + - Encapsulation + - Example: `transmission.el` + - Abstraction + - Example: `sql.el` + - Extensibility + - Example: comint +- Conclusion + + +[[!inline pages="internal(2021/captions/form)" raw="yes"]] + +[[!inline pages="internal(2021/info/form-nav)" raw="yes"]] diff --git a/2021/talks/freedom.md b/2021/talks/freedom.md new file mode 100644 index 00000000..0b2af117 --- /dev/null +++ b/2021/talks/freedom.md @@ -0,0 +1,84 @@ +[[!meta title="How Emacs made me appreciate software freedom"]] +[[!meta copyright="Copyright © 2021 Protesilaos Stavrou"]] +[[!inline pages="internal(2021/info/freedom-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# How Emacs made me appreciate software freedom +Protesilaos Stavrou + +[[!taglink CategoryPhilosophy]] + +[[!inline pages="internal(2021/info/freedom-schedule)" raw="yes"]] + +The theme will be "how Emacs empowered my software freedom". +I will outline the key moments in my transition to a GNU/Linux operating +system and mark those which eventually contributed towards me becoming +an Emacs user, maintainer of a—dare I say—popular package, and +contributor to upstream Emacs (among others). By alluding to personal +experiences, I will draw generalisable insights and connect them to what +I believe are irreducible qualities of Emacs qua software and Emacs as a +community of like-minded people. The talk will be theoretical in +nature: there won't be any code-related demonstration nor technical +references that only people with a background in computer science would +likely recognise. Personal anecdotes shall be tangential to the point +and considered as ancillary to the thesis of what Emacs represents from +the standpoint of software freedom and user empowerment. The +presentation is intended for a general audience that is interested in +GNU software in general and Emacs in particular. My formal educational +background as a social scientist (i.e. not a programmer) and later as a +philosopher informs my approach to this topic. + +The presentation shall be 40 minutes long. Its text will be in essay +form and shall be supplied as complementary material to the video. The +notation will be in Org mode. I cannot provide an outline in advance, +as it will most likely not be consistent with the actual presentation. +If, however, this is absolutely required for administrative purposes I +shall furnish one regardless with the proviso that I am in no way bound +by it and thus reserve the right to modify it ahead of the main event. + +# Discussion + +Questions: + +- Q1: (Unrelated, feel free not to answer): Is there an Emacs or + GNU/FSF group in Cyprus? I know it's a politically motivated + country, with a strong student-base, so I'm interested whether the + Emacs circles and political circles have any overlap. +- Q2: What do you think is the most effecitve way to demonstrate the + value of software freedom to non-techincal people? For a person who + can't program (or doesn't want to learn) the freedom seems less + immediate. +- Q3: your quote "emacs makes emergent workflow's possible" reminds + me very much of the previous talk (Emacs as Design Pattern + Learning). Can you share/reflect how you go about making/designing + your personal workflows? +- are "Prometheas" & "Prometheus" both forms acceptable? Is one "truer" than the other? + - protesilaos: Both are correct. The former is modern Greek. + +Other notes: + +- Emacs documentation is first class. +- Emacs is inclusive to both new users and experienced users alike, + which empowers all users. +- Knowledge is to be shared not hoarded.. +- Emacs is an ecosystem you have to spend a lot of time with to fully + appreciate. + +Feedback: + +- "I'll definitly use this talk to try to convert more colleagues :D (not joking)" +- Wow, you phrased prometheus bit that excellently! +- wow great point on new users being enticed by the "easy productivity" angle +- I want to be productive, so give me this really complicated tool with countless high-level functions so I can get stuff done ASAP. bit of a paradox, really. very well said. +- what a well thought-through and well prepared talk. really appreciating this! +- you can't be an emacs tourist because IT SUCKS YOU IN AND DOESN'T LET GO +- protesilaos is a gift to the community +- i really appreciate prot's point right here: emacs is "free software" in the strongest sense of the word, from a practical point of a view since even if another program is libre, its usually so darn complicated that the freedom to modify the program is pretty useless since i'm not smart enough to do it +- the nuance brought by protesilaos between ellitism and exigence is very good. + +[[!inline pages="internal(2021/captions/freedom)" raw="yes"]] + +[[!inline pages="internal(2021/info/freedom-nav)" raw="yes"]] + diff --git a/2021/talks/frownies.md b/2021/talks/frownies.md new file mode 100644 index 00000000..87320134 --- /dev/null +++ b/2021/talks/frownies.md @@ -0,0 +1,91 @@ +[[!meta title="The True Frownies are the Friends We Made Along the Way: An Anecdote of Emacs's Malleability"]] +[[!meta copyright="Copyright © 2021 Case Duckworth"]] +[[!inline pages="internal(2021/info/frownies-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# The True Frownies are the Friends We Made Along the Way: An Anecdote of Emacs's Malleability +Case Duckworth + +[[!inline pages="internal(2021/info/frownies-schedule)" raw="yes"]] + +Emacs is well-known for being extremely flexible, programmable, and +extensible; in fact, that's probably the biggest reason it's still +being used after 40+ years of existence, and even has enough clout to +generate an entire conference in its name. In this medium-length +presentation, I will add another point to the data set proving Emacs's +abilities, by narrating the latest package I made, `frowny.el`, from +its conception to its current, nearly-completed state. + +I wrote frowny.el to scratch someone else's itch as a joke on IRC, but +it has been called "pretty useful, for a joke package." I feel like +that encapsulates the spirit of Emacs and that's why I want to present +on this topic. + +Along the way, I'll discuss just a little of my own history of Emacs, +and why I feel it's a great tool for non-technical users to sink their +teeth into. + +## Speaker information + +- Name pronunciation: /keɪs ˈdʌkwə(ɹ)θ/ (CASE DUCK-worth) +- Prounouns: he/him +- Homepage: <https://www.acdw.net> +- Preferred contact info: [email](mailto:acdw@acdw.net) +- Links: + - <https://breadpunk.club>, a shared unix server about bread + - [my Mastodon account](https://writing.exchange/@acdw) (though I'm moving to +[tiny.tilde.website](https://tiny.tilde.website/@acdw) ... soon™) + +# Discussion + +- How do we obtain frowny.el? + - A: Please check <https://github.com/duckwork/frowny.el> +- What was the funniest time a frown emerged from unintended code? + Or any similar occurrence. + - A: I frown a lot when I'm problem solving ;) +- What packages you used for writing? + - A: I just use org-mode for its markup. If you mean the + presentation, I think... org-present? +- You wrote the package quite fast. Would you say you knew what + you were going to program before you did it? Or was it iterative + process? + - A: pretty iterative, but very fast b/c it's a small project + space! +- from chat (Cairn): do you have a personal site? + - A: <https://www.acdw.net> +- not related to the talk, but on a different note: I like the + emacs background image used in the video stream. is it available + somewhere for download? :-) + - A: <https://emacsconf.org/i/emacsconf-logo1-256.png> (nervous + laugh) +- Why host it on GitHub? or codeberg.org, or sr.ht, or (non-)GNU savannah, or your own server +- Does frowny work with ;) + +- Compulsively C-q anything electric. Don't need a hook when you've got one in your brain. +- TBH you should transform it into a patch for electric-pair-mode +- So I want to contribute to Emacs, but I don't know enough elisp. Perhaps I could contribute some documentation? But I have no idea what that would be... +- From the speaker: i'd love to hear more about licensing, basically i don't care how my stuff is used at all + +- From [YouTube](https://www.youtube.com/watch?v=CZn_H93wc5A&feature=em-comments): Hey Case! Thanks for the great talk. I feel like I have had a similar experience to yours by also learning from vanilla Emacs. I like how you're showcasing how easy it is to scratch your own itch in Emacs. + +Feedback: + +- These kinds of talks are real fun, great job! +- For real though, I love the path you took to get to where you are. It's super relatable and I've loved hearing about it. +- These ‘how I got suckered into programming emacs by [hilariously trivial thing]’ are always fun. +- frowny.el shows how writing a package can help learn things---all sorts of things to consider and lots of "aha!" moments + +Links: + +- <https://breadpunk.club> +- /r/emacs - <https://old.reddit.com/r/emacs> +- Planet Emacs - <https://planet.emacslife.com> +- HISTORY.org - <https://github.com/duckwork/frowny.el/blob/main/HISTORY.org> +- <https://github.com/duckwork/frowny.el> + + +[[!inline pages="internal(2021/captions/frownies)" raw="yes"]] + +[[!inline pages="internal(2021/info/frownies-nav)" raw="yes"]] diff --git a/2021/talks/gregorian.md b/2021/talks/gregorian.md new file mode 100644 index 00000000..8c61e394 --- /dev/null +++ b/2021/talks/gregorian.md @@ -0,0 +1,40 @@ +[[!meta title="Typesetting Gregorian Chant with Emacs"]] +[[!meta copyright="Copyright © 2021 Spencer King"]] +[[!inline pages="internal(2021/info/gregorian-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Typesetting Gregorian Chant with Emacs +Spencer King + +[[!inline pages="internal(2021/info/gregorian-schedule)" raw="yes"]] + +There are a variety of methods for typesetting gregorian +chant scores and outputting high-quality sheet music. One of these is +a tool called Gregorio, which integrates with LaTeX allowing scores to +be cleanly inserted into other documents. All Gregorio files are plain +text, allowing them to easily be shared with other users and managed +with a version control system. In this talk, I will give a brief +overview of the Gregorio tool and then show how it can be used in +Emacs by typesetting a simple score. All code and examples will be +made available to help new users get started with typesetting their +own scores. + +# Discussion + +- what are the advantages of this over lilypond? +- do you know if there is something similar for byzantine notation? + +# Outline + +- 5-10 minutes: (brief description/outline) + 1. Introduction to chant music + 2. Introduction to Gregorio + 3. Example of typesetting a score in Emacs + 4. Code and example availability + + +[[!inline pages="internal(2021/captions/gregorian)" raw="yes"]] + +[[!inline pages="internal(2021/info/gregorian-nav)" raw="yes"]] diff --git a/2021/talks/imaginary.md b/2021/talks/imaginary.md new file mode 100644 index 00000000..01f1e7a7 --- /dev/null +++ b/2021/talks/imaginary.md @@ -0,0 +1,243 @@ +[[!meta title="Imaginary Programming"]] +[[!meta copyright="Copyright © 2021 Shane Mulligan"]] +[[!inline pages="internal(2021/info/imaginary-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Imaginary Programming +Shane Mulligan + + + +[[!inline pages="internal(2021/info/imaginary-schedule)" raw="yes"]] + +Imaginary Programming (IP) is both methodology and paradigm. It is an +extension of literate programming and a way of creating software without +the use of imperative, functional or even declarative code. Yet IP employs +all disciplines to achieve the miraculous. The only contingency is on one +or more language models, known as foundation models. The real value of IP +is not found by abandoning sound logic altogether, but in weaving the real +with the imaginary. The future of imaginary programming is one in which +almost all of computing is inferred. I have built a suite of tools based on +emacs for interfacing real programming languages with imaginary ones; all +of this in order to demonstrate what I mean; a ‘complex’ terminal that lets +you imagine what happens no matter how nested you are within interpreters, +an example-oriented language, a file format that encodes the provenance of +text and a library for imaginary functional programming primitives called +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 + +Pad: + +- Q1: Do you have a site we can follow more of your writing on? + - A:Pen.el Tutorial: https://semiosis.github.io/posts/pen-el-tutorial/ + - https://semiosis.github.io/posts/ilambda-tutorial/ + - https://emacsconf.org/2021/talks/imaginary/ +- Q2: re slide 27, would it mean that 2 such "idefined" functions would be the "same", meaning do the same thing the same way, given that they are defined without a "body"? (i'm trying to get a better grasp on the objects that get so "imagined" under the hood) + - A: The first time a function is run with given parameters, the results are remembered. I use the memoize library. You can update the function every time by surrounding the call the the function with the (upd ...) macro. The body evaluation is completely short-circuited with idefun. The imacro works a bit differently. It will generate real code. You can use the normal macro-expand on an imacro. +- Q3:Opalvaults :What are some underlying concepts/papers, that we could read to become more familiar with your overarching ideas? (i.e. for instance things that inspired your ideas) + - A: paper: pretrain, prompt and predict +- Q4: Sorry, I just don't get it: How is a function that does something different each time it's called useful? + - A: Each time you run one of these functions, you are getting the computer to imagine for you. It's a bicycle for the imagination. You can automate the filtration of the results you want, say by doing many generations and applying grep, or other prompts such as the semantic search prompt to the results. The functions are memoised, so they technicaly do the same thing every time if you want them to. Also, if you use a temperature of 0 for the prompt functions (I demonstrate how to override that, somewhere in the slides), it will be deterministic too, even when bypassing the cache. +- Q5: How on earth do you ensure that what ilambda gets back from GPT-3 is Lisp and not, say, Harry Potter fanfic? :) + - A: A combination of good prompt design, filtering the results, and validating the results. Also, you can fine-tune models to the task you want to eliminate the possibility of unwanted generations. +- Q6: Your views on the pluses and minuses of GPT-3? + - A:It's something we have to live with because of its transformative nature on computing. These language models unfortunately are license-blind. +- Q7: Any interesting ideas about potential applications of GPT-3 to Emacs itself (or Emacs-adjacent things)? + - A: Emacs is the ultimate text-centric operating system. It will become a kernel for AGI, I think. That's what I plan on making. The power-user's terminal of human-ai interaction. I'm trying to extend as many modes in emacs as possible. Org-brain, eww browser, org-mode, comint, emacs lisp primitives, etc. +- Q8: Follow-up on Q2: how does infering functions in this manner differ from, say, how in the Haskell ecosystem functions are infered by specifying inputs and return type (such as when searching for a suitable function for a given purpose)? + - A: Where in haskell, type-declarative function search look through a discrete set of functions by type, the domain of possible functions that are search for using language models is qualatively and quantatively infinite. +- Q9: Are you deriving functions from their names? What do you do when this is ambiguous - for example, when the name of the function is "get-element-from-pair"? + - A: idefun will infer computation and short-circuit the code. Given either 'function name', alone, function name + args, or function name, + args + docstring, or function nae + args + docstring + function body, it will make use of the context you have provided and imagine evaluation. It will create functions which infer rather than properly evaluate, based on merely the name of the function, for example. + - A (re: ambiguity): If you had an imaginary defun for this, you'd need to send the final list + +BBB: + +- libertyprime: What kinds of software is IP (imaginary programming) not suitable for? + - libertyprime: Good question. IP is great for things like mocking API calls, because you can imagine the API call output. It's great for code generation where you can then do a macro-expand to generate code as you are programming. It's great for coming up with functions that might be difficult to write (idefun color-of-watermelon), for example +- Hey libertyprime, where do we follow up to find out more? + - libertyprime: it's not really good for scaffolding code. I consider emacs to be 45 years of scaffolding to build imaginary functions around + - libertyprime: Because IP needs a rigid complimentary code. +- So how does an IP user verify that the imagined code does what is intended? +- I like the word 'imaginary' to describe the paradigm +- libertyprime: How does an IP user verify that the imagined code does what is intended? Through a combination of 'validator functions', imaginary validation functions and language model fine-tuning. So you may also choose an underlying language model to use when running code. That model may have been trained to do the task you are giving it. If you're trying out the docker container you can run `pen config` or do `M-x pen-customize` to force the language model, or chage it in the imagine-evaluating-emacs-lisp .prompt file +- libertyprime: Haha. The brilliance of emacs, and the reason this stuff is so easy to do with emacs, is that emacs provides intelligible modes and abstractions with which to build prompts. Otherwise you have an amorphous blob of a language model. +- libertyprime: So the value is absoltely not in replacing emacs entire, as I've come to understand it, but in combining real and imaginary. +- (wish i could give you back just a fraction of the time you saved just this one person here!) +- I would love to see the result of imaginary major modes and keymaps +- libertyprime, is the idea for the first draft of the gpt output to be final, or do you expect to edit some? +- There seems to be a lot of jargon in this context, like validators, prompts, language models, etc. It's really hard for someone who doesn't already use these things to understand what these pieces are and how they fit together. + - well prompts seem to be the input you give to the language model, which it then generates a follow up to + - validators sounds like tests? language models are neural language models like GPT-3/j etc. + - libertyprime: <http://github.com/semiosis/glossaries-gh/blob/master/pe-prompt-engineering.txt> +<http://github.com/semiosis/glossaries-gh/blob/master/prompt-engineering.txt> +<http://github.com/semiosis/glossaries-gh/blob/master/pen.el.txt> + - libertyprime: Here are some glossaries for the subjects + - So like, a prmpt would be "Marco!" and GPT-3 would of course say... "Polo" + - libertyprime: @alphapapa, I also have a much matured prompt format readme, here: <https://github.com/semiosis/prompts> + - libertyprime: which can explain 'validator'', etc. +- aindilis: So uh... does GPT-3 know... everything? in every human and computer language? I don't understand its role exactly, or its limitations. + - GPT-3 knows a lot, but not all, from my experience. It's pretty scary, in a good way. I think libertyprime wants to keep it libre. + - libertyprime: the latest language models such as Codex are world language + codex, and they know everything at an abstract level, like a human does, in a way. So their depth may be superficial. They're pretty good knowledge aggregators. +- so libertyprime can you just tab complete and it completes on like the previous sentence, region, buffer, etc? + - libertyprime: Yes, it has basic autocompletion functions, (word, line, lines). I'm also making more interesting autocompletion functions, which do beam-search on downstream generations, -- calling it desirable-search. <http://github.com/semiosis/pen.el/blob/master/src/pen-example-config.el> + - libertyprime: There are some key binding definitions here which will work for the docker container +- Does GPT-3 "know" how to transliterate from say public code written in JS / Other-Lang to elisp if you were trying to imaginary code similar function names? + - libertyprime: yes, it absolutely can. transpilation is one thing it is very good at. But more bizarrely, you can also transpile intermediary languages, that are composed of multiple different language chimerically. For example, you can smash out your algorithm with a combination of elisp and bash and it will understand when it transpiles into a real language. +- How well does it actually work to write a function in a mishmash of Bash and Elisp? I can't imagine that working well in practice. There are too many semantic differences in the languages and implementations + - libertyprime: it's a very new sort of thing, but feels natural as you are doing it, to generate code. the results of generating code should most probably be looked at before running. that beign said, you can also run 'ieval' around it to run it in inference. I think the takeawaay should be that these models are getting better and better and show no signs yet of reducing quality of results or ability -- no sign yet +- how does lexical binding affect things, if at all? +- How about going from a CLOS/EIEIO style of OO to Java / C++ style? Or Erlang style of parameter pattern matching? +- so IIUC GPT-3 is a service run on a remote system, right? And it's proprietary? How big is it in terms of bytes? + - libertyprime: yes, aggregated language models are not good in my opinion. GPT-3 is around 170 GB, approximately 1GB per million parameters, IIUC + - libertyprime: There are libre models, and you can connect one to penel to run the inference etc. My goal is to decentralise them though + - libertyprime: Because I don't think that 170GB is accessible enough. The issue is actually running the models though. You need a very large computer indeed for that + - libertyprime: I can do a customized demo if anyone wants +- can someone here provide some sample input, and you run it and paste the result, just to give an idea of the quality? or do you already have samples online? +- here's an idea for a demo... something like (idefun (string target-language) "Translate STRING from its source language into TARGET-LANGUAGE and output it to the echo area.") + - oops I forgot to name the function, was thinking of ilambda + - I have a feeling that such a large scope for the function will exceed the max output size of the model. maybe we work on a more realistic example? + - I was hoping the model would solve all the messy problems for me :) + - libertyprime: Oh crud. I hope I havent broken Ilambda. Lol I added support for 0 arguments, it makes it variadic. This will work + - doesn't seem like it quite understood the purpose but I can see the connection +- what happens if you change target lang to "Elisp" >:) + - look at the echo area if you didn't notice it + - oh wait, I missed the echo area + - libertyprime: Yup, exactly, that will work too. One sec +- can you run the function again or show "C-h e"? And can we see the resulting source code? + - libertyprime: translate python to elisp + - libertyprime: just with (idefun translate) + - libertyprime: No docstring, etc. or arguments. + - libertyprime: ccrud. It didnt work haha + - libertyprime: Sigh. +- libertyprime: I need to fix the 2-ary argument thing. :S Really sorry I think I broke it +- I'd like to see the generated (or "imagined") Elisp source code, assuming it does some HTTP API queries to do the translation and such +- libertyprime: Yup, I can show that. It works much better when I use OpenAI Codex. Here are some generated functions +- libertyprime: That's how it works under the hood. Then it cuts out the bit that you want +- This reminds me of the classical AI paradigm of "generate and check." +- libertyprime: Sigh. I really cry when demos break. Sorry. I demo'd the underlying prompt though. I broke ilambda, i think +- I think I saw it generate a huge fibonacci function, is that still in your kill-ring? +- okay, well thanks for demoing, the code is pretty stable though at this point right? this is just the norm with any demo. +- I bet people would be glad to watch/read something later on if you want time to work on it. +- libertyprime: <https://semiosis.github.io/cterm/> This is what I call the complex terminal. Essentially you prefix any terminal program with ct and you get autocompletion etc. for anything. it uses emac's term-mode +- libertyprime: <https://semiosis.github.io/ii/> And this, ii, it's fully imaginary terminals, so you can import imaginary libraries, etc. and work with them. +- libertyprime: <https://semiosis.github.io/apostrophe/> This one here, which imagines conversations with anyone that the model knows about. So I'm demoing having a 3way conversation with amber heard, tom cruise and chris nolan. + - so you used GPT to generate a compliment, and now GPT generates the convo from that prompt? + - libertyprime: Yeah, so the best way to interact with these types of chatbots is to imagine the situation you are in before hand. the initial phrases can be anything you can think of really. Why are you in the bath tub?, for example. But I tend to open with something like, may I interrupt? What were you just working on? so by choosing the prompt very carefully, you can tease out the information you require. +- libertyprime: <https://semiosis.github.io/nlsh/> and this, which is a natural language shell +- libertyprime: I also have a way to filter results semantically, with my semantic search prompt <http://github.com/semiosis/prompts/blob/master/prompts/textual-semantic-search-filter-2.prompt> +- libertyprime: YOu can run all these prompts also from bash like so: pl "["It's cool. I used to dance zouk.","I don't know.","I'm not sure.","I can't stop dancing to it.","I think it's ok.","It's cool but I prefer rock and roll.","I don't know. It sounds good.","Nice but a bit too fast,"Oh, I know zouk, you can teach it to me.","Zouk is nice."]" | "penf" "-u" "pf-textual-semantic-search-filter/2" "positive response". That will pipe json results into Pen.el, and have it filtered. all prompting functions are also available as shell commands. +- well I think this is the coolest thing I've seen in a long time. how do we follow up with you and get involved? run it etc? +- libertyprime: hehe thanks aindilis: i'm on #emacs as libertyprime. Feel free to hit me up any time. Otherwise, the setup for pen.el is fairly straight forward. If you have any issues demoing, I'd be very interested, so I can make Pen.el more reliable. I have a discord server. I'll copy the link. One sec +- Do you think you could run an IRC channel too? + - libertyprime: <https://discord.gg/sKR8h9NT> +- Thanks a lot, very interesting and I am excited to learn more later! +- yeah this talk was crazy good, ty! + +IRC: + +- 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 + +From [YouTube](https://www.youtube.com/watch?v=pJm4TaCyDnk&feature=em-comments): + +- Is this Emacs with smooth scrolling? How is that possible? I tired that really hard. Or is it just a PDF reader? +- Lets go!!!!! Imaginary Programming all the way. + +# Outline + +- 5-10 minutes: +- a 5 minute introduction to imaginary programming, followed by + - a demonstration of iLambda. + - iλ, a family of imaginary programming libraries + <https://mullikine.github.io/posts/designing-an-imaginary-programming-ip-library-for-emacs/> + +<!--20 minutes: + +- a 5 minute introduction to imaginary programming, followed by + + - a 5 minute introduction and demonstration of Pen.el. + - <https://semiosis.github.io/pen/> + - a 5 minute org-babel and emacs lisp demonstration of iLambda. + + - iλ, a family of imaginary programming libraries + + <https://mullikine.github.io/posts/designing-an-imaginary-programming-ip-library-for-emacs/> + - a 5 minute demonstration of ‘cterm’ (complex term) and ‘ii’ + + (imaginary interpreter). + + - <https://mullikine.github.io/posts/imaginary-real-codex-complex/> + - <https://semiosis.github.io/ii/> + + - + +40 minutes: + +- a 10 minute introduction to language models, their capabilities and + imaginary programming. + + - a 10 minute introduction to creating prompts with Pen.el. + - a 5 minute org-babel and emacs lisp demonstration of iLambda. + + - iλ, a family of imaginary programming libraries + + <https://mullikine.github.io/posts/designing-an-imaginary-programming-ip-library-for-emacs/> + - a 5 minute demonstration of ‘cterm’ (complex term) and ‘ii’ + + (imaginary interpreter). + + - <https://mullikine.github.io/posts/imaginary-real-codex-complex/> + - <https://semiosis.github.io/ii/> + + - A 5 minute brief on examplary and advanced prompt programming. + - <https://semiosis.github.io/examplary/> + - 5 minutes for Prompting Requests and Q&A + +Availability + +(during the conference days (Nov 27 and 28)) + +All hours. + +How you’d like to handle questions + +Live web conference + +---> + +IRC libertyprime at #emacs on libera + +Shane Mulligan + +## Links + +- Pen.el Tutorial: <https://semiosis.github.io/posts/pen-el-tutorial/> + +[[!inline pages="internal(2021/captions/imaginary)" raw="yes"]] + +[[!inline pages="internal(2021/info/imaginary-nav)" raw="yes"]] diff --git a/2021/talks/invoice.md b/2021/talks/invoice.md new file mode 100644 index 00000000..c3534656 --- /dev/null +++ b/2021/talks/invoice.md @@ -0,0 +1,60 @@ +[[!meta title="Find Your (In)voice: Emacs for Invoicing"]] +[[!meta copyright="Copyright © 2021 Bala Ramadurai"]] +[[!inline pages="internal(2021/info/invoice-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Find Your (In)voice: Emacs for Invoicing +Bala Ramadurai + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/invoice-schedule)" raw="yes"]] + +[[!table header="no" class="speaker-details" data=""" +Name pronunciation: | BA-lA +Pronouns: | he/his +Homepage: | <https://balaramadurai.net> +Preferred contact info | <bala@balaramadurai.net> +"""]] + +Ye Freelance warriors, please lend me your I/O devices for 5 minutes. + +Your time is your money! Do you find it a pain to generate an invoice, +record the details into your accounting software and keep track of +taxes and payments? You are not alone, I found the whole invoice +thingy to be extremely painful. + +But worry not, Emacs comes to our rescue. + +My talk will give you a basic intro on how to use org mode, some embedded python code and file jugglery to generate stylistic and professional invoices. + +What you will learn during the session: + +- How to track your freelance time using orgmode +- How to create the basic infrastructure for invoice generation +- How to generate the invoice +- How to manage multiple clients +- How to enter the finance details into your accounting software +- How to track invoice payments + +We will use the following packages: + +- Emacs+orgmode (duh?) +- yasnippet +- python layer (I use spacemacs, so whatever is the equivalent in your config) +- Some unnecessary Shakespearean references + +# Discussion + +- okay, this is some next level invoicing automation! +- The accounting system transactions are a nice touch +- it's really hard to tell that came from org :) +- European format would be DD.MM.YYYY and not with dashes which can be mixed up with ISO or other formats. in the UK it's often with slashes: DD/MM/YYYY +- From [YouTube](https://www.youtube.com/watch?v=b__d04aHEbI&feature=em-comments): This looks great! Much better than my amateurish attempts. Thanks!!! + + +[[!inline pages="internal(2021/captions/invoice)" raw="yes"]] + +[[!inline pages="internal(2021/info/invoice-nav)" raw="yes"]] diff --git a/2021/talks/janitor.md b/2021/talks/janitor.md new file mode 100644 index 00000000..ab903616 --- /dev/null +++ b/2021/talks/janitor.md @@ -0,0 +1,158 @@ +[[!meta title="A day in the life of a janitor"]] +[[!meta copyright="Copyright © 2021 Stefan Monnier"]] +[[!inline pages="internal(2021/info/janitor-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# A day in the life of a janitor +Stefan Monnier + + + +[[!inline pages="internal(2021/info/janitor-schedule)" raw="yes"]] + +Because of a reckless former Emacs maintainer that shall + better stay unnamed, ELisp has seen a fair bit of churn in the last 10 + years, making it necessary to clean up "old" code [in order to open up + the road for yet more recklessness? ]. + In this documentary we will follow a famous janitor in his every day job + dealing with the aftermath of the cl-lib / lexical-binding party. + +# Discussion + +Pad: + +- Q1: How did you narrow to two specific areas in a single buffer when + compering the two functions. I can be handy + - A:In this case I just split the window into 2. In other cases I + use `M-x smerge-make-conflict`. Oh wait, did you really mean + "narrow"? I don't use narrowing, I only use + outline-minor-mode (with reveal-mode to un-hide as I move) + - I will look into both work flows they look very handy. Thanks. +- Q2: Could you further elaborate on quoting functions with #'fun + (aka (function fun)) instead of 'fun (aka (quote fun))? + - A:Not sure what further elaboration you want (e.g. "why?" or + "when?") + - I would like why? Is it just style since Emacs understand both, + or not? + - The why is to be more explicit (i.e. a form of documentation, so + as a reader I can see that this refers to the function rather + than being just a use of a symbol for other purposes)). The + compiler knows about it and will hence give you a warning if you + refer this way to a function it's not aware of. There are also + corner cases where the two behave differently, mostly when + referring to a function defined via `cl-flet` or `cl-labels` + (or `named-let`, ...) + - Thanks! +- Q3: Stefan, you mentioned a lot of conventions, I really like to + read more about them: Where can I find a list of these conventions + (like #'function for functions )? Is there a page or info about + ELisp conventions used nowadays? + - A:Good question. We have several of them documented in the + ELisp reference manual (searching for "convention" should get + you there), but that only covers those conventions with which + Emacs maintainers agree. Others are much less clearly + formalized. I seem to remember someone collecting such + information and making a webpage out of it, but I can't + remember where nor who it was. + - Probably, + <https://github.com/alphapapa/emacs-package-dev-handbook> + - Thanks! I'll take a look at the reference manual and search for + this information. 👍 +- Q4: Stefan, that was really amazing to watch. After the changes you + made, how confident are you that the package still works as + intended? It seems as though there might be some room for errors + that the byte compiler wouldn't necessarily catch. + - A: I think for those three packages I'm quite confident that + they should work as well as before. Not because the compiler + did not complain but because the changes were sufficiently + simple. Sadly in ELisp, I can't rely on the compiler to catch + errors. I can only use it ask it to point me to suspicious + code, and I know that it will miss some. + +BBB: + +- I couldn't help but note that in the C world we are more and more making large-scale changes like this to the whole tree at once using tools like coccinelle. it feels like the regular structure of Lisp would lend itself to this very well... It feels like a better use of your time, is all :) +- anyway, thanks for de-terrifying lexical-binding conversion in particular -- I think I might start pitching in there (I assumed it was a lot more paranoid and proof-based than this, which it seems like something I could do!) + - what do you mean you don't search the entire space dominated by every funcall for uses of each var :) + - God knows what crazy things users have done with either hooks or advice, and what vars they implicitly depend on :/ +- Curious, is the Emacs you showed also your personal config, or one just for the video? + - Understandable, I'd do the same. I was curious to see what your real config looked like though :) +- oh that reminds me, thanks for pcase, it's amazing :) +- Oh that's fast. Compare to Linux: 16 years and counting (!) for the -rt patches... +- What's your opinion about tree-sitter? Is it possible to see something like paredit but for non-lisp language? +- I suppose you can just ask "how old is this?" and it's the ancient stuff that is hardest to convert +- Hi Stefan, thank you for this very insightful talk, full of tacit knowledge. I've learned much also from your HOPL talk (and paper). Is there a world in which you could consider doing other short informal videos just to show your thinking and pass on such tacit knowledge to those that would be interested in getting into emacs-devel per se. +- May I ask a silly question? I'm curious about your style of signing your mailing list messages, i.e. "Stefan 'who foo bar baz'" Where did that originate? :) + - I enjoy it, the list needs levity like that :) +- (Also, I for one liked that you didn't use specialized tools, for precisely those reasons that it makes it more accessible to those just starting.) +- Would it be too off-topic to ask about ELPA? I was thinking that it would be helpful to have a way to list packages on the site by last-updated time +- Is it possible to see metaobject protocol support in elisp? +- What features of the language/platform do you see as higher priority for future development? i.e. I'm looking for package pages that use the HTML-formatted readme from the patches we worked on, but I don't know which pages have been updated recently, so it's hard to find them :) +- could download counts be done? Would that require the Savannah folks to code? +- Do you install packages from melpa? +- Stefan: Are you using native-comp already? +- Do you use Org much? +- Do you use magit? +- What are some of the improvements coming in future Emacs versions you're looking forward to? +- What's your opinion about Po Lu's recent patchs about GStreamer? +- Have you ever met any of the other Emacs maintainers or developers in person? +- How do you hack on installed packages? I mean installed packages are not a git cloned repo. But I want to commit changes and to see an immediate effect in a running Emacs. What is suggested workflow for this? +- What's Lars like in real life? He seems like a fun person :) + - oh is he tall? +- From your academic/research work, are there things you would like the elisp language or platform to evolve towards, even if medium-long term? Or is the long term path a different language(s) altogether? +- Do you personally use paredit? +- Do you lean toward Scheme-style macros rather than CL ones? +- What non-lisp languages are you looking at that we could possibly inspire from, if any? +- I'd like to see something like a with-gensyms macro to make them easier to use. Dima Akater also has some ideas (and code) for enhancing defmacro in a similar way +- (hehe, yes i meant mostly typed functional programming languages) +- Can namespaces solve some macro issues? +- are there technical difficulties in preserving that source code data associated with symbols and sexps? or could something like defstructs be used simply to do that in a primitive way? +-so almost like a parallel macro/elisp implementation then? +- doesn't adding code/data distinction break homoiconicity? +- Could a Clojure-like metadata approach to extend the data be useful for this, and if so doable? +- fat cons cells sounds useful, could maybe be used to do CL-style VALUES too? +- even more tedious than janitorial work I suppose :) +- BTW, Stefan, I forget, are you Canadian/Quebecois, or do you just happen to live and work there? :) + - ah, so you are French? +- thought of another simple question to bombard you with :) Do you mostly run Emacs from master, or other versions? + - Stefan Monnier: I basically only use my own version, which tracks `master` with a bunch of local experimental & cosmetic changes +- elisp looks very much like a procedural language. Do you like it this way or maybe you wish it moving towards more functional/Scheme style? + - Stefan Monnier: ELisp is halfway between imperative and functional, and I think it works rather well this way. The usual style has evolved towards a more functional style. + - Stefan Monnier: The ELisp implementation sadly isn't good enough to support a truly functional style, currently. +- Stefan Monnier: I tend to edit code as I read it, so my local changes probably accumulate to 1MB or so of patch, but most of it is purely cosmetic changes which I "should" push to master but can't be bothered to. + +IRC: + +- Question: Is there a place where these conventions and compilers checks are listed? A web page, an info perhaps? +- Wow, I think you are going to have to know a LOT on Emacs development, versions, Elisp details, ... to do that kind of work. + - One very helpful thing anyone can do is just confirm bug reports and add reproduction steps if they are missing. +- The double-dash is a convention for an func intended to be called internally only? + - Yes. `pacakge-foo` is public, `package--foo` is internal. +- mindless tree-wide transforms like this are what coccinelle is for. why are emacs maintainers still doing this by hand? you'd think lisp would be well-suited for expressing semantic patches to lisp... :/ this ceases to seem interesting when you've seen cocci do ten thousand transforms like this across a 500MiB tree in 20s or so + - Does cocci work on elisp? + - no, but the *idea* should work there, and Lisp is so regular in structure that something like coccinelle is the sort of thing lisp boosters say is really easy in lisp. but nooo, none exists that I know of :( (coccinelle itself is written in ocaml :) ) + - https://coccinelle.gitlabpages.inria.fr/website/ +- There's a monstrous heap of regexps that match most reasonable compiler output. I wrapped an ancient MS-DOS compiler for an obsolete language in a script that invokes it inside DOSBox and echos the output‚ and it Just Worked with compilation mode. + - Wow, that's awesome! Yes, lots of the "historic" parts of emacs are amazing. +- if folks are interested in the lexical dynamic transition: https://hopl4.sigplan.org/details/hopl-4-papers/13/Evolution-of-Emacs-Lisp + +Feedback: + +- OK, this blows my mind in a sense that I realize that I really don't have an idea of coding Elisp. +- This talk is great. There should be more like that online, so more people learn to help with "janitorial" work + +# Outline + +- ~20 minutes + Here really, I'm not sure how much time this will take. I put 20 + minutes because I think I might be able to fill that and I think more + than that could turn too boring. I intend to make it a "live coding" + kind of thing, without anything like an outline: it's basically "make" + followed by fixing the warnings. + + +[[!inline pages="internal(2021/captions/janitor)" raw="yes"]] + +[[!inline pages="internal(2021/info/janitor-nav)" raw="yes"]] diff --git a/2021/talks/maintainers.md b/2021/talks/maintainers.md new file mode 100644 index 00000000..8a39e41a --- /dev/null +++ b/2021/talks/maintainers.md @@ -0,0 +1,104 @@ +[[!meta title="How to help Emacs maintainers?"]] +[[!meta copyright="Copyright © 2021 Bastien Guerry"]] +[[!inline pages="internal(2021/info/maintainers-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# How to help Emacs maintainers? +Bastien Guerry + +[[!inline pages="internal(2021/info/maintainers-schedule)" raw="yes"]] + +<https://bzg.fr/en/how-to-help-gnu-emacs-maintainers/> + +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. + +# Discussion + +Pad: + +- [[!template text="Q1: How did you come up with this knowledge? By doing or by experience or by reading books (which?)?" start="00:04:30.840" video="qanda" time="1" id=subtitle]] + - A: All 3 of them. + - He was reading the book: Fred turner : counter culture to cyberculture + - The other one he mentioned appears to be Eghbal, Nadia [Stripe Press] (2020) Working in public: the making and maintenance of open source software +- [[!template text="Q2: (Maybe answer this last, if time permits) How did you come to start using Org?" start="00:06:10.000" video="qanda" time="1" id=subtitle]] + - A: Bastien started with his own library BHL and was introduced/invited to contribute to Org by Carsten. +- [[!template text="Q3: You have recently overseen a major transition for org mode maintenance, what would you advise for other teams that are preparing for transitions so that processes can be maintained with minimal disruption? How do we take processes that were originally maintained by a single person to one maintained by multiple people?" start="00:08:39.720" video="qanda" time="1" id=subtitle]] + - A: (Probably answered by voice.) +- [[!template text="Q4: What do you think about the latest Orgdown thing? (Yes, it's me, Karl :-) )" start="00:35:32.840" video="qanda" time="1" id="subtitle"]] + - A: (Probably answered by voice.) +- Q5: Could you settle this "Org" vs "Org-mode" vs "orgmode" vs ... once and for all (i.e. which one, capitalized how, and where)? :) + - A: (Probably answered by voice.) +- [[!template text="Q6: Does this mean that you do not need to be technical to be(come) a maintainer? Would that really work?" start="00:15:09.880" video="qanda" time="1" id="subtitle"]] + - A: The co-maintainer could be a person with less technical background. +- [[!template text="Q7: If time — what does the day of the orgmode maintainer look like? Lots of hours of work every day? Spread out?" start="00:17:24.520" video="qanda" time="1" id="subtitle"]] + - A: Not always. Last two months "MIA." Bastien wants to step down as maintainer but wants to prepare project/community for the next maintainer. "When I was working hard on this it was something like two hours a day. But usually it would be 2-4 hours per week." Most of time spent on mailing list (Bastien notes that he likes mailing list isn't split between users/developers). +- [[!template text="Q8: Thanks for the hard work. Which place is the right place to request a dark mode for orgmode.org website ?" start="00:10:55.200" video="qanda" time="1" id="subtitle"]] + - A: write an email to the Org-mode team. This seems to be a reasonable request. +- [[!template text="Q9: Do you think having centralized roles for people to carry out certain tasks such as documentation across multiple areas would be a constructive approach to inviting new maintainers" start="00:21:11.800" video="qanda" time="1" id="subtitle"]] (in contrast to "every person take an issue of their own choosing", which leaves parts of maintenance and documentation neglected)? From personal experience, sometimes it can be easier for those to be told "hey, we need this area maintanined, or a focus on contribution to this particular area". If we take a page from Catalonian Spain of the early 1900's, even the most decentralized organizations have to dedicate certain persons to specific tasks. Sorry for the long winded question. + - A: (Probably answered by voice.) +- [[!template text="Q10: I think org has and may potentially greatly influence Emacs development. If you would tend to agree, do you have places where you feel Emacs need to "pull back" harder, to" start="00:24:21.440" video="qanda" time="1" id="subtitle"]] incluence org? Key areas where org is clearly "leading the way"? + - A: "Org is to Emacs was Emacs is to computer systems" +- [[!template text="Q11: Could you expound a little on what's happening with contrib ... I'm a little confused. Mechanics/technical. " start="00:27:52.320" video="qanda" time="1" id="subtitle"]] + - (Karl: Do you mean technically "how to migrate" or the background why this happened? I personally did the conversion this week. I got the separate repository (or package) and had to do more local "use-packages" (the way of loading elisp files in my setup) and that's it. The hard thing was to find out which error refers to which org file to load separately.) Thanks. Seems like time for bankrupcy again :-/. + - A: contrib = stuff that didn't go to Emacs (copyright assignment not necessary). This was not a clean solution because it was mixed with copyright-transferred files in the same repository. New contrib goes now to "non-GNU" which is a clear separation according to copyright assignments. The way to install Org is via Org MELPA and contrib for Non-GNU MELPA. YES. THANKS. +- Q12: (Maybe not a question, just an observation) I like the analogy to gardening. FOSS projects seem much like community gardens. Also, shepherding seems like an apt analogy; I could imagine files having "shepherds" :) + - A: (Probably answered by voice.) +- [[!template text="Q13: Has splitting contrib actually reduced maintenance load? Is it too soon to tell? (I have found that splitting repos ultimately increases maintenance overhead due to multiplying" start="" video="qanda" time="1" id="subtitle"]] release overhead etc.) + - A: It is clearly easier now and less confusing for contributors. org-contrib is soon to die: packages will be moved to their own packages since contrib was founded when there was no packaging around. +- Q14: So was BHL the basis for org-export? + - A: https://bzg.fr/en/theorgfather/ + +BBB: + +- agreed, I appreciate that the list isn't split. + - vastly simplifies workflows. +- (Missing context) Wouldn't they be missing the key part, Emacs? + - Questioner: (ah, i understood forking for a different toolset, vs markdown-based org-mode on Emacs, apologies) + - Bastien Guerry: <https://list.orgmode.org/87y2jvkeql.fsf@gnu.org/> +- devil's advocate to Karl's point now though: is that from habit? +- link syntax in markdown is impossible to remember for simplifying e.g. keyword syntax can be made regular. consistency across levels is extremely hard due to interactions between features, in part because you only encounter those much later in implementation. another part of the issue is that Org has more features than pandoc markdown so it is sometimes unrepresentable. +- interestingly Timothy has solved most of the markdown &> org + - plain orgmode is easy to visualize. with markdown you need to export this if you have many md lines. org tables is a clear example of the visualization +- I think the argument of the best syntax is a hard battle to fight, but where the bar is clear is the software (org-mode) and what it can do with it, as of today. +- [[!template text="FYI org-sidebar provides a backlinks tool" start="00:54:54.080" video="qanda" time="1" id="subtitle"]] +- Backlinks! Yes! +- Backlinks for me: <https://karl-voit.at/2020/07/22/org-super-links/> +- was going to say : many of the org-roam features should make their way into core org-mode eventually +- how to manage and cache other types of data that are similar to backlinks +- something like org-id caching, you mean? +- alphapapa: not quite, more things that we don't want to put in the org file directly; e.g. babel caches for huge pieces of data +- id caching for performance would be great, some of the vizualisation things are very interesting too + - it is a hard problem + +BBB feedback: + +- Thank you for taking the time to share your accumulated wisdom with us, Bastien :) +- merci Bastien! + +IRC: + +- 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"]] + +[[!inline pages="internal(2021/info/maintainers-nav)" raw="yes"]] diff --git a/2021/talks/model.md b/2021/talks/model.md new file mode 100644 index 00000000..ad33ff8f --- /dev/null +++ b/2021/talks/model.md @@ -0,0 +1,124 @@ +[[!meta title="Extending the "model" of Emacs to other applications"]] +[[!meta copyright="Copyright © 2021 Laszlo Krajnikovszkij"]] +[[!inline pages="internal(2021/info/model-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Extending the "model" of Emacs to other applications +Laszlo Krajnikovszkij + +[[!inline pages="internal(2021/info/model-schedule)" raw="yes"]] + +Emacs is a great operating environment in a sense that it provides consistency +across different tools and applications within the Emacs ecosystem, as well as +external apps that can be integrated into it. It is also the most truly +malleable environment, each element of which can be adjusted or extended, +therefore providing the user with more power and freedom in personal computing. +Emacs definitely can be considered one of greatest software products in +existence. + +As a non-programmer, having had the chance to stumble upon Emacs a couple of +years ago, the only regret to have is that it didn't happen earlier. The definite +killer feature of Emacs - Org-mode, is what draws many of the less technical +folks to join the party and gradually start to use Emacs for writing documents, +whether personal or work related, manage tasks, emails and potentially everything +else. The learning curve and difference in approach, however, leaves some +potential users too scared of the arcane interface even with all it's quirks and +features because it requires at least some technical skills to understand and +use properly, and does not have an easy way to connect with external tools that +most people are forced to use for work. + +This talk proposes some ideas about how the model of Emacs, it's focus on +consistency, extensibility, as well as it's powerful interaction model can be +carried over to make modern interfaces, whether desktop or web applications, +that would be designed with a goal of reflecting the spirit of Emacs in terms of +the aforementioned features it possesses, and therefore enhance the capabilities +of the Emacs, while at the same time utilizing it as a backend for +text-processing and editing to a large extent. It would be really great to have +a personal web-interface for using modern task management tools, chats, emails +and such, but from a UI defined by the user. The goal is to use it on a desktop +or mobile, locally or self-hosted on a server, with support for touch and +gesture-based workflows, while preserving the Emacs philosophy and allowing to +seamlessly switch between Emacs and its web extension + +The proposed solution is to integrate more of the modern tools with Emacs, +utilize Org-mode as a way to define application-specific parameters for these +tools through Org properties, and then utilize these parameters for making a +modern local frontend that would enhance Emacs UI while allowing to use external +tools in a more personal and freedom respecting way (making the originals +obsolete over time). The talk serves the purpose of inviting community members to +a discussion about how Emacs can become more modern, more approachable by people +who don't possess the neccessarry technical skills to adjust it themselves, but +are keen to learn it, and potentially how to attract more users to greater +productivity, computer literacy and the ideas of free software. + +# Discussion + +- Q1: What is the URL of your web page? I guess the URL on your slide + is currently not available (see links below). + - A: The URL written is correct, but unfortunately the website is + down due to some misconfiguration and will be back soon. You can + contact me at laszlo.lk@protonmail.com until it is resolved +- Q2: It is important to note that for EAF to extend to the web apps + you mentioned (Asana, Jira) in a deeper way than just displaying the + web app using EAF Browser, the APIs of these web apps need to be + exposed too. + - A:Exactly, otherwise only a one way update would be possible. As + long as they have integration with other external tools, there + must be a closed API documentation for making it work. + +Links: + +- different form + <https://github.com/emacs-eaf/emacs-application-framework> in that + the goal here is not to do everything in emacs buffers. +- <https://github.com/ag91/emacs-with-nyxt> + +# Outline + +- 5-10 minutes + - Introduction + - Issues with most modern tools for work + - Issues with Emacs as a tool for work + - In search for a hybrid approach + - User controlled web-apps + - Opinions encouraged + - Contacts + +<!-- +- 20 minutes: + - Introduction + - Why Emacs? + - Issues with most modern tools for work + - Issues with Emacs as a tool for work + - In search for a hybrid approach + - Emacs as the text-based "backend" + - Org as the universal format to convert data + - User controlled web-apps + - Potential use cases + - Potential difficulties with implementation + - Opinions encouraged + - Contacts + +- 40 minutes: + - Introduction + - Why Emacs? + - Issues with most modern tools for work + - Issues with Emacs as a tool for work + - Keyboard driven workflows and modal editing + - In search for a hybrid approach + - Emacs as the text-based "backend" + - Org as the universal format to convert data + - User controlled web-apps + - Releasing proprietary web-apps from the "cloud cage" + - Potential use cases + - Potential difficulties with implementation + - Extending the idea further by combination with Guix + - Opinions encouraged + - Contacts + +--> +[[!inline pages="internal(2021/captions/model)" raw="yes"]] + +[[!inline pages="internal(2021/info/model-nav)" raw="yes"]] diff --git a/2021/talks/mold.md b/2021/talks/mold.md new file mode 100644 index 00000000..7c5eb707 --- /dev/null +++ b/2021/talks/mold.md @@ -0,0 +1,113 @@ +[[!meta title="Moldable Emacs, a step towards sustainable software"]] +[[!meta copyright="Copyright © 2021 Andrea"]] +[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Moldable Emacs, a step towards sustainable software +Andrea mailto:andrea-dev@hotmail.com - pronouns: he/him -- https://ag91.github.io + +[[!inline pages="internal(2021/info/mold-schedule)" raw="yes"]] + +We could learn about things better. Mountains of knowledge hide in +places we cannot access or use. The more we write down, the more it +takes to find and understand things we find useful. + +Knowledge (web, software, books) keeps growing faster and faster! This +is not sustainable: we cannot keep up with it! What if we repeat the +error of somebody else, only because it would take too much reading to +know? What if that knowledge is in some code we work with everyday? + +Moldable development is a paradigm shift that attempts to solve this +problem. In a gist, the tool you use should let you create special tools +to learn smartly from what you have already. + +Since we use Emacs, let's make our great editor moldable! + +This talk shows my progress in making Emacs closer to such a tool. We +are going to see how we can mold structured (and maybe even natural) +text to learn better, how we can inject notes in our projects and how +self documenting this tool is! + +I aim to inspire you to find a quicker way to learn from our digital +world! + +You can learn more about this at: <https://github.com/ag91/moldable-emacs> + +# Discussion + +IRC nick: `andrea + +Pad: + +- Q1: How to find a balance between «generic» molds that do not + provide specific enough info vs writing a new mold for every new + query/question? + - A: You can write molds that are private for your special + problem. I created molds for my work that I don't share: like + find the stories I am working on and how long time I spent on + tasks lately. Also, moldable-emacs is to make these tools easy + to write, so you should free to throw away tools when you need + them once only. If I believe a tool is a good start for many + other tools, I put them among the core molds, else if I use them + often I store them as contrib. If it is a one off, I throw it + away. +- Q2: How would you evaluate this workflow for package managemnt in + large independent codebases. Can one integrate it with code sematic + analyzers to make for a better work flow? + - A: moldable-emacs is about creating custom tools you can apply + to your situation. I started experimenting with molding NPM json + packages + security data from OWASP to view/display security + issues in my packages to my colleagues in the past. + moldable-emacs gives me the infrastructure to answer my question + about security, and I now started asking myself about + architecture coherence, so I have scaled up tree-sitter over + projects to check that modules don't use packages from other + modules. By that I mean that as long as your code semantic + analyzers output data, you can mold that (context) data to tell + your story (answer the question you have). Does this answer your + question? + - You answered it very well. I am also a security auditor for + multiple development teams. And I am incharge of code analysis + in an understaffed security team. So your usecase example got my + usecase spot on. + - Cool! For now you can define insecure patterns using tree-sitter + expressions (for example, I find a variable called "password" + in the code set to a string. For the package.json I linked to + OWASP API and looped through the packages using tree-sitter + tokens. I didn't get there, but I wanted to see an Org Mode + buffer with the list of the most vulnerable deps highlighted by + color + how to solve them: so I could pass them to developers to + resolve them (I am a dev, but sometimes others don't know about + security risks). + - Often molds are to tell stories to others. + - This is probably the most important thing for my personal + usecase. Thank you very much. Now it's my turn to learn it and + use it well. + - Please open issues or email me, and I will try to help if you + like how it works :) + - I'll do so. + +IRC: + +- 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. + +Links: + +- Telling a story about code using buffer views <https://moldabledevelopment.com/> + +# Outline + +- 5-10 minutes: quick demo of moldable-emacs +<!--- 20 minutes: same as above but going more in depth for the vision of the package, how it fits with my code-compass talk of last year and some features +- 40 minutes: same as above and explanation of how you can extend the features available +--> + +[[!inline pages="internal(2021/captions/mold)" raw="yes"]] + +[[!inline pages="internal(2021/info/mold-nav)" raw="yes"]] diff --git a/2021/talks/molecular.md b/2021/talks/molecular.md new file mode 100644 index 00000000..3cc7d829 --- /dev/null +++ b/2021/talks/molecular.md @@ -0,0 +1,158 @@ +[[!meta title="Reproducible molecular graphics with Org-mode"]] +[[!meta copyright="Copyright © 2021 Blaine Mooers"]] +[[!inline pages="internal(2021/info/molecular-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Reproducible molecular graphics with Org-mode +Blaine Mooers + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/molecular-schedule)" raw="yes"]] + +Research papers in structural biology should include the code used to make +the images of molecules in the article in the supplemental materials. +Some structural bioinformaticists have started to include +their computer code in the supplemental materials to allow readers +to reproduce their analyses. However, authors of papers reporting new +molecular structures often overlook the inclusion of the code that makes +the images of the molecules reported in their articles. Nonetheless, +this aspect of reproducible research needs to become the standard practice +to improve the rigor of the science. + +In a literate programming document, the author interleaves blocks +of explanatory prose between code blocks that make the images of molecules. +The document allows the reader to reproduce the images in the manuscript by running the code. +The reader can also explore the effect of altering the parameters in the +code. Org files are one alternative for making such literate programming +documents. + +We developed a **yasnippet** snippet library called **orgpymolpysnips** for +structural biologists (<https://github.com/MooersLab/orgpymolpysnips>). +This library facilitates the assembly of literate programming documents +with molecular images made by PyMOL. PyMOL is the most popular +molecular graphics program for creating images for publication; it has +over 100,000 users, which is a lot of users in molecular biology. PyMOL +has been used to make many of the images of biological molecules found +on the covers of many Cell, Nature, and Science issues. + +We used the **jupyter** language in **org-babel** to send commands from +code blocks in Org files to PyMOL's Python API. PyMOL returns the +molecular image to the output block below the code block. An Emacs +user can convert the Org file into a PDF, `tangle' the code blocks +into a script file, and submit these for non-Emacs users. We describe +the content of the library and provide examples of the running PyMOL +from Org-mode documents. + +# Discussion + +Pad: + +- Q1: Do you also do any hydrogen-bond analysis in your workflows? + Also, could your snippet library be extended for other non-python + simulation programs like GROMAC? + - A: Yes, i have a snippet that generate publication qualtiy + hydrogen bonds. Yes, I have thought of making snippet library + molecular simulation like Gromacs and AMNER and drug design + software packages like autodock Vvna and rdkit. They can help + lower the barrier to entry. I made library for crystallographic + computing with CCTBX for use in Jupyter. I should make it + available for org-mode. +- Q2: We've seen a few talks regarding managing academic papers and + citations in emacs/org, what does your workflow look like? + - A: I switched to Emacs as my primary editor 3 months ago. I have + yet to write a paper in Org. I am very comfortable with LaTeX + and I have been writing my papers on Overleaf in LaTeX for + several years. I used bibtex and JabRef to manage by refernces. + I have started playing by org-ref. It looks super promising. +- Q3: Hi Blain, you mentioned that you have been able to come back to + a file years later, how do you manage the environment that the org + file executes in? + - A: Good question. The PyMOL code is good for years so the images + should be reproducible regardless of the version of org. + PyMOL's domain specific language is very stable. The Python + code largely just wraps around the DSL code. +- Q4: Have you used Org Mode and pyMOL for publications? Could you + share a link to any of them? + - A: I have yet to use org in a publication. The first step will + be to use it for supplemental material. + +BBB discussion: + +- We've seen a few talks regarding managing academic papers and citations in emacs/org, what does your workflow look like? + - Blaine: My workflow involves a dozen different software packages and 20-200 GB of data. Complete literate programming is not possible at this time. The smallest possible step towards that goal is to make the molecular images reproducible because the files involved are on 1-100 MB in size. + - Questioner: I assume that's why there might be lag with several images rendered on an org buffer? +- I was specifically interested in your workflow with managing citations and papers as I'm sure you have to do, is there anything in particular you use for citation management? + - Blaine: I switched to Emacs as my primary editor 3 months ago. I have yet to write a paper in Org. I am very comfortable with LaTeX and I have been writing my papers on Overleaf in LaTeX for several years. I used bibtex and JabRef to manage by references. I have started playing by org-ref. It looks super promising. + - Questioner: I still use zotero and biblatex, but the previous two talks about org-ref got me thinking about my workflow +- Have you used Org Mode and pyMOL for publications? Could you share a link to any of them? + - Blaine: I have yet to use org in a publication. The first step will be to use it for supplemental material. + - thanks, makes sense, I'm off in a part of the python world where code base churn can be pretty severe; but it sounds like pymol is able to avoid those issues + - Blaine: PyMOL as a domain specific language that is very stable. The transition from Python2 to Python3 as bit disruptive. +- Hi Blaine, you mentioned that you have been able to come back to a file years later, how do you manage the environment that the org file executes in? + - Blaine: Good question. The PyMOL code is good for years so the images should be reproducible regardless of the version of org. + +BBB feedback: + +- Blane, great job with the talk. Awesome presentation. + - I know people loved it in the IRC chat :D +- I can share that I was excited to see how you made things so seamless and integrated feeling into Emacs. The results are really eyepopping. + + +IRC discussion: + +- which is the package name for export org mode to pymol? +- the async header argument can be helpful with the problem of the amount of time for generating the images +- think of this is use case explication for being able to manage and render 3d models in org +- It might be faster to keep sections folded by default +- This is exactly the sort of thing my users love. + +# Outline + +- 5-10 minutes: (brief description/outline) + - Title slide + - Structural Biolog Workflow in the Mooers Lab + - Cover images made with PyMOL + + - Why develop a snippet library for your field? + - PyMOL in Org: kernel specification + - Creating a conda env and installing PyMOL + - Example code block in Org to make DSSR block model of tRNA + - Resulting image + - Summary + - Acknowledgements + +<!-- +- 20 minutes: (brief description/outline) + + I would prefer to give a 20-minute talk because this allows time to develop the context. + +- Title slide +- Structural Biology Workflow in the Mooers Lab +- Cover images made with PyMOL +- Bar graph of PyMOL's popularity +- Origin story of PyMOL +- PyMOL's hybrid open-source model +- PyMOL's GIU +- Default molecular representations in PyMOL +- Example of the PyMOL macro language +- Same commands in Python +- Corresponding code in yasnippet snippet +- Extension of molecular representations with orgpymolpysnips +- Hermann Ebbinghaus's Forgetting Curve +- Why develop a snippet library for your field? +- PyMOL in Org: kernel specification +- Anatomy of kernel file +- Creating a conda env and installing PyMOL +- Example code block to make DSSR block model of tRNA +- Resulting image +- Org vs. JuptyerNotebook, Juptyer Lab, and RStudio +- Summary +- Acknowledgements + +--> +[[!inline pages="internal(2021/captions/molecular)" raw="yes"]] + +[[!inline pages="internal(2021/info/molecular-nav)" raw="yes"]] diff --git a/2021/talks/montessori.md b/2021/talks/montessori.md new file mode 100644 index 00000000..8c734ad9 --- /dev/null +++ b/2021/talks/montessori.md @@ -0,0 +1,234 @@ +[[!meta title="Emacs and Montessori Philosophy"]] +[[!meta copyright="Copyright © 2021 "]] +[[!inline pages="internal(2021/info/montessori-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs and Montessori Philosophy + +[[!taglink CategoryPhilosophy]] + +[[!inline pages="internal(2021/info/montessori-schedule)" raw="yes"]] + +As a former Montessori guide and now parent, I often think about the +relationship of this particular educational philosophy and how it manifests +in my work with software, Emacs in particular. This talk introduces the +concept of Emacs as an educational environment and how it expresses elements of +Montessori psychology regarding "Human Tendencies". Human tendencies are innate +drives present in everybody that allow us to explore and make sense of our world. + +# Discussion + +- Q1: Would you say that the Montessori philosophy follows a "verb" + based methodology, where an abstract action is performed on an item, + without locking the action to what the item can support, like an + Object-oriented language would do? + - e.g. `throw(rock)` instead of `rock.throw()`, i.e. a + function in a global namespace, instead of a function belonging + to an object? + - A: i'd like to think about this some more, but honestly i think + its a bit of both? there's certainly some things I can think of + that are more like `rock.throw()`... Here are the things you + can do with these materials, and that is it. On the other hand, + I've certainly seen inventive uses of educational materials + that follow more of a `throw(pencil)` type of thing. + - The philosophy is highly observation based, so I'm thinking + about the difference of something like `Child::new.learn()` vs + `learn(some-child)`. In this case I do feel like the "verb" + based methodology is more appropriate. We need to stop and + observe a child, to notice what is driving them, what they're + responding to, and where they are in their abilities. Depending + on our observations, we may offer different kinds of input. Its + certainly much less like "oh i have another Child object and I + need to have them do x, y, z" in order to get to point B. + - I hope this somewhat answers the question. I'll keep pondering + :) + - Thank you, I guess some children favour one method over + another, but it's not as black and white as I initially + thought. Thanks! +- Q2: How old do you think childen need to be to start exploring with + Emacs? + - A: Children 0-6 are in a phase called the "absorbent mind". It + is this miraculous superpower that children have to absorb + everything around them. The ability to learn language is + probably the most obvious example. So, if children can interact + with Emacs, they can start exploring it. Of course, as a text + editor, basic literacy is pretty important. I personally have + not tried teaching young children Emacs, but I believe with the + right kinds of interfaces, it could be possible. +- Q3: How to let my kids exploring Emacs?(No need to answer this. + It's simillar to Q2) + - A: Great question! Much of the early childhood Montessori work + is highly tactile. Abstract concepts are embodied in physical + objects. One example is the "binomial cube" which is a set of + blocks that demonstrates (a + b)^3. Children know nothing about + the math behind it, but by interacting with it as a tactile + puzzle, something about the math concept behind it, the + abstraction, is available to the child and their absorbent mind. + - That is to say... perhaps there are ways to bring Emacs into + the physical world for the very young. I've been fantasizing + about some kind of "physical lisp" where young children can + interact with a sort of physical programming language. I don't + have a lot of concrete ideas on how to get young children + exploring Emacs, but I do believe it is possible. + - For older, literate children, I believe simple things that give + instant feedback are a great way to encourage interaction. Being + able to do something like (set-cursor-color "orange") and see + it work at your finger tips is amazing. I believe that a well + prepared set up where M-x is easy to access and you get some + kind of completion to show you what you can do would go far. + Even ielm could be useful. Children are not nearly as afraid of + a command prompt as some grown ups are. They come to it with + much less preconceptions on how it should be used. + - I would like to think more about this, as giving children the + opportunity to experience Emacs feels critical these days, when + they may be forced into using much non-free software just do do + their school work. +- Q4: How big of an impact does the environment have on the children + that you teach? + - A: the environment is huge. giving children a prepared space + where everything is accessible to them, down at their level, the + correct size, etc, it can lead to amazing things. When I worked + with 1.5-3 year olds, I remember telling people it was like + managing a restaurant where my employees were toddlers. I could + work with a group of children to get food served into properly + sized dishes, beverages poured, ceramic plates and glass cups + set on the tables, napkins folded, and so on all finished in + time to get everyone down for lunch before we had major melt + downs. This would not be possible in a normal grown-up + environment. + - I'm not sure i said this in the talk, but the environment is an + active process on all of us, not just children. the 0-6 year + olds (and beyond) are absorbing so much from the environment + that we simply filter out. i think this is important to consider + for new emacs users. I tend to filter out a lot of things that a + new user may pick up and stumble over. + - To re-emphasize: the elements of education are The Learner, The + Guide(s), and The Environment. Montessori focuses on the + Prepared Environment, in order that it can be the most effective + for the child's ability to become an independent, self-realized + person. +- Q5:Do you have a good reference for the Montessori principles + (actually any nice book ref)? + - A: I'd like to find a more modern resource, I'm sure they are + out there. Much of my experience was direct hands-on classroom + time. I've read much of "The Absorbent Mind" which really + lays out a lot of the observations Maria Montessori made of the + young child, 0-6 years old. The other book I've studied is + "The Secret of Childhood". I would like to stress though, a + lot of the knowledge in Montessori is very very similar to + traditional knowledge. When I was learning more about Lakota + culture and parenting, I was finding that Montessori was + expressing much of the same thing. Any resource (book, human, + whatever) that respects children as whole human beings is worth + paying attention to. Another author I've enjoyed is Aletha + Solter, who writes about parenting. +- Q6:How do you think Emacs could improve re: Montessori Principles + (if at all)? + - A: My main takeaway is that we should acknowledge the three + elements of learning: The Learner (user), The Guides + (contributors), and The (Prepared) Environment. Each user coming + to Emacs is an individual with their own mix of internal drives + (human tendencies) that compel them to learn and experience. + Everyone that is a contributor to Emacs (whether in code, on the + web, or in chat) acts as a Guide in the environment (whether + they know it or not). The Prepared Environment could be + considered how the application is set up for users. I think + there is room for a friendlier Prepared Environment, though I am + always amazed at what I can discover where the self-documenting + feature helps me out. Interactive tutorials teaching one how to + learn how to learn Emacs would be tricky, but I think some + interesting work could happen there! + - Another principle is "control of error", meaning, when you + fail at something or make a mistake, it should be obvious, and + hopefully the correction of the error should be obvious as well. + This is hard to do in a huge software environment like Emacs, + but I think there could be some work done in this regard. I'm + reminded of Racket's beginning student languages, which make + error messages more human focused and less computery is a good + example. + - I think the community could also improve as Guides. I have + certainly had many pleasant interactions with Emacs users, but + sometimes you run into things like "RTFM" or "read the + source". While I don't disagree, it can come off as elitist + sometimes. Many new users are afraid to read source, or have + found a manual but still don't understand. We certainly want to + encourage independence, so offering techniques like "have you + tried M-x describe-function?" is better than just answering + outright. Sometimes we need to take a moment and understand the + Learner we're working with. Maybe they aren't ready for "read + the source". I could keep writing, but I think I need to wrap + up. Anyone should feel free to email me to talk more! perhaps + i'll try doing some writing about it. +- Q8: What was the presentation mode you used? + - A: org-tree-slide - <https://github.com/takaxp/org-tree-slide> - + i love using this package because i can practice and edit my + presentation at the same time. + +Feedback: + +- having studied in a school which founded by following Montessori Philosophy, I can relate <3 +- Love the emphasis on creativity! +- Such a cool talk +- Great perspective in that talk. +- the reference to Montessori made me think of Alan Kay's talks about Frenet and Papert. + - i was thinking the exact same thing regarding Alan Kay and his talks about education, and of his philosophies behind Smalltalk (the programming language). + - and Smalltalk as a platform shares a lot with Emacs, both are a world where a user lives and develops + - garjola: yeah...the whole thing about discovery, figuring things out for yourself, having an epiphany. + +Links and other notes: + +- <https://github.com/takaxp/org-tree-slide> +- <grant@churls.world> +- @kheya@mastodon.social +- <http://blog.shoshin.digital/> (there's not really anything there + xD) + +# Outline + +- 5-10 minutes: (brief description/outline) + Quick overview of a Montessori classroom environment: + + - the adults or guides primarily observe and present material + - the children are free to explore materials as they choose (within limits) + - the environment itself is prepared specifically to foster engagement + + Enumerate the "Human Tendencies": + + - Abstraction + - Activity + - Communication + - Exactness + - Exploration + - Manipulation (of the environment) + - Order + - Orientation + - Repetition + - Self-Perfection + - Work (also described as "purposeful activity") + + How does Emacs express these things? + + - in the short version, pose the question, and perhaps give one example. + - Emacs is an environment that provides facilities for individuals to + find their way to proficiency through their Human Tendencies. + - We are all both learners and guides, Emacs is our classroom + +<!-- +- 20 minutes: (brief description/outline) + This would follow the same outline as above, but go more deeply into how + Emacs fosters understanding and growth by allowing individuals to express + the various Human Tendencies. + +- 40 minutes: (brief description/outline) + I don't have in mind to do a 40 minute talk, though a friend and fellow Emacs + user is also a former Montessori guide and we had talked about sharing our + experience together in this presentation. This would include more anecdotal + evidence of what we experienced ourselves observing children as well as our + journey to competency as software developers through the classroom of Emacs. +--> + +[[!inline pages="internal(2021/captions/montessori)" raw="yes"]] + +[[!inline pages="internal(2021/info/montessori-nav)" raw="yes"]] diff --git a/2021/talks/nangulator.md b/2021/talks/nangulator.md new file mode 100644 index 00000000..bbf7bfed --- /dev/null +++ b/2021/talks/nangulator.md @@ -0,0 +1,57 @@ +[[!meta title="Introducing N-Angulator"]] +[[!meta copyright="Copyright © 2021 Kevin Haddock"]] +[[!inline pages="internal(2021/info/nangulator-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Introducing N-Angulator +Kevin Haddock + +[[!inline pages="internal(2021/info/nangulator-schedule)" raw="yes"]] + +<https://github.com/vigilancetech-com/N-Angulator> + +The Unix file system is essentially an N-dimentional sparse array that +currently lacks a decent editor and browser which +can effectively leverage the logical tri-angulation (or, more properly +"n-angulation") of atoms/blobs within it. + +N-Angulator is the genesis, to wit, the "Model-T," of such a program. + +# Discussion + +IRC nick: N-Angulator + +- Q1: Can this be considered as a UI to manage hardlinks with + additional functionality such as listing the hardlinks of a single + file? + - A: that is part of what it could be considered. I see it more + as re-imagining the Unix/Linux file system as a data cloud +- Q2: Remark: I did a PhD on that very same topic: + <https://karl-voit.at/tagstore/en/papers.shtml> - Your approach does + seeom to have similarities to the Semantic File System (Gifford et + al) or SemFS (Mohan at al) or TagFS (Bloehdorn et al). + - A: yes, I just started checking it out. I was not aware of any + of those when I wrote it. I just had a need for a much more + comprehensive filing/retrieval system to support my various + activities (law, programming, time management, etc...). It + worked amazingly well at the time but "life happened" and I + was never really able to keep it up with the times like porting + it from the orphaned XEmacs into FSF and promote it at all. +- <https://github.com/vigilancetech-com/N-Angulator> + +- N-Angulator: I wrote it 10 years ago and am no porting it to GNU emacs +- is this a graph-as-filesystem +- I'd much rather work with keybindings rather than clicking things. Is there support for that? + - N-Angulator: I think the menu system does automatically assign some unique keys but it's been a long time since I looked at it +- I love these kind of advanced file systems +- This is weirdware in the best sort of way. +- Are you familiar with tagstore/TagTrees (by me) or Semantic File System (Gifford et al) or SemFS (Mohan at al) or TagFS (Blöhdorn et al)? my work: https://karl-voit.at/tagstore/en/papers.shtml -> preferably the PhD document that summarizes everything + +- From [YouTube](https://www.youtube.com/watch?v=ggmfWPmse_w&feature=em-comments): Any chance you can explain what this package can actually do? I don't want to be critical. It looks interesting but I just don't know what to do with this. + + +[[!inline pages="internal(2021/captions/nangulator)" raw="yes"]] + +[[!inline pages="internal(2021/info/nangulator-nav)" raw="yes"]] diff --git a/2021/talks/native.md b/2021/talks/native.md new file mode 100644 index 00000000..2916c9f5 --- /dev/null +++ b/2021/talks/native.md @@ -0,0 +1,193 @@ +[[!meta title="Emacs Lisp native compiler, current status and future developments"]] +[[!meta copyright="Copyright © 2021 Andrea Corallo"]] +[[!inline pages="internal(2021/info/native-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs Lisp native compiler, current status and future developments +Andrea Corallo + + +[[!inline pages="internal(2021/info/native-schedule)" raw="yes"]] + +Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor +family. GNU Emacs is traditionally capable of executing Elisp code +either interpreted or byte-interpreted after it has been compiled to +byte-code. + +In this talk I'll discuss the Emacs Lisp native compiler. This feature +recently merged into the main Emacs development line allow for +automatically compiling and executing Elisp as native code. + +During the presentation I'll touch on: + +- design goals +- compiler and runtime design and implementation +- performance implications +- upstream process +- area of improvements and future developments + +Format: 40 minutes + +# Discussion + +Pad: + +- Q1: Why do you say that Elisp is *nearly* a general purpose + programming lang? What's missing? (and btw, huge thanks for your + work!) + - A: +- Q2: Is this the "rudiments" that the garbage collector talk was + discussing yesterday? Feel free to ignore this n00b question. + - A: +- Q3:Is the idea to enventually develop Emacs itself in ELisp (c.f. + Smalltalk VM developed in Smalltalk)? + - A: +- Q4: How did you work on this? Did you use Org Mode to keep track of + your progress? Did you use pictures to keep track of your compiler + transformations or you made only for the presentation? Asking + because it seems a complex project and I am not sure how you kept + that all in your mind! For example, make sure to pick stuff that FSF + was okay with while also deciding how to implement the optimization. + Great job anyway! + - A: +- Q5:Is this pipeline a possible source of new security + vulnerabilities, or a new category of vulnerabilities? Is it + something you are worried about or have had to deal with? + - A: +- Q6: What code, if any, would still benefit significantly from being + written in C? Could/should some of the existing C code be converted + without significant performance loss? + - A: +- Q7: What's the risk of (setq native-comp-speed 3)? + - A: Not sigificant risks. Some side effects might include: + needing to recompile a whole file or compilation unit when + redefining a function, otherwise the old function definition + could be used. +- Q8: Are there any limits introduced by native comp with respect to + runtime introspectability, changeability/redefinability, etc? + - A: +- Q9: Is there a benefit in setting native-comp-compiler-options to + "-mtune=native -march=<cpu>"? + - A: Not at the moment. Maybe in the future if, e.g. libgccjit is + enhanced further. +- Q10: You mentioned native-comp coming in emacs 28, will this be the + default at build time, or will distros have to set this themselves? + - A: It will not be enabled by default. Distros would need to + enable it themselves.(Thanks!) +- Q11: Could we avoid libgccjit.so? Or consider using another jit lib + (e.g. dynasm used by luajit) et al to gain better optimization + - A: libgccjit is more for AoT compilation, more in-depth + optimization, which JITters don't typically do, so they aren't + really equivalent. +- Q12: How much of emacs C code base could be translated to + emacs-lisp? What is the minimum C code base necessary? (seems + duplicate of Q6) + - A: Very hard questions to answer. :) Not generally + feasible/worth to convert most of it. +- Q13: could we statically type elisp code (via macros?) to provide + more optimization hints to compiler? + - A: Hope to extend existing Elisp variable-type annotations to + arguments and use that for optimization. +- Q14: Elisp and Python all are dynamically typed langauge, but + benchmark shows that Elisp runs slower than Python. Could we learn + some best practices from the Python community? As you mentioned. + make parameter type annotated is a promising point. + - A: Not sure if Elisp is really generally slower than Python. + The Elisp bytecode VM is similar in design to the Python VM. + Some native-compiled Elisp may already be faster than Python, + e.g. for certain math code. +- Q15: Did you try to optimize with Rust too? What are your thoughts + on Rust for this particular optimization and security? + - A: Optimize what? There is no Rust here. :) Rust is + interesting, though. There may be some possibilities, e.g. with + regard to some similarities between Rust and some CL + implementations. +- Q16: Why not implement Emacs Lisp in Guile and use Guile's + compiler? + - A: (not Andrea answering) This has already been tried and done, + lookup Guilemacs, e.g. on EmacsWiki. + - A: I think they meant to implement Elisp in Guile, and not + to replace Elisp with Scheme + - Yes, that's already been done. Guile can already run + some subset of Elisp. Look it up. :) + +BBB: + +- Where did funding for your work came from? Will you be able to maintain this in the foreseeable future? +- akrk: What kinds of applications do you envision native-comp enabling to work well in Emacs in the next few years, that wouldn't otherwise be possible? +- Is this the first real-world practical use of libgccjit? +- Is there any easy tasks you need help with? +- yes, your updates and communication with the community have been great +- I believe, going by the aliases, there's at least a couple of GNU compiler hackers in this BBB room now :) +- you mentioned that these improvements are orthogonal to the garbage collector. Do you know of any work on that area? +- hmmm XEmacs got a new GC, much better -- and it turned out *slower* than the original. This stuff is hard... + - NullNix: Really? Yesterday Stefan mentioned XEmacs's GC and said that it could be used in GNU Emacs + - Alas, quite noticeably slower :( cache locality, probably. It may be possible to make it faster with more work, though, while the existing Emacs one is probably at its implementation limits. + - IIRC, the XEmacs one was a generational GC. It was a long time ago though, ICBW + - The JDK and Go both have interesting GC designs in this area... +- some level of "naive" optimism is necessary to start working on these big projects :) +- what kind of packages do you think could be now practical with native comp? +- ok, but what are the limits, in your opinion? How fast can elisp go? +- relevant link: <https://www.emacswiki.org/emacs/GuileEmacs> (with caveats. lots of caveats). note: guile has native support for elisp -- but the lack of buffers, the different rep with strings, etc, was *hard*. the guile compiler changed a *lot* in v3. v1.8 -> 2.0 -> 2.2 -> 3.0 were all big changes in the guile comp world +- indeed :) +- What are some other hobbies/interests of yours besides Emacs? + - Questioner: cool, reminds me of Thierry Volpiatto who's a professional climber, and there are several Emacsers who do DJing; that would be fun; "Emacs Plumbers Conf"; +- will you be presenting there or anywhere else in the next year? +- Emacs keeps creeping toward being the Lisp Machine of the 21st century :) + - not only that, but with LSP and things like Doom, there is an increasing appeal for Emacs as an editor for the general public; native compilation will help with that +- (Probably a live question) + - yes, myths about emacs-devel are hard to dispel + - Eli is so patient with the people on Reddit :D + - agreed, we owe him a lot +- I've always wanted to do Emacs trading cards; like features, devs, etc :P + - that's a great idea :D + - I designed some for an old gaming clan years ago, it was a lot of fun + - Not American?~; in the US we have a tradition of baseball, and other sport playing cards, each with a picture and some stats on the back + - we have that with football (real football) in Europe :) +- (Probably live question + - there might be even more from RMS that weren't accounted for as separate commits when the repo was converted to git +- Where is the pre-git repository? + - I thought it was from bzr. + - I don't remember the details, but ESR's written about it on his blog IIRC +- do you have 'wish list' features, things you long for Emacs to be able to do? +- look for posts about reposurgeon +- dickmao has a patch that makes Gnus async.... 8k lines from what I've heard + - I recall that dickmao posted it to the Emacs tracker but it was somewhat monolithic and wasn't well accepted + - i think he was asked to break it down to more reviewable units +- One thing I wondered if you wanted to talk more about andrea was, to the prior point about "myths" about what emacs-devel is "like", there's also "make the culture your own". do you have advice on how to approach the community you haven't gotten to yet? + +BBB feedback: + +- Extremely impressive work, Andrea. Also, very needed for the long term sustainability of the platform. Thanks a lot for the hard work! + - Yes, if there were an Emacs Hall of Fame, Andrea would deserve a prominent place in it. :) + - we really do need an Emacs Hall of Fame so we can remember those who laid the foundations +- I think I can safely say that we are very grateful for your work, because there aren't many people in the world that could do it and who also have enough interest in Emacs to do so :) +- I have to go, thanks for replying to our questions, for the chat and for the incredible work, Andrea +- Thanks very much, and for your work on gccmacs :D +- thanks for the presentation and answering all of the questions. +thanks to you andrea for your awesome talk, and for the extended q&a! + +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"]] + +[[!inline pages="internal(2021/info/native-nav)" raw="yes"]] diff --git a/2021/talks/news.md b/2021/talks/news.md new file mode 100644 index 00000000..79cc9bb0 --- /dev/null +++ b/2021/talks/news.md @@ -0,0 +1,31 @@ +[[!meta title="Emacs News Highlights"]] +[[!meta copyright="Copyright © 2021 Sacha Chua"]] +[[!inline pages="internal(2021/info/news-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + +# Emacs News Highlights +Sacha Chua <mailto:sacha@sachachua.com> - pronouns: she/her, pronunciation: SA-shah CHEW-ah - <https://sachachua.com> + +[[!inline pages="internal(2021/info/news-schedule)" raw="yes"]] + +Quick overview of Emacs community highlights since the last conference + +You can find the links and images at +<https://github.com/sachac/emacsconf-2021-emacs-news-highlights> + +# Discussion + +- how do I "type" an emoji? I know how to copy them from ~/bigsrc/emacs28/admin/unidata/emoji-test.txt, but there must be better ways... + - you could use emojify-mode (there's M-x emojify-insert-emoji) +- Other notes: + - Oh wow, I didn't actually know about embark + - Yeah, switch to "smaller" turned out to be quite nice + - but noticed projectile greps faster than consult/counsel in a lot of cases + - Oh wow, the color picker!!! + - a huge thank you for such an understandable yet detailed summary of what's happening in the Emacs world! + - From [YouTube](www.youtube.com/watch?v=270ljvW6UrA&feature=em-comments): Excellent summary!! Thanks for the timestamps as well. + + +[[!inline pages="internal(2021/captions/news)" raw="yes"]] +[[!inline pages="internal(2021/info/news-nav)" raw="yes"]] diff --git a/2021/talks/nongnu.md b/2021/talks/nongnu.md new file mode 100644 index 00000000..9bfa990a --- /dev/null +++ b/2021/talks/nongnu.md @@ -0,0 +1,32 @@ +[[!meta title="NonGNU ELPA Update"]] +[[!meta copyright="Copyright © 2021 Philip Kaludercic"]] +[[!inline pages="internal(2021/info/nongnu-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# NonGNU ELPA Update +Philip Kaludercic + + + +[[!inline pages="internal(2021/info/nongnu-schedule)" raw="yes"]] + +NonGNU ELPA was announced last year, as a package repository +that will be enabled by default in Emacs, but doesn't require +any copyright assignment. This means that a lot of popular +packages can now be installed easier, without any additional +configuration. + +In this talk I would like the give a reminder of what NonGNU +ELPA is and how it works, update the participants on what has +happened since last year and what maintainers have to do if they +want their packages to be added to the repository. + +# Discussion: + +- It was really pleasant to listen to. + +[[!inline pages="internal(2021/captions/nongnu)" raw="yes"]] + +[[!inline pages="internal(2021/info/nongnu-nav)" raw="yes"]] diff --git a/2021/talks/nyxt.md b/2021/talks/nyxt.md new file mode 100644 index 00000000..371f9ea5 --- /dev/null +++ b/2021/talks/nyxt.md @@ -0,0 +1,52 @@ +[[!meta title="Emacs with Nyxt: extend your editor with the power of a Lisp browser"]] +[[!meta copyright="Copyright © 2021 Andrea"]] +[[!inline pages="internal(2021/info/nyxt-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs with Nyxt: extend your editor with the power of a Lisp browser +Andrea mailto:andrea-dev@hotmail.com - pronouns: he/him -- https://ag91.github.io + +[[!inline pages="internal(2021/info/nyxt-schedule)" raw="yes"]] + +In 2021 browsers are essential if you use a computer. Even if Emacs +users love text as a format, they may need to shop and video call from +time to time (even more so in a pandemic!). Some of us modified their +browsers to at least have the same keybindings as our editor of +choice. What if I told you there is an Emacsy browser in the making? +What if you could "ace-jump" within a web page? What if you could run +a REPL to extend your browser while browsing? What if you could record +macros?! The browser exists: its name is Nyxt! + +In this talk I will share why it has great potential, how you can +integrate it with Emacs, and how you can migrate your Emacs mastery to +the web! + +If you were wishing for a Lispy and Emacsy browser, you should not +miss this talk! + +You can learn more about this at: <https://github.com/ag91/emacs-with-nyxt> + +# Discussion + +IRC nick: `andrea + +- I thought I read somewhere that this browser was attempting to allow extensions in a similar manner to Chrome/Firefox extensions. It'd be nice to have a central location to grab those, install them etc. +- does nyxt also have an inspector, to edit html and css? + - `andrea: yes, I am just sending my JS to the inspector via Common Lisp +- loving the youtube note taking with the timestamp +- If you've been following Nyxt for a while, one of the core design goals is to push web browsing back towards its original conception of intertwingling readership and authorship. +- you have some amazing elisp skills and ideas +- Back when I was using Nyxt I had it tied to stumpwm and I puppeteered them both from emacs with sly. +- I wonder how hard it would be to integrate or compile JS extension to a form available to Nyxt +- `andrea: I need to ask about LibreJS: they have a discourse https://discourse.atlas.engineer/ + +# Outline + +- 5-10 minutes: quick demo of running Nyxt from Emacs and a little explanation of the code necessary for integration +<!-- - 20 minutes: same as above plus some time to share Nyxt other capabilities and showing a workflow where you can go full circle: Emacs, Nyxt, Emacs --> + +[[!inline pages="internal(2021/captions/nyxt)" raw="yes"]] + +[[!inline pages="internal(2021/info/nyxt-nav)" raw="yes"]] diff --git a/2021/talks/omegat.md b/2021/talks/omegat.md new file mode 100644 index 00000000..f1bb4a3b --- /dev/null +++ b/2021/talks/omegat.md @@ -0,0 +1,84 @@ +[[!meta title="Emacs manuals translation and OmegaT"]] +[[!meta copyright="Copyright © 2021 Jean-Christophe Helary"]] +[[!inline pages="internal(2021/info/omegat-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs manuals translation and OmegaT +Jean-Christophe Helary + +[[!inline pages="internal(2021/info/omegat-schedule)" raw="yes"]] + +Even if it is generally agreed that software localization is a good thing, Emacs is lacking in that respect for a number of technical reasons. Nonetheless, the free software using public could greatly benefit from Emacs manuals translations, even if the interface were to remain in English. + +OmegaT is a multiplatform GPL3+ "computer aided translation" (CAT) tool running on OpenJDK 8. CATs are roughly equivalent for translators to what IDEs are for code writers. Casual translators can benefit from their features but professionals or committed amateurs are the most likely to make the most use of such tools. + +When OmegaT, free software based forges and Emacs meet, we have a free multi-user translation environment that can easily sustain the (close to) 2 million words load that comprise the manuals distributed with Emacs, along with powerful features like arbitrary string protection for easy typing and QA (quality assurance), automatic legacy translation handling, glossary management, history based or predictive autocompletion, etc. + +The current trial project for French is hosted on 2 different forges: + +1. sr.ht hosts the source files + <https://sr.ht/~brandelune/documentation_emacs/> +2. chapril hosts the OmegaT team project architecture + <https://forge.chapril.org/brandelune/documentation_emacs> + +The sources are regularly updated with a po4a based shell script. + +# Discussion + +IRC nick: brandelune + +- Q: Does this project encompass Emacs packages? Is there anything we can do, as package authors, to make translation easier? +- Q: Could this package be used to generate translated and well-formatted MOBI or EPUB ebooks? Or better yet, an interactive multi-language Emacs Manual "Bible" App for Android? +- Q: I love OmegaT and use it always. But I would have liked to hear about the experience of working both with Emacs and OmegaT. Can you tell us something about it? + +- translation is nice but typing anything non latin or cyrillic is hard with keyboard + - Try out the Emacs IMF. One of the main reasons I use Emacs. Input Method Framework: https://www.gnu.org/software/emacs/manual/html_node/emacs/Input-Methods.html +- Hi, thanks for the talk. I love OmegaT and use it always. But I would have liked to here about the experience of working both with Emacs and OmegaT. Can you tell us something about it? +- brandelune: wondering if anyone is interested in working on translating the emacs manuals to a language different from French. I know there are ongoing attempts in a number of languages (Japanese for one). LibreOffice JA has worked with "machine translation post editing" (MTPE in the "industry") and they seem to have produced good results. + - i'd definitely be interested, tho not sure i'll have the time anytime soon. but if there's a mailing list i'd be interested in subscribing or joining an irc channel. + +Feedback: + +- OmegaT looks very powerful: it goes to show how much work goes into translations; work that we sometimes take for granted +- I once had to translate a document the old-fashioned way: it was painful... Will check OmegaT afterwards. Thanks! + +# Outline + +- Duration: 10 minutes +- Software introduced during the presentation + - [po4a](https://po4a.org) a tool to convert documentation formats to and from the commonly used `gettext` **PO** format. + po4a supports the `texinfo` format along with many others. + - [OmegaT](https://omegat.org) a "computer aided translation" tool used by professional (and amateur) translators to efficiently combine translation resources (legacy translations, glossaries, etc.) so as to produce more consistent translations. + +During this short presentation, I will address: + +- The specificities of the Emacs manuals and the difficulties they present to the translator +- How to convert the texi and org files to a format that translators can handle +- How to adapt OmegaT to the Emacs manual specificities +- How to use OmegaT features such as arbitrary string protection, legacy translation handling, glossaries, autocompletion, QA, etc. +- How to use OmegaT with a team of 2 (or more) translators working at the same time + + +I will *not* discuss: + +- How to create an OmegaT project +- How to set up an OmegaT team project +- How to use OmegaT from the command line to work in localization pipelines +- How to use machine translation and MT "post-edit" +- How to convert back the translated files to texi format +- How to install translated texi files for use in Emacs + +People who are interested in knowing more about OmegaT are invited to check the [online user manual](https://omegat.sourceforge.io/manual-latest/en/). + +# Personal information +- Name pronunciation: [ʒɑ̃kRstɔf elaRi](https://doublet.jp/wp-content/uploads/2021/11/jch.ogg) +- Pronouns: he +- Mostly free software for translators Homepage: [https://mac4translators.blogspot.com](https://mac4translators.blogspot.com) +- Preferred contact info: [jean.christophe.helary@traduction-libre.org](jean.christophe.helary@traduction-libre.org) +- Links for sponsoring/supporting: [https://doublet.jp](https://doublet.jp) + +[[!inline pages="internal(2021/captions/omegat)" raw="yes"]] + +[[!inline pages="internal(2021/info/omegat-nav)" raw="yes"]] diff --git a/2021/talks/org-outside.md b/2021/talks/org-outside.md new file mode 100644 index 00000000..e13948b0 --- /dev/null +++ b/2021/talks/org-outside.md @@ -0,0 +1,153 @@ +[[!meta title="The use of Org mode syntax outside of GNU/Emacs"]] +[[!meta copyright="Copyright © 2021 Karl Voit"]] +[[!inline pages="internal(2021/info/org-outside-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# The use of Org mode syntax outside of GNU/Emacs +Karl Voit + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/org-outside-schedule)" raw="yes"]] + +With the rising interest in Org mode, the GNU/Emacs community gained +much momentum in the last decade. Being [a nicely designed lightweight +markup +language](https://karl-voit.at/2017/09/23/orgmode-as-markup-only/), +Org mode does not only benefit users of GNU/Emacs. There are many +tools and services supporting Org mode syntax documents that do have +no direct connection to GNU/Emacs. I would like to elaborate on the +advantages on using Org mode syntax for arbitrary text outside of +GNU/Emacs for better typing usability and collaboration tasks. + +Unfortunately, we do face some issues with the current situation. +First of all, we do already have a number of non-Emacs tools that do +support Org mode syntax. Then, we also do have an unclear consensus of +what it takes to "support Org mode" without re-implementing the whole +feature-set of Org mode of GNU/Emacs. + +For that purpose, I came up with a new name for the syntax of the Org +mode lightweight markup language: **Orgdown**. + +Please do visit the [Orgdown +homepage](https://gitlab.com/publicvoit/orgdown) and read my +motivation article [Orgdown - a New Lightweight Markup Standard for +Text Documents](https://karl-voit.at/2021/11/27/orgdown/) for further +information. + +# Discussion + +Pad: + +- Q1: Great talk. I have been following your work on PIM for a while + (incl. a sneak read of your dissertation:-). Just curious, what + would you personally use Orgdown for? + - A: Oh, this would be a very loooong answer. I think you want to + visit: + - <https://karl-voit.at/tags/emacs/> and go to other pages + like <https://karl-voit.at/2019/09/25/using-orgmode/> + - Basically, Orgdown is already part of my workflows since + years: <https://github.com/novoid/lazyblorg/> or + <https://github.com/novoid/appendorgheading/> and much more. + +BBB: + +- Hi Karl. I was wondering, does the specification make any restrictions with regard to indentation levels or hard vs. soft line breaks? Do you have any type of test suites that an implementation can use to be "certified" as orgdown(1)? +- Are you worried about the different levels of orgdown leading to the same confusing situation we have with Markdown? +- I think the ability to indicate that some tools are compatible with org is fantastic! +- Less of a question and more of an idea: I feel like it might be clearer to have more "semantic" names for orgdown such as "basic" orgdown, "full" orgdown or something. Those names are not great, but I think that might make it easier to remember what is what. Thoughts? Was there a specific reason for choosing a numbering system? + - I like the Idea very much. There are some Mobile Markdown/Text Editors which shy away from support for org-mode. Maybe with orgdown support will be more widespread. + - Questioner: And we should really try to proliferate the orgdown compatibily +- Was the syntax specification based on commonmark in any way? +- I think my main concern when writing in org mode at the moment is that exporters aren't heavily test (I found the plain text export was accidentally mixing spaces and tabs in indentation). Do you have any thoughts on a specification of reference implementation for an export process? Or is that out-of-scope? +- although usb 3.2 2x2 is also not much clearer +- Oh, tags are not included in orgdown1 ... would this come in 2, or is there some workaround? +- I like the Idea very much. There are some Mobile Markdown/Text Editors which shy away from support for org-mode. Maybe with orgdown support will be more widespread. I did actually plan on making an org-roam focused app, for which I will definitely include the orgdown compatibility! Very excited about this + - You already answered this (tags). Sounds good to keep it simple at first. +- On the gitlab page it mentions that GH/GL have 95% support for orgdown: what is the 5 missing percent? +- Are you hoping for most of this discussion to happen through GitLab? +- Shame that gitlab does not have a github like discussion page yet +- Did you get any feedback from the Org mode maintainers? +- Just wanna preface this that I don't wanna complain about GitLab. Just also bringing up what a few folks on #emacsconf said as well. Sourcehut could be used, especially because of its mailing lists feature. The only other reason I could see that being interesting is that the head of Sourcehut is a large Gemini advocate as well. That could motivate more attention within the growing Gemini community for using Orgdown (outside of Emacs). +- Yeah, honestly, I'm excited to see what the rest of the Org community would want. Whatever platform, I'm excited to start contributing when I can. +- There seems to be a similar simplify-the-org-format approach in this recent neovim project: <https://github.com/nvim-neorg/neorg,> FYI. Might be worth looking to see if orgdown1 is compatible +- neorg seems to be an expanded org-mode syntax and is not compatible with orgmode + +BBB feedback: + +- I think no tags is a good idea, very implementation specific +- I think it's a fantastic idea, and the initial proposal is very good! +- i need to go, but thanks for introducing the idea, excited to see where it goes! +- Thanks for your proposal. I really hope it will work out. + +IRC: (nick: publicvoit) + +- is there a tree-sitter parser for orgdown already? :P +- it seems to me that as org evolves, either orgdown eventually becomes incompatible with org or org is prevented from changing because it would break orgdown. I guess backcompat with existing org documents constrains org-mode this way already, though +- what level would you call github's implementation is? +- i'm not sure if we want a proliferation of org-syntaxes like markdown's +- Disentangling "org" the markup language and "org"/"org-mode" the piece of software that runs inside Emacs is long overdue +- I gotta say, why "Orgdown" and not just "Org"? That way we've got "Org" (the markup syntax) and "Org-Mode", the mode for that. Just delineate the mode from the thing the mode handles. + - there was a move in the opposite direction, using "Org" instead of "Org-mode" for the piece of software that runs inside Emacs, which to me is where the problem arises... +- +1 for "org" aas the format name, and the (already present) derived handling of the format being org-mode! To be clear, +1000000% in favour of this generally. +- Next year. Talk on presenting org as a mime-type. Who? + - it's officially being considered as a 'thing to be done or at least talked about', but I don't have a better status than that. +- I think the org/orgdown split makes sense: orgdown stripped-down org +- Why GitLab? GitLab.com requires reCAPTCHA to sign up, and nonfree cloudflare js to sign in + - publicvoit: I wanted to test an alternative to GitHub which I was using so far. + - I recommend codeberg.org, notabug.org, sr.ht, or savannah.nongnu.org +- 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 + + +From [YouTube](www.youtube.com/watch?v=JLuTYkhFDQY&feature=em-comments): + +- Great idea! I’m not sure about the name though. To me it implies it has something syntactically to do with Markdown (which it doesn’t). In my view OrgMode markup is far more expressive than Markdown. It’s almost a new markup language in and of itself. So, how about OrgMark or Org Mode Markup Language aka OMML. + +Links and other notes: + +- The article from 2017 that started the whole discussion: "Org Mode + Is One of the Most Reasonable Markup Languages to Use for Text" + <https://karl-voit.at/2017/09/23/orgmode-as-markup-only/> +- Orgdown homepage: <https://gitlab.com/publicvoit/orgdown> +- Orgdown motivation article: + <https://karl-voit.at/2021/11/27/orgdown/> + +# Outline + +- The term Org mode stands for different things +- The Org syntax is better than much more dominant lightweight markup languages +- We do have an unclear consensus of "Org mode support" +- A new name for the syntax alone: Orgdown +- What Orgdown should be and should not be +- Advantages of Orgdown for everybody +- Orgdown comes in different levels: Orgdown1 +- OD1 Compatibility Percentage +- The future of Orgdown +- Your contribution! + +# Personal information + +- Name pronunciation: sounds like "karl foit" ([IPA](https://en.wikipedia.org/wiki/International_Phonetic_Alphabet): [kaʁl](http://ipa-reader.xyz/?text=ka%CA%81l) [foɪt](http://ipa-reader.xyz/?text=fo%C9%AAt)) +- Pronouns: he/him +- Homepage: [https://Karl-Voit.at](https://Karl-Voit.at "personal web page of Karl Voit") +- Preferred contact info: EmacsConf21 (ɶt) Karl-Voit.at + +[[!inline pages="internal(2021/captions/org-outside)" raw="yes"]] + +[[!inline pages="internal(2021/info/org-outside-nav)" raw="yes"]] diff --git a/2021/talks/pattern.md b/2021/talks/pattern.md new file mode 100644 index 00000000..9779161b --- /dev/null +++ b/2021/talks/pattern.md @@ -0,0 +1,285 @@ +[[!meta title="Emacs as Design Pattern Learning"]] +[[!meta copyright="Copyright © 2021 Greta Goetz"]] +[[!inline pages="internal(2021/info/pattern-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Emacs as Design Pattern Learning +Greta Goetz + +[[!taglink CategoryPhilosophy]] + +[[!inline pages="internal(2021/info/pattern-schedule)" raw="yes"]] + +How do we manage today? This presentation is for people interested in thinking about Emacs as a tool sophisticated enough to cater to the complex assemblage of tasks, people, activities/outcomes, tools (Markauskaite & Goodyear). Some software oversimplifies. Emacs both helps users implement design pattern learning that can cope with complexity while also modeling design pattern learning. By championing the opportunity for users to also be co-creators (cf. Beaty et al.), the free software design at the core and center of Emacs teaches us a way of "being" (Alexander, Gabriel) that can be extended to both the Emacs community and beyond, in a knowledge of how to live (Stiegler, Illich). + +1. Definition of design patterns and relation to Emacs +2. Why this approach matters +3. Managing complexity: Emacs as mind map +4. Emacs as design pattern framework +5. Personal customization +6. Implementing Emacs as a model for learning +7. Emacs as accommodating complex social, community assemblages + +# References + +- Andler, D. & Guerry, B. (Eds.). *Apprendre demain: Sciences cognitives et éducation à l’ère numérique*, 137-154. Paris: Hatier. +- Alexander, C. (1977). *A pattern language*. New York: Oxford University Press. +- Alexander, C. (1979). *The timeless way of building*. New York: Oxford University Press. +- Alexander, C. (1993). *A foreshadowing of 21st century art: The color and geometry of very early Turkish carpets*. New York: Oxford University Press. +- Beaty, L., Cousin, G., & Hodgson, V. (2010). Revisiting the e-quality in networked learning manifesto. In L. Dirckinck-Holmfeld, V. Hodgson, C. Jones, M. de Laat, D. McConnell, & T. Ryberg (Eds.), *Proceedings of the 7th International Conference on Networked Learning* (pp. 585–592). Aalborg: Lancaster University. http://www.lancs.ac.uk/fss/organisations/netlc/past/nlc2010/abstracts/PDFs/Beaty.pdf. Accessed 30 October 2021. +- Chua, S. (2021). Completing sketches. https://sachachua.com/dotemacs/#org092e0d5. Accessed 29 October 2021. +- Crichton, M. (1983). *Electronic life*. New York: Knopf. +- Gabriel, R. (1996). *Patterns of software*. New York, Oxford: Oxford University Press. +- Goodyear, P. & Retalis, S. (2010). Learning, technology and design. In Goodyear, P. & Retalis, S. (Eds.). *Technology-enhanced learning: Design patterns and pattern languages*, 1-27. Rotterdam, Boston: Sense Publishers. +- Guo, P. (2018). Students, systems, and interactions: Synthesizing the first +four years of Learning@Scale and charting the future. L@S 2018, June 26–28, 2018, London, United Kingdom. DOI: https://doi.org/10.1145/3231644.3231662. <https://pg.ucsd.edu/pubs.htm>. Accessed 25 October 2021. +- Guo, P., Kim, J. & Rubin, R. (2014). How video production affects student engagement: An empirical study of MOOC videos. ACM Conference on Learning at Scale. <https://pg.ucsd.edu/pubs.htm>. Accessed 25 October 2021. +- Illich, I. (1973). *Tools of conviviality*. New York: Harper & Row. +- Kim, J., Guo, P., Seaton, D., Mitros, P., Gajos, K. & Miller, R. (2014). Understanding in-video dropouts and interaction peaks in online lecture videos. ACM Conference on Learning at Scale. <https://pg.ucsd.edu/pubs.htm>. Accessed 25 October 2021. +- Markauskaite, L. & Goodyear, P. (2017). *Epistemic fluency and professional education: innovation, knowledgeable action and actionable knowledge*. Dordrecht: Springer. +- Markel, J. & Guo, P. (2020). Designing the future of experiential learning environments for a post-COVID world: A preliminary case study. NFW ’20 (Symposium on the New Future of Work), August 3–5, 2020, Virtual Event. <https://pg.ucsd.edu/pubs.htm>. Accessed 25 October 2021. +- Morin, E. ([2004] 2008). *La Méthode - tome 6: Éthique*. Éditions du Seuil: Paris. +- Planet Emacs Life. <https://planet.emacslife.com/>. Accessed 25 October 2021 +- Stallman, R. (2002). My Lisp experiences and the development of GNU Emacs. https://www.gnu.org/gnu/rms-lisp.en.html. Accessed 29 October 2021. +- Stiegler, B. (2018). *The neganthropocene*. Open Humanities Press. +- Trocmé-Fabre, H. (1999). *Réinventer le métier d’apprendre*. Paris: Éditions d’organisation. + +# Discussion + +Pad: + +- Q1: Any reference to a Christopher Alexander book that you liked + most? + - (peer answer A: + - Alexander, C. (1977). A pattern language: towns, buildings, + construction. New York: Oxford University Press. + - Alexander, C. (1979). The timeless way of building. New + York: Oxford University Press. (thanks!!) + - also check out: Gabriel, R. (1996). Patterns of software: + tales from the software community. New York: Oxford + University Press. + (<https://dreamsongs.com/Files/PatternsOfSoftware.pdf>) + - Alexander, C. (1993). *A foreshadowing of 21st century art: + The color and geometry of very early Turkish carpets*. New + York: Oxford University Press. + - A: The peer answer is excellent. If you are looking for an 'entryway' into Alexander, there is also his essay A City Is Not A Tree, <https://raw.githubusercontent.com/dmvaldman/library/master/essays/Alexander%20-%20A%20City%20Is%20Not%20A%20Tree.pdf>. +- Q2: You are making a great case for the ease-of-use, humanizing, and + empowering aspects of Emacs, but how does this align with the + initial difficulty for many users in learning Emacs? What is the + weakness of Emacs here, in relation to these design patterns? + - A: If we take a Vygotskyean approach to learning, we begin step + by step, gradually building on to what we know. What I found + fascinating as a non-programmer coming to Emacs was how this + approach works even in Emacs. Particularly if we are taking a + human-based approach to Emacs, it has no weakness here, because + humans can only move forwards from where they are, not where + they want to be. So Emacs becomes a good teacher in + process-based learning. We need to hierarchize what we know, + what we are ready/motivated to learn next, and also remember the + time required for growth. +- Q3: How do you suggest emacs users should go about desinging their + work(flow) patterns? + - A: Strangely, I seem to have answered this above! +- Q4: Emacs provides a lot of extensibility as mentioned in your talk. + This is a good thing, but such extensibility and possiblility can + sometimes inhibit creativity (for me at least). How could we + incorporate constraints in to how we use Emacs, in order to deal + with the possibilities that might make it's use more complex? A + great answer, thank you! + - A: I love this question. What about thinking about Emacs as + one's own path of desire? What do we want to do most with it? + But also, because Emacs is the ultimate blank canvas, in this + context I would recommend reading Cameron's "Blasting through + blocks" chapter in The Artist's Way to get through any related + anxiety and find one's 'creative purpose' with Emacs. And + building on an answer from above, taking things one + project/activity/outcome at a time. Trusting that over time + skills and proficiency grow. + - I like the idea about "Emacs as one's own path of + desire". It's all in my init.el. + - Emacs is seriously the best in this respect! :) And it is + so great to be part of this conference to be among like + minds!:) +- Q5:In your opinion, what approaches might be tried to introduce + individuals to these aspects of emacs's user experience? In my + experience, many of my co-workers are often impressed with what I am + able to do with emacs, but they remain reticent to attempt it + because I find it difficult to produce a suitably encapsulating + "elevator pitch" for it. + - A: Not everyone wants to think about the tools that they use. + Haha, that is why I am trying to get one convert at a time, and + let them convert others in their midst :) +- Q6: Are there ways to reach out to you after the conference to dig + deeper here? + - A: I blog at <https://gretzuni.com>; my professional site is <https://gretagoetz.com>. +- Q7:On the mention of emacs being 'frontierless': Doesn't this + result in a kind of 'characterless' or 'non-definied' space? For + example, if I learn a musical instrument, I am bound by various + frontiers/horizons (12 tone system, the tamber of the particular + instrument, etc). Surely there are similar limits on the + extensibility of emacs and the possibilities it offers for 'human + expansion'. If so, which limits/boundaries of emacs do you see as + most meaningful/impactful on growth and transformation? + - A: That is a really interesting question. Aren't the limits + here our knowledge? I am really stuck on the idea of Lisp and + its dialects as being particularly philosophical. Any time I + look at what people do with Lisp it seems to be profoundly + related to design on a deeper level. I will leave it here for + now - but thank you for the question, I will be sure to mull it + over and possibly blog about it at some point... + - Hi! Thank you for the answer, that was exactly what I was + thinking about (elisp being something particular/defining to the + emacs experienc/environment). I don't know lisp/programming + myself, so I was just interested in your perpsective! Really + loved the talk a lot! But the way, the question came from a + hermeneutic perspective, where boundaries/horizons are essential + for defining/demarcating the self (of course, within a boundary + there can be endless play, but the limits set the 'rules' for + play, and therefore create meaning).Thanks again! + - A: Wow - a fellow hermeneuticist?! + - Haha, yes. In my past life I studied it ;) also studied a lot of + Stiegler too, so was interested to find him in the talk! + - A: That is quite uncanny! The combination of the three (plus Emacs) + have given me a whole new perspective on life - and I wonder why + Stiegler didn't pursue Free Software more, though he does nod + to it here and there. Do you have any work to share, would you + like to keep in touch? + - sure! would be great! :) My main area was Ricoeur, so I have + written some things on Ricoeur and technology (there was a + recent volume on his work, and I wrote something on + postphenomenology and ricoeur) I've since left academia though, + because it was quite difficult to find full-time work + (especially since hermeneutics is so + underappreciated/underreppresented! so, I always get excited to + hear others talking about it ;) + - A: Yes, I know what you are talking about and actually the whole + future - and present - of academe is an interesting question - + haha that I think is related to Emacs, I mean, we do live in the + knowledge age so we need tools to help with this. Ricoeur has a + great essay on ideology and science critique, which is so limber + (as opposed to so much calcified academic thinking) and I am so + interested in exploring approaches to academe that 'continue + the ongoing work of the hermeneuticist' (I am paraphrasing him + here) that make use of technology, possibly through something + like Ted Nelson had in mind, where we literally trace the traces + among ideas... wow, that's a mouthful of a comment. Ha! I am + overjoyed at the opportunity for this conversation, thank you so + much! :) + - really interesting that you are referencing Ted Nelson in + this context. I think org-roam, in many ways, resembles what + he had in mind with Xandadu; well, with the limitation that + org-roam only serves Personal Information Management, not + our civilisations' as he intended with Xanadu. + - A: That's an interesting point - and related to how org-roam writer Leo is now extending org-roam to collaborative work as he explains in his talk <https://emacsconf.org/2021/talks/erg/>. + - Yes! the feeling is mutual :) I really love Ricoeur's general + style and approach to questions. Unfortunately he didn't write + much about technology itself, which made my job quite difficult! + But I did meet a friend of his once that told me that, in the + 70s, Ricouer had asked him "are we still writing when we use + computers?". So, he was thinking about the question at least. I + only discovered emacs after I finished all that word, but since + then I can finally say that 'yes!' we can 'write' using + computers (with writing being a core activity of the self for + Ricoeur). Also, I just wish I had emacs instead of just writing + so many academic papers in microsoft word! + - A: Yes, the moment of being freed from that software box and + having all the LaTeX options in Emacs (here, I list my fave) is + like stepping into technicolor out of black and white - to this + day, I still feel that way! So much you wrote is interesting. + Stiegler's concern of whether technology - like the writing pad + in Plato earlier - would strip us of our intellectual capacity + (I can see that possibly happening with automaticizing tools + like - maybe Excel is a good example, because one does not + really have to think about what one is doing). But Emacs use + prompts us to ask questions and design *exactly* what we are + looking for. + - wow, yes, that is so interesting. I never considered the + question of desire and emacs until your talk, and it was + definitely one of the most interesting parts! + In my work I was also mostly interested in Freud (the role of + 'technique' in psychoanalysis) and also Foucault's later + lectures on hermeneutics of the self/technologies of the self. + The angle of 'desire' in relation to personal + configuration/design was so interesting to me and like an + 'aha' moment. I'll definitely be thinking about it more! + Thank you so much again for the talk and all the responses! + - A: Thank you too, and hope we'll be in touch! + - Yes :) enjoy the rest of the conference! + - A: Likewise :) +- Q8: What was that Crichton quote? That was neat! (From the + references - Crichton, M. (1983). *Electronic life*. New York: + Knopf.) + - A: Thank you - I hope that general computing will have its day! +- Q9: Greta, you seem to be an academic researcher. Any of your + publications or other good references on this topic that you can + share/link here? +- Here are two: +- <https://doi.org/10.1080/00131857.2021.1962706> A song of teaching + with free software in the Anthropocene +- <https://10.1007/s42438-020-00188-3> The odyssey of pedagogies of + technoscientific literacies + +**Links and other notes:** + +- Design Pattern: macro solution; human-centered +- Emacs is a design pattern for learning. +- Why do we care about design patterns? +- Emacs as a mental map. +- Everyone's Emacs is their own. +- The development of the Emacs communitiy is similar to the [free] + core of Emacs devlopment. + +IRC: + +- this paper is relevant to exploring the space of design patterns: https://www.aaai.org/Papers/Workshops/1998/WS-98-08/WS98-08-024.pdf it's old and a little cryptic, but a good paper. it's "Recommender Systems for Problem Solving Environments" + - greta: Thanks for that link! +- if I may ask, what's the little toy figure in the background, looks nice :D + - A wooden (fake) Transformer :) +- do you think emacs could have implemented with this design pattern, but in another programming language? + - Emacs Lisp as a dialect of Lisp shares its philosophical qualities. I often think about what Norvig wrote about Lisp back in the day, e.g. <https://www.norvig.com/lisp_talk_final.htm>, and while there are some people who feel strongly that Lisp's time is passed, I think that Emacs shows that it is the opposite: that we haven't fully taken advantage of Lisp's potential. Another example would be what Rick Hickey has done with Clojure, and recommend his talk Are We There Yet, <https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/AreWeThereYet.md>. + +Feedback: + +- That's a great point about the sketches, and why Emacs graphical improvements are important. +- yes this talk is excellent. i'm very happy to find some of my thoughts echoed here in such a clear and well researched way +- this is exactly my experience. using/learning emacs is THE way that i gained the skills, the learning to learn skills i needed to become a professional programmer (which is incidental to the growing up into a hacker :P) +- a friend of mine (my original emacs mentor) has been telling me about Ivan Ilich and wondering about how his philosophy lines up with free software, so this is amazing synchronicity of thought for me. +- cognitive democracy is a very useful phrase to describe emacs (and FOSS) culture +- This is saying out loud in concrete language everything I've felt about emacs and the community since e.g. the package system became available and social git forges made it easy to explore others' configs +- What a wonderfully diverse set of viewpoints so far. Not just viewpoints but concepts I would never have expected in an ‘Emacs conf’. I'm glad I dropped by. Thank you greta. +- This quote of Richard Gabriel rings a bell in the emacs context: "If it is small, it was written by an extraordinary person, someone I would like as a friend; if it is large, it was not designed by one person, but over time in a slow, careful, incremental way" (Gabriel, R. (1996). Patterns of software: tales from the software community. New York: Oxford University Press. (https://dreamsongs.com/Files/PatternsOfSoftware.pdf) +- I just finished listening to Greta Goetz's talk and I love it so much. +- I listened to it after listening to acdw's talk on the frownies mode, a little mode to do something very simple, how he met people, wrote that mode, published it, got feedback. Your talk felt like an excellent background on the experience. The part about helping each other also really resonated with me. I would like to search for how many messages I must have posted to comp.emacs and gnu.emacs.help back in the days. I feel like it must have been about 2000 of them. :) Much of that long before I started writing any code. + +# Speaker release + +By submitting this proposal, I agree that my presentation at +EmacsConf 2021 is subject to the following terms and conditions: + +The EmacsConf organizers may capture audio and video (a "Recording") +of my presentation and any associated materials, which may include +slides, notes, transcripts, and prerecording(s) of my presentation +that I provide to the EmacsConf organizers. + +I authorize the EmacsConf organizers to distribute, reproduce, +publicly display, and prepare derivative works of the Recording and +any derivative works of the Recording (the "Licensed Materials") +under the terms of the Creative Commons Attribution-ShareAlike 4.0 +International (CC BY-SA 4.0) license. + +I grant to the EmacsConf organizers permission to use my name, +likeness, and biographic information in association with their use +of the Licensed Materials under the above license. + +I represent that I have the authority to grant the above license to +the EmacsConf organizers. If my presentation incorporates any +material owned by third parties, I represent that the material is +sublicensable to the EmacsConf organizers or that my use of them is +fair use. + + +[[!inline pages="internal(2021/captions/pattern)" raw="yes"]] + +[[!inline pages="internal(2021/info/pattern-nav)" raw="yes"]] diff --git a/2021/talks/professional.md b/2021/talks/professional.md new file mode 100644 index 00000000..5a16d2c1 --- /dev/null +++ b/2021/talks/professional.md @@ -0,0 +1,83 @@ +[[!meta title="Using Org-Mode For Recording Continuous Professional Development"]] +[[!meta copyright="Copyright © 2021 Philip Beadling"]] +[[!inline pages="internal(2021/info/professional-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Using Org-Mode For Recording Continuous Professional Development +Philip Beadling + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/professional-schedule)" raw="yes"]] + +I recently had the pleasure of being audited for my CPD record with one +of the large engineering professional bodies. I decided to harness +org-mode's TODO lists to record CPD items and my progress against them +completely within Emacs. I also wanted the ability to export the data +in a well presented, compact format for auditing submission. + +The project was a success (I passed the audit) and the resulting system +integrates really well into my wider daily Emacs workflow, making future +CPD recording seamless. + +The talk will explain how I tweaked and extended org-mode to get it to +record the data I wanted, followed by a demo. + +A basic demo org file with embedded elisp can be seen here: +<https://raw.githubusercontent.com/falloutphil/Misc/master/cpd.org> + +A basic generated PDF from the basic demo is here: + + +I have a much more involved example I could also use for the demo. + +The template contains a few examples. Examples are Goals that are split +up into Activities. All Activities must have a Goal, and within a Goal +all activities must be complete for the Goal to be automatically set to +complete. + +It's basically leveraging Org Capture Templates to create custom Goals +and Activities. + +On save or update these are then rendered into a table using Column View. + +Activities are sorted by date they were completed on. + +The Column View is pre-configured to be exported to PDF in a condensed +but readable format for submission. It stays fairly readable even when +the pages get busy. + +The elisp required is all under the "Config" bullet and Emacs will ask +to execute it on opening the Org file. The elisp concerns itself with +nice custom org capture functions and a few functions to ensure nice +formatting on export, etc. + +# Discussion + +IRC nick: pbeadling + +- Very impressive use of capturing +- This is madness, and I am a little ashamed of saying that I have wanted to do something similar for personal reasons. I feel it is an overkill I cannot justify to myself + - pbeadling: For me it largely motivated by trying to make the whole task more interesting + - i think of like lots of us falling in lots of rabbit holes, making for quite a cavernous attack surface, when we consider Emacs is including it's various package arcives. +- hmm, hooking is a neat way to check in/ouut +- the workflow looks good but why he isn't integrating this with org agenda ? + - pbeadling: Agree - merging with org-agenda is the next thing I want to do with this + - pbeadling: For the CPD thing the biggest limitation I think is that you have to have the org file in the current buffer to add items - really you want to be able to capture CPD items from anywhere in your workflow - when I get some time I'll update the script to integrate better with capture and agenda like this. +- <https://www.reddit.com/r/emacs/comments/jmpsdl/continuous_professional_development_record_in/> + +# Outline + +- 5-10 minutes: + +A quick walkthrough of the setup and functions, followed by a demo of how +to add CPD items, and update them. Finally show generation of a PDF +containing all the items tabulated and ready for audit review. I +estimate this at approx 10 minutes. + + +[[!inline pages="internal(2021/captions/professional)" raw="yes"]] + +[[!inline pages="internal(2021/info/professional-nav)" raw="yes"]] diff --git a/2021/talks/project.md b/2021/talks/project.md new file mode 100644 index 00000000..d7f93c01 --- /dev/null +++ b/2021/talks/project.md @@ -0,0 +1,36 @@ +[[!meta title="Budgeting, Project Monitoring and Invoicing with Org Mode"]] +[[!meta copyright="Copyright © 2021 Adolfo Villafiorita"]] +[[!inline pages="internal(2021/info/project-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Budgeting, Project Monitoring and Invoicing with Org Mode +Adolfo Villafiorita + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/project-schedule)" raw="yes"]] + +In this talk I will present how we use Org Mode at Shair.Tech for +budgeting, project monitoring, and invoicing. + +We are a small company and we are still tuning and improving the +process, but with a bit of Emacs Lisp, the functions Org Mode +provides, and reading here and there what other users do, we +implemented an effective workflow we have been using for nearly a +year, now, and with which we are very happy. + +# Discussion + +IRC nick: adolfo + +- Why is Michele working more than Adolfo??? + - adolfo: I can answer that :-) because he is better than I am ;-) +- watching this talk I really want to get the OPENED: cookie added +- what is the difference between hledger and ledger ? + - adolfo: implementation. hledger is in Haskell, ledger written in C++; there are also some differences in the format supported + +[[!inline pages="internal(2021/captions/project)" raw="yes"]] + +[[!inline pages="internal(2021/info/project-nav)" raw="yes"]] diff --git a/2021/talks/research.md b/2021/talks/research.md new file mode 100644 index 00000000..a0468c64 --- /dev/null +++ b/2021/talks/research.md @@ -0,0 +1,60 @@ +[[!meta title="Managing a research workflow (bibliographies, note-taking, and arXiv)"]] +[[!meta copyright="Copyright © 2021 Ahmed Khaled"]] +[[!inline pages="internal(2021/info/research-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Managing a research workflow (bibliographies, note-taking, and arXiv) +Ahmed Khaled + +[[!taglink CategoryOrgMode]] +[[!taglink CategoryOrgRoam]] + +[[!inline pages="internal(2021/info/research-schedule)" raw="yes"]] + +[Configuration I use in Doom Emacs as part of my academic reading/notetaking workflow](https://gist.github.com/rka97/57779810d3664f41b0ed68a855fcab54) + +Researchers and knowledge workers have to read and discover new papers, +ask questions about what they read, write notes and scratchwork, and store +much of this information for use in writing papers and/or code. Emacs allows +us to do all of this (and more) using simple text interfaces that integrate +well together. In this talk I will talk about the following: + +a. Using elfeed and elfeed-score to read new papers from arXiv. +b. Using org-ref to import arXiv papers of interest into a local +bibliography. +c. Using Emacs hooks with biber and rebiber in order to keep the local + bibliography clean and up-to-date with conference versions of papers. +d. Using org-roam and org-roam-bibtex to take linked, searchable notes in +org on research papers. + +This text-based workflow allows for keeping everything accessible under +version +control and avoids the platform lock-in of binary formats (e.g. Mendeley). I +will share my Doom Emacs configuration for this workflow, but it is not +limited +to Doom. + +# Discussion + +- Are there any good packages for emacs/Lisp libraries that are similar to Matplotlib/Pyplot/Numpy? + - use numpy with org-mode and babel + - plotting is a bleak spot in the lisp space, racket has a built in plot library that is probably the best on that front +- are these helper functions public? +- this talk just gave me an idea, I organize repos inside ~/code/{github.com,gitlab.com,gnu.org,etc}/author@repository-name.git - and I can instead use a single directory and use this strategy for projectile-switch-project where author is one column, repository name is another, git remote is another, etc + +# Outline + +- 5-10 minutes: I will demo the packages I use in 5 minutes. +<!-- +- 20 minutes: I will describe the packages I use in some detail and give a +demo of them. + +- 40 minutes: I will describe the packages I use, give a demo of them, and +include a video segment on configuring the packages in Emacs. +--> + +[[!inline pages="internal(2021/captions/research)" raw="yes"]] + +[[!inline pages="internal(2021/info/research-nav)" raw="yes"]] diff --git a/2021/talks/rust.md b/2021/talks/rust.md new file mode 100644 index 00000000..00e3d4c7 --- /dev/null +++ b/2021/talks/rust.md @@ -0,0 +1,36 @@ +[[!meta title="Extending Emacs in Rust with Dynamic Modules"]] +[[!meta copyright="Copyright © 2021 Tuấn-Anh Nguyễn"]] +[[!inline pages="internal(2021/info/rust-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Extending Emacs in Rust with Dynamic Modules +Tuấn-Anh Nguyễn + +[[!inline pages="internal(2021/info/rust-schedule)" raw="yes"]] + +Dynamic module support has been available since Emacs 25. It can be +used to extend Emacs with native libraries, for performance, +OS-specific features, or other functionalities that would take a lot +of time to re-implement in Lisp. The officially supported language is +C, which is tedious and error-prone to use. This talk discusses a +**safe** alternative that is also a lot **more convenient**: writing these +dynamic modules in Rust. + + + +# Outline + +- Walking through creating **a simple dynamic module** in + Rust, including setting up CI. +- Going through and explaining the **available APIs**. +<!--- 40 minutes: All of the above, together with reporting the experience + of using it in real packages (e.g. tree-sitter), as well as + discussing **challenges and potential improvements** to dynamic modules + in general.--> + + +[[!inline pages="internal(2021/captions/rust)" raw="yes"]] + +[[!inline pages="internal(2021/info/rust-nav)" raw="yes"]] diff --git a/2021/talks/structural.md b/2021/talks/structural.md new file mode 100644 index 00000000..03089a2d --- /dev/null +++ b/2021/talks/structural.md @@ -0,0 +1,124 @@ +[[!meta title="Tree-edit: Structural editing for Java, Python, C, and beyond"]] +[[!meta copyright="Copyright © 2021 Ethan Leba"]] +[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Tree-edit: Structural editing for Java, Python, C, and beyond! +Ethan Leba + + + +[[!inline pages="internal(2021/info/structural-schedule)" raw="yes"]] + +[[!table header="no" class="speaker-details" data=""" +Name pronunciation | E-than LEE-ba +Pronouns | he/him +Homepage | <https://ethan-leba.github.io/> +Preferred contact info | <ethanleba5@gmail.com> +"""]] + +In this talk, I'll discuss a vision for how writing code could be, where the +editing operations map directly to the primitives of the language itself -- and +my humble attempt of implementing this vision. _tree-edit_ seeks to provides a +structural editing plugin supporting conceivably any language with a tree-sitter +parser. + +**Structural editing does not have to be relegated to lisps or niche DSLs.** + +I liken the state of code editing today to writing assembly. The reason why +people like Python more than assembly is that for most purposes, the building +blocks of the language are mismatched with our thought process. We don't think +in terms of registers and addresses, we think in terms of variables, functions, +etc. So when we write and edit code, why do we edit in terms of deleting, +inserting, replacing characters – not wrapping, inserting, raising, +deleting expressions and statements? + +I'll also discuss the implementation of tree-edit, which uses a novel +combination of the fantastic +[tree-sitter](https://github.com/emacs-tree-sitter/elisp-tree-sitter) parser +with an embedded logic programming DSL ([miniKanren](http://minikanren.org/), +using elisp port [reazon](https://github.com/nickdrozd/reazon)) to power it's +syntax tree generation. + +Check out the GitHub repo [here](https://github.com/ethan-leba/tree-edit)! + +# Discussion + +IRC nick: ethan + +- Q1: so tree-edit is orthogonal to the LSP features? + - A: only uses tree-sitter yeah +- Q2:any chance you tried this with Clojure as well? + - A: haven't tried it yet, i don't think tree-sitter-langs has a + clojure grammar AFAIK +- Q3: Would we be able to do things like extract statement to a + variable? For example, extract a a math operation happening in a + fucntion call argument into a separate variable an then replace the + funtion call arg with the variable name. +- Q4: How do tree-edit and combobulate compare? + - A: a lot of similarities, tree-edit replaces traditional text + editing style combobulate still implements +- Q5: Are similar packages for structural editing common to other + editors or they are just popular in Emacs cause of the paredit + tradition? + - A: emacs seems to be a trend-setter +- Q6: Great talk! How difficult do you imagine adding more languages + to Tree-edit will be? + - A: Trying to add python, not super simple, C-like should be drop + in replacements +- Q7: @ethan 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? +- Q8: Any plans for an Evil mode integration? evil-textobj-tree-sitter + seems like it has a long way to go if it's to catch up to + tree-edit. + +- 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). + +Links and other notes: + +- Github repo : <https://github.com/ethan-leba/tree-edit> +- editing operations that map directly to the structure of the + language +- inspired by paredit and lispy +- Another similar project is <https://github.com/mickeynp/combobulate> + by Mickey Petersen, the writer of Mastering Emacs. +- It's an open source project so contributers are welcome +- Future implication for this kind of work could be voice controlled + code writing/editing + +# Outline + +- Discuss motivation (Why should I care?) +- Demonstrate tree-edit (Live-coding with tree-edit) +- Demonstrate tree-edit syntax tree generator (Elevator pitch on miniKanren) + +<!-- +- 20 minutes: (brief description/outline) + - discuss motivation + - discuss prior art (paredit, lispy) + - demonstrate tree-edit + - demonstrate and discuss tree-edit syntax tree generation engine + +- 40 minutes: (brief description/outline) + +same as 20 minutes, with more detailed discussion of the implementation. + +--> +[[!inline pages="internal(2021/captions/structural)" raw="yes"]] + +[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]] diff --git a/2021/talks/teach.md b/2021/talks/teach.md new file mode 100644 index 00000000..16052178 --- /dev/null +++ b/2021/talks/teach.md @@ -0,0 +1,77 @@ +[[!meta title="Using Org-mode to teach programming"]] +[[!meta copyright="Copyright © 2021 Daniel German"]] +[[!inline pages="internal(2021/info/teach-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Using Org-mode to teach programming +Daniel German + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/teach-schedule)" raw="yes"]] + +In this presentation I will explain how to use org-mode effectively to +prepare teaching materials, and how to present them. + +For the last 5 years I have been using org-mode to teach programming +in different languages: C++, SQL, Ruby, Python, SML +and Scheme. Org-mode has three key advantages: + +1. it supports most programming languages with a common interface, +2. it is an interactive medium for delivering teaching materials; and +3. it is an always-up-to-date format that does not need to be exported in order to be published. + +I explain how I use org-mode in my courses and how I combine org-mode +notes other tools such as github org-mode to get +always up-to-date teaching materials that one can use for both +teaching and studying (see +<https://github.com/dmgerman/csc116ModernCplusplus/blob/master/lectures/l-01-1-intro/01_1_intro.org> +for an example). + +Finally, I will discuss some important aspects to consider when using +org-mode for this purpose. + +# Discussion + +IRC: + +- how do you keep the discipline of working on your notes? that's probably my biggest problem +- I like "Try that with PowerPoint!" as a new org-babel slogan +- we just need krita and inkscape modes +- i remember doing similar in Smalltalk using a presentation tool with in it but with a full on graphical display of the Smalltalk environment not just text based. +- I liked the trick with annotating the code in xournal -- what is the elisp glue for that? Do you have a package for that? + +BBB: + +- Can you talk about how the students re0act to this org-mode approach? +- What level are your students typically? what is the subject matter? +- Why GitHub? GitHub is nonfree. + - Perhaps because gitlab is also there and that there is achoice? + - GitHub requires reCAPTCHA to signup and similar things that are free exist (various GitLab and Gitea servers, Savannah, sourcehut). + - GitLab.com is just as bad (and unlike GitHub, you can't sign in without nonfree JS), but GitLab CE is fine. +- Do you think org-mode+git could be used for students' assignments? + +From [YouTube](https://www.youtube.com/watch?v=Bmi9AAaqegY&feature=em-comments): + +- this is by far one of the most motivating talk about Org. I feel sorry about all my teaching colleagues that still use WYSIWYG presentation tools. my life, as a trainer, literally changed with Org, even without literate programming. +- Great presentation. New to Emacs and starting to find many uses for it. One thing which theme you are using + +# Outline + +20 minutes: + +- Introduction +- Quick demonstration +- Workflow +- Some Important considerations +- Emacs configuration and how to get started + +I have create a git repository with examples and config files that is ready to use: +<https://github.com/dmgerman/teachingProgOrg> + + +[[!inline pages="internal(2021/captions/teach)" raw="yes"]] + +[[!inline pages="internal(2021/info/teach-nav)" raw="yes"]] diff --git a/2021/talks/tech.md b/2021/talks/tech.md new file mode 100644 index 00000000..c327181d --- /dev/null +++ b/2021/talks/tech.md @@ -0,0 +1,84 @@ +[[!meta title="Creating technical API documentation and presentations using org-babel, restclient, and org-treeslide"]] +[[!meta copyright="Copyright © 2021 Jan Ypma"]] +[[!inline pages="internal(2021/info/tech-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Creating technical API documentation and presentations using org-babel, restclient, and org-treeslide +Jan Ypma + +[[!taglink CategoryOrgMode]] + +[[!inline pages="internal(2021/info/tech-schedule)" raw="yes"]] + +The emacs org-babel package is often mentioned in conjunction with +literate programming. The ability to mix code segments with prose +indeed offers an intuitive way to augment semantic code pieces with +textual descriptions. + +In recent projects, I've started to turn to org-mode as the primary +format to maintain technical documentation, as well as slides for a +technical language course. By using org-babel to pull in "live" code +for REST requests, language examples, and shell scripts, one can be +sure that the documentation and slides are never out of date. + +The session will show how leverage org-babel, restclient and +org-treeslide to write and present technical documentation with style. + +# Discussion + +Pad: + +- Q1: Sorry if you already answered this somewhere (but if not, can + someone with a reddit account copy this over? thx). Hi, I would love + to move my team over to using something org-based, but that'll + never happen because, well... (wait for it) Emacs! By the way, I'm + currently using heavily customized Sphinx setup, mostly internal, + sometimes shared with data partners; lots of schema-gen from message + protocols defined in code, etc. Anyhow: questions. Do you work with + non-Emacs users? If so, how did you get them to accept this + workflow? And if it's just you DJ'ing, how do they weigh in when + they want an update, open a formal ticket? +- <https://github.com/jypma/emacsconf2021/blob/master/presentation.org> + +BBB: + +- Have you encountered any push-back from people requesting the documentation who are of the opinion that only a Word document will do? + - Jan: Not really, I tend to deliver the PDFs only. If more is needed, I expect I'd make a docker container with emacs in it, so people can export the org-file to PDF themselves. + - The main problem I have is that effectively they end up branching it in order to use Word's change tracking, and there is no reverse path. + - Jan: That sounds more like a team thing. Most people I interact with are developers, and are OK reading/interpreting change tracking as a git diff, e.g. on github or azure devops. + - OK, thanks. I think that is the root of my problem I just thought I would ask in-case you had encountered the same. Thank you for the talk. + - Jan: I think in your case I'd either introduce them to a nice web-based git interface (org-mode looks fine usually), so they see it can do similar things as word change tracking. + - Jan: Thanks for your feedback :) feel free to reach out if you want to chat more. + - Unfortunately in this case they refuse to use anything that isn't a WYSIWYG interface. So even a Markdown editor in a split screen with a preview window is not accepted. + - Thanks! + - Jan: Hold their hands, be kind, small baby steps :) + +IRC: (nick: jan-ypma) + +- I use restclient everyday, but never thought about using it from code blocks, duh! Very interesting talk! +- This is a good demo, I've found org-babel to be a really amazing glue language for stuff that's sort of annoying to automate otherwise. +- Thanks! :) So the fonts of the current talk are: Fixed pitch (serif): New Heterodox Mono, Variable pitch (serif): ETBembo +- for live coding presentations, demo-it is also pretty cool +- indeed, i have been trying to work out literate devops through org documents. Very cool and useful in specific contexts atleast I guess. like finding the status of a service quickly right within a structured org document. + +# Outline + +- Introduction +- Demo: Developer guide +- Demo: REST API guide +- Demo: Presentations +- Used packages and configuration +[[!inline pages="internal(2021/captions/tech)" raw="yes"]] + +[[!inline pages="internal(2021/info/tech-nav)" raw="yes"]] + +# Speaker profile + +Jan Ypma is an independent software architect and developer, specializing on the Java platform, functional +programming and distributed systems. + +Name pronunciation: Jan EEP-mah +Pronouns: he/his +Preferred contact info: jan@ypmania.net diff --git a/2021/talks/telega.md b/2021/talks/telega.md new file mode 100644 index 00000000..54a151f4 --- /dev/null +++ b/2021/talks/telega.md @@ -0,0 +1,42 @@ +[[!meta title="telega.el and the Emacs community on Telegram"]] +[[!meta copyright="Copyright © 2021 Gabriele Bozzola and Evgeny Zajcev"]] +[[!inline pages="internal(2021/info/telega-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# telega.el and the Emacs community on Telegram +Gabriele Bozzola and Evgeny Zajcev + +[[!inline pages="internal(2021/info/telega-schedule)" raw="yes"]] + +Telegram is a cross-platform instant messaging system. The large number of +features and the widespread adoption make it a good choice for both private +conversations with friends and for large online communities. In this talk, I +am going to present the Emacs community on Telegram and its initiatives. I +am also going to discuss telega.el, the Emacs client for Telegram. telega.el +is a high-quality package that perfectly integrates in Emacs. It supports +the vast majority of the features supported by the official clients, while +adding several unique ones. In the talk, I will present the package and +highlight some of the most important features. + +# Discussion + +- Q1: Do any of these main emacs telegram groups bridge to matrix? + - A: [Speaker] We discussed adding a bridge to matrix for the + main channel @emacs_en. We never got around to doing it, but I + can bring this up again. +- Q2: Could telega.el auto install TDLib like lsp-mode auto installs + servers? +- A: [Speaker] Possibly. The difference is that TDLib requires a + number of dependencies that might not be available. Evgeny chose + another route to simplify setting up telega.el: the package can now + be installed with a Dockerfile that also ships with also the + optional dependencies. This ensures that everything works as + intended. +- Does telega still require company for completion? +- Telegram has become a real (and desired) option to WhatsApp, thanks to telega.el + +[[!inline pages="internal(2021/captions/telega)" raw="yes"]] + +[[!inline pages="internal(2021/info/telega-nav)" raw="yes"]] diff --git a/2021/talks/test.md b/2021/talks/test.md new file mode 100644 index 00000000..9165e7b6 --- /dev/null +++ b/2021/talks/test.md @@ -0,0 +1,62 @@ +[[!meta title="Test blocks"]] +[[!meta copyright="Copyright © 2021 Eduardo Ochs"]] +[[!inline pages="internal(2021/info/test-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Test blocks +Eduardo Ochs + +[[!inline pages="internal(2021/info/test-schedule)" raw="yes"]] + +In this presentation I will show an idea that feels completely obvious +once we see it, but that only occured to me after after using Emacs +and eev as my main interface to the computer for more than 20 years. +Take any interpreted language that supports multi-line comments, and +whose interpreter can be run in an Emacs buffer - for example Lua, +Haskell, Python, or Julia; let's say just "Lua" from here on for +simplicity. So: suppose that we have a Lua script that we wrote, that +is called "foo.lua" and that defines lots of functions and defines the +classes Bar and Bletch. We can put after the definition of the class +Bar a multi-line comment that contains an eepitch block that when +executed starts a Lua interpreter, loads the script foo.lua (by +running 'dofile "foo.lua"'), and then has several tests for that class +and its methods; and we can put another block with tests like that +after the class Bletch, and other blocks after some functions. Eepitch +allows sending these tests line by line to the Lua interpreter by +typing <f8> on each line that we want to send, and this lets us create +tests that are very easy to understand even without writing comments; +this gives us a very quick way to document code by executable tests, +that is super-great for experimental code that is still going to +change a lot before running the risk of being read by other people. + +These multi-line comments with eepitch blocks that run an interpreter +and make it load the current file are called "test blocks". The +command `M-x eeit' inserts a test block at point, using the major mode +to decide the right syntax to use for the multi-line comments and for +the "dofile". We can configure the syntax of the test blocks for the +current major mode by running `M-x find-eeit-links'; this can also be +used to add support for test blocks to more languages (or, more +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"]] + +[[!inline pages="internal(2021/info/test-nav)" raw="yes"]] diff --git a/2021/talks/ui.md b/2021/talks/ui.md new file mode 100644 index 00000000..0fbf9322 --- /dev/null +++ b/2021/talks/ui.md @@ -0,0 +1,121 @@ +[[!meta title="Yak-shaving to a UI framework"]] +[[!meta copyright="Copyright © 2021 Erik Anderson"]] +[[!inline pages="internal(2021/info/ui-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Yak-shaving to a UI framework +Erik Anderson + + + +[[!inline pages="internal(2021/info/ui-schedule)" raw="yes"]] + +[[!table header="no" class="speaker-details" data=""" +Name pronunciation: | ERR-ick ANN-dur-sun +Pronouns: | he/him +Homepage: | <https://github.com/ebpa/tui.el> +Preferred contact info: | <erik@ebpa.link> +"""]] + +Tui.el is a textual User Interface (UI) framework for Emacs Lisp +modeled after the popular JavaScript 'React' framework. This package +implements React Component API's with the goal of simplifying +development of interactive UI's for all Emacs users- regardless of +their prior experience with React or web programming. Components +provide a useful functional unit for constructing complex interfaces +declaratively and also eliminate much of the burden associated with +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 + +Pad: + +- Q1: A common issue I have with Magit status buffers is that focus + get lost easily when staging hunks since scroll gets lost during + re-render (Magit attempts at recovering). Are we getting magit-tui? + - A: It is certainly possible and compatible. + - I am interested in tui.el but haven't looked at it too closely + yet. Have been entertaining the idea of something like this for + a long time now. -- jonas (magit maintainer) +- Q2:We can update images as well?! Like SVG, or the comics you shown. + This is awesome! + - A: Yes, that's possible. +- Q3:Have you tried to display any diagram? Like UML sequence diagrams +- Q4: So does tui implement some sort of DOM model? + - A: Yes. +- Q5: How does performance compare with some other libraries, like + EWOC, magit-section, tabulated-list? e.g. to render a view with + thousands of elements (and thank you for your work on this, it's + very exciting for Emacs's future) + - A: In general EWOC and tabulated-list should perform better, and + tui still needs some optimization. TUI has the potential to be + better, but it needs some work. +- Q6: Are you planning to contribute tui.el to emacs core? + - A: Eventually, once its polished and more robust. +- Q7: What is the memory overhead like, e.g. I guess values are hashed + to detect whether items need to be re-rendered? + - A: Haven't done any memory profiling, but memory overhead could + probably be an issue. +- Q8: Awesome. Would lack of concurrency/multi-threading in Emacs be + an issue? + +BBB: + +- like in dogears.el readme +- So I'm really interested in potentially using tui for Ement.el +- 1. For the room buffers, showing events in the chat rooms. That sometimes has thousands of events, so that's why I asked about performance for that case. +- It seems like it could be very helpful for re-rendering some events when their content changes, e.g. when messages are edited, when coalescing adjacent join/leave events... +- EWOC does work for that to some extent, but I've been unable to get nested EWOCs to work correctly so far, so TUI is an interesting alternative +- yeah, EWOC uses markers too AFAIK, and it seems to perform well enough even with 2000-3000 events in a buffer +- oh yeah, your grid idea +- yes, sorting and filtering, temporarily hiding elements! +- like "show all messages from this user or mentioning that user in this room" +- and then press a key and all the others are shown again +- expanding larger images from thumbnails, captions for files, etc +- like Element.io but in Emacs with TUI, that would be great +- that's the official Matrix Web client +- Sounds great! well thanks for the presentation, I really look forward to TUI's progress! maybe someday I can help with it, in the distant future... I have too many Emacs projects already :) +- hmm, a TUI library for taxy.el... more ideas! +- TUI would be like a natural frontend for taxy.el as a backend +- are you on Matrix by any chance? +- I'm bad with email, but when I have time to check out TUI in more detail, I look forward to it! + +IRC: + +- 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 + +IRC feedback: +- I like the bird mascot on the repo readme :) +- FYI if you would want it to show at the side of the readme, you can see the Org markup I use to accomplish that in some of my readmes + + +# Outline + +- 5-10 minutes: + - Problem space: UI implementation complexity. + - API introduction: Displaying content, Components. + - Visual taste of dashboards and applications built with tui. +<!--- 20 minutes: + - (same as the above- less some visual tour, plus:) + - Introducing **state** to your UI. + - Demonstration via development of a trivial web comic reader. +- 40 minutes: + - (same as the above, plus:) + - Demonstration of developer helpers/utility functions for: + - Explanation of the reconciliation algorithm. + - More Emacsisms: Implementing a comic dashboard component. +---> + +[[!inline pages="internal(2021/captions/ui)" raw="yes"]] + +[[!inline pages="internal(2021/info/ui-nav)" raw="yes"]] diff --git a/2021/talks/unix.md b/2021/talks/unix.md new file mode 100644 index 00000000..c9a9263a --- /dev/null +++ b/2021/talks/unix.md @@ -0,0 +1,79 @@ +[[!meta title="GNU's Not UNIX: Why Emacs Demonstrates The UNIX Philosophy Isn't Always The Only Answer"]] +[[!meta copyright="Copyright © 2021 Daniel Rose"]] +[[!inline pages="internal(2021/info/unix-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# GNU's Not UNIX: Why Emacs Demonstrates The UNIX Philosophy Isn't Always The Only Answer +Daniel Rose + +[[!taglink CategoryPhilosophy]] + +[[!inline pages="internal(2021/info/unix-schedule)" raw="yes"]] + +The talk targets users who are curious about computational philosophies, +or those who might not know how to best utilise Emacs conceptually. The +talk will cover what the UNIX philosophy is, the GNU Free Software +principles, a typical (Neo)Vi(m) user's approach, and then how one might +accomplish this in Emacs combining the aformentioned ideals. The +listeners will learn how they can approach Emacs ideologically, and how +blocking themselves into one philosophy or the other will limit their +efficiency. Although you may be a veteran GNU/Linux and Emacs user, +understanding how to use both philosophies together will still allow you +to be more performant than without. + +# Discussion + +IRC nick: thecatster + +- Q: So, how do you decide when it's not "worth it" to use Emacs + for a certain thing? +- Q: What's your opinion on EAF? +- Q: What is your opinion on starter-kits and making emacs + accessible, practical for people who want to keep things simple? +- Q: Do you integrate tools via Emacs or you just jump between those? + For example, did you need to integrate your C WM somehow with Emacs? + - A: mostly via keybindings. Thanks for the answer! +- Q: Do you use Emacs for email? + - A: I do, and many more clients too. +- Q: No personal website? + - A: <https://www.danielr.xyz> +- Q:When will Emacs improve its GC and support truely multithreading? + +Feedback: + +- I really appreciate this talk's perspective! I'm very invested in living inside, Emacs, but this is also a great perspective! +- yes, nice perspective. Saying that I am struggeling with that is overstating it, but sometimes it does make me think. thank you Daniel! +- Nice talk, I feel like some Emacs purists could complain but let's be honest, this is a reasonable take on actually getting stuff done + +From [YouTube](www.youtube.com/watch?v=kXVjCRIqS4c&feature=em-comments): + +- Right on. For most of these reasons I’ve went back to Vim and just accepted it’s limitations rather than try and torture it into a Frankenstein IDE that half works. When I need to do $LANG work especially debugging, I use vs code or Xcode etc and most of the big IDEs have Vim keybinding emulation that is good enough to get to work. + +# Outline + +- How can one limit their usage of CLI tools while still maintaining + the ideals of both. +- How using CLI tools can still perfectly flow into Emacs. +- How having all programs in Emacs and unified keybindings is akin + to a terminal user. +- Why thinking about computational philosophies might itself be an + impediment. + +<!-- +- 20 minutes: + Go more in-depth about both philosophies, and how the ideas can play + off each other. Follow the same outline of the 5-10 minute version but + in more detail and with more interactivity. + +- 40 minutes: + Based on the 20 minutes format, play more off the ideas of the + audience. Interact with them more, and ask for their input and + examples that they can contribute to the conversation. Use more + examples, demonstrate my workflow. +--> + +[[!inline pages="internal(2021/captions/unix)" raw="yes"]] + +[[!inline pages="internal(2021/info/unix-nav)" raw="yes"]] diff --git a/2021/talks/world.md b/2021/talks/world.md new file mode 100644 index 00000000..e329e536 --- /dev/null +++ b/2021/talks/world.md @@ -0,0 +1,74 @@ +[[!meta title="World Citizen"]] +[[!meta copyright="Copyright © 2021 Mohsen BANAN"]] +[[!inline pages="internal(2021/info/world-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# World Citizen +Mohsen BANAN + +[[!inline pages="internal(2021/info/world-schedule)" raw="yes"]] + +Starting with Emacs 24, full native bidi +(bidirectional) support became available. For +many years prior to that Unicode support was +available and by around year 2000, reasonable +open-source shaping libraries were also available. + +With these in place at around 2012, I developed +two Persian input methods for emacs. These input +methods or variations of them can also be used +Arabic and other persoarabic scripts. + +With all of these in place, Emacs has now become +the ne plus ultra Halaal/Convivial usage +environment for persoarabic users. + +Since emacs comes loaded with everything (Gnus +for email, Bbdb for address books, XeLaTeX modes +for typesetting, org-mode for organization, spell +checkers, completions, calendar, etc.), all basic +computing and communication needs of persoarabic +users can be addressed in one place and +cohesively. + +In this talk I will demonstrate what a wonderful +environment that can be. + +- 40 minutes: (brief description/outline) + + My talk will be in two parts. + + In Part 1, I cover persian input methods. With an + emphasis on "Banan Multi-Character (Reverse) + Transliteration Persian Input Method". The + software is part of base emacs distribution. + Full documentation is available at: + Persian Input Methods + For Emacs And More Broadly Speaking + شیوههایِ درج به فارسی + <http://mohsen.1.banan.byname.net/PLPC/120036> + + In Part 2, I will cover the ramifications of bidi + on existing emacs applications, including: + + - Gnus: + - Persoarabic rich email sending in HTML. + - Ramifications of bidi on from, to and + subject lines. + + - Bbdb: Ramifications of bidi on display and + completion. + + - Calendar: + - Ramifications of bidi on display. + - Use of persian text for Persian (solar) calendar. + - Use of arabic text for Muslem (lunar) calendar. + + - AUCTeX: Persian typesetting with XeLaTeX + + +[[!inline pages="internal(2021/captions/world)" raw="yes"]] + +[[!inline pages="internal(2021/info/world-nav)" raw="yes"]] |